Subject: Re: Son of RFC3280 path validation rules

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 20 Oct 2006 13:50:15 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Oct 2006 13:17:55 +0100

Denis,

> would happen to have the same DN".

No, I meant writing an I-D that justifies a correct version of that
sentence, ("no protection" being vastly overstated) - explaining how
that collision might actually happen in the real world, and not in
Hollywood; the many, many simple ways to avoid such a collision, and
the actual consequences (as opposed to the above) if the collision
does occur, including perhaps a consideration of the reasonable
impact on a CA's general trustworthiness if it hasn't managed to
pick itself a unique name. Maybe 5 pages.

Stephen.

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 23 Oct 2006 17:41:42 +0200

On Fri, Oct 20, 2006 at 01:17:55PM +0100, Stephen Farrell wrote:
> >"The path validation algorithm provides no protection in case two CRL 
> >Issuers under the same trust anchor would happen to have the same DN".
> 

The point is that having the same trust anchor or different trust
anchors is THE SAME, "security" wise. It is possible to ensure that
one CA cannot revoke certificates from other CAs, but what is currently
proposed is not enough.

If the list is interested, we can produce a (maybe) "real world"
example. For instance, we can take an s/mime message that was sent to
this very list and add certificates and CRLs to the CMS envelope so that
the signature on the message will become invalid because the certificate
will be considered to be revoked. The only thing you need to do is
to add a new Root CA to your Root CA store. Would that be considered
"Hollywood" or "real-file ?

Regards,

--
Julien Stern

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Oct 2006 17:11:06 +0100

Julien Stern wrote:
 > For instance, we can take an s/mime message that was sent to

If you can populate a new CA in my root CA store then the game is over
already - I assume you would just feed me bogus certs.

If you can mess with the CMS envelope you can flip a bit to invalidate
the signature.

Either way, nothing new or interesting.

So, yes, I think you're still living right in the middle of Hollywood.

Stephen.

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 23 Oct 2006 08:53:25 -0800

Could someone please restate the point of this thread?

Mike

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 24 Oct 2006 11:48:33 +0200

> already - I assume you would just feed me bogus certs.

But if you start with the assumption that all your Root CAs behave
nicely, you have no need for the new validation rules requiring
the same trust anchor... :) Oh well...

> If you can mess with the CMS envelope you can flip a bit to invalidate

I was only talking about changing the certificates and/or CRLs
included in the CMS, not the integrity protected part...

--
Julien

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Oct 2006 11:52:08 +0100

> the same trust anchor... :) Oh well...

There was - maybe someone else remembers the details, I'm afraid
I don't really, and haven't time right now to excavate for them;-)

It was something to do with indirect CRLs and the upshot was that
so long as there are no CA name collisions under a single root,
then none of the roots could cheat on one another in any interesting
way (when the new rules apply).

We did all this on the list before and I believe the draft accurately
reflects where we ended up, even if not everyone agreed with that
outcome.

S.

---

From: "Julien Stern" <[email-masked]>
Date: Thu, 26 Oct 2006 14:42:36 +0200

> way (when the new rules apply).

Stephen,

I do remember the discussion and I already pointed out at that time
that the new rule did NOT prevent the attack as it was envisionned,
(to the best of my understanding).

Now, it seems that several of you feel that I'm wasting everyones time,
(and I apologize if I'm indeed completely out of scope).

So, I'll just leave it where it is. If someone is willing to take the
time to explain what the "cheat" is, and what the security assumptions
are, I'd be glad to take the time to mount an attack under the new rule.

Regards,

--
Julien Stern