Subject: Re: [pkix] CRL and OCSP signer certs

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2011 02:11:51 +0200 (MEST)

> 
> Jean-Marc Desperrier wrote:
> >
> > Michael StJohns wrote:
> > >
> > > 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 question looks slightly non-sensical to me.

The first part of the sentence describes something that can be
fulfilled by a non-CA certificate, so the answer to the second
would be "no".

It is rather the norm to use non-CA (=end entity) certificates to
"contain public keys used exclusively for purposes other than validating
digital signatures on certificates".

It might seem slighty strange to create an explicit *CA* certificate and
"use it exclusively for purposes other than validating digital signatures
on certificates", but I don't think that there is anything in the
specification that says that you can not do this.

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

X.509 provides the option of an indirect CRL, i.e. where the "issuer"
of the CRL is not necessarily the issuer of all (or any) of the certificates
contained in the CRL.  So it perfectly permissible to use a non-CA
certificate to sign CRLs (but that requires the use of crlEntryExtension
"CertificateIssuer" on the very first CRL entry, and the CRL issuer/signers
name to never appear as "CertificateIssuer" in any crlEntryExtension
of the CRL. (indirect CRLs make use of a non-obvious compression scheme
with that crlEntryExtension "CertificateIssuer").

  http://tools.ietf.org/html/rfc5280#section-5.3.3

Peter Sylvester wrote:
>
> 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".)

You are mis-reading rfc5280, there is no requirement that "conforming
CA certificates" contain a KeyUsage extension, it only applies to the
_subset_ of "conforming CA certificates" issued by "conforming CAs".

Rfc5280 has requirements for "compliant certificates" and for "compliant CAs"
on the BasicConstraints extension:

  http://tools.ietf.org/html/rfc5280#section-4.2.1.9

Requirements for BasicConstraints on conforming CAs:
   Conforming CAs MUST include this extension in all CA certificates
   that contain public keys used to validate digital signatures on
   certificates and MUST mark the extension as critical in such
   certificates. 

Requirements for BasicConstraints on conforming (CA) certificates:
   The cA boolean indicates whether the certified public key may be used
   to verify certificate signatures.  If the cA boolean is not asserted,
   then the keyCertSign bit in the key usage extension MUST NOT be
   asserted.  If the basic constraints extension is not present in a
   version 3 certificate, or the extension is present but the cA boolean
   is not asserted, then the certified public key MUST NOT be used to
   verify certificate signatures.

Rfc5280 requirements for the KeyUsage extensions differ!

  http://tools.ietf.org/html/rfc5280#section-4.2.1.3

Requirements for KeyUsage on conforming CAs:
   Conforming CAs MUST include this extension in certificates that
   contain public keys that are used to validate digital signatures on
   other public key certificates or CRLs.  When present, conforming CAs
   SHOULD mark this extension as critical.

Requirements for KeyUsage on conforming (CA) certificates:
   If the keyUsage extension is present, then the subject public key
   MUST NOT be used to verify signatures on certificates or CRLs unless
   the corresponding keyCertSign or cRLSign bit is set. 

-Martin

PS: If you check the certificates in the TLS X.509 trust anchor store
    of common browsers, you will realize that "conforming CAs" are a
    pretty rare species in the real world.