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

From: Santosh Chokhani <[email-masked]>
Date: Wed, 16 May 2001 17:47:55 -0400

I will not speak for X.509 or for pkix.  But from my humble notion of
security, a trust anchor can do whatever it pleases.  After that, if the key
usage extension is present in a certificate and is marked critical, and does
NOT have cRLSign bit set, the public key in the certificate MAY NOT be used
to verify a signature on a CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 4:02 PM
To: [email-masked]
Subject: Semantics of cRLSign (new-part1-06)?

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: [email-masked]
Date: Fri, 18 May 2001 11:49:59 -0400

David,

>
>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.
>
>
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 case I meant was that the CA would issue itself a self-signed cert
asserting the cRLSign bit, not a cert for a different key.  So the key
would no longer be limited.

>
>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.
>
>
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.
>
>
>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?
>
>
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 don't understand this.  An RP would only consider trusting a CRL if that
CRL is signed either by the certificate issuer, or by an entity named as a
CRLIssuer in the CDP extension of the certificate.  The only possible
effect of the cRLSign bit (or rather its absence) is in preventing one of
these entities from being trusted to sign CRLs.  The RP is already
protected from spoofing by random third parties.

It doesn't make sense (I think) to ever not trust a CA to sign its own
CRLs, so the only plausible effect if the cRLSign bit is on entities that
appear in the CDP extension.  Now, if the CA put some entity's name into a
certificate as a CRLIssuer, it presumably trusted that entity when it cut
the certificate.  So the only deliberate reason for there not to be a
cRLSign bit in the entity's certificate is if the CA has tried to revoke
that ability.

However, since the cRLSign bit isn't "scoped", the CRLIssuer might be an
authorized CRL signer for some other CA (it might even be a
certificate-issuing CA itself), so it might well have some other
certificate for the same key that does assert cRLSign.  So it seems like
the only plausible use of the cRLSign bit (to allow revoking of CRL-signing
ability) doesn't in fact work.

The only way that I can see that a CA could ever guarantee that it would be
able revoke the delegation of CRL signing capability is if the trust path
to that CRL-signer was restricted (by RPs) to direct trust from the CA
(i.e. the path used by an RP when validating a CRL-signer's key for the
purpose of CRL checking must include, as its final certificate, a
certificate issued by the CA, and with the cRLSign bit asserted).

The CA would also have to take responsibility for revoking such
CRL-delegation certificates itself :)

If we want to allow CAs to delegate the ability to sign CRLs to third
parties, or even to seperate keys (and there are compelling operational
reasons to do so), I think we need to add a restriction like the above on
suitable trust paths for CRL-signer validation.

John