Subject: CA=True for an OCSP certficat

From: Peter Sylvester <[email-masked]>
Date: Wed, 02 Apr 2008 12:52:42 +0200

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
   appear as a critical or non-critical extension in end entity
   certificates.

There seems to be twao conflicting definitions of what is a CA certficate:
- a cert that has CertSign set

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

- one that 'belongs to a CA'

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

Is a CRL-Signer and end entity? What is an end -entity? Something that
does not have CertSign as keyusage?

My reading  that OCSPsigner or time stamp authorities or
SCVP responders, etc can have CA=TRUE when they 'belong to a CA'.
Are such things are 'end entities'?

Thanks in advance for any comment.
Peter

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Apr 2008 19:23:27 -0400

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 2 Apr 2008 20:15:18 -0400

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: [email-masked] [mailto:[email-masked]]
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,

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 Apr 2008 12:22:50 +0200

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

This is interesting because of both conditions.

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

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

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?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 3 Apr 2008 09:06:43 -0400

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: [email-masked] [mailto:[email-masked]] 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.

keyusage:

subject key identifier :

basic constraints say

   This extension MAY

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 Apr 2008 16:42:38 +0200

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. 

I hope that this is the correct summary.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 03 Apr 2008 19:09:29 +0200

Peter Sylvester wrote:
> A test tool that wants to distingusih 'CA certficates, CRLsigners and 
> EE certs':
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 
person producing it intended to do ?
Therefore there's no reason to care as much as you do for the result, 
Auto-Detect is a convenience but just don't use it when a predictable 
result is really important.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 03 Apr 2008 19:46:21 +0200

> 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) a…
Now we're getting to something interesting.

So for retro-compatibility reasons, a proper implementation of RFC3280 should accept a certification path where one of the CA certificate has Basic Contraint CA=True but has no Key Usage extension.

I don't feel really at ease with that.
I'd be really wary when encoutering such a case and I'm not sure it corresponds to a very useful need.

But so be it, and does give weight to Peter's argument that any cert with BC including CA=True should be handled as a CA cert in all cases.

> 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.
It would be extremely dangerous to allow a certificate to act as a 
certificate issuer if it has a key usage extension without the key cert 
Sign bit set and fortunately step n does not do that, it only allows 
through certificates with a *missing* key usage extension.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 3 Apr 2008 14:57:05 -0400

I am not saying that if the key usage extension is present, key cert
sign bit need not be set.

What I am saying is that key usage can be absent altogether as long as
basic constraints is set.

If key usage is present, key cert sign bit must be set in order to use
the associated public key to verify signature on a certificate.

As far as your wariness is concerned, if a CA omitted key usage
extension in a CA certificate, the CA will not comply with RFC 3280.

Client need not ensure the presence of the extension.

If you are really wary, 3280 permits you to have your own additional
checks.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jean-Marc Desperrier
Sent: Thursday, April 03, 2008 1:46 PM
To: pkix
Subject: Re: CA=True for an OCSP certficat

Santosh Chokhani wrote: 

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.

So for retro-compatibility reasons, a proper implementation of RFC3280
should accept a certification path where one of the CA certificate has
Basic Contraint CA=True but has no Key Usage extension.
 
I don't feel really at ease with that. 
I'd be really wary when encoutering such a case and I'm not sure it
corresponds to a very useful need.
 
But so be it, and does give weight to Peter's argument that any cert
with BC including CA=True should be handled as a CA cert in all cases.

	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.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Apr 2008 18:00:57 -0400

At 9:06 AM -0400 4/3/08, Santosh Chokhani wrote:
>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.
>

I was not looking at the validation algorithm, but rather at our 
definitions of extensions. I think it is very unfortunate to have a 
mismatch between the two, as you describe.

What do others think?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Apr 2008 18:02:15 -0400

At 12:22 PM +0200 4/3/08, Peter Sylvester wrote:
>A test tool that wants to distingusih 'CA certficates, CRLsigners 
>and EE certs':

Given the description of the problem you're solving, I think there 
are several ways to perform the checks, not just one right way.

>If not; If it has CRLsign, then it is a CRL signer

I am not comfortable declaring a cert to be an EE cert by default, 
without looking at the basic constraints extension.

3280 does say that the keyCertSign bit is used to mark a CA cert, but 
the wording there is less "direct" than in the discussion of the 
basic constraints extension, i.e., 4.2.1.3  says

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

whereas 4.2.1.10 says:

"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 emphasizes the need for the CA flag to be TRUE, but also asserts 
the need for the keyCertSIgn bit to be set.  so I would argue that 
checking the basic constraints extension is the preferred 
discriminator between a CA cert and an EE cert, but that's a minor 
point since both have to have the right values for a cert to be a 
valid CA cert.

As for a CR signer, the 4.2.1.10  says:
"If the subject is a CRL issuer (e.g., the key usage extension, as 
discussed in 4.2.1.3, is present and the value of cRLSign is TRUE) 
..."

so your criteria here seems more appropriate.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Apr 2008 18:02:23 -0400

>CA certificate signing key can be used for OCSP signing.

Whoops, you're right. I had not looked at 2560, but 4.2.2.2 says 
explicitly that the response can be signed using the same key that 
was used to issue the cert, the status of which is being checked 
(although it sates this in a rather backwards fashion :-)).

Peter also pointed me to text in 3280, in the discussion of Basic 
Constraints that clearly indicates that it is OK for a CA cert to be 
used to verify non-cert and non-CRL data, in the case of cert 
enrollment protocols:

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.

Steve

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 04 Apr 2008 10:00:19 +0200

Stephen Kent wrote:
> definitions of extensions.
> I think it is very unfortunate to have a mismatch between the two, as 
> you describe.
>
> What do others think?
I think the mismatch between the two is by design : Be lenient in what 
you accept, strict in what you produce.

The validation algorithm defines what RFC 3280 accepts, the rest of the 
text what it produces, and it would be good to write this explicitly 
somewhere so that there's no confusion.
Especially this mean the validation algorithm should not be used a 
reference text to help define the certificate format of RFC 3280.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 Apr 2008 12:23:22 +0200

>
> The interface of the tools enable to specify which of the tree types 
> the input is.
Right, bu you have valid certificates that do not fall into these three 
catagories.
If "End Entity" means CA=false, then there is a forth case with "Other 
CA certficate".
> But when confronted with a cert that has CA=True but no Cert signing 
> and no CRL signing in key usage and therefore is :
> the one Auto-Detect will pick is a random choice, knowing that the 
> tool will report the cert is invalid and therefore rejected
But such a certficate is completely valid according RFC 3280. The three 
categories
do not cover all possibilities.

I agree that for  CA=false and keyusage=certsign you cannot  determine a 
valid category.

The definitions are problematic: You can have a certficate which is 
Certficate Signer and CRL Signer.
And you can have certificates of a CA which are not usable for cert/crl 
signing. If you don't
have injection such as for a certificat with certsign and crlsign, but 
slightly changing the
definition to CRL signer "only" (with certsigning), the first problem 
can be solved (and
as far as I see, the tool implements exactly this.)

The problem is that there is no surjection in the above three cases. 
There is no category that
you can explicitely select, and obviously, you cannot determine it. 
Either there is a forth case
of you modify the last to mean "EE cert or other CA certs (no CRL sign, 
no cert sign)"

> This is my main point Peter. The Auto-Detect option is inadequate for 
As well as the three explicit options.
> person producing it intended to do ?
But the cert in question IS valid: As long as the categories do not 
completely cover the
space of valid certficates, there is a problem.
For invalid certficates, i.e. invalid combinations of the values of 
basicconstraints and keyusage,
auto detection does not work indeed.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 04 Apr 2008 13:04:53 +0200

> I don't feel really at ease with that. 
Indeed.  But we are hear in a different case as I initially described. 
Since RFC 3280 makes restrictions,
and the tool in question is determining whether the CA creates good 
certficats, a V3 cert with BC
and no Keyusage is an error.

I agree with Santosh that  if one allows such a cert to participate in 
the path validation game
(i.e. one with CA=true and no keyusage) it would be accepted as signing 
certficat. The question
is whether it should be allowed to play. That's a different problem.

At least one can appreciate that the path validation algorithm is a 
concrete thing. This
would be different for example if  two rules would be replaced by
    'If the certficat can sign certificats ...'

> I'd be really wary when encoutering such a case and I'm not sure it corresponds to a very useful need.
It is non conformant, but at least we know what the path validation 
algorithm is doing.
> But so be it, and does give weight to Peter's argument that any cert with BC including CA=True should be handled as a CA cert in all cases.
In fact I said the contrary, Santosh and Steve did say that. I don't care
as long as the definition can be understood by a tester and as long as
the tool does not reject valid certificats and puts them into an 
understandable
category.

I have no idea what a user expects "Can this cert be used to sign other 
certs"
or "Does this cert belong to some (certification) authority"? Of what type
is a cert of a  TSAuthority? Assume CA=true or CA=false?

> certificate issuer if it has a key usage extension without the key 
> cert Sign bit set and fortunately step n does not do that, it only 
> allows through certificates with a *missing* key usage extension. 
Yes,
Wasn't there a famous bug several years ago in some widely deployed 
software
that allowed an end-entity to become CA? :-)

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 4 Apr 2008 07:24:08 -0400

See the following paragraph in Section 6.1 of 3280bis

"While the certificate and CRL profiles specified in sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in sections 4 and 5, this profile
   RECOMMENDS against including such checks."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jean-Marc Desperrier
Sent: Friday, April 04, 2008 4:00 AM
To: pkix
Subject: Re: CA=True for an OCSP certficat

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 4 Apr 2008 07:53:15 -0400

Guys,

You are making it lot more complicated than it is.

The interoperability approach is simple.  Constrain the producers (i.e., CA in this case).  But, the consumers need to be forgiving to enhance interoperability as long as it does not impact security.  Once an issuer declares some one to be a CA using basic constraints, unless there is a contrary information in the certificate, it is a CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Sylvester
Sent: Friday, April 04, 2008 7:05 AM
To: Jean-Marc Desperrier
Cc: pkix
Subject: Re: CA=True for an OCSP certficat

Yes,

---

From: Tom Gindin <[email-masked]>
Date: Sun, 6 Apr 2008 03:25:39 -0400

I don't think that your statement below that a v3 certificate with 
BC but no KeyUsage is an error is a correct reading.  However, I think 
that it would be better than the current rule, which seems to be the first 
sentence of the second paragraph of 4.2.1.3, "This extension (referring to 
keyUsage) MUST appear in certificates that contain public keys that are 
used to validate digital signatures on other public key certificates or 
CRLs".  If I may summarize, in RFC 3280 a certificate with 
BasicConstraints.CA set must contain keyUsage if keyCertSign or cRLSign 
conditions actually apply, but need not do so if they don't.
        I would favor either requiring that keyUsage be present in any 
certificate which contains a basicConstraints extension with CA true, or 
changing 6.1.4 (n) to suggest that verification reject any v3 intermediate 
certificate without the keyCertSign bit set, rather than allowing v3 
intermediate certificates without keyUsage present.
        Can anyone think of any legitimate reason why a CA should issue a 
certificate with CA true but no keyUsage extension present?  Does any 
existing CA software issue v3 intermediate certificates without a keyUsage 
extension?

                Tom Gindin

Peter Sylvester <[email-masked]> 
Sent by: [email-masked]
04/04/2008 07:04 AM

To
Jean-Marc Desperrier <[email-masked]>
cc
pkix <[email-masked]>
Subject
Re: CA=True for an OCSP certficat

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 6 Apr 2008 04:38:18 -0400

Tom,

The point is that for enhanced interoperability 3280 clients should be able to consume certificates that are produced by CAs that do not comply with 3280.

Thus, I do not favor a change to the RFC.

The change you suggest will make existing compliant clients non-compliant with 3280.

Finally, I do not see a security benefit to this requirement.  The issuer has already declared the subject to be a CA.  Does it have to shout at the top of its lungs and put more extensions in to say the same thing over and over.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Gindin
Sent: Sunday, April 06, 2008 3:26 AM
To: Peter Sylvester
Cc: pkix; Jean-Marc Desperrier
Subject: Re: CA=True for an OCSP certficat

                Tom Gindin

To

Yes,

---

From: Tom Gindin <[email-masked]>
Date: Sun, 6 Apr 2008 09:32:12 -0400

Santosh:

        The security benefit is to prevent compromised certificates which 
CA's originally used for SSL or OCSP from being used to issue certificates 
or CRL's.  Your point about backward compatibility is a reason not to 
change 6.1.4(n) in the way suggested, but does not apply to requiring that 
keyUsage be present in any certificate which contains a basicConstraints 
extension with CA true.  It suggests that placing a requirement to include 
keyUsage on CA's, rather than on RP's, is a better course.

Tom Gindin

"Santosh Chokhani" <[email-masked]> 
04/06/2008 04:38 AM

To
Tom Gindin/Watson/IBM@IBMUS, "Peter Sylvester" 
<[email-masked]>
cc
"pkix" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>
Subject
RE: CA=True for an OCSP certficat

Tom,

The point is that for enhanced interoperability 3280 clients should be 
able to consume certificates that are produced by CAs that do not comply 
with 3280.

The change you suggest will make existing compliant clients non-compliant 
with 3280.

Finally, I do not see a security benefit to this requirement.  The issuer 
has already declared the subject to be a CA.  Does it have to shout at the 
top of its lungs and put more extensions in to say the same thing over and 
over.

-----Original Message-----
On Behalf Of Tom Gindin

extension?

                Tom Gindin

To

Yes,

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 6 Apr 2008 20:29:13 -0400

Tom,

The RFC already says that.  I do not quite see what needs to change.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Sunday, April 06, 2008 9:32 AM
To: Santosh Chokhani
Cc: pkix; Jean-Marc Desperrier; Peter Sylvester
Subject: RE: CA=True for an OCSP certficat

        Santosh:

Tom Gindin

To

Tom,

-----Original Message-----

extension?

                Tom Gindin

To

Yes,

---

From: Tom Gindin <[email-masked]>
Date: Mon, 7 Apr 2008 08:08:04 -0400

What the RFC does not currently say is that for a CA issuing a 
certificate in which basicConstraints.CA is true, the keyUsage extension 
MUST (or at least SHOULD) also be present.  Such a statement should IMO be 
added to the existing second paragraph of RFC 3280 4.2.1.10.  The 
statement which currently occurs in the second paragraph of 4.2.1.3 does 
not cover certificates issued to CA's for reasons other than certificate 
and CRL signing.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> wrote on 04/06/2008 08:29:13 

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 10 Apr 2008 10:11:14 -0400

When a CA is issued a certificate with basic constraints asserted to be true and if the key is to be used for limited purposes (e.g., only verify signatures on CRL or only use the key for signing and/or encrypting protocol data), key usage must be present with appropriate bits set.  

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 8:08 AM
To: Santosh Chokhani
Cc: pkix; Jean-Marc Desperrier; Peter Sylvester
Subject: RE: CA=True for an OCSP certficat

                Tom Gindin

basic 
1

---

From: Tom Gindin <[email-masked]>
Date: Thu, 10 Apr 2008 19:21:03 -0400

Santosh:

        I agree with your statement, of course.  I do NOT see anything in 
3280 or 3280-bis which requires it.  The fourth paragraph of 3280-bis 
4.2.1.9, which is unchanged from the corresponding paragraph in 3280 
4.2.1.10, does not require the presence of key usage for certificates 
"that contain key management public keys used with certificate enrollment 
protocols".  If there is still time in this cycle, I would insert a new 
sentence into the second paragraph, such as "If the cA boolean is 
asserted, the key usage extension MUST be present in the certificate."
        This is a fine point, of course.  The actual security risk this 
would block is limited to undetected compromises of those keys used with 
certificate enrollment protocols.  I still would like to know from our 
fellow members who work for CA vendors if anyone actually issues v3 
certificates with cA set but without key usage.

                Tom Gindin

04/10/2008 10:11 AM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"pkix" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>, 
"Peter Sylvester" <[email-masked]>
Subject
RE: CA=True for an OCSP certficat

When a CA is issued a certificate with basic constraints asserted to be 
true and if the key is to be used for limited purposes (e.g., only verify 
signatures on CRL or only use the key for signing and/or encrypting 
protocol data), key usage must be present with appropriate bits set. 

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 8:08 AM
To: Santosh Chokhani
Cc: pkix; Jean-Marc Desperrier; Peter Sylvester
Subject: RE: CA=True for an OCSP certficat

                Tom Gindin

basic 

1