Though we've been through each of these points before responses are inline...
From: pkix-bounces(_at_)ietf(_dot_)org
[mailto:pkix-bounces(_at_)ietf(_dot_)org] On Behalf Of Denis Pinkas
Sent: Friday, January 29, 2010 3:19 AM
To: ietf
Cc: pkix
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor
ManagementProtocol(TAMP)) to Proposed Standard
Carl,
You said: "the current protocol is able to accommodate the web browser model
and
does so for the existing path processing constraints defined in RFC 5280, i.e.,
name constraints, certificate policies and certificate policy constraints".
Unfortunately, this is not the case. Applying "name constraints, certificate
policies
and certificate policy constraints" as defined in RFC 5280 is not sufficient to
accommodate
the web browser model.
The web browser model controls characteristics which only apply to leaf
certificates,
in practice EKU (Extended Key Usages) and OIDs of Certication Policies.
[CW] Certificate policies and policy constraints are fully supported. EKU is
not processed across a certification path so its utility in a TA is limited.
Independent of TAMP/TAF, the EKU-like mechanism used by some browsers has been
the subject of mailing list posts describing interoperability problems. This
could be addressed by defining and using a similar extension that has
associated path processing rules. It has also been suggested that the
certificate policies extension could serve this purpose without defining a new
extension. TAMP is not the place to sort out that issue.
You claim that this feature could be provided as an extension to the protocol.
[CW] I claim this, have given pointers to similar extensions and have offered
to co-author or review the new specification.
This is an acknowledgment that the current document does not currently support
the web browser model.
[CW] The use of an EKU extension in a TA is not a different model. It's a
different extension that fits within the model that has been defined.
The current draft is in fact covering three use cases, none of them is
correctly addressing the web browser model.
Should an extension be defined, it would be difficult to use, since extensions,
as supported in the draft,
mandate to use two separate operations: to set the initial content of a trust
anchor and then to modify it
afwterwards using a TAMPUpdate operation (which is solely able to use
extensions).
[CW] This is not correct. A trust anchor can be added to a trust anchor store
with a full definition (including extensions) using an add operation. There is
no need for a second message simply to set extensions.
The initial content of a Trust Anchor is defined by:
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }
None of these options, include an extension field.
[CW] All of these options include an extensions field:
Certificate.tbsCertificate.extensions, TBSCertificate.extensions,
TrustAnchorInfo.exts.
Only the TAMP update operation includes an extension field:
TBSCertificateChangeInfo ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
signature [0] AlgorithmIdentifier OPTIONAL,
issuer [1] Name OPTIONAL,
validity [2] Validity OPTIONAL,
subject [3] Name OPTIONAL,
subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
exts [5] EXPLICIT Extensions OPTIONAL }
Using a change function to add information is not the right way to proceed.
The protocol is unable to support the sending of a full description of a trust
anchor,
including the support of extensions, all in a single exchange.
[CW] The protocol fully supports the sending a full description of a trust
anchor, including the support of extensions, all in a single exchange. You
reference the change operation above. Look at the add operation.
As said in the PKIX list, this can be done in a single step. Proposals have
been posted to demonstrate how it could be done.
It has been responded that the proposal was correctly adressing the issue in
principle, but the editors were not willing
to make a change which was considered as a major change to the initial proposal.
Another major issue for this draft is that it is unable to tell for which usage
(e.g. for which application or which purpose)
each trust anchor may be used.
[CW] A variety of extensions can be included to indicate the intended usage of
a trust anchor so it's easy to look at a trust anchor and find this
information.
All these issues led me to propose that this document proceeds on the
EXPERIMENTAL track,
thus leaving room for a STANDARD protocol adressing the needs of the Internet
community
when using X.509 self-signed certificates associated with metadata.
Denis
De : pkix-bounces
À : denis.pinkas,ietf
Date : 2010-01-25, 16:20:06
Sujet : Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor
ManagementProtocol(TAMP)) to Proposed Standard
Denis,
As we have discussed on the PKIX mailing list, the current protocol is
able to accommodate the web browser model and does so for the existing path
processing constraints defined in RFC 5280, i.e., name constraints, certificate
policies and certificate policy constraints. The problem you are referring to
is really with the current EKU extension, which is not processed across a
certification path. Were one to define an EKU variant that has path processing
semantics, TAMP would convey this information just fine. Other specifications
have defined extensions for inclusion in trust anchors to extend the RFC 5280
set, including RFC 3779 and CCC. Something similar is appropriate for this
purpose.
Carl
From: pkix-bounces(_at_)ietf(_dot_)org
[mailto:pkix-bounces(_at_)ietf(_dot_)org] On Behalf Of Denis Pinkas
Sent: Monday, January 25, 2010 3:49 AM
To: ietf
Cc: pkix
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor
ManagementProtocol (TAMP)) to Proposed Standard
The current protocol has severe limitations.
They have been pointed during the last call at the PKIX WG level, but
the protocol
has not been modified to address them.The end result has only been to
add text
to explain the limitations without removing these limitations.
See section 3: "When using these structures without any additional
extension,
for which purposes the trust anchor info shall be used to verify
certification paths needs to be locally defined; this means that
different
usages for the same or different trust anchors placed in the same TAS
are not possible either.
One way to have different usages for different trust anchors without
using extensions is to use a different TAS for every different usage".
The consequences are as follows:
All web browser providers currently use a different model to manage
trust anchors.
They are able to associate different key usages for every leaf
certificate
with any trust anchor (all placed in the same trust anchor store). This
can be done
in a single operation.
Furthermore, with the introduction of EV SSL Certificates
(i.e. Extended Validation SSL certificates) the Certification Policy
OIDs of
leaf certificates that fulfills the requirements of EV SL certificates
are added to the trust anchor to which the EV SSL certificate relates.
This means that supporting the web browser model mandates to be able to
add
key usages (e.g. EKU extended key usages) for leaf certificates
as well as Certification Policies for leaf certificates.
This is not possible with the proposed protocol.
As a consequence, the current protocol is unable to accomodate the web
browser model.
Since the protocol seems to be sufficient for another community
(but not to the Internet community), it is proposed to place this
document
on the EXPERIMENTAL track rather than on the standards track.
Denis
Date : 2010-01-14, 18:34:14
Sujet : [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor
Management Protocol (TAMP)) toProposed Standard
The IESG has received a request from the Public-Key
Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Trust Anchor Management Protocol (TAMP) '
<draft-ietf-pkix-tamp-05.txt> as a Proposed Standard
This document includes a downref to draft-ietf-pkix-new-asn1,
which
is under consideration by the IESG for publication as an
Informational RFC.
This document updates ASN.1 modules for PKIX specifications to
conform to
the 2002 version of ASN.1, but makes no changes to the bits on
the wire.
The community is specifically requested to consider whether
down refs
to draft-ietf-pkix-new-asn1 are appropriate in the general
case,
in addition to the specific case of draft-ietf-pkix-tamp.
The IESG plans to make a decision in the next few weeks, and
solicits
final comments on this action. Please send substantive comments
to the
ietf(_at_)ietf(_dot_)org <mailto:%20ietf(_at_)ietf(_dot_)org>
mailing lists by 2010-01-28. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org
<mailto:%20iesg(_at_)ietf(_dot_)org> instead. In either case, please
retain the beginning of the Subject line to allow automated
sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-05.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17760&rfc_flag=0
_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org <mailto:%20pkix(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf