I've no very strong opinion myself about what's right for this aspect of the scope of the proposed work.
But I do think the scope in terms of applications needs to be clear and whatever scope is chosen needs a good justification. (When I say "applications," I mean the set of applications that are dependent on the in-scope aspects of PKI, not that this WG would be saying how HTTPS or S/MIME should work.) Tim's initial text is clear, but I don't get the justification for that choice, should it be the one that ends up being made. In particular, I don't get why code-signing is called out of scope. S On 08/22/2012 10:27 PM, Hill, Brad wrote: > I agree with Tim that we should start with a narrow scope focused on the Web > PKI rather than documents, etc., I also think there are cases that are on > the edge - like the programmatic HTTP clients used by mobile aps, embedded > browsing contexts with different PKI error handling logic than standalone > ones, and, towards the more complex end, web services that use HTTP and the > web PKI explicitly but might also use other transports and trust models. Not > clear from the draft charter where to draw the line among these, but there is > plenty of work to do and that needs doing urgently. > > Brad Hill > > From: [email protected] [mailto:[email protected]] On Behalf Of > Tim Moses > Sent: Wednesday, August 22, 2012 5:45 AM > To: '[email protected]' > Subject: [wpkops] First draft charter proposal > > 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
