While I have comments on this version, I personally think its almost-baked so should be fine for the BoF approval call.
S On 09/17/2012 04:48 PM, Ronald Bonica wrote: > 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 > > _______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
