Re: CA=True for an OCSP certficat

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

Stephen and Santosh,
thanks for the answer.

The origin of my question:

A test tool that wants to distingusih 'CA certficates, CRLsigners and EE 
certs':
(CA certficates in the meaning: It can sign certificates).

IMO the way to proceed is:
A CA cert is one that has keyusage=keyCertSign
If not; If it has CRLsign, then it is a CRL signer
else it is an EE cert.

One does not use basicconstrints to distinguish these types.

If for keysuage=keyCertSign, the CA flag is not asserted, one
this is an error. Similar, if not both keyCertSign and CA flag is
set pathlength must not be asserted.

Stephen Kent wrote:
> Peter,
>
> I expect the CA flag to be set to TRUE only in a cert used to validate 
> signatures on other certs, and/or signatures on CRLs.
Well, that's what you might expect, but that's not what is required in 
the text nor excluding
the opposite.
> A cert for an EE contains no basic constraints extension, or one in 
> which the CA flag is FALSE.
I cannot logically deduce this from the text. I can only deduce, it is 
one that does  neither have
keyusage  certsign  crlsign
(not talking about certs without extensions but that's another story).
> A cert issued to a service run by a CA, such as OCSP server or a time 
> stamp server is not  CA cert, but an EE cert, i.e., it is used to 
> verify signatures on objects others than certs or CRLs, and thus it 
> MUST not have the CA flag set TRUE.
I think that there are two conflicting definitions of 'CA certficate' in 
RFC 3280 which
are indicated by either  basicconstraints ca=true or keysuage 
keyCertSign in the text.

Since these conditions are not identical, I cannot properly interprete 
you response.

'A cert issed to a service run by a CA', this sounds to be like

  The basic constraints extension identifies whether the subject of the
  certificate is a CA 


Where is text that say, EE certs MUST not have CA=true?

keyusage:

     The keyCertSign bit is asserted when the subject public key is
     used for verifying a signature on public key certificates.  If the
     keyCertSign bit is asserted, then the cA bit in the basic
     constraints extension (section 4.2.1.10) MUST also be asserted.

     The cRLSign bit is asserted when the subject public key is used
     for verifying a signature on certificate revocation list (e.g., a
     CRL, delta CRL, or an ARL).  This bit MUST be asserted in
     certificates that are used to verify signatures on CRLs.

These statements only require:   keyCertSin => ca=true
but not  for crlSign.

subject key identifier :

  To facilitate certification path construction, this extension MUST
  appear in all conforming CA certificates, that is, all certificates
  including the basic constraints extension (section 4.2.1.10) where
  the value of cA is TRUE.  

for crl signers this is useful.

basic constraints say

  The basic constraints extension identifies whether the subject of the
  certificate is a CA and the maximum depth of valid certification
  paths that include this certificate.


The first statement says something about the nature of the subject, but not
of the purpose of the certificate.

  The cA boolean indicates whether the certified public key belongs to
  a CA.  If the cA boolean is not asserted, then the keyCertSign bit in
  the key usage extension MUST NOT be asserted.

This statement essentially repeats the corresponding keyusage statement.
It does not say anything about crlSign.

  The pathLenConstraint field is meaningful only if the cA boolean is
  asserted and the key usage extension asserts the keyCertSign bit

This is interesting because of both conditions.

  Usually, the last certificate is an end
  entity certificate, but it can be a CA certificate.

This sentence is a little bit irritating because there is not proper
definition of CA certficate. in that context I assume keyusage=keycertsign
is the good interpretation.

  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. 

in this context CA certificate seems to mean basicconstraints ca=true
What are such 'CA certficates'? Aren't they in fact end-entities?

  This extension MAY
  appear as a critical or non-critical extension in end entity
  certificates.

This statement covers the rest.

CAs MUST NOT include the pathLenConstraint field unless the cA
  boolean is asserted and the key usage extension asserts the
  keyCertSign bit.

Again here, we have two conditions.



Does all that may some sense?



--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature