Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor ManagementProtocol (TAMP)) to Proposed Standard
"Carl Wallace" <CWallace@cygnacom.com> Mon, 25 January 2010 15:28 UTC
Return-Path: <cwallace@cygnacom.com>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B9128C0D9; Mon, 25 Jan 2010 07:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZhdIbvg4RO1; Mon, 25 Jan 2010 07:28:58 -0800 (PST)
Received: from p03c11o143.symantecmail.net (p03c11o143.symantecmail.net [208.65.144.86]) by core3.amsl.com (Postfix) with ESMTP id 23DEE3A69AB; Mon, 25 Jan 2010 07:28:57 -0800 (PST)
Received: from unknown [65.242.48.13] by p03c11o143.symantecmail.net (mxl_mta-5.7.0-7) with SMTP id 0c8bd5b4.3545451440.42869.00-007.p03c11o143.symantecmail.net (envelope-from <cwallace@cygnacom.com>); Mon, 25 Jan 2010 08:29:04 -0700 (MST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9DD1.E02CDC74"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 25 Jan 2010 10:20:06 -0500
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48EA4AA2@scygexch1.cygnacom.com>
In-Reply-To: <DreamMail__094905_04101423050@msga-001.frcl.bull.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor ManagementProtocol (TAMP)) to Proposed Standard
Thread-Index: Acqdm0hCrxfFNy50SAa90W5x3gOGEgANGCbw
References: <20100114173414.94CAE3A67ED@core3.amsl.com> <DreamMail__094905_04101423050@msga-001.frcl.bull.fr>
From: Carl Wallace <CWallace@cygnacom.com>
To: denis.pinkas@bull.net, ietf <ietf@ietf.org>
X-Spam: [F=0.2000000000; S=0.200(2010011101)]
X-MAIL-FROM: <cwallace@cygnacom.com>
X-SOURCE-IP: [65.242.48.13]
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor ManagementProtocol (TAMP)) to Proposed Standard
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 15:28:59 -0000
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
- [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anc… The IESG
- Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust… Denis Pinkas
- Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust… Carl Wallace
- Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust… David Borman
- Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust… Denis Pinkas
- Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust… Carl Wallace
- Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust… Denis Pinkas