[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 []) 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-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 ([]) by localhost (core3.amsl.com []) (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 []) 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 []) 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 []) 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 []) 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 []) 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 []) 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 as permitted sender) receiver=mit.edu; client_ip=; envelope-from=rbarnes@bbn.com;
Received: from [] (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 (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.


Section 1, Paragraph 2

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