RE: CA=True for an OCSP certficat

["Santosh Chokhani" <SChokhani@xxxxxxxxxxxx>]

Peter,

RFC 3280 is pretty clear on what determines a CA.  It is based on basic constraints for version 3 certificates and out of band means for version 1 and 2.  See section 4.2.1.10 (Basic Constraints) and step k in Section 6.1.4.

RFC 3280 is also clear that CA certificate need not contain key usage extension, let alone have key cert Sign bit.   See step n in Section 6.1.4.

I agree that if key usage extension is present, key cert sign bit must be set in order to verify signature on a child certificate.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Peter Sylvester
Sent: Thursday, April 03, 2008 6:23 AM
To: Stephen Kent
Cc: pkix; zzSantosh Chokhani
Subject: Re: CA=True for an OCSP certficat

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.