Subject: Re: [pkix] RFC 5280 Questionnaire for CAs

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 02 Sep 2009 15:52:17 +0200

David A. Cooper wrote:
> (5) Can the CA issue delta-CRLs?  Have you verified that
>     clients developed by other vendors can use the
>     CRLs to verify the status of certificates?

Here in France, the CA of health professionals, gip-cps, is a very large 
scale exemple of the use of delta-CRLs. Software that are certified to 
work with it are required to be able to use them.

Unfortunately, all the documentation I can find is in french.

The following public url :
ldap://annuaire.gip-cps.fr/cn=gip-cps classe-1, ou=gip-cps 
professionnel,o=gip-cps,c=fr?deltarevocationlist;binary
allows access to one of the delta crl DP of that CA.

It's published in the following document in chapter 5.3.2 :
http://www.gip-cps.fr/pdf/certif/CPS2ter%20Certificats%20X-509%20V1-4c.pdf
together with more technical info about that CA, the description of 
certificate profiles inside can probably be understood without reading 
french.

Another point, about a feature what you might consider as a really 
minor, but that I'd really like to know what the open usage of is.

The "basic constraint" chapter in RFC5280 says that :
    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.

Whilst the text literally says "this extension", the logical 
interpretation is that the intend is to enable those CA certificates to 
include a CA boolean set to true, in addition to the certificate that 
are intended to be used to verify certificate signatures.

So did you find certificates that make use of this possibility ? Do 
other member of the list know about some ?

In my experience, CAs just don't use that, I have seen several 
certificates use for enrollment protocols, they did not have CA set to 
true, the main public OCSP server certificates do not set CA to true, 
and in my opinion it would be better to remove that text because I have 
yet to find the specific, useful purpose that it serves, compared with 
the danger of the possible confusion setting CA to true can have if 
there's any software around that only takes into account the sentence 
"The cA boolean indicates whether the certified public key may be used 
to verify certificate signatures" and forgets the possible 
interpretation of the other sentence.

Anyway I think the current text is simply bad.  Either it should be made 
really clear everywhere that CA can be set to true for certs that are 
not intended to generate certificate signatures, or it should be clearly 
forbidden to set it to true for any other kind of certificate.
But currently the text goes both way, depending on which part you read.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 02 Sep 2009 17:42:02 +0200

Peter Sylvester wrote:
> This has been discussed more than a year ago

It was discussed before the RFC5280 was published, so before the text 
about the cA boolean changed from "The cA boolean indicates whether the 
certified public key belongs to a CA." in RFC3280 to "The cA boolean 
indicates whether the certified public key may be used to verify 
certificate signatures." in RFC5280.

I do not share your view that this change means nothing.

> At least not the piece that you gave.

That's the other piece that I gave "The cA boolean indicates whether the 
certified public key may be used to verify certificate signatures".

That's the only positive info in the RFC on what setting the cA boolean 
means : "allows to verify certificate signatures". What *does* it mean 
to set it on a certificate that is not intended for that ? There's no 
indication about that in RFC5280.

Your interpretation is that in that case the flag means "this 
certificate is operated directly under control of a CA".
If so, it would be good if we'd come back to something nearer the old 
text, like for example :
    The cA boolean indicates whether the certified public key belongs to
    a CA. The certified public key may be used to verify certificate
    signatures only if the cA boolean is set.

Even if it so, when such a certificate is used, there's a caveat emptor 
: "make certain the certificate will really be used by a CA, or else 
this flag is not acceptable".

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 02 Sep 2009 17:09:17 +0200

Jean-Marc,

>
> Anyway I think the current text is simply bad.  Either it should be 
> made really clear everywhere that CA can be set to true for certs that 
> are not intended to generate certificate signatures, or it should be 
> clearly forbidden to set it to true for any other kind of certificate.
This has been discussed more than a year ago,  the text clearly says 
that CA can be set for
certs that are not necessarily intended to generate certificate signatures.

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 02 Sep 2009 20:59:15 +0200

