Hi Tim, On 08/22/2012 09:56 PM, Tim Moses wrote: > Thanks Stephen. To explain ... when I suggested a profiling activity, I had > in mind to describe the subset of PKIX that is actually used in the Web PKI > (as well as non-conformant variations). For instance, I don't believe any > publicly-trusted CAs issue delta CRLs or that any browsers use OCSP nonces. > If this is true, then it isn't recorded in any one place. I had in mind to > record those facts. And, there are - no doubt - many other features of RFC > 5280 that are not exercised in the Web PKI. Do that seem appropriate to you?
It does, yes. I think though that it'll be important for this to always be seen in context so avoiding the (mis-)perception that the goal is to re-visit PKIX will continue to be important. Perhaps avoiding the term "profiling" will help - PKIX after all was setup to profile X.509, which is not what you're after here. While doing that profiling PKIX had to invent lots of detailed rules that weren't specified in the CCITT docs but that were (thought to be) needed for interop, and its that kind of invention that we want to avoid here I think. Maybe focus on saying "document deployed PKI" as much as possible just to be clear? S > > All the best. Tim. > > -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Wednesday, August 22, 2012 4:33 PM > To: Tim Moses > Cc: '[email protected]' > Subject: Re: [wpkops] First draft charter proposal > > > Thanks Tim for that. > > I agree with Ron - that's a really good start, but does need work. > > My initial thoughts on that: > > - I think the milestone list you presented is too detailed for a charter, > especially at this point. But I'd say that can be left for now though until > the overall scope is clearer. So fix that later and let's try focus on the > scope for now. > > - I'm not sure that omitting code signing is a good plan, since the same > libraries and trust anchors are used and code-signing has been a recent > attack vector of note. Omitting document signing and email seems ok to me > though as those are much more enterprisey things, but HTTPS and code-signing > are both common on the public Internet. So I'd like to understand that better. > > - I think the putative OPS WG ought document deployed stuff as you say, but > beyond that its scope ought be explicitly limited to developing (at most) > use-cases and/or requirements for any new protocol. So I'm not at all sure > how to interpret some of the deliverables you envisage. For example, what's > the "certificate, CRL, and OCSP profile" document? If that means "invent a > new profile" then I have a problem with that. If it means "document deployed > deviations from 5280/2560" then that'd be fine I think but then it ought have > a different name. > > - As Ron said, the IETF doesn't do product evaluations but I think that's an > easy one, just include in scope documenting the behaviour of "recent" > browsers, web servers and (I guess) relevant middleboxen, so long as they > have non-trivial deployment. > > Cheers, > S. > > On 08/22/2012 01:44 PM, Tim Moses wrote: >> Colleagues - Here is a first draft of a charter proposal. Please give it >> some thought and share the results of your deliberations. Thanks a lot. >> All the best. Tim. >> >> >> The Web PKI is the set of systems and procedures most commonly used to >> protect the confidentiality, integrity and authenticity of communications >> between Web browsers and Web content servers. It first appeared in 1993 or >> thereabouts and has developed continuously in a somewhat organic fashion >> since then. Across all the suppliers and the point releases of their >> products, there are now hundreds of variations on the Web PKI in regular >> use. And this can be a source of problems both for end-users and >> certificate issuers. >> >> >> >> For end-users, there is no clear view whether certificate "problems" remain >> when they see indication of a "good" connection. For instance, in some >> browsers, a "good" indication may be displayed when a "revoked" response has >> been received and "accepted" by the user. Whereas, other browsers may >> refuse to display the contents under these circumstances. >> >> >> >> And for issuers, it can be difficult to predict what proportion of the user >> population will accept a certificate chain with certain characteristics. >> For instance, when a browser includes a nonce in an OCSP request but the >> server supplies a response that does not include the nonce, it is hard to >> know which browsers will accept and which will reject the response. >> >> >> >> Starting from the premise that more consistency in Web security behavior is >> desirable, a natural first step would be to document current and historic >> browser and server behavior. >> >> >> >> Future activities may attempt to prescribe how the Web PKI "should" work, >> and the prescription may turn out to be a proper subset of the PKIX PKI. >> However, that task is explicitly not a goal of the proposed working group. >> Instead, the group's goal is merely to describe how the Web PKI "actually" >> works in the set of browsers and servers that are in common use today. >> >> >> >> Additionally, a number of applications (other than the Web) may use the same >> trust anchors as the ones used by the Web. These applications include: >> document signing; code signing; and email. They may use PKI in a way that >> differs from the way in which the Web uses it. Therefore, these >> applications are explicitly out of scope for the working group. >> >> >> >> Also, the reliability of the Web PKI depends critically on the practices of >> its certificate issuers. However, the topic of practices is outside the >> scope of the IETF. Therefore, this will be left to other competent bodies. >> >> >> >> That there are technical shortcomings with Web PKI, as it is practiced >> today, is well recognized. And, that there is also some urgency in >> addressing these shortcomings is also well recognized. But, it is felt that >> too much haste can be counter-productive. The expectation is that the work >> of this group will bring to light, in a systematic way, aspects of the Web >> PKI that should be progressed in future working groups of the IETF's >> Security Area, and that suppliers will be willing to participate in those >> working groups and modify their products to comply with their standards. >> >> >> >> Given the urgency of the required developments and the scale of the task, it >> is agreed that adherence to the published schedule should take precedence >> over completeness of the results. The working group should focus its >> initial attention on the browser and server versions that make up the >> largest part of the desktop and mobile Web today. >> >> >> >> The output documents will all be BCP-style RFCs. >> >> >> >> 1. Agree the working group charter (1 month). >> >> 2. Catalog the products and versions to be analyzed (1 month). >> >> 3. First WG draft of "trust model" document (4 months). >> >> 4. First WG draft of "public-key submission and certificate installation" >> document (4 months). >> >> 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 >> months). >> >> 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 >> months). >> >> 7. First WG draft of "certificate re-issuance" document (4 months). >> >> 8. First WG draft of "certificate renewal" document (4 months). >> >> 9. First WG draft of "certificate revocation" document (8 months). >> >> 10. IESG submission of "trust model" document (16 months). >> >> 11. IESG submission of "public-key submission and certificate installation" >> document (16 months). >> >> 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 >> months). >> >> 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 >> months). >> >> 14. IESG submission of "certificate re-issuance" document (16 months). >> >> 15. IESG submission of "certificate renewal" document (16 months). >> >> 16. IESG submission of "certificate revocation" document (20 months) >> >> >> >> The schedule is predicated upon the group's ability to recruit a sufficient >> number of editors and engage either the relevant product experts or other >> experts willing to test the selected product configurations. >> >> >> T: +1 613 270 3183 >> >> >> >> >> _______________________________________________ >> wpkops mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/wpkops >> > _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
