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

From: [email-masked]
Date: Thu, 17 May 2001 14:44:33 -0400

So, if I am a CA, and want to be sure that RPs will be able to check the
revocation status of my certificates without having to install me as a
trust anchor, I need to ensure that any cross-certificates in which I am
named as a subject include a cRLSign key-usage?  Now, I can't force the
other CAs to do anything special (although some request protocols would
allow me to request that the bit be set), so this seems to be saying that,
in order for a distributed PKI to work, the cRLSign bit ought always to be
set in CA certificates.

On the other hand, even if it isn't set, an RP could construct a valid path
from a trust anchor through me that acquires the cRLSign capability if I
issue a self-signed certificate that asserts the bit.  Such self-signed
certiicates are explicitly excluded from being limited by the path-length
constraints in the validation algorithm in new-part1-06, so such a
certificate ought to be able to be inserted into any valid chain without
invalidating it.

So it sounds as though any CA certificate in which keyCertSign also grants
the target CA the right to sign CRLs (which makes not setting the bit
somewhat useless).

How about the converse: A CA certificate that includes cRLSign but not
keyCertSign?  This would seem to allow a CA to delegate the ability to sign
CRLs to another entity or key which is an important operational feature.
With the new text about pathLenConstraint in new-part1-06 (which
incidentally is mis-spelled at "pathLengthConstraint" in the path
validation section), a CRL-signing certificate shouldn't be counted towards
the maximum path length, as it's the last certificate in the chain.  But
what I don't understand is what the bit buys you.  If a certificate
contains a CDP extension naming entity A as the appropriate cRLIssuer, yet
the trust chain the the RP constructs that ends with A doesn't contain the
keyCertSign bit, I presume the RP is supposed to say that revocation status
can't be verified.  But how would this situation arise in practice?  I can
think of only two possibilities: either the CA made a mistake and didn't
set the cRLIssuer key-usage bit in the cert it issued for the CRL-signer,
or the RP constructed the wrong chain to party A.  In the first case, the
bit has merely served to introduce the possibility of an operational
failure (with no benefit); the latter case can be divided into two
sub-cases: either the key derived for A verifies the signature on the CRL
or it doesn't.  In the latter case the absence of the cRLSign bit has
changed nothing - the RP wouldn't have used the CRL anyway.  In the former
case, it has again merely introduced the possibility of a spurious failure
with no apparent benefit.

Even if the chain I build to CRL-signer "A" does assert the cRLSign
key-usage, I don't see anything that verifies whether that particular chain
has anything to do with the CA that issued the cert that is bing checked.
"A" might be acting as a CRL-signer for another CA as well, and the trust
chain the the RP built happened to terminate with the CRL-signing cert
issued by that other CA.  I don't see that it's any more appropriate to use
some random CA's CRL-signing cert than to use a cert that doesn't assert
cRLSign at all.

Hopefully I'm just overlooking something obvious, and there is a real
function that this bit provides.

John

                    "David A. Cooper"                                                                                 
                    <david.cooper@nist        To:     [email-masked]                                              
                    .gov>                     cc:     [email-masked]                                               
                    Sent by:                  Subject:     Re: Semantics of cRLSign (new-part1-06)?                   
                    owner-ietf-pkix@ma                                                                                
                    il.imc.org                                                                                        

                    05/16/01 04:53 PM                                                                                 

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.

At 04:02 PM 5/16/01 -0400, [email-masked] wrote:

>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)?

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.

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

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

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 18 May 2001 11:08:11 -0400

John,

Here are my thoughts on the usefulness of the keyUsage bits in certificates issued to CAs. Others may have different (better?) thoughts on the issue.

>in order for a distributed PKI to work, the cRLSign bit ought always to be

Yes. I would say that if one CA is issuing a cross-certificate to another CA, that certificate should have both the keyCertSign and cRLSign key usage bits set, unless the certificate issuer knows that the subject public key will not be verify signatures on CRLs. 

>certificate ought to be able to be inserted into any valid chain without

Yes. A CA can always issue a certificate to itself with whatever key usage bits set that it wants. This is OK, however, since the purpose of setting the key usage bits in certificates issued to CAs is to limit the possible uses of the subject public key, not the CA in general.

>the target CA the right to sign CRLs (which makes not setting the bit

A CA should always be able to sign CRLs that cover the certificates that it issues. It would make no sense to allow a CA to issue certificates but prevent it from revoking those certificates through CRLs. That does not mean that not setting the bit is useless. 

Suppose that a CA maintains 2 public/private key pairs. One private key is used to sign certificates and CRLs. This private key is stored in a FIPS 140-1 Level 4 validated cryptographic module, and the certificate/CRL generating hardware along with the cryptographic module are kept off-line and are placed in a tightly secured room. The second private key is only intended to be used to sign administrative messages (e.g., S/MIME messages exchanged with other CAs to make cross-certification arrangements). This second key is stored in a FIPS 140-1 Level 1 module on a standard desktop machine that is connected to the Internet and is placed in an office with limited physical access controls.

Clearly their is a higher risk that the second private key will be compromised than that the first key will. So, the CA will arrange for the all cross certificates issued to it to include the first private key as the subject public key. This key will have the keyCertSign and cRLSign key usages set. The CA will issue itself a certificate with the second public key as the subject public key. This certificate will have the digitalSignature key usage set, but neither keyCertSign nor cRLSign will be set.

So, if an attacker manages to compromise the second private key, he will be able to sign S/MIME messages that will be trusted as having come from the CA. However, since neither the keyCertSign nor cRLSign bits were set in the certificate that certified the corresponding public key, no certificates or CRLs signed by the attacker with the compromised key will be trusted by relying parties as having been signed by the CA.

>CRLs to another entity or key which is an important operational feature.

Exactly. Imagine the example above, with the exception that different keys are used to sign certificates and CRLs, and the CRL signing key is less well protected than the certificate signing key.

>can't be verified.  But how would this situation arise in practice?

The example above in which the CRL was signed using a compromised key that was never intended by the CA to be used to sign CRLs works. In this case, the cRLSign bit not being set protects the relying party from trusting a CRL that was signed by an attacker.

>I can think of only two possibilities: either the CA made a mistake and didn't

As I said in my last message, a CRL signed by CRL-signer "A" should only be trusted to provide information about certificate "B" if:

         a) CRL-signer "A" was also the issuer of certificate "B"; or

         b) certificate "B" contains a CRLDistributionPoints extension in which the cRLIssuer field is
             present and has the value "A". In this case the issuer of certificate "B" is specifically
             telling the relying party to trust CRLs signed by "A".

If neither of these conditions is met, then the relying party should not trust "A"'s CRL with respect to the status of certificate "B". It is not sufficient to find a random CA that is authorized to issue CRLs, one must only use CRLs that have been signed by CAs authorized by the certificate issuer. Once the correct CRL-issuer has been identified, the cRLSign bit can be used to determine whether a particular public key belonging to the authorized CRL-issuer can be used to verify signatures on CRLs (because if it wasn't, but the private key was used to sign CRLs anyway, this may be an indication of a key compromise).