-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/23/12 1:28 PM, Hodges, Jeff wrote: > 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.
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? >> >> 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, 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA2i5UACgkQNL8k5A2w/vwt5gCgtPPTJYdYRXA7Vte1DJXlXstP La0An3sCMSbYg9dnlhrraMWAdzlqcVDb =llow -----END PGP SIGNATURE----- _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
