|
Carl,
It is clear that we disagree.
The key points are the following:
1) CAs issue self-signed certificates.
2) CAs do NOT place constraints on the usage of theirs self-signed
certificates.
These usages are placed OUTSIDE the self-signed certificates by Relying
Parties.
The current draft with its current extensions does not allow to manage at
the same time
self-signed certificates and usage conditions for leaf
certificates.
In the case of the Web browser model, it would be necessary to add
conditions
which apply to the leaf certificate only, namely:
a) EKU, and
b) OIDs of Certification Policies.
In the more general case, it would be advantageous to also add an
"application class"
so that applications can know which self-signed
certificates associated with usages
that apply to leaf certificates are adequate for them.
Denis
-----
Message reçu -----
Date
: 2010-01-29, 14:12:32
Sujet
: RE: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor
ManagementProtocol(TAMP)) toProposed Standard
Though
we?ve been through each of these points before responses are
inline?
From:
pkix-bounces@xxxxxxxx [mailto:pkix-bounces@xxxxxxxx] 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
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.
[DP] EKU should be processed
for the leaf certificate.
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.
[DP] If TAMP is not the place
to slove this issue, then it means that TAMP should go on the EXPERIMENTAL
track.
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.
[DP]The current definition ofa
TrustAnchorChoice allows to add a structure that is inappropriate
since it
does not allow to support the missing features indicated at the top of this
e-mail or
to add the missing feaures in a single
operation.
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.
[DP]The extension field of
Certificate cannot be used. See the main comment at the top of this
e-mail.
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.
[DP] I did look at it. The
problem is the same.
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.
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
|