Fwd: WG Action: Formed Web PKI OPS (wpkops)

fyi
-- 
Thomas Roessler, W3C <tlr@w3.org> (@roessler)



Begin forwarded message:

> From: The IESG <iesg-secretary@ietf.org>
> Subject: WG Action: Formed Web PKI OPS (wpkops)
> Date: February 26, 2013 18:58:52 +0100
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: wpkops WG <wpkops@ietf.org>
> 
> A new IETF working group has been formed in the Operations and Management
> Area. For additional information please contact the Area Directors or the
> WG Chairs.
> 
> Web PKI OPS (wpkops)
> ------------------------------------------------
> Current Status: Proposed Working Group
> 
> Chairs:
>  Sharon Boeyen <boeyen@entrust.com>
>  Tim Moses <tim.moses@entrust.com>
> 
> Assigned Area Director:
>  Ronald Bonica <rbonica@juniper.net>
> 
> Mailing list
>  Address: wpkops@ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/wpkops
>  Archive: http://www.ietf.org/mail-archive/web/wpkops/
> 
> Charter 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.
> 
> 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'
> 
> 
>

Received on Tuesday, 26 February 2013 18:02:46 UTC