Re: Open Issue in Part1: path length constraints

["David A. Cooper" <david.cooper@xxxxxxxx>]

Steve,

You are right that RFC 2459 seems to be somewhat careless in its use of
the term CA. However, X.509 seems to be more clear:

(1) Certification Authority is defined as "An authority trusted by
one or more users to create and assign public-key
certificates."

(2) For the basicConstraints extension, it states: "The
cA component indicates if the certified public key
may be used to verify certificate signatures."

(3) For the cRLDistributionPoints extension, it states: "The
cRLIssuer component identifies the authority that
issues and signs the CRL."

So X.509, when defining CAs, doesn't seem to say anything about CRLs and
also uses the term authority instead of certification authority to
describe the entity that signs a CRL.

At 06:29 PM 3/2/01 -0500, Stephen Kent wrote:

X.509 states "[t]he cA component indicates if the certified public key may be used to verify certificate signatures". It says nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are you arguing that we should change the standards to require basicConstraints with cA=TRUE in certificates that only authorize the use of the subject's public key to verify signatures on CRLs? Or are you suggesting that a certificate should be treated as a CA certificate if cRLSign is set in keyUsage even if basicConstraints is absent?

I have always expected to see the CA flag set to true on a cert used to sign CRLs, but, as I noted in my message, a closer look at 2459 fails to require that. Still, throughout most of the document we see references to CAs, not to EEs, with regard to CRL signing. If there was an intent to allow non-CAs to sign CRLs, we certainly did not make it clear.

Until we had the KeyUsage extension and the the certSign bit in v3 certs, there was no doubt that only a CA could sign a CRL. It was not clear to me that X.509, or 2459, made a point of advertising that a feature of this extension, and of indirect CRLs, was to promote the signing of CRLs by other than a CA. Rereading the 259 text, I still have to say that is not a message that comes through.

To be more specific, if we accept the idea that pathLenConstraint should be computed differently depending on what type of certificate the last one in the path is, should CA1's relying parties accept CRLs issued by CA3 in the certification path below?

CA1 ----------------------------> CA2 ----------------------------------> CA3
        basicConstraints:                               keyUsage:
                cA=TRUE                                 cRLSign
                pathLenConstraint=0

                keyUsage:                               CRLDistributionPoints:
                        keyCertSign, cRLSign            cRLIssuer: CA3

I would say no, if I understand your diagram. First, the cert from CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution point extension is in the cert issued by CA2 to CA3, it is a statement about where to find the CA3 cert if it is ever revoked. If the distribution point were in certs issued by CA2 to EEs, then it would be saying that CA3 would be the issuer of these CRLs. But, look at the text below, from 2459

Yes, I should have CA issuing two certificates: one to an EE with the
CRLDistributionPoints extension and the other issued to CA3 with the
keyUsage extension.


> 5.2.5 
> Issuing Distribution Point
>    The issuing distribution point is a critical CRL
> extension  identifies the CRL distribution point for a particular
> CRL, and it indicates whether the CRL covers revocation for end entity
> certificates only, CA  certificates only, or a limitied set of
> reason codes.  Although the extension is critical, conforming
> implementations are not required to support this extension.
>
>    The CRL is signed using the CA's private key.  CRL
> Distribution Points do not have their own key pairs.  If the CRL is
> stored in the X.500 Directory, it is stored in the Directory entry
> corresponding to the CRL distribution point, which may be different than
> the Directory entry of the CA.
>
> This explicitly refers to the CRL being signed with a CA private key, not
> an EE private key.

The quote from 2459 above seems to have been copied from the following
statement from X.509. Notice that in X.509, however, it uses the term
"CRL issuer" instead of CA.

        

        

The
CRL is signed by the CRL issuer’s key  CRL distribution points do
not have

        

        

their
own key pairs. However, for a CRL distributed via the Directory, the
CRL

        

        

is
stored in the entry of the CRL distribution point, which may not be the
directory

        

        

entry
of the CRL issuer.

So, I would argue that any suggestion in 2459 that only CAs can sign CRLs
was as a result of the authors not being sufficiently cautious in their
use of terms. I see no reason to reject a CRL simply because the
certificate issued to CRL's issuer does not contain basicConstraints with
cA=TRUE.

Dave