Tim,
Hi. Couple of comments and some editorial nits.
spt
On 11/19/12 11:56 AM, Tim Moses wrote:
Colleagues – In accordance with Ron’s instructions, this is a last call
for comments on the WPKOPS draft charter (v05), which you will find
below. The last call closes on 3 Dec 2012. Thanks a lot. All the
best. Tim.
The Web PKI is the set of systems and procedures most commonly used, in
Not sure about this one, but maybe we should add policies? to systems
and procedures - systems, policies, and procedures.
conjunction with security protocols such as TLS, to protect the
r/such as TLS/(e.g., TLS/SSL, OCSP)
confidentiality, integrity and authenticity of communications between
Web browsers and Web content servers. More specifically, the Web PKI (as
considered here) consists of the actual contents of the certificates
r/of the actual contents of the certificates/consists of fields included
in certificates
issued to Web application providers by Certification Authorities (CAs),
Is it just application providers or is it also content providers or are
they the same thing?
the certificate validation services provided by the Authorities to web
Do you mean certificate status services instead of certificate
validation services? I think you're talking about OCSP servers here so
maybe status is better and validation is usually about the whole path.
browsers and their users, and the TLS/SSL protocol stacks embedded in
web servers and browsers.
The Web PKI first appeared in 1993 or thereabouts and has developed
continuously in a somewhat organic fashion since then. Across all the
suppliers and the point releases of their products, there are now
r/suppliers/Web browsers (for consistency with the 1st para)
hundreds of variations on the Web PKI in regular use. And this can be a
r/can be/is
source of problems for end-users, certificate holders, and certificate
issuers (CAs).
For end-users, there is no clear view whether certificate "problems"
Add in here that end-users are the relying parties?
r/end-users/end-users (i.e., the relying parties)
remain when they see indication of a "good" connection. For instance,
in some browsers, a "good" indication may be displayed when a "revoked"
r/may be/is This does actually happen right ;)
response has been received and "accepted" by the user, whereas other
browsers may refuse to display the contents under these circumstances.
r/may refuse/refuse
Certificate holders may have difficulty understanding whether some
I think this is true and it sounds a little more assertive :)
r/Certificate holders may have difficulty understanding whether
some/Many certificate holders are unsure which
browser versions will reject their certificate if certain content
specifications are not met, such as a subject public key that does not
I think we should just be blunt about this bit, which is where I think
you're trying to say some people don't follow the profiles.
/content specifications/certificate profiles
satisfy a minimum key size, or a certificate policies extension that
does not contain a particular standard policy identifier.
And for certificate issuers, it can be difficult to predict what
proportion of the user population will accept a certificate chain with
When you say user population are do you mean end-users or browsers?
Maybe we should avoid it - suggestions below.
certain characteristics. For instance, when a browser includes a nonce
in an OCSP request but the server supplies a response that does not
include the nonce, it is hard to know which browsers will accept and
which will reject the response.
I'd like to make sure the point isn't lost that rejecting the OCSP
response affects the validation of the path so maybe:
And for certificate issuers, it is difficult to predict whether a
certificate chain with certain characteristics will be accepted. For
instance, some browsers includes a nonce in their OCSP requests and
expect one in responses, not all servers include a nonce in replies, and
his means some certificate chains will validate while others won't.
Starting from the premise that more consistency in Web security behavior
is desirable, a natural first step would be to document current and
r/would be/is
historic browser and server behavior, identifying, where appropriate,
specific products and specific versions of those products. But, such a
project has to be bounded. Therefore, only server-authentication
behavior encountered in more than 0.1 percent of connections made by
desktop and mobile browsers should be considered. While it is not
r/should be/is to be
intended to apply the threshold with any precision, it may be used to
r/may be/will be
justify the inclusion or exclusion of a technique.
Does the above imply that any client authentication discussions are also
out of scope? Opps never mind it's discussed later.
Future activities may attempt to prescribe how the Web PKI "should"
work, and the prescription may turn out to be a proper subset of the
PKIX PKI. However, that task is explicitly not a goal of the proposed
working group. Instead, the group's goal is merely to describe how the
Web PKI "actually" works in the set of browsers and servers that are in
common use today.
Additionally, a number of applications (such as client authentication,
document signing, code signing, and email) often use the same trust
anchors and certificate processing mechanisms as those used for server
authentication on the Web. This reuse creates problems in some
r/server authentication on the Web/Web server authentication
situations [1]. While these applications are outside the scope of this
working group, deliverables should (wherever practical within the
available expertise and time) identify mechanisms that are reused by
other applications and identify the implications of that reuse.
The effectiveness of the Web PKI depends critically upon decisions made
by its users in response to information provided in the user interfaces
of its various components. Therefore, such information should be
accurate and complete, yet comprehensible. While recording the design
details of the user interfaces of specific products is not necessary,
state changes that are visible to, and/or controlled by, the user should
be captured.
Also, the reliability of the Web PKI depends critically on the
"practices" of its certificate issuers; these practices comprise how
certificate issuers perform their functions and implement controls, and
are described in documents known as "Certification Practice Statements"
[2][3] and operational requirements documents [4][5]. However, the topic
of certification practices is outside the scope of the working group.
That there are technical shortcomings with Web PKI, as it is practiced
today, is well recognised. And, that there is also some urgency in
addressing these shortcomings is also well recognised. But, it is felt
that too much haste can be counter-productive. The expectation is that
the work of this group will bring to light, in a systematic way, aspects
of the Web PKI that should be progressed in future working groups of the
IETF's Security Area, and that suppliers will be willing to participate
r/suppliers/Web browsers and CAs
in those working groups and modify their products to comply with their
standards.
Given the urgency of the required developments and the scale of the
task, it is agreed that adherence to the published schedule should 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 "certificate, CRL, and OCSP field and extension
processing" 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 "certificate, CRL, and OCSP field and extension
processing" document (24 months).
7. IESG submission of "certificate revocation" document (20 months).
8. IESG submission of "TLS stack operation" document (16 months).
References:
[1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html
[2] Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework. S. Chokhani et al, IETF RFC3647
https://tools.ietf.org/html/rfc3647
[3] Electronic Signatures and Infrastructures (ESI); Policy requirements for
certification authorities issuing public key certificates.
ETSI TS 102 042 V2.2.1 (2011-12)
http://www.etsi.org/deliver/etsi_ts/102000_102099/102042
/02.02.01_60/ts_102042v020201p.pdf
[4] Network and certificate system security requirements, CA/Browser Forum,
Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf
[5] Baseline Requirements for the Issuance and Management of
Publicly-Trusted
Certificates Version 1.0, CA/Browser Forum, Nov 2011,
https://www.cabforum.org/Baseline_Requirements_V1.pdf
T: +1 613 270 3183
_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops
_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops
