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@ietf.org [mailto:pkix-bounces@ietf.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@ietf.org <mailto:%20ietf@ietf.org>  mailing lists by
2010-01-28. Exceptionally, 
	comments may be sent to iesg@ietf.org <mailto:%20iesg@ietf.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@ietf.org <mailto:%20pkix@ietf.org> 
	https://www.ietf.org/mailman/listinfo/pkix