RE: Son of RFC3280 path validation rules

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

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:41:57 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879051344DB@EXVS01.ex.dslextreme.net>
Thread-Topic: Son of RFC3280 path validation rules
Thread-Index: Acb0PDpqVI5JE2LjQieH4kEf8wkQYAAAF9Eg
From: Santosh Chokhani <chokhani@orionsec.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Denis Pinkas <denis.pinkas@bull.net>, ietf-pkix@imc.org
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk

Steve,

Writing an I-D will be a breeze.  But, when I briefed the stuff in 2004,
there was no support for doing this.

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
Sent: Friday, October 20, 2006 7:39 AM
To: Santosh Chokhani
Cc: Denis Pinkas; ietf-pkix@imc.org
Subject: Re: Son of RFC3280 path validation rules


Hi Santosh,

That's true. What I meant however, was an I-D. If no-one wants to
write one then maybe this isn't actually such a pressing problem.

S.

Santosh Chokhani wrote:
> 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.
> 
> 
> 
> 
>

Son of RFC3280 path validation rules Julien Stern
Re: Son of RFC3280 path validation rules Denis Pinkas
Re: Son of RFC3280 path validation rules Stephen Farrell
Re: Son of RFC3280 path validation rules Peter Sylvester
RE: Son of RFC3280 path validation rules Santosh Chokhani
RE: Son of RFC3280 path validation rules Santosh Chokhani
Re: Son of RFC3280 path validation rules Stephen Farrell
Re: Son of RFC3280 path validation rules Denis Pinkas
Re: Son of RFC3280 path validation rules Stephen Farrell
Re: Son of RFC3280 path validation rules Stephen Farrell
RE: Son of RFC3280 path validation rules Michael Myers
Re: Son of RFC3280 path validation rules Julien Stern
Re: Son of RFC3280 path validation rules Stephen Farrell
RE: Son of RFC3280 path validation rules Michael Myers
RE: Son of RFC3280 path validation rules Santosh Chokhani
Re: Son of RFC3280 path validation rules Julien Stern
Re: Son of RFC3280 path validation rules Stephen Farrell
Re: Son of RFC3280 path validation rules Julien Stern