[secdir] SECDIR review of draft-ietf-pkix-other-certs-04
Richard Barnes <rbarnes@bbn.com> Thu, 13 August 2009 00:43 UTC
Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9147E3A67F3 for <secdir@core3.amsl.com>; Wed, 12 Aug 2009 17:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.65
X-Spam-Level:
X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=1.949, BAYES_00=-2.599, 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 BFsKj7hG948c for <secdir@core3.amsl.com>; Wed, 12 Aug 2009 17:43:01 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 870DF3A6D14 for <secdir@ietf.org>; Wed, 12 Aug 2009 17:43:01 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7D0gboC011524 for <secdir@ietf.org>; Wed, 12 Aug 2009 20:42:37 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7D0gZ84011521 for <secdir@PCH.mit.edu>; Wed, 12 Aug 2009 20:42:35 -0400
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n7D0gPYQ011379 for <secdir@mit.edu>; Wed, 12 Aug 2009 20:42:25 -0400 (EDT)
Received: from mx11.bbn.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 3DF0D1B28C4A for <secdir@mit.edu>; Wed, 12 Aug 2009 20:42:25 -0400 (EDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu with ESMTP id VucUYpPqo3mDlKdj for <secdir@mit.edu>; Wed, 12 Aug 2009 20:42:24 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of rbarnes@bbn.com designates 128.33.0.80 as permitted sender) receiver=mit.edu; client_ip=128.33.0.80; envelope-from=rbarnes@bbn.com;
Received: from [128.89.254.244] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <rbarnes@bbn.com>) id 1MbNSV-00071H-Ea; Wed, 12 Aug 2009 19:42:19 -0400
Message-ID: <4A83616C.1030506@bbn.com>
Date: Wed, 12 Aug 2009 20:42:20 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: IESG <iesg@ietf.org>, SECDIR <secdir@mit.edu>, IETF Discussion <ietf@ietf.org>, draft-ietf-pkix-other-certs@tools.ietf.org
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] SECDIR review of draft-ietf-pkix-other-certs-04
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2009 00:43:02 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This documents creates a certificate extension that allows the issuer of a certificate to assert that the subject of the certificate is the same as that of a set of other certificates (i.e., that the same entity holds all the corresponding private keys). This extension clearly creates some impersonation risks, but the document provides sufficient advice to CAs to mitigate these risks. Overall, I think the document is basically ready for publication. Some comments, mostly editorial, follow below. --Richard ----- Section 1, Paragraph 2 s/assoicate/associate/ Section 1, Paragraph 3 To be clear here and decouple this paragraph from the last, I would replace the phrase "... supports such linkage" to something like "... allows a certificate issuer to attest that the end entity that holds the private key for the certificate in question also holds other private keys corresponding to other certificates." This change also clarifies why you refer to "end entities" below instead of just "subjects". Section 2, Paragraph 3 Change "... change CA when renewing its certificate" to "... change CA when replacing its certificate". Renewal only happens with the same CA. Section 3, ASN.1 fragment Change "::==" to "::=". Section 3, Paragraph 6 (counting the two ASN.1 lines as a single para) The first sentence in this paragraph seems very vague -- what does it mean for a use of this extension to be "safe"? Suggest replacing with a requirement that is notably absent from this paragraph, namely that "CAs MUST issue a certificate containing this extension only after they have validated that the holder of the private key for the certificate also holds the private keys for linked certificates." Section 3, Paragraph 6 (same as above) Do you mean to have both requirements in the final sentence as "SHOULD NOT"? It might be helpful here to note how the "purpose" a certificate might be determined, e.g., via CP or EKU OIDs. Setion 3, Paragraph 10 The validation procedure in RFC 5280 requires an RP to verify that a certificate has not been revoked (Section 6.1.3, step (a)(3)), so the initial conditional can be omitted. This requirement is really important for this extension, since one reason that certificates get revoked is private key compromise, in which case a party other than the intended subject has possession of the private key (by definition). This situation would allow the attacker to obtain linked certificates even from a CA that complies with this document. Section 3, Paragraph 12 It would be helpful to clarify why this restriction is in place, e.g., "Since CA certificates are only used for certificate validation, and this extension has no effect on the validation procedure, this extension is meaningless for CA certificates." Section 5 It's not clear that this section belongs in this document. It would not reduce the clarity of the document to remove it. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir
- [secdir] SECDIR review of draft-ietf-pkix-other-c… Richard Barnes
- Re: [secdir] SECDIR review of draft-ietf-pkix-oth… Stephen Farrell
- [secdir] SECDIR review of draft-ietf-yam-rfc1652b… Richard Barnes