Jean-Marc Desperrier wrote:
> about the cA boolean changed from "The cA boolean indicates whether 
> the certified public key belongs to a CA." in RFC3280 to "The cA 
> boolean indicates whether the certified public key may be used to 
> verify certificate signatures." in RFC5280.
The text was stable since draft 1 issued July 2005. The discussion was 
based on the
draft. The last draft was in february (11), the discussion was in April 
2008 on
the bases of these texts, no single has been changed since.

> I do not share your view that this change means nothing.
The changed text was simply and only a correction of unprecise wording,
to exclude any possible interpretation that was not ment  nor verifyable.
> That's the other piece that I gave "The cA boolean indicates whether 
> the certified public key may be used to verify certificate signatures".
>
> That's the only positive info in the RFC on what setting the cA 
> boolean means : "allows to verify certificate signatures". What *does* 
> it mean to set it on a certificate that is not intended for that ? 
> There's no indication about that in RFC5280.
Yes, text says, when the flag is TRUE, then it might be used to verify 
signature provided
that keyusage is compatible of course.

> certificate is operated directly under control of a CA".
No. Strictly speaking, I have no interpretation for the case CA true 
keyusage not certsign/crlsign.
If A ==> B is true, you cannot say anything about  B ==> A or  notA ==> 
notB

>    signatures only if the cA boolean is set.
I say, that this is not my interpretation. 3280 suggested this, and that 
was why it
was removed.

>
> Even if it so, when such a certificate is used, there's a caveat 
> emptor : "make certain the certificate will really be used by a CA, or 
> else this flag is not acceptable".
Since it is not so ...

There is no test implied anywhere concerning a CA=TRUE independantly of 
keyusage.
Note in particular:

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3). 

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

Peter

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 02 Sep 2009 17:03:33 -0400

