Thanks!
> -----Original Message----- > From: Tim Moses [mailto:[email protected]] > Sent: Monday, September 17, 2012 1:18 PM > To: Ronald Bonica > Cc: [email protected]; Stephen Farrell > Subject: RE: [wpkops] Third draft charter proposal > > 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:[email protected]] > Sent: Monday, September 17, 2012 11:49 AM > To: Stephen Farrell; Tim Moses > Cc: [email protected] > 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: [email protected] [mailto:[email protected]] On > > Behalf Of Stephen Farrell > > Sent: Saturday, September 15, 2012 1:35 PM > > To: Tim Moses > > Cc: [email protected] > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/wpkops > > > > > _______________________________________________ > > wpkops mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/wpkops _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
