Re: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor ManagementProtocol(TAMP)) toProposed Standard
"Denis Pinkas"<denis.pinkas@bull.net> Wed, 03 February 2010 12:37 UTC
Return-Path: <denis.pinkas@bull.net>
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 A0F0028C0F7; Wed, 3 Feb 2010 04:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.323
X-Spam-Level: *
X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_56=0.6, RCVD_BAD_ID=2.837]
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 dSIn7IxZWkiH; Wed, 3 Feb 2010 04:37:17 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 931C03A68F3; Wed, 3 Feb 2010 04:37:16 -0800 (PST)
Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 04E941800F; Wed, 3 Feb 2010 10:15:55 +0100 (CET)
Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2010020310130198:21919 ; Wed, 3 Feb 2010 10:13:01 +0100
From: Denis Pinkas <denis.pinkas@bull.net>
To: ietf <ietf@ietf.org>
Date: Wed, 03 Feb 2010 10:13:02 +0100
Message-Id: <DreamMail__101302_52364716650@msga-001.frcl.bull.fr>
References: <FAD1CF17F2A45B43ADE04E140BA83D48EA4DE5@scygexch1.cygnacom.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 03/02/2010 10:13:02, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 03/02/2010 10:13:03, Serialize complete at 03/02/2010 10:13:03
Content-Type: multipart/alternative; boundary="----=_NextPart_10020310130205262683028_002"
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor ManagementProtocol(TAMP)) toProposed Standard
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: denis.pinkas@bull.net
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: Wed, 03 Feb 2010 12:37:19 -0000
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 ----- De : Carl Wallace À : denis.pinkas,ietf Date : 2010-01-29, 14:12:32 Sujet : RE: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor ManagementProtocol(TAMP)) toProposed Standard Though weve been through each of these points before responses are inline From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] 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. [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. Its 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 its 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@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 mailing lists by 2010-01-28. Exceptionally, comments may be sent to iesg@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 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