From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: wpkops WG <wpkops@ietf.org>
Subject: REVISED WG Review: Web PKI OPS (wpkops)
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-20.
Web PKI OPS (wpkops)
------------------------------------------------
Current Status: Proposed Working Group
Chairs:
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
==========
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).
Milestones:
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: wpkops WG <wpkops@ietf.org>
Subject: WG Action: Formed Web PKI OPS (wpkops)
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'
Ballot announcement
Ballot Announcement
Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?
Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are <TO BE ADDED BY THE AD>.'
RFC Editor Note
(Insert RFC Editor Note here or remove section)
IRTF Note
(Insert IRTF Note here or remove section)
IESG Note
(Insert IESG Note here or remove section)
IANA Note
(Insert IANA Note here or remove section)