Subject: [wpkops] Second draft charter proposal

From: Tim Moses <[email-masked]>
Date: Thu, 30 Aug 2012 15:41:54 +0000

Colleagues - I have updated the proposed charter to reflect the discussion (see below).  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 both for end-users 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.

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 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 document signing, code signing, and email) may use the same trust anchors and certificate-handling libraries as the ones used by the Web.  Nevertheless, they may use the results in a way that is visibly different from the way in which the Web uses them.  Therefore, these applications are explicitly out of scope for the working group.

Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers.  However, the topic of practices is outside the scope of the IETF.  Therefore, this will be left to other competent bodies.

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 "Web-server / CA communications" document (4 months).

4.    First WG draft of "certificate revocation" document (8 months).

5.    First WG draft of "TLS stack operation" document (8 months).

6.    IESG submission of "trust model" document (16 months).

7.    IESG submission of "certificate, CRL, and OCSP field and extension processing" document (24 months).

8.    IESG submission of "Web-server / CA communications" document (16 months).

9.    IESG submission of "certificate revocation" document (20 months).

10. IESG submission of "TLS stack operation" document (16 months).

T: +1 613 270 3183

---

From: Carl Wallace <[email-masked]>
Date: Thu, 30 Aug 2012 12:18:12 -0400

InlineŠ

From:  Tim Moses <[email-masked]>
Date:  Thursday, August 30, 2012 11:41 AM
To:  "[email-masked]" <[email-masked]>
Subject:  [wpkops] Second draft charter proposal

>Colleagues 
> I have updated the proposed charter to reflect the discussion (see
>below).  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 both for end-users
> 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.
>
>
>
> 
>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.
>
>
>

Is client authentication processing performed by web servers in scope?  If
not, explicitly push that out of scope.

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

Why are so many words quoted here and in the second paragraph?

>
> 
>Additionally, a number of applications (such as document signing, code
>signing, and email) may use the same trust anchors and
>certificate-handling libraries as the ones used by the Web.
>Nevertheless, they may use the results in a way that
> is visibly different from the way in which the Web uses them.
>Therefore, these applications are explicitly out of scope for the working
>group.
>
>
>

I'd like to see the charter include identification of overlap between the
Web PKI and other applications as in scope.  As written, it's not clear
this information will be captured.  Any BCP resulting from this effort
can't ignore impact on other applications (even if those applications are
not in scope for this effort).

>
> 
>Also, the reliability of the Web PKI depends critically on the practices
>of its certificate issuers.  However, the topic of practices is outside
>the scope of the IETF.  Therefore, this will be left to other competent
>bodies.
> 
>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 "Web-server / CA communications" document (4 months).
>4.   
>First WG draft of "certificate revocation" document (8 months).
>5.   
>First WG draft of "TLS stack operation" document (8 months).
>6.   
>IESG submission of "trust model" document (16 months).
>7.   
>IESG submission of "certificate, CRL, and OCSP field and extension
>processing" document (24 months).
>8.   
>IESG submission of "Web-server / CA communications" document (16 months).
>9.   
>IESG submission of "certificate revocation" document (20 months).
>10.IESG submission of "TLS stack operation" document (16 months).
> 
> 
> 
>T: +1 613 270 3183
> 
>
>
>
>_______________________________________________
>wpkops mailing list
>[email-masked]://www.ietf.org/mailman/listinfo/wpkops

---

From: Jon Callas <[email-masked]>
Date: Thu, 30 Aug 2012 09:28:36 -0700

> not, explicitly push that out of scope.

It would be nice if it were in scope. Client authorization is a vastly under-used feature. 

I wouldn't want to endanger everything else over it, but if we keep sweeping it under the rug, it will continue to languish.

	Jon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Aug 2012 12:28:43 -0400

> 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 i…

This is stated as a concern primarily for issuers, but it is arguably
more of a concer for certificate holders than for issuers, if i'm
reading it correctly.

There are 4 parties involved in web pki fwict:

 * web clients (mostly the users of web browsers, as far as i can make
out in this proposaL)

 * certificate issuers

 * software developers and vendors

 * certificate holders

The charter proposal here speaks directly to the first three categories,
but doesn't seem to explicitly address the last category.  Is it worth
mentioning them explicitly?

Also, i wonder about the scoping of web clients specifically to the
users of browsers.  While this is convenient for discussion, web
protocols are used heavily as transport backends and automated contexts
as well.  For example, HTTPS is required for CALDAV; it's used by many
RSS feedreaders; and it's used as a backend transport for federated
messaging systems.

Currently, i think the clarification about "other applications are
explicitly out of scope" a bit ambiguous, because it's not clear where
to draw the line between, say, S/MIME e-mail certificates (clearly out
of scope) and a human in front of a web browser (clearly in-scope).

should that line be more clearly drawn?

Regards,

	--dkg

---

From: Carl Wallace <[email-masked]>
Date: Thu, 30 Aug 2012 12:31:07 -0400

On 8/30/12 12:28 PM, "Jon Callas" <[email-masked]> wrote:

>I wouldn't want to endanger everything else over it, but if we keep
>sweeping it under the rug, it will continue to languish.

I agree and would like to see it stay in scope as well.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 30 Aug 2012 18:50:02 +0200

> I agree and would like to see it stay in scope as well.

I'm not sure what client authorization and WebPKI has in common.
Are you rather to for for example TLS client-certificate-authentication?

Anders

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

---

From: Tim Moses <[email-masked]>
Date: Fri, 31 Aug 2012 15:52:17 +0000

All - I have no fundamental objection to expanding the scope in the ways suggested.

It's true that the original idea was to limit the scope to server-auth to Web browsers.  That's because vulnerabilities have been demonstrated and the impact can clearly be severe.  Do those conditions exist for client-auth and CalDAV?  If not, I might assign them lower priority.

On the other hand, if they impact the workload by no more than (say) 10%, why wouldn't we include them?

I think it's important to remember that increased workload must be borne not just by the editors but also by the reviewers (every subscriber to the mail-list).

All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, August 30, 2012 12:31 PM
To: Jon Callas; [email-masked]
Subject: Re: [wpkops] Second draft charter proposal

On 8/30/12 12:28 PM, "Jon Callas" <[email-masked]> wrote:

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