Subject: [wpkops] draft 4th draft charter

From: =JeffH <[email-masked]>
Date: Fri, 19 Oct 2012 11:23:49 -0700

Hi wpkops denizens,

In an effort to help out, below is an updated draft 4th draft charter :)

I rolled in changes suggested by Stephen Farrell, Carl Wallace, and myself.

I did not alter the list of proposed deliverables -- StephenF suggested it be 
refined -- that should probably be an item for list and/or BoF discussion.

I incorp'd Carl Wallace's suggested text, but didn't add in the specific 
examples he sent in a later message -- I finessed it by just referencing his 
message.

side-by-side diff (generated via www.text-compare.com) attached.

HTH,

=JeffH

====================================================================

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 (CAs).

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 certificate 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) often use the same trust anchors and
certificate processing mechanisms as used for server authentication on the
Web.  This reuse creates problems in some 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.

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 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, though 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

====================================================================

---

From: SM <[email-masked]>
Date: Fri, 19 Oct 2012 12:15:52 -0700

Hi Jeff,
>In an effort to help out, below is an updated draft 4th draft charter :)

[snip]

>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, though without 
>sacrificing technical correctness.

What does the above gem mean?

Regards,
-sm

---

From: Tim Moses <[email-masked]>
Date: Sun, 21 Oct 2012 13:59:24 +0000

It means that schedule and accuracy take precedence over completeness.  Faced with a tough deadline appeals to correct errors will be heard, appeals to add content won't.

On 2012-10-19, at 3:28 PM, "SM" <[email-masked]> wrote:

>> 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, though without sacrificing technical correctness.
> 
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops