Re: Son of RFC3280 path validation rules

["Denis Pinkas" <[e-mail]>]

Hi Stephen,

>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.

You are proposing to write an I-D to add a single sentence like:
"The certificate from the CRL Issuer MUST be issued by the CA that has issued the target certificate."
I suspect you are kidding.

The alternative would be to add in the security considerations section :

"The path validation algorithm provides no protection in case two CRL Issuers under the same trust anchor 
would happen to have the same DN".

Denis

>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: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Stephen Farrell
>> Sent: Friday, October 20, 2006 5:44 AM
>> To: Denis Pinkas
>> Cc: [e-mail]
>> 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.