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 _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
