Subject: Semantics of cRLSign (new-part1-06)?

From: [email-masked]
Date: Wed, 16 May 2001 16:02:24 -0400

Reading through the treatment of CRLs in the new-part1-06, plus the earlier
discussions including the one about path length constraints that petered
out without an obvious resolution, I realized I am completely confused by
the whole topic :)    So I'm going to try to ask the major questions I have
in individual messages.

What are the semantics of the cRLSign bit?  Does it mean:
1)  "The subject of this certificate should be trusted to sign (arbitrary)
CRLs", or
2)  "The subject of this certificate should be trusted to sign CRLs
containing certificates signed by the subject of this certificate", or
3)  "The subject of this certificate should be trusted to sign CRLs
containing certificates signed by the issuer of this certificate"

(1) is hopelessly vague, and (I hope) not what is intended although it is
what a literal reading of the text seems to imply.
(2) would allow a parent CA to create a child CA with two distinct keys,
one of which is used for certificate signing, and the other for CRL
signing.  But it wouldn't allow the child CA to manage its own CRL-signing
key.  It would be possible for a child CA to issue a CRL-signing
certificate to itself under another key, though.
(3) explicitly permits a CA to delegate responsibility for creating its
CRLs to another entity (or to a different key that it owns and manages
itself), which is a useful function, and allows a CA to deal with
revocation however it wants, and roll-over its CRL-signing key without
having to get new certificates issued to it by parent CAs or other CAs that
have cross-certified it.

The definition of the indirectCRL extension implies that it is possible for
a CRL-signer to have a different name from the name of the issuer of the
certificates in the CRL, so this implies that (2) isn't what's meant, but
it should be made clearer.

If a CA is certified by a certificate that doesn't have the cRLSign bit
set, does that meant that the CA shouldn't be trusted revoke certificates
it has issued?  Or is a CA always trusted to revoke its own certificates,
and can additionally choose to use the cRLSign bit to delegate that ability
to another entity or key (which would be in line with interpretation (3)
above)?

There's nothing I could see in section 6.3 of new-part1-06 (CRL Validation)
that says anything about cRLSign being required (or even looked at)
anywhere along the trust path to the CRL being checked.  I think this needs
to be fixed.

John

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 16 May 2001 16:53:35 -0400

John,

The cRLSign bit merely indicates whether the subject public key may be used to verify signatures on CRLs (any CRLs). If the cRLSign bit is not set, it does not necessarily indicate that the subject of the certificate should not be trusted to sign CRLs, it simply means that this particular public key should not be used to verify CRLs (the subject may have other certified public keys).

More to the point, however, the cRLSign bit is not the place to be looking to determine who is trusted to do what. By default a CA should be trusted to sign CRLs containing revocation information about its own certificates. If an entity other than the certificate issuer is to sign the CRLs that cover a certificate, the identity of that CRL issuer should be specified in the CRLDistributionPoints extension.

So, if a certificate contains the CRLDistributionPoints extension with the cRLIssuer field present, then the entity identified in the cRLIssuer field should be trusted to sign the CRLs that provide revocation information for that certificate. If the extension is not present (or is present, but the cRLIssuer field is not), then only the certificate issuer should be trusted to sign the CRLs.

Once the identity of the CRL signer has been determined, the cRLSign key usage bit can be used to determine whether a particular public key belonging to that entity should be trusted to sign CRLs.

So, technically meaning (1) below is correct (or is closest to correct). However, one should only trust the information in a CRL about a particular certificate if the certificate specifies that the CRL signer should be trusted to sign the CRLs for that certificate.

>to another entity or key (which would be in line with interpretation (3)

Again, the cRLSign bit only makes a statement about the particular public key in the certificate. Even if "a CA is certified by a certificate that doesn't have the cRLSign bit set", there may be another certificate (perhaps a self-signed one) issued to the CA in which the cRLSign bit is set. Perhaps, for security reasons, the CA issues CRLs under a different key than the one it uses to sign certificates.

>anywhere along the trust path to the CRL being checked.  I think this needs

Section 6.3 does not specify how to validate signatures on CRLs. The general rule for validating a signature is to (1) determine which public key needs to be used to validate the signature, (2) validate a path in which the end certificate certificates that public key, and (3) use the results of path validation to determine if the public key may be used for the intended purpose (e.g., check key usage, extended key usage, policies, etc.). This applies whether one is validating signatures on CRLs or S/MIME messages.

Bear in mind, however, that there is no requirement to perform path validation to validate the public key used to sign a CRL. For example, if the CRL is to be verified using a key that belongs to one of the relying party's trust roots (i.e., the key is contained in one of the trusted self-signed certificates), then no path validation may be necessary, and so there would be no key usage bits to examine.

Dave