Thanks Sean. I'll incorporate these into the next version. All the best. Tim.
On 2012-11-20, at 11:15 AM, "Sean Turner" <[email protected]> wrote: > Tim, > > Hi. Couple of comments and some editorial nits. > > spt > > On 11/19/12 11:56 AM, Tim Moses wrote: >> Colleagues – In accordance with Ron’s instructions, this is a last call >> for comments on the WPKOPS draft charter (v05), which you will find >> below. The last call closes on 3 Dec 2012. Thanks a lot. All the >> best. Tim. >> >> The Web PKI is the set of systems and procedures most commonly used, in > > Not sure about this one, but maybe we should add policies? to systems and > procedures - systems, policies, and procedures. > >> conjunction with security protocols such as TLS, to protect the > > r/such as TLS/(e.g., TLS/SSL, OCSP) > >> confidentiality, integrity and authenticity of communications between >> Web browsers and Web content servers. More specifically, the Web PKI (as >> considered here) consists of the actual contents of the certificates > > r/of the actual contents of the certificates/consists of fields included in > certificates > >> issued to Web application providers by Certification Authorities (CAs), > > Is it just application providers or is it also content providers or are they > the same thing? > >> the certificate validation services provided by the Authorities to web > > Do you mean certificate status services instead of certificate validation > services? I think you're talking about OCSP servers here so maybe status is > better and validation is usually about the whole path. > >> browsers and their users, and the TLS/SSL protocol stacks embedded in >> web servers and browsers. >> >> The Web PKI 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 > > r/suppliers/Web browsers (for consistency with the 1st para) > >> hundreds of variations on the Web PKI in regular use. And this can be a > > r/can be/is > >> source of problems for end-users, certificate holders, and certificate >> issuers (CAs). >> >> For end-users, there is no clear view whether certificate "problems" > > Add in here that end-users are the relying parties? > r/end-users/end-users (i.e., the relying parties) > >> remain when they see indication of a "good" connection. For instance, >> in some browsers, a "good" indication may be displayed when a "revoked" > > r/may be/is This does actually happen right ;) > >> response has been received and "accepted" by the user, whereas other >> browsers may refuse to display the contents under these circumstances. > > r/may refuse/refuse > >> >> Certificate holders may have difficulty understanding whether some > > I think this is true and it sounds a little more assertive :) > > r/Certificate holders may have difficulty understanding whether some/Many > certificate holders are unsure which > >> browser versions will reject their certificate if certain content >> specifications are not met, such as a subject public key that does not > > I think we should just be blunt about this bit, which is where I think you're > trying to say some people don't follow the profiles. > > /content specifications/certificate profiles > >> satisfy a minimum key size, or a certificate policies extension that >> does not contain a particular standard policy identifier. >> >> And for certificate issuers, it can be difficult to predict what >> proportion of the user population will accept a certificate chain with > > When you say user population are do you mean end-users or browsers? Maybe we > should avoid it - suggestions below. > >> 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. > > I'd like to make sure the point isn't lost that rejecting the OCSP response > affects the validation of the path so maybe: > > And for certificate issuers, it is difficult to predict whether a certificate > chain with certain characteristics will be accepted. For instance, some > browsers includes a nonce in their OCSP requests and expect one in responses, > not all servers include a nonce in replies, and his means some certificate > chains will validate while others won't. > >> Starting from the premise that more consistency in Web security behavior >> is desirable, a natural first step would be to document current and > > r/would be/is > >> historic browser and server behavior, identifying, where appropriate, >> specific products and specific versions of those products. 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 > > r/should be/is to be > >> intended to apply the threshold with any precision, it may be used to > > r/may be/will be > >> justify the inclusion or exclusion of a technique. > > Does the above imply that any client authentication discussions are also out > of scope? Opps never mind it's discussed later. > >> 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) often use the same trust >> anchors and certificate processing mechanisms as those used for server >> authentication on the Web. This reuse creates problems in some > > r/server authentication on the Web/Web server authentication > >> situations [1]. While these applications are outside the scope of this >> working group, deliverables should (wherever practical within the >> available expertise and time) identify mechanisms that are reused by >> other applications and identify the implications of that reuse. >> >> The effectiveness of the Web PKI depends critically upon decisions made >> by its users in response to information provided in the user interfaces >> of its various components. Therefore, such information should be >> accurate and complete, yet comprehensible. While recording the design >> details of the user interfaces of specific products is not necessary, >> state changes that are visible to, and/or controlled by, the user should >> be captured. >> >> Also, the reliability of the Web PKI depends critically on the >> "practices" of its certificate issuers; these practices comprise how >> certificate issuers perform their functions and implement controls, and >> are described in documents known as "Certification Practice Statements" >> [2][3] and operational requirements documents [4][5]. However, the topic >> of certification practices is outside the scope of the working group. >> >> That there are technical shortcomings with Web PKI, as it is practiced >> today, is well recognised. And, that there is also some urgency in >> addressing these shortcomings is also well recognised. 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 > > r/suppliers/Web browsers and CAs > >> 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, without sacrificing >> technical correctness. >> >> Milestones >> >> ========== >> >> 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] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html >> >> [2] Internet X.509 Public Key Infrastructure Certificate Policy and >> >> Certification Practices Framework. S. Chokhani et al, IETF RFC3647 >> >> https://tools.ietf.org/html/rfc3647 >> >> [3] Electronic Signatures and Infrastructures (ESI); Policy requirements for >> >> certification authorities issuing public key certificates. >> >> ETSI TS 102 042 V2.2.1 (2011-12) >> >> http://www.etsi.org/deliver/etsi_ts/102000_102099/102042 >> >> /02.02.01_60/ts_102042v020201p.pdf >> >> [4] Network and certificate system security requirements, CA/Browser Forum, >> >> Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf >> >> [5] 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
