Subject: Re: [wpkops] scope of addressed app technologies (was: First draft charter proposal)

From: "Hodges, Jeff" <[email-masked]>
Date: Thu, 23 Aug 2012 19:28:31 +0000

Peter SA replied:
> On 8/22/12 10:23 PM, Hill, Brad wrote:
>>> Brad, do you include the use of PKIX certificates in application 
>>> technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog,
>>> and XMPP as part of or derivative from "the Web PKI"? The
>>> proposed charter seems tightly focused on browsers and HTTPS, but
>>> (as documented in RFC 6125) there's plenty of implementation and 
>>> deployment of PKIX certificates outside that space.
>> 
>> Good questions.  They are closer cousins than the offline use
>> cases. My follow up questions would be:
>> 
>> a) Is there the same perceived need to document the "state of 
>> interop" for these uses of PKIX as there is for HTTPS?
> 
> I think there is for some of those technologies. In any case, admins
> who are requesting certificates for email or IM servers interact with
> the very same CAs as admins who are requesting certificates for web
> servers. I'd hate to see misalignment creep in because we're
> deliberately excluded everything but the web.

This begs the question of what we mean by "the web" in this discussion, and I've been 
supposing that it essentially means "https". 

I think Peter has a good point here, speaking as the other co-author on RFC6125, 
wherein we were compelled to address matching of presented identifiers (in certs) 
on behalf of various protocols (basically the list of protocols he mentions above).

However, RFC6125 is also an example of both a data-gathering descriptive document, 
as well as a subsequent prescriptive one.  This turned out to be do-able (but 
still a ton of work) because IMV we were concentrating on just one narrow piece 
of the PKI puzzle. 
 
Given that the present proposal is to be first descriptive, and then to see whether
prescriptive work is warranted, I don't think there's much risk of misalignment
in the nearer term.  

<snippage/>
>>
>> d) Does that work depend on or build directly from the HTTPS work,
>> or are there other WGs where it can be undertaken on its own
>> timeline and where the "right people" are already assembled?
> 
> I think some of the work for other application technologies is
> parallel to the HTTPS work, and some of it is downstream. We'll need
> to get down to cases and see exactly what work applies more generally
> and what work is specific to particular technologies.

Given that just doing this work for HTTPS will be tough, I'm for keeping the charter 
narrowly focused on HTTPS PKI for now, coming up with some initial drafts, and then 
as they firm up, shopping them around to the other app technology communities (aka 
working groups) to see if they have interest in doing the same for their areas of interest, 
and then consider re-chartering. 

Another way to approach this if i understand correctly is to write something like the 
above paragraph into the charter and charter schedule in order to avoid the re-chartering
step. 

HTH, 

=JeffH

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Aug 2012 13:59:17 -0600

On 8/23/12 1:28 PM, Hodges, Jeff wrote:
>>>> Brad, do you include the use of PKIX certificates in
>>>> application technologies like IMAP, LDAP, NETCONF, SIP, SMTP,
>>>> SNMP, Syslog, and XMPP as part of or derivative from "the Web
>>>> PKI"? The proposed charter seems tightly focused on browsers
>>>> and HTTPS, but (as documented in RFC 6125) there's plenty of
>>>> implementation and deployment of PKIX certificates outside
>>>> that space.
>>> 
>> I think there is for some of those technologies. In any case,
>> admins who are requesting certificates for email or IM servers
>> interact with the very same CAs as admins who are requesting
>> certificates for web servers. I'd hate to see misalignment creep
>> in because we're deliberately excluded everything but the web.
> 
> This begs the question of what we mean by "the web" in this
> discussion, and I've been supposing that it essentially means
> "https".
> 
> I think Peter has a good point here, speaking as the other
> co-author on RFC6125, wherein we were compelled to address matching
> of presented identifiers (in certs) on behalf of various protocols
> (basically the list of protocols he mentions above).
> 
> However, RFC6125 is also an example of both a data-gathering
> descriptive document, as well as a subsequent prescriptive one.
> This turned out to be do-able (but still a ton of work) because IMV
> we were concentrating on just one narrow piece of the PKI puzzle.
> 
> Given that the present proposal is to be first descriptive, and
> then to see whether prescriptive work is warranted, I don't think
> there's much risk of misalignment in the nearer term.

Jeff, I think that makes sense.

> <snippage/>
>>> 
>>> d) Does that work depend on or build directly from the HTTPS
>>> work, or are there other WGs where it can be undertaken on its
>>> own timeline and where the "right people" are already
>>> assembled?
>> 
>> parallel to the HTTPS work, and some of it is downstream. We'll
>> need to get down to cases and see exactly what work applies more
>> generally and what work is specific to particular technologies.
> 
> Given that just doing this work for HTTPS will be tough,

True. You saw how long it took us to produce RFC 6125...

> I'm for keeping the charter narrowly focused on HTTPS PKI for now,
> coming up with some initial drafts, and then as they firm up,
> shopping them around to the other app technology communities (aka 
> working groups) to see if they have interest in doing the same for
> their areas of interest, and then consider re-chartering.

Perchance. I somewhat doubt that every community will have the energy
to work on dedicated documents of a descriptive nature (and some of
those communities no longer have WGs at the IETF), but I do think that
if someone writes a more general descriptive (or, eventually,
prescriptive) document or set of documents then we would be able to
get feedback from those different communities (much as we did while
working on RFC 6125). So for now I will mostly go along with what
you've just proposed, with the proviso that I'll keep an eye on the
work here (and encourage folks from other technology communities to do
the same) so we can see where input from outside of HTTPS would be
important.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/