Subject: [pkix] CRL and OCSP signer certs

From: Michael StJohns <[email-masked]>
Date: Wed, 24 Aug 2011 15:07:08 -0400

Hi -

After pawing through 5280 et al, I'm unclear of whether or not the cRLSign keyUsage bit can be asserted in a non-CA certificate (a certificate where the basicConstraints extension is missing, or where cA is FALSE in such extension).   Do certificates that "contain public keys used exclusively for purposes other than validating digital signatures on certificates" need to be  or should they be CA certificates?

Secondly, am I correct in reading that a basicConstraints extension with cA is FALSE gets encoded as an empty sequence?

This is extracted from 5280 and refers to the basicConstraints extension. It is the only item somewhat on point I could find - but doesn't actually say anything about cA=FALSE.

This extension MAY appear as a critical or non-
   critical extension in CA certificates that contain public keys used
   exclusively for purposes other than validating digital signatures on
   certificates.  Such CA certificates include ones that contain public
   keys used exclusively for validating digital signatures on CRLs and
   ones that contain key management public keys used with certificate
   enrollment protocols. 

Thanks! Mike

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 29 Aug 2011 04:22:57 +0200

On 24/08/2011 21:07, Michael StJohns wrote:
> After pawing through 5280 et al, I'm unclear of whether or not the 
> cRLSign keyUsage bit can be asserted in a non-CA certificate (a 
> certificate where the basicConstraints extension is missing, or where 
> cA is FALSE in such extension).
There's existing usage of that. I believe X509 makes it clearer it's 
possible.
> Do certificates that "contain public keys used exclusively for 
> purposes other than validating digital signatures on certificates" 
> need to be  or should they be CA certificates?
This depends on what setting the CA bit to true is *precisely* supposed 
to mean.
They are varying interpretations and it's never been settled which one 
*exactly* is the correct one.

Based on the fact a number of CRL issuer don't set the CA bit to true, 
the most restrictive of the interpretations, "CA is set to say this 
certificate issues other certificate, basically redondant with 
keyCertSign keyusage", should be the correct one for that existing usage 
to be correct.

With the more extensive interpretations, "CA to true means the entity 
that controls the cert is a CA", or "CA to true means the DN of this 
cert designates a CA entity", many of those CRL issuers ought to have 
set CA to true, and didn't.

I know one software that assumes CRL issuer don't have the CA bit set to 
true, but that software actually is hand tailored for the one CRL issuer 
certificate using CA it supports.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 Aug 2011 18:14:47 +0200

> There's existing usage of that. I believe X509 makes it clearer it's 

yes.

> This depends on what setting the CA bit to true is *precisely* 
> supposed to mean.
Unless I have overlooked something, I don' think that there is something 
that remains to be settled:
> keyCertSign keyusage", should be the correct one for that existing 
> usage to be correct.
But this is not the case. It is not written like that and the
the logical function is to combine certsign and CA=true with a logical 
AND, not OR.
if you want to validate a certificate that has signed another one. Both 
extensions must be present.

IMO this seems to be an invalid interpretation.

There may be historical software that only looks at CA=true.  BUT, since 
RFC 5280 requires keyusage
to be a critical extension in conformant certs, software that does not 
recognize keyusage would
not accept a certsign cert if they don't understand keyusage (hoping 
that the software understands "critical".)

Anyway, we are not talking about certSign.

There is nothing in the text that relates crlSign with basicconstraints. 
Any cert that has no certSign can have any value of the CA boolean.
It is not verified by any of the rules concerning these keyusage fields.

If some verifier requires any particular setting of basicconstraints 
during validation a a CRLsigner cert, the
verifier seems wrong to me.

IMO "ought to have" has no standing.

>
> I know one software that assumes CRL issuer don't have the CA bit set 
> to true, but that software actually is hand tailored for the one CRL 
> issuer certificate using CA it supports.
See above.

regards
/P