Hi Ron. I have written up a BoF proposal/application and it is with Steve Hanna for his consideration. I'll forward it to you as soon as I hear back from Steve. All the best. Tim.
-----Original Message----- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Monday, September 17, 2012 11:49 AM To: Stephen Farrell; Tim Moses Cc: wpkops@ietf.org Subject: RE: [wpkops] Third draft charter proposal Folks, On September 26, the IAB and IESG will review BoF proposals. Would it be OK if I included this version of the charter proposal in the BoF proposal? Ron > -----Original Message----- > From: wpkops-boun...@ietf.org [mailto:wpkops-boun...@ietf.org] On > Behalf Of Stephen Farrell > Sent: Saturday, September 15, 2012 1:35 PM > To: Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Third draft charter proposal > > > Hi Tim, > > That looks pretty good to me. Some comments below. > > On 09/15/2012 05:00 PM, Tim Moses wrote: > > Colleagues - Here is a third draft of the WPKOPS charter proposal. > It attempts to accommodate comments received on the second draft. > > > > The other major change is that I have deleted the proposal for a > draft on communications between the certificate-holder and the > certificate issuer. This was included originally to ensure that we > didn't lose sight of the role of the Web server in the "stapling" > process. But, I think this can be dealt with in the "certificate > revocation" document. > > > > Equally to the point, I have received commitments from individuals > > to > act as the primary editors for the remaining documents. Rick Andrews > from Symantec with Scott Rea and Ben Wilson from DigiCert have offered > to tackle certificate revocation, Ben Wilson and colleagues from > DigiCert have offered to tackle the behavior of the certificate using > product, and Adam Langley of Google has volunteered to edit the draft > on TLS stack operation. > > > > I am looking for others to volunteer to assist in an editing role. > Please let me know as soon as you possibly can and I'll put you in > touch with the editors that have already been identified. > > > > 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 > for end-users, certificate holders, 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. > > > > Certificate holders may have difficulty understanding whether some > browser versions will reject their certificate if certain content > specifications 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. > > > > 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. But, such a project > has to be bounded. Therefore, only server-authentication behavior > encountered in more than 0.1 percent of connections made by desktop > and mobile browsers should be considered. While it is not intended to > apply the threshold with any precision, it may be used to justify the > inclusion or exclusion of a technique. > > > > 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 (such as client > authentication, document signing, code signing, and email) may use the > same trust anchors and certificate-handling libraries as the ones used > for server authentication on the Web. Nevertheless, they may use the > results in a way that is visibly different from the way in which they > are used for server authentication. While these applications are > considered outside the scope of this working group, deliverables > should (wherever practical within the available expertise and time) > identify other applications that exhibit identical behavior and > identify the implications of that behavior where they differ from > those for server authentication. > > > > Also, the reliability of the Web PKI depends critically on the > practices of its certificate issuers; practices such as: how the > contents of certificate applications are verified and how access (both > direct and indirect) to the CA's private key is controlled. However, > the topic of practices is considered outside the scope of the working > group. > > I think that last sentence is problematically ambiguous. I suspect > that the term "practice" has evolved into something well defined for > CAB forum members but I don't think its well understood in the IETF. > If you don't make this more precise, in terms understood in the IETF > context, I suspect the WG might have recurring friction about what is > or is not in scope. > > Some examples of what's in/out of scope might help the discussion here > I reckon. > > > This topic will be left to other competent bodies, such as the > CA/Browser Forum [1][2]. > > I think that sentence wouldn't be needed if the previous one were well > enough defined. I also think that since CAB forum's constitution is in > flux it'd be better to just not mention it in the charter. > > > > > 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. > > I sympathise with that, but it needs to be understood (e.g. by folks > new to the IETF) that the usual IETF processes do apply and the WG > doesn't get to override those. That means that technically correct and > relevant comments can be a showstopper at any point for example. I > don't know if that needs different text, but it needs to be understood. > > > Milestones > > ========== > > I think these deliverables need to be better characterised in the text > above, e.g. its not clear that the "trust model" document is meant > only to document the existing trust model(s) that are in use in > non-trivial deployments. > > I'm also not sure if this is the right structure for the set of > documents you want to produce, e.g. whether or not its better to > separate trust models from the processing of e.g. issuer, subject and > SPKI fields, nor whether it makes sense to discuss OCSP in one > document but revocation in another. > > So I think a bit more discussion on that is needed. > > Cheers, > S. > > > > > 1. First WG draft of "trust model" document (4 months). > > 2. First WG draft of "certificate, CRL, and OCSP field and > extension processing" 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 "certificate, CRL, and OCSP field and > extension processing" document (24 months). > > 7. IESG submission of "certificate revocation" document (20 > months). > > 8. IESG submission of "TLS stack operation" document (16 months). > > > > > > References: > > > > [1] Network and certificate system security requirements, > CA/Browser Forum, Aug 2012, > https://www.cabforum.org/Network_Security_Controls_V1.pdf > > > > [2] Baseline Requirements for the Issuance and Management of > Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, > https://www.cabforum.org/Baseline_Requirements_V1.pdf > > > > > > > > > > T: +1 613 270 3183 > > > > > > > > > > _______________________________________________ > > wpkops mailing list > > wpkops@ietf.org > > https://www.ietf.org/mailman/listinfo/wpkops > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops