Folks, Adrian Farrel has posted a blocking objection to the proposed WPKOPS charter and offered alternative text (attached). IMHO, the text that Adrian proposes does not in any way change the WG's charter.
Does anyone object to using Adrian's alternative text? Ron > -----Original Message----- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Wednesday, January 30, 2013 12:47 PM > To: Ronald Bonica; 'The IESG' > Subject: RE: Adrian Farrel's Block on charter-ietf-wpkops-00-01: (with > BLOCK) > > Alright Ron, > > How does the attached look? I believe I have captured all of the WG > actions, and all of the out of scope items. > > But I have also tried to remove a lot of the explanation and history. I > can believe this is interesting, but not that it belongs in the > charter. > > If it is no good, throw it out and I will probably Noobj the charter > (given the "urgency" :-) > > A > > > -----Original Message----- > > From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf > > Of Ronald Bonica > > Sent: 30 January 2013 15:12 > > To: Adrian Farrel; The IESG > > Subject: RE: Adrian Farrel's Block on charter-ietf-wpkops-00-01: > (with > > BLOCK) > > > > Adrian, > > > > The two paragraphs below, taken from the charter, tell you what the > WG will do: > > > > "Starting from the premise that more consistency in Web security > > behavior is desirable, a natural first step is to document current > and > > historic browser and server behavior, including: the trust model on > > which they are based; the contents and processing of fields and > > extensions; the processing of the various revocation schemes; and how > > the TLS stack deals with PKI, including varying interpretations and > > implementation errors, as well as state changes visible to the user. > > Where appropriate, specific products and specific versions of those > > products will be identified." > > > > "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." > > > > I wouldn't fault the authors for providing "reams of background > text". > > When crafting this text, they were very aware of the fact that the > > were writing to an audience that had no background in the area. > > > > If you want to take a crack at wordsmithing the charter, go for it. > > > > Ron > > > > > > > > > -----Original Message----- > > > From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On > Behalf > > > Of Adrian Farrel > > > Sent: Wednesday, January 30, 2013 9:37 AM > > > To: The IESG > > > Subject: Adrian Farrel's Block on charter-ietf-wpkops-00-01: (with > > > BLOCK) > > > > > > Adrian Farrel has entered the following ballot position for > > > charter-ietf-wpkops-00-01: Block > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > - > > > -- > > > BLOCK: > > > ------------------------------------------------------------------- > - > > > -- > > > > > > Look, I am in favor of forming this working group, but this is a > > > really awful draft charter! Far too much waffle, and far too little > > > about what the WG will actually do. > > > > > > I could have a stab at rewriting, but I doubt I know wnough about > > > the topic to make a good job. > > > > > > Can someone tell me that the reams of text are actually needed, or > > > can someone please take an axe to it. > > > > > > > > > > > >
The Web Public Key Infrastructure (PKI) is the set of systems, policies, and procedures used to protect the confidentiality, integrity, and authenticity of communications between Web browsers and Web content servers. The Web PKI is used in conjunction with security protocols such as TLS/SSL and OCSP. More specifically, the Web PKI (as considered here) consists of the fields included in the certificates issued to Web content and application providers by Certification Authorities (CAs), the certificate status services provided by the Authorities to Web browsers and their users, and the TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI Operations (wpkops) working group will work to improve the consistency of Web security behavior. It will address the problems caused by the many hundreds of variations of the Web PKI currently in use: - For end-users (i.e. relying parties), there is no clear view of whether certificate "problems" remain once they see an indication of a "good" connection. For instance, in some browsers, a "good" indication is displayed when a "revoked" response has been received and "accepted" by the user, whereas other browsers refuse to display the contents under these circumstances. - Many certificate holders are unsure which browser versions will reject their certificate if certain certificate profiles are not met, such as a subject public key that does not satisfy a minimum key size, or a certificate policies extension that does not contain a particular standard policy identifier. - Certificate issuers (i.e., CAs) find it difficult to predict whether a certificate chain with certain characteristics will be accepted. For instance, some browsers include a nonce in their OCSP requests and expect one in the corresponding responses, not all servers include a nonce in their replies, and this means some certificate chains will validate while others won't. The working group's goal is to describe how the Web PKI "actually" works in the set of browsers and servers that are in common use today. To that end, the working group will document current and historic browser and server behavior. For each this will include: - The trust model on which it is based; - The contents and processing of fields and extensions; - The processing of the various revocation schemes; - How the TLS stack deals with PKI, including varying interpretations and implementation errors, as well as state changes visible to the user. - The state changes that are visible to and/or controlled by the user (to help predict the decisions that will be made the users and so determine the effectiveness of the Web PKI). - Identification of when Web PKI mechanisms are reused by other applications and implications of that reuse. Where appropriate, specific products and specific versions of those products will be identified, but recording the design details of the user interfaces of specific products is not necessary. Only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers is to be considered. While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion of a technique. A number of activities are outside the immedaiate scope of this working group, but might be considered in future re-chartering activity or included in the work of other working groups: - The working group will not work to describe how thw Web PKI "should work. - The working group will not examine the certification practices of certificate issuers. - The working group will not investigate applications (such as client authentication, document signing, code signing, and email) that often use the same trust anchors and certificate processing mechanisms as those used for Web server authentication. Given the urgency of the required developments and the scale of the task, it is agreed that adherence to the published milestones will take precedence over completeness of the results, without sacrificing technical correctness. Milestones ========== 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "field and extension processing for certificates, CRLs, and OCSP responses" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "field and extension processing for certificates, CRLs, and OCSP responses" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months).
_______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops