Re: [secdir] SECDIR review of draft-ietf-pkix-other-certs-04

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 17 August 2009 16:32 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 0452E3A6F48 for <secdir@core3.amsl.com>; Mon, 17 Aug 2009 09:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.67
X-Spam-Level:
X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_20=-0.74, 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 8K+oM-z8dIYH for <secdir@core3.amsl.com>; Mon, 17 Aug 2009 09:32:23 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 48FE528C2DF for <secdir@ietf.org>; Mon, 17 Aug 2009 09:31:25 -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 n7HGVR9K005954 for <secdir@ietf.org>; Mon, 17 Aug 2009 12:31:27 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n7HGVPMK005947 for <secdir@PCH.mit.edu>; Mon, 17 Aug 2009 12:31:26 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n7HGVE9r007015 for <secdir@mit.edu>; Mon, 17 Aug 2009 12:31:15 -0400 (EDT)
Received: from TX2EHSOBE006.bigfish.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 4D87A22B2473 for <secdir@mit.edu>; Mon, 17 Aug 2009 12:31:13 -0400 (EDT)
Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by mit.edu with ESMTP id EUQILo4zoEDQGNrZ (version=TLSv1 cipher=RC4-MD5 bits=128 verify=NO) for <secdir@mit.edu>; Mon, 17 Aug 2009 12:31:13 -0400 (EDT)
Received: from mail59-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 8.1.340.0; Mon, 17 Aug 2009 16:31:11 +0000
Received: from mail59-tx2 (localhost.localdomain [127.0.0.1]) by mail59-tx2-R.bigfish.com (Postfix) with ESMTP id 062F2159841B; Mon, 17 Aug 2009 16:31:12 +0000 (UTC)
X-SpamScore: -42
X-BigFish: VPS-42(zz1432R98dN936eM10d1Izz1202hzz1033ILz2dh6bh87h61h)
X-Spam-TCS-SCL: 0:0
X-FB-SS: 5,
X-FB-DOMAIN-IP-MATCH: fail
Received: by mail59-tx2 (MessageSwitch) id 1250526669954437_28980; Mon, 17 Aug 2009 16:31:09 +0000 (UCT)
Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail59-tx2.bigfish.com (Postfix) with ESMTP id A61AA1B28056; Mon, 17 Aug 2009 16:31:09 +0000 (UTC)
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 2674068006; Mon, 17 Aug 2009 17:31:09 +0100 (IST)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A039C619089; Mon, 17 Aug 2009 17:31:09 +0100
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id D659868006; Mon, 17 Aug 2009 17:31:08 +0100 (IST)
Message-ID: <4A8985CD.3030001@cs.tcd.ie>
Date: Mon, 17 Aug 2009 17:31:09 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Richard Barnes <rbarnes@bbn.com>
References: <4A83616C.1030506@bbn.com>
In-Reply-To: <4A83616C.1030506@bbn.com>
X-Enigmail-Version: 0.96.0
X-AntiVirus-Status: MessageID = A139C619089
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.112.7)
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
Cc: sec-ads@ietf.org, SECDIR <secdir@mit.edu>, draft-ietf-pkix-other-certs@tools.ietf.org
Subject: Re: [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: Mon, 17 Aug 2009 16:32:24 -0000

Thanks Richard,

I'll roll changes for those comments into a rev of the document whenever
the AD says to do so.

Cheers,
S.

Richard Barnes wrote:
> 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.
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir