Subject: Updated position on indirect CRL path restrictions

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 22 Jul 2005 19:30:20 +0100

All,

I would like to change my position on the issue of indirect CRL path
restrictions.

I do no longer propose any further restrictions other than those
originally proposed in RFC 3280bis.

The cause of this is that I realized that I, and I think also the
discussion on this list, have made an omission in the assessment of the
name collision threat of indirect CRLs.

In the name matching between a certificate and an indirect CRL there is
not only a name matching of the CRL Issuer name between the CRL issuer
field in the CDP extension of the certificate against the Issuer name of
the CRL, there is also a name matching of the certificate issuer name
between the certificate issuer CRL entry extension in the CRL and the
issuer field of the validated certificate.

So for a successful CRL replacement, there need to be both a CRL issuer
name collision AND a CA name collision at the same time + a URL
collision of the storage location of the CRL (even though specification
of a URL is optional and may not be present, it is highly likely to be
present in indirect CRLs).

More clearly:

If CA A use CRL issuer A, there must be another colliding CA A' using a
colliding CRL issuer A' (both names must collide at the same time) for a
successful replacement to take place.

This is a highly unlikely event, especially given the rarity of indirect
CRL use in the first place.
Forcing the certificate and the CRL to be validated from the same root
should thus be sufficient to mitigate any realistic threats.

However, I'm still for a recommendation that paths SHOULD be closely
related and pointing out that conformant implementations MAY choose to
apply restrictions on deviating paths for reasons of local policy and/or
efficiency.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 26 Jul 2005 16:24:47 +0100

Stefan,

See below.

>present in indirect CRLs).

It would seem that your remark is correct. Howver until I see the writing of a text 
which tells exactly how the two names are verified, I will hold my position: 
the current text is far from crystal clear and even if the probability becomes low 
it is not equal to zero.

There is also an exception: when a CA issues a CRL for itself and other CAs 
using a CRL signing key different from the certificate signing key.

In such a case it must be made sure that the "same certification path" is being used. 

I would also like to change my position :
"same trust anchor" does not even MITIGATE the risk, 
however the "same certification path" SUPPRESSES it in any case. 

If we had no other solution at hand, then we would have to live with it and place 
a warning in the security considerations section. However this is unnecessary 
since there is a secure solution at hand: "same certification path".

Denis

>Program Manager, Standards Liaison

Regards,

Denis Pinkas