* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Wpkops Status Pages

Web PKI OPS (Concluded WG)
Ops Area: Robert Wilton, Warren Kumari | 2013-Apr-11 — 2015-May-22 
Chairs
 
 


2013-11-12 charter

Web PKI OPS (wpkops)
--------------------

 Charter

 Current Status: Active

 Chairs:
     Tim Moses <tim.moses@entrust.com>
     Jeremy Rowley <jeremy.rowley@digicert.com>

 Operations and Management Area Directors:
     Benoit Claise <bclaise@cisco.com>
     Joel Jaeggli <joelja@bogus.com>

 Operations and Management Area Advisor:
     Joel Jaeggli <joelja@bogus.com>

 Mailing Lists:
     General Discussion: wpkops@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/wpkops
     Archive:            http://www.ietf.org/mail-archive/web/wpkops/

Description of Working Group:

  The Web Public Key Infrastructure (PKI) is the set of systems,
  policies, and procedures used to protect the confidentiality,
  integrity, and authenticity of communications between Web
  browsers and Web content servers.  The Web PKI is used in
  conjunction with security protocols such as TLS/SSL and OCSP.

  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 Operations (wpkops) working group will work to
  improve the consistency of Web security behavior.  It will
  address the problems caused by the many hundreds of variations
  of the Web PKI currently in use:

  - For end-users (i.e. relying parties), there is no clear view
    of whether certificate "problems" remain once they see an
    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.

  - Certificate issuers (i.e., CAs) find it 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.

  The working group's goal is to describe how the Web PKI
  "actually" works in the set of browsers and servers that are in
  common use today.  To that end, the working group will document
  current and historic browser and server behavior.  For each
  this will include:

  - The trust model on which it is based;
  - The contents and processing of fields and extensions;
  - The processing of the various revocation schemes;
  - How the TLS stack deals with PKI, including varying
    interpretations and implementation errors, as well as state
    changes visible to the user.
  - The state changes that are visible to and/or controlled by
    the user (to help predict the decisions that will be made the
    users and so determine the effectiveness of the Web PKI).
  - Identification of when Web PKI mechanisms are reused by other
    applications and implications of that reuse.

  Where appropriate, specific products and specific versions of
  those products will be identified, but recording the design
  details of the user interfaces of specific products is not
  necessary.

  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.

  A number of activities are outside the immedaiate scope of this
  working group, but might be considered in future re-chartering
  activity or included in the work of other working groups:

  - The working group will not work to describe how thw Web PKI
    "should work.
  - The working group will not examine the certification
    practices of certificate issuers.
  - The working group will not investigate applications (such as
    client authentication, document signing, code signing, and
    email) that often use the same trust anchors and certificate
    processing mechanisms as those used for Web server
    authentication.

  Given the urgency of the required developments and the scale of
  the task, it is agreed that adherence to the published
  milestones will take precedence over completeness of the
  results, without sacrificing technical correctness.

Goals and Milestones:
  Jun 2013 - First WG draft of 'trust model' document
  Oct 2013 - First WG draft of 'certificate revocation' document
  Oct 2013 - First WG draft of 'TLS stack operation' document
  Feb 2014 - First WG draft of 'field and extension processing for certificates, CRLs, and OCSP responses' document
  Jun 2014 - IESG submission of 'trust model' document
  Jun 2014 - IESG submission of 'TLS stack operation' document
  Oct 2014 - IESG submission of 'certificate revocation' document
  Feb 2015 - IESG submission of 'field and extension processing for  certificates, CRLs, and OCSP responses'


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/wpkops/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -