[secdir] [new-work] REVISED WG Review: Web PKI OPS (wpkops)

[IESG Secretary <[e-mail]>]

A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2013-02-19.

Web PKI OPS (wpkops)
------------------------------------------------
Current Status: Proposed Working Group

Chairs:
  Tim Moses <[e-mail]>

Assigned Area Director:
  Ronald Bonica <[e-mail]>

Mailing list
  Address: [e-mail]
  To Subscribe: https://www.ietf.org/mailman/listinfo/wpkops
  Archive: http://www.ietf.org/mail-archive/web/wpkops/

Charter of Working Group:

The Web PKI is the set of systems, policies and procedures most
commonly used, in conjunction with security protocols (e.g.
TLS/SSL and OCSP), 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 fields included in the certificates issued
to Web content and application providers by Certification
Authorities (CAs), the certificate status 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. 
Taking into account all the versions of Web servers and browsers
that have been released in the intervening years, there are now
hundreds of variations on the Web PKI in regular use.  And this
is a source of problems for end-users, certificate holders, and
certificate issuers (CAs).

For end-users (i.e. relying parties), 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 is displayed when a "revoked" response has been
received and "accepted" by the user, whereas other browsers
refuse to display the contents under these circumstances.

Many certificate holders are unsure which browser versions will
reject their certificate if certain certificate profiles 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 is difficult to predict whether a
certificate chain with certain characteristics will be accepted. 
For instance, some browsers include a nonce in their OCSP
requests and expect one in the corresponding responses, not all
servers include a nonce in their replies, and this 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 is to document
current and historic browser and server behavior, including: the
trust model on which they are based; the contents and processing
of fields and extensions; the processing of the various
revocation schemes; and how the TLS stack deals with PKI,
including varying interpretations and implementation errors, as
well as state changes visible to the user.  Where appropriate,
specific products and specific versions of those products will be
identified.

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.

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 is to
be considered.  While it is not intended to apply the threshold
with any precision, it will 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 those used for Web server authentication.  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 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 Web servers, browsers and CAs 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, without
sacrificing technical correctness.

Milestones
==========
1.    First WG draft of "trust model" document (4 months).

2.    First WG draft of "field and extension processing for
certificates, CRLs, and OCSP responses" 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 "field and extension processing for
certificates, CRLs, and OCSP responses" 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


Milestones:


_______________________________________________
new-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work