RE: Son of RFC3280 path validation rules

"Santosh Chokhani" <chokhani@orionsec.com> Fri, 20 October 2006 12:01 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gat4S-0000f5-Ou for pkix-archive@lists.ietf.org; Fri, 20 Oct 2006 08:01:52 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gat4R-0001ED-CO for pkix-archive@lists.ietf.org; Fri, 20 Oct 2006 08:01:52 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9KBB8sp094137; Fri, 20 Oct 2006 04:11:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9KBB8cC094136; Fri, 20 Oct 2006 04:11:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9KBB8ob094108 for <ietf-pkix@imc.org>; Fri, 20 Oct 2006 04:11:08 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Son of RFC3280 path validation rules
Date: Fri, 20 Oct 2006 04:12:17 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879051344C6@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Son of RFC3280 path validation rules
Thread-Index: Acb0Nwa6bMU3Ch4OSDqIx4H7vutDRgAAXPWw
From: Santosh Chokhani <chokhani@orionsec.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Denis Pinkas <denis.pinkas@bull.net>
Cc: ietf-pkix@imc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9KBB8ob094131
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5

Steve,

Text has already been written and briefed to the PKIX group as early as
November 2004.  See the slides and minutes from Nov 2004 IETF in
Washington DC

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]
On Behalf Of Stephen Farrell
Sent: Friday, October 20, 2006 5:44 AM
To: Denis Pinkas
Cc: ietf-pkix@imc.org
Subject: Re: Son of RFC3280 path validation rules



Hi Denis,

Denis Pinkas wrote:

> ...the sentence : "The trust anchor for the certification path
> MUST be the same as the trust anchor used to validate the target
certificate" does not allow 
> to address the cases where:

As it happens I disagree with you but that was done to death on the
list before I think.

> 
>      a) two CAs in different branches of a certification tree would
have the same DN, and
> 
>      b) two CAs in different trees of a certification forest would
have the same DN.
> 
> Dave, the text of son-of-RFC328 is currently insufficient to enable
secure implementations.

That strikes me as a wild overstatement almost akin to saying that
we should spend forever figuring out how to handle cases where two
CAs end up with the same private key and never mind making any
progress in the meantime.

I think the current text is fine, an improvement on 3280, and well
worth proceeding with.

I suggest that you write up a separate document that says how to
handle the corner cases above.

Stephen.