RE: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor ManagementProtocol(TAMP)) to Proposed Standard

"Carl Wallace" <CWallace@xxxxxxxxxxxx> · Fri, 29 Jan 2010 08:12:32 -0500

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

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@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.

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@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

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf