CA=True for an OCSP certficat

RFC 3280 specifies for Basic constraints

    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.

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension asserts the keyCertSign bit
   (section 4.2.1.3).  In this case, it gives the maximum number of non-
   self-issued intermediate certificates that may follow this
   certificate in a valid certification path.  A certificate is self-
   issued if the DNs that appear in the subject and issuer fields are
   identical and are not empty.  (Note: The last certificate in the
   certification path is not an intermediate certificate, and is not
   included in this limit.  Usually, the last certificate is an end
   entity certificate, but it can be a CA certificate.)  A
   pathLenConstraint of zero indicates that only one more certificate
   may follow in a valid certification path.  Where it appears, the
   pathLenConstraint field MUST be greater than or equal to zero.  Where
   pathLenConstraint does not appear, no limit is imposed.

   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.  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.  This extension MAY

Re: CA=True for an OCSP certficat

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.

A cert for an EE contains no basic constraints extension, or one in 
which the CA flag is FALSE.

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.

Steve

RE: CA=True for an OCSP certficat

Steve,

I agree with you the time stamp server.

But, under RFC 2560, one of the model is for the CA (and I interpret
that to mean using the same key that signed the certificate whose
revocation status is being checked) to sign the OCSP response.   Hence
CA certificate signing key can be used for OCSP signing.

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Stephen Kent
Sent: Wednesday, April 02, 2008 7:23 PM
To: Peter Sylvester
Cc: pkix
Subject: Re: CA=True for an OCSP certficat

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.

A cert for an EE contains no basic constraints extension, or one in 
which the CA flag is FALSE.

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.

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 

RE: CA=True for an OCSP certficat

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 <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] 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

Re: CA=True for an OCSP certficat

After a short exchange with Santosh we seem to agree to the following:

- It is an obligation for a CA that issues a V3 certificate that
  is usable for certsigning, that it  MUST have ca=true in 
  basicconstraints and keysuage=certsign.

- it is not a requirement for a path validation algorithm to verify that 
  both extensions are present:

    (k)  Verify that the certificate is a CA certificate (as specified
     in a basicConstraints extension or as verified out-of-band).

     (n)  If a key usage extension is present, verify that the
     keyCertSign bit is set.

- A certificate that has Ca=true and keyusage=digitalsignature is NOT 
  an invalid certficate in 3280, it can be used for purposes other 
  than verification of signatures on certificates and CRLs. 
  It is invalid for verification of signatures on certificates and CRLs.

- A tool that wants to distinguish whether a certificate can be used for 
  1. cert signing, 
  2.  crl signing  
  and 3. anything else 
in the case when keyusage and basicconstraints are present, determines 
case 
  1: by requiring CA=TRUE+keyusage + certsigning, 
  2: the second keyusage=crlsign ca=any 
  and 3: ca=any and appropriate key usage. 

Re: CA=True for an OCSP certficat

Peter Sylvester wrote:
> 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.
There's a pair of aspects missing from your description .

The interface of the tools enable to specify which of the tree types the 
input is.
There's also an option "Auto-Detect" which as any "Auto-Detect" option 
will do it's best effort to determine the right type.
That option is guaranteed to give the right result for any valid 
Certificate Signer, CRL Signers or EE Cert.
But when confronted with a cert that has CA=True but no Cert signing and 
no CRL signing in key usage and therefore is :
- not a valid Certificate Signer
- not a valid CRL Signer
- not a valid EE Cert
the one Auto-Detect will pick is a random choice, knowing that the tool 
will report the cert is invalid and therefore rejected.

This is my main point Peter. The Auto-Detect option is inadequate for 
such a certificate.
When the cert is invalid, how could anybody *know for sure* what the 

Re: CA=True for an OCSP certficat

RE: CA=True for an OCSP certficat

Re: CA=True for an OCSP certficat