Re: Son of RFC3280 path validation rules

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

Julien,

Your remark is important.

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

X.509 is fairly too open and in some cases insecure ! For this reason, 
I do not care too much about "breaking compatiblity" when at the same time security is also broken.

However ,I care about security and 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:

     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.

Denis

>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