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
> 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
> - 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
> 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
> 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.
> 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'
|Free forum by Nabble||Edit this page|