Re: [wpkops] Third draft charter proposal
From: Tim Moses Date: Saturday, September 15, 2012 12:00 PM To: "wpkops@ietf.org" Subject: [wpkops] Third draft charter proposal > > > 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. I think the concern is that reused mechanisms can interfere with each other, not that results are used differently. > 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. I don't understand the reference to identical behavior. I suggest the following: Additionally, a number of applications (such as client authentication, document signing, code signing, and email) use the same trust anchors and certificate processing mechanisms as used for server authentication on the Web. This reuse creates problems in some situations. 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. ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Third draft charter proposal
+1 to Stephen's comments. Also, I think the first paragraph's definition of "Web PKI" merits a bit more full definition. Various folks that aren't quite as familiar with all this may well be reading and trying to understand the charter. Suggested enhancement (first paragraph becomes two paragraphs).. ### The Web PKI is the set of systems and procedures most commonly used, in conjunction with security protocols such as TLS, to protect the 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 issued to Web application providers by Certification Authorities (CAs), the certificate validation 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 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. ### (though, this isn't critial and shouldn't hold anything up) HTH, =JeffH ___ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
Re: [wpkops] Third draft charter proposal
Thanks! > -Original Message- > From: Tim Moses [mailto:tim.mo...@entrust.com] > Sent: Monday, September 17, 2012 1:18 PM > To: Ronald Bonica > Cc: wpkops@ietf.org; 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: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 ho
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: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, documen
Re: [wpkops] Third draft charter proposal
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: 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
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
