Subject: Re: Son of RFC3280 path validation rules

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 20 Oct 2006 10:28:56 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Oct 2006 10:43:57 +0100

Hi Denis,

Denis Pinkas wrote:

> ...the sentence : "The trust anchor for the certification path

As it happens I disagree with you but that was done to death on the
list before I think.

> 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: Peter Sylvester <[email-masked]>
Date: Fri, 20 Oct 2006 12:43:41 +0200

I propose to consider the following:

1 - "The basic path algorithm may be extended to have a different trust 
anchor
 for crl path validation."

2 - "When the basic path algorithm is extended to use multiple trust 
anchors, i.e.,
  several trust anchors for end entities and may be others for crl paths,
  then this algorithm is logically implemented as running the basic 
algorithm
  for each of the trust anchors independantly with the desired 
combinations of
  end entity path trust anchors and crl path trust anchors.