|
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.
You claim that this feature could be provided as an
extension to the protocol.
This is an acknowledgment that the current
document does not currently support the web browser model.
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).
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.
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.
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.
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
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@xxxxxxxx [mailto:pkix-bounces@xxxxxxxx] 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.
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@xxxxxxxx mailing lists by
2010-01-28. Exceptionally,
comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pkix
|