This issue has probably been discussed several times.  I found a
discussion about this in the PKIX mail list archive from April and May
of 2001 (http://www.imc.org/ietf-pkix/old-archive-01/mail3.html).

Peter Sylvester wrote:

It was discussed before the RFC5280 was
published, so before the text

I'll just note that X.509 says:

The cA component indicates if the certified public

key may be used to verify certificate signatures.

While one might argue whether the text in RFC 3280 was inconsistent
with this, it seems clear that the text in RFC 5280 is consistent with
this.

Dave

Peter Sylvester wrote:

Peter Sylvester wrote:

Since it is not so ...

Peter

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix
.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 03 Sep 2009 00:16:30 +0200

Peter Sylvester wrote:
> Strictly speaking, I have no interpretation for the case CA true

Peter, I can hardly believe what I read here.
Are you really writing that at the end, your position about all this 
comes down to : the case "CA true keyusage not certsign/crlsign" is ... 
undefined !

If so, I hope you can understand why as a programmer I don't even want 
to dip a toe in there.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 03 Sep 2009 00:41:36 +0200

At the end, I think the acid test is :
     Do established CAs or CA products in their normal configuration 
make use of that or not ?

Findings about that would be useful in the task of determining how that 
feature is actually implementated and advancing the text further in the 
standard path.

David A. Cooper wrote:
> While one might argue whether the text in RFC 3280 was inconsistent with
> this, it seems clear that the text in RFC 5280 is consistent with this.
>
> Dave
>
> Peter Sylvester wrote:

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 Sep 2009 03:30:38 +0200

> Peter, I can hardly believe what I read here.
You are misinterpreting I think.
> comes down to : the case "CA true keyusage not certsign/crlsign" is 
> ... undefined !
No, undefined is something else.  "no interpretation" means, it doesn't 
matter,
what value you have for CA if keyusage is only digitalsignature.  Both 
values
are acceptable and have no influence  on the  possibility to verify a
signature on anything other than a cert or crl (unless otherwise said).

The bug that I am referring to is that you say that it is *invalid*
for an OCSP signer with keyusage signature and/or non-rep
to have BC CA=true. Idem for a timestamp cert.

That was the conclusion of the discussion as far as I remember.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Sun, 06 Sep 2009 12:01:44 +0200

Peter Sylvester wrote:
>> [...]
> No, undefined is something else. "no interpretation" means, it
> doesn't matter, what value you have for CA if keyusage is only
> digitalsignature. Both values are acceptable and have no influence on
> the possibility to verify a signature on anything other than a cert
> or crl (unless otherwise said).

Sorry Peter, but your demonstration is wrong.

The trouble with it is that if it were true, it would apply exactly the 
same to any kind of certificate.
What you are saying here would apply exactly the same to a SSL, 
signature, authentication, encryption certificate.

You are saying here is the hole in the spec that I'm using to give 
myself the right to set cA to true for OCSP and timestamping.

I'm replying you that the hole as you describe it can be used for any 
kind of certificate, and therefore if your interpretation is valid, the 
cA boolean looses any kind of meaning.

Let's try to make this discussion meaningful now that you have defined 
some context by saying the one you want to set cA to true for are OCSP 
and timestamping certificates.

I could be OK with an interpretation of setting cA to true for some OCSP 
responders, together with a good explanation like for example how it 
allows to make the distinction between a OCSP responder whose revocation 
information is directly handled by the CA and an independent OCSP 
responder. But where would be the limit ? An independant OCSP could say 
after all he is just using directly the CRL issued by the CA, so has 
exactly the same info as CA operated OCSP that's in fact internally 
based on CRLs like many are. There would almost be a whole litterature 
to write in order to describe that precisely. None of it exists. And to 
my knowledge, no CA currently sets that flag for it's OCSP responder 
(I'd would enjoy been proven wrong with a concrete example. We'd stop 
discussing about how many angels can dance on the point of a needle and 
be back in the concrete).

As for timestamping, I don't see how there could be any meaningful use 
of cA set to true. Timestamping is for me an orthogonal concept to CA. 
If it happens that as cA also acts as a timestamping authority, I don't 
care. Each of the role MUST have no consequence on the other.

So as a conclusion, for me, both are bad practice, a dark corner of the 
spec where even the best experts are at a lost when asked to provide 
precise guidance. Therefore the best thing to do is to stay away from 
it, and to also strongly recommend everyone else to do the same.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 08 Sep 2009 21:02:00 +0200

> Sorry Peter, but your demonstration is wrong.
Jean-Marc, could you show some specification in
rfc 5280 or others that forbids to set Ca=true in
certificats that are not used to verify signatures
on certificats.

what text forbids to set  ca=true in an ssl 
ee certificat for example, etc?

you care for the value of CA if only crlsign is said?

/p

---

From: Tom Gindin <[email-masked]>
Date: Tue, 8 Sep 2009 21:15:59 -0400

I think we have two basic schools of thought here.  The first 
school is that any certificate with CA set must exercise a CA-specific 
function.  In particular, it should normally have keyCertSign or cRLSign 
set in KeyUsage, or perhaps id-kp-OCSPSigning in ExtendedKeyUsage.  The 
second school is that any certificate with CA set belongs to a CA, and 
thus to an entity with at least one certificate with keyCertSign - but 
that server authentication or even e-mail certificates from a CA can have 
CA set.  The fourth paragraph of RFC 5280 section 4.2.1.9, clearly comes 
down on the side of the second school ("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").  That same text occurs in RFC 3280 section 
4.2.1.10 as well, although not in RFC 2459.
        As you point out in passing, Peter, there's usually little reason 
for relying party software to make decisions based on the value of the CA 
flag if the keyUsage extension is present.  If keyCertSign is set, CA must 
be set; if cRLSign is set but not keyCertSign, CA is irrelevant; if a CA 
operates an SSL server, CA is probably irrelevant and will be ignored by 
most SSL client code.  I guess code could be written which refused to 
upload a PKCS#10 unless CA were set in the SSL server certificate.  RFC 
4210 doesn't suggest that similar things be done in CMP, nor does 
cmp-transport-protocols.

                Tom Gindin

From:
Peter Sylvester <[email-masked]>
To:
Jean-Marc Desperrier <[email-masked]>
Cc:
[email-masked]
Date:
09/08/2009 03:03 PM
Subject:
Re: [pkix] cA field of basicConstraints extension (was Re: RFC 5280 
Questionnaire for CAs)
Sent by:
[email-masked]

/p

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 09 Sep 2009 11:18:33 -0400

I hate to get involved in this discussion, but I believe that I fall 
into a third camp.

X.509 says:  "The cA component indicates if the certified public key may 
be used to verify certificate signatures."

RFC 5280 says:
   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.

I have seen no text in either X.509 (or RFC 5280) that says that the cA 
boolean is intended to generally indicate whether the subject is a CA or 
whether the subject public key is used to perform "CA-like" functions.  
So, my believe is that if the subject public key cannot be used to 
verify certificate signatures then the cA boolean should not be asserted.

For that reason, I do not agree with your interpretation of the second 
sentence in the following paragraph:

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

This paragraph only discusses when the extension MUST/MAY appear in a 
certificate, not that value of the cA boolean in such certificates.  In 
order to accept your interpretation, I would have to accept that the cA 
boolean indicates whether the certificate is a CA certificate rather 
than indicating "if the certified public key may be used to verify 
certificate signatures".

But, I do agree with you that this shouldn't really affect relying 
parties.  If the certificate is being used as an intermediate 
certificate in a certification path (i.e., if the certified public key 
is being used to verify a certificate signature), then both X.509 and 
RFC 5280 are very clear that the basicConstraints extension must be 
present with cA=TRUE (even if the keyUsage extension is present with 
keyCertSign asserted, although it would be wrong for a CA to issue such 
a certificate).  If the certified public key is being used to verify a 
signature on anything other than a certificate, then the presence or 
absence of the basicConstraints extension and the value of the cA 
boolean if the basicConstraints extension is present is irrelevant.

Dave

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 09 Sep 2009 19:45:44 +0200

Tom, David, as far as I understand, you both conclude that
with the actual texts the value of ca is "irrelevant" except in one case
where it MUST be true;  it is not illegal/prohibited by some
MUST in rfc 5280 or x509 to set it to any value
if keyusage does not include certsign. (The text in X509
is somewhat tie break). 

David,

you said:
"I have seen no text in either X.509 (or RFC 5280) that says that the cA 
boolean is intended to generally indicate whether the subject is a CA or 
whether the subject public key is used to perform "CA-like" functions."

good, you didn't say "I can't see nowhere" :-)
I have not seen in the bible, in any encyclopedia a statement that says 
"that the cA boolean is intended to generally indicate whether the 
subject is a CA or whether the subject public key is used to perform 
"CA-like" functions". More, if I look around, I don't find such thing
on any street sign. There are many facts that indicate whatever 
something else, the number is huge.

  "So, my believe is that if the subject public key cannot be used to 
verify certificate signatures then the cA boolean should not be asserted." 

Hm....

IMO or AFAIK, the reason for having MUST, MAY SHOULD
in rfcs is to avoid normal logically ambiguities and traps of
natural languages in order to establish "Boolean" logic
(there should be AND, OR I think, at one of them).
The argument above is not not even natural non-Boolean
logic, I don't have the right term. :-)

Well, one can have all kinds of ideas of what ca=true could mean
in other cases, including that nobody cares, currently
there is no need for a work item IMO or the contrary.

"This paragraph only discusses when the extension MUST/MAY appear in a 
certificate, not that value of the cA boolean in such certificates."
Excellent point. 
BTW: In the text what means CA certificate in:
 "CA certificates that contain public keys used
  exclusively for purposes other than validating digital signatures on
  certificates."
Although I refered to the paragraph it is actually not needed
as an argument.

Wasn't this the same conclusion last year?
This hasn't changed since as far as I interprete the comments.

Peter

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 10 Sep 2009 11:40:33 +0200

> Wasn't this the same conclusion last year?

What conclusion ? I've been reading that message twice and saw no 
conclusion.

When you insist that the RFC can be interpreted as meaning that any 
certificate can have cA set to true, I am bothered by your lack of 
concern over wether this interpretation serves any useful purpose, and 
over wether anybody implements that.

The IETF standard process in opposite relies on actual implementation 
and recommends that features that are not actually used should be removed.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 10 Sep 2009 14:08:38 +0200

Tom Gindin wrote:
> CA set.

Skimming through the 2001 discussion that David referred to, I didn't 
see those two schools. I saw some people in favor of the strict 
interpretation that cA should be set to true only for certificate that 
can sign other certificat, and some defending that CRL signer can have 
it set also. I might have missed a part of the discussion referring to 
applying it to other certificates types though.

>  The fourth paragraph of RFC 5280 section 4.2.1.9, clearly comes

And the second paragraph clearly comes down on the othe side.
As for the four paragraph, one can note as David just did, that it only 
refers to the Basic Constraint extension, not specifically to cA.

Basically, the text is not as clear as one would wish.

> most SSL client code.

Here you said "most SSL client code", not "all". Would you dare say "I'm 
certain that it will have no consequence, or if it does, a really 
deliberated and intended consequence" ? :-)

>  I guess code could be written which refused to

I have never seen actually that case, but there's something else 
similar. It's the case where the certificate request exports the private 
key for the key recovery server of the CA.
The Microsoft implementation of that is secured by the fact the name of 
the certificat is identical to the DN of the CA, postfixed with "-Xchg". 
The older implementation used to explictly set cA to false in the Basic 
Constraint extension. The newer one does not include Basic Constraint at 
all, and has a Application Certificate Policy (private MSFT extension 
1.3.6.1.4.1.311.21.10) extension with a Policy Identifier set to Private 
Key Archival. The various incarnation of the Netscape Certificate 
Management System do not either set cA to true in that case.

I think this is a good exemple of the problem with the idea of giving a 
special meaning to cA = true to certificates other than certificate or 
CRL signing. It's not specific enough to be really useful. The CA ends 
up implementing something much more specific to control the use of the 
certificate, and not needing cA = true.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 10 Sep 2009 15:43:36 +0200

> What conclusion ? I've been reading that message twice and saw no 
Hm.
> over wether anybody implements that.
Advocatus diaboli non est diabolus. 
> and recommends that features that are not actually used should be removed.
1 - feel free to write a draft, currently we don't have a proposal.
     Do you want something like: "If keyusage does not have certSign, 
then bc.ca MUST not be true."
     because of ... ?

2 - Since you want to prohibit something, you seem to admit that it is 
not forbidden at this moment.

Have fun.

---

From: Tom Gindin <[email-masked]>
Date: Sun, 13 Sep 2009 14:13:13 -0400

Responses below.

                Tom Gindin

Jean-Marc Desperrier <[email-masked]> wrote on 09/10/2009 08:08:38 AM:

> [image removed] 
> Jean-Marc Desperrier 
> to:
> 09/10/2009 08:09 AM
> Peter Sylvester, pkix
        Most of the discussion dealt with CRL signing, but not all of it. 
My archive shows people saying things like "However, a CA does more than 
just issue certificates and CRLs. A CA may have a private key dedicated to 
signing PKI transaction messages (e.g., certification response, revocation 
response, proof-of-possession challenge). If a certificate were issued to 
a CA with its PKI transaction message verification key as the subject 
public key, neither the keyCertSign nor the cRLSign bit in KeyUsage would 
be set, but the subject of the certificate would still be a CA." (David 
Cooper at http://www.imc.org/ietf-pkix/old-archive-01/msg01269.html) 
Sharon Boeyen's message in the same thread (
http://www.imc.org/ietf-pkix/old-archive-01/msg01271.html) seems to be in 
favor of "keyCertSign only", although it doesn't quite say so ('Clause 
8.4.2.1 on basic constraints "...with the certified public key being used 
to verify certificate signatures", that's the key to use of that bit in 
the extension'), and she was editor of X.509 at the time.

> deliberated and intended consequence" ? :-)
        No, I can't guarantee that.  See my next paragraph for a 
relatively sensible use of the CA flag for an SSL certificate.

> Management System do not either set cA to true in that case.
        What does relying party software do in such a case?  What you have 
here is MS CA software saying essentially "We don't regard CA key recovery 
certificates as deserving the CA flag in BasicConstraints".
 
> certificate, and not needing cA = true.

        Again, certificate extensions are primarily used by the relying 
party rather than by the CA.  Is there any RP software out there which 
uses the CA flag on a certificate with neither keyCertSign nor cRLSign to 
mean "the certificate in question does belong to a CA, and thus I can 
perform the following action which is only appropriate towards a CA"?  If 
there is no such software, an extendedKeyUsage value would be a better 
idea to indicate the actual function.