Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Thomas Roessler
fyi
--
Thomas Roessler, W3C <[hidden email]> (@roessler)



Begin forwarded message:

> From: The IESG <[hidden email]>
> Subject: WG Action: Formed Web PKI OPS (wpkops)
> Date: February 26, 2013 18:58:52 +0100
> To: IETF-Announce <[hidden email]>
> Cc: wpkops WG <[hidden email]>
>
> 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 <[hidden email]>
>  Tim Moses <[hidden email]>
>
> Assigned Area Director:
>  Ronald Bonica <[hidden email]>
>
> Mailing list
>  Address: [hidden email]
>  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'
>
>
>


Loading...