Subject: [wpkops] Third draft charter proposal

From: Tim Moses <[email-masked]>
Date: Sat, 15 Sep 2012 16:00:11 +0000

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.  This topic will be left to other competent bodies, such as the CA/Browser Forum [1][2].

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.

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]   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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Sep 2012 18:35:27 +0100

Hi Tim,

That looks pretty good to me. Some comments below.

On 09/15/2012 05:00 PM, Tim Moses wrote:
> 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.

> 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.

> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 17 Sep 2012 11:48:38 -0400

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-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Farrell
> Sent: Saturday, September 15, 2012 1:35 PM
> To: Tim Moses
> Cc: [email-masked]
> Subject: Re: [wpkops] Third draft charter proposal
> 
> 
> Hi Tim,
> 
> > 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.
> >
> > 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.
> 
> 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.
> 
> > 2.    First WG draft of "certificate, CRL, and OCSP field and
> extension processing" document (12 months).
> > 6.    IESG submission of "certificate, CRL, and OCSP field and
> extension processing" document (24 months).
> > [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
> >
> >
> >
> >

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Sep 2012 18:10:49 +0100

While I have comments on this version, I personally
think its almost-baked so should be fine for the BoF
approval call.

S

---

From: Tim Moses <[email-masked]>
Date: Mon, 17 Sep 2012 17:18:14 +0000

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-masked]] 
Sent: Monday, September 17, 2012 11:49 AM
To: Stephen Farrell; Tim Moses
Cc: [email-masked]
Subject: RE: [wpkops] Third draft charter proposal

Folks,

                                          Ron

> the nonce, it is hard to know which browsers will accept and which 
> will reject the response.
> >
> encountered in more than 0.1 percent of connections made by desktop 
> and mobile browsers should be considered.  While it is not intended to 
> 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.
> >
> 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 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.
> 
> urgency in addressing these shortcomings is also well recognized.  
> But, it is felt that too much haste can be counter-productive.  The 
> will be willing to participate in those working groups and modify 
> their products to comply with their standards.
> >
> task, it is agreed that adherence to the published schedule should 
> take precedence over completeness of the results.
> 
> 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.
> 
> SPKI fields, nor whether it makes sense to discuss OCSP in one

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 17 Sep 2012 14:34:36 -0400

Thanks!

> From: Tim Moses [mailto:[email-masked]]
> Sent: Monday, September 17, 2012 1:18 PM
> To: Ronald Bonica
> Cc: [email-masked]; Stephen Farrell
> 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.
> 
> 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
> 
> 
> in