Subject: Son of RFC3280 path validation rules

From: "Julien Stern" <[email-masked]>
Date: Fri, 13 Oct 2006 11:34:24 +0200

Folks,

a fairly major difference came up between RFC3280 and son-of-RFC3280
regarding path validation, namely:

RFC3280:

   (f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set.

son-of-RFC3280:
   (f)  Obtain and validate the certification path for the issuer of
   the complete CRL.  The trust anchor for the certification path
   MUST be the same as the trust anchor used to validate the target
   certificate.  If a key usage extension is present in the CRL
   issuer's certificate, verify that the cRLSign bit is set.

So, son-of-RFC3280 adds the additional constraint of having both
paths ending at the same trust anchor.

I'm a bit surprised that this modification does not come with more
details and explaination. As a matter of fact, it breaks compatibility
with previous versions of the standard, with X509, and the advantages
of this additional constraint are not clear.

X509 specifically allows the certificate issuer and the CRL issuer to be
two different trust anchors, as indicated in section 8.1.5 of X509 v5:

X509.v5  8.1.5
   If an authority uses the same key to sign certificates and CRLs, a
   single self-issued certificate of category a) shall be used. If an
   authority uses a different key to sign CRLs than that used to sign
   certificates, the authority may choose to issue two self-issued
   certificates of category a), one for each of the keys. In this
   situation, certificate users would need access to both self-issued
   certificates to establish separate trust anchors for certificates and
   CRLs signed by that authority. Alternatively, an authority may issue
   one self-issued certificate of category a) for certificate signing and
   one self-issued certificate of category b) for CRL signing. In this
   situation, certificate users use the key certified in the certificate of
   category a) as their single trust anchor for both certificates and CRLs
   signed by that authority. In this case, if the self-issued certificate
   of category b) were to be used to verify signatures on CRLs, there
   is no means defined in this standard to check the validity of that
   certificate.

Also, this additional constraint can make indirect CRLs much harder
to implement in practice, if not impossible in some cases. It means
that if two different CAs wish to delegate CRL issuance to the same
CRL issuer, the CRL issuer needs to have two (cross) certificates
with the same key, or all three need to chain to the same root.

It will also make key-rollover more complex when the CA has issued
a certificate to itself for CRL signing.

Finally, this constraint does not add security. It merely helps
path builders to speed up the reconstruction process, and possibly
to detect an ambiguity if two CAs with the same name happen to exist.
It does not however prevent a rogue CA from issuing a bogus CRL.

So, all in all, is a "MUST" really what we want? Or should we simply
say that an implementation may check this additional constraint, but
risks in that case to refuse perfectly valid CRLs from a PKI following
an older version of the PKIX standard or X509 ?

Regards,

--
Julien Stern

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 23 Oct 2006 11:09:58 -0700

Julien,

To simply require that the two roots match, the following assumptions
must be true.  These assumptions seem reasonable to me.

1.  The Root and sub CAs are not rogue.

2.  If there is a name collision concern, name constraints is used.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Monday, October 23, 2006 11:42 AM
To: [email-masked]
Subject: Re: Son of RFC3280 path validation rules

On Fri, Oct 20, 2006 at 01:17:55PM +0100, Stephen Farrell wrote:
> 
> Denis,
> 
> Denis Pinkas wrote:
> >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".
> 
> 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.

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