Subject: When to set CA = True ?

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 11 Apr 2008 11:15:57 +0200

This is a subsidiary discussion on the "CA=True for an OCSP certficate" 
subject in order to determine which certificates exactly can have the 
CA=True set.

In a talk with me (outside of the list), Peter interpreted that the  
4.2.1.10 Basic Constraints chapter sentence, "The cA boolean indicates 
whether the certified public key belongs to a CA." means that all 
certificates technically operated by the CA may have the CA=True bit set.

I'm not fully satisfied with that because it means that any kind of 
certificates used by a CA will have the cA boolean set which will 
probably not be very well interpreted by softwares and dilutes the 
meaning of that bit.
Also it goes in the opposite direction of this sentence in chapter 
"4.1.2.6 Subject"

    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)

which allows even a crl issuer cert to not have the cA boolean set, so 
goes in the direction of "few certificates should have the cA boolean 
set to true".

Rereading also this in chapter "4.1.2.6 Subject"
    If
    the subject is a CA (e.g., the basic constraints extension, as
    discussed in 4.2.1.10, is present and the value of cA is TRUE), then
    the subject field MUST be populated with a non-empty distinguished
    name matching the contents of the issuer field (section 4.1.2.4) in
    all certificates issued by the subject CA

and the first sentence of  "4.2.1.10 Basic Constraints"

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

as well as the rest of the text, I'm more in favor of another 
interpretation that in my opinion underlines the whole text but is not 
explicitly enough described.

A CA (as has been already lengthy discussed here) is defined by it's DN.
Every certificate that have the same DN design the same CA.
So when the text says "If the subject is a CA" - "the subject of the 
certificate is a CA", this mean quite clearly "when the DN in the 
subject identifies a CA entit"y, and so only certificate whose subject 
is equal to the subject of a CA entity may have the CA=True bit set.

Going further I'd suggest that it would make things a lot clearer and 
more precisely determinated to make it a must that all certificates 
emitted with a subject that is the DN of a CA entity MUST have the basic 
Constraint cA boolean set to true, and all certificates emitted with a 
subject that is not the DN of a CA entity MUST NOT have the basic 
Constraint cA boolean set to true.

The point in chapter "4.1.2.6 Subject" that allows a CRL Issuer to not 
have the  cA boolean set to true would then correspond to the fact that 
when the CRL Issuer entity is also acting as a CA, it MUST have the cA 
boolean set to true, but when the CRL Issuer is a delegated crl issuer 
that does not also act as a CA entity, it MUST NOT have it set.
This would make things a lot less fuzzy by providing clear guidance on 
when to set that bit.

This been said I know at least one CA that does not set the cA boolean 
true on it's crl issuer certificate, despite it not being a delegated 
crl issuer (Crl verification relies on the fact the DN is the same as 
the DN of the CA).
That approach would be the "let's never set the cA boolean true except 
on certificates that sign other certificates" approach which can also 
make sense, because in the current state of things they are the only 
ones that actually require that bit.

---

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

RFC 3280 says:

   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 does not exclude OCSP, SCVP, DVCS responders, TSAs, LTAP servers
XKMS services or whatever else you might associate to a CA. 

A technical of CA=true is only associated to CertSigners (in the
path validation routine, and in the keyusage requirements. 
Other protocols/usages are not concerned. 

One may conclude from the text in 3280 
that if issuer=subject then CA=true must be set.
but I am not sure because of the difference 
in the first and second sentence in 
the description of basic constraints.

   certificate is a CA ... 

   The cA boolean indicates whether the certified public key belongs to
   a CA.  

I don't think that this really matters.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 14 Apr 2008 13:37:12 +0200

Peter Sylvester wrote:
>   signatures on certificates.    Such CA certificates include ones that
Yes, it doesn't. On the other hand, it just say it can occur inside 
them, it doesn't say which value should be used.
> I don't think that this really matters.
I'm now certain it matters even more that I thought, and also that my 
interpretation was too open.
I've just checked what exactly X.509/200508 says about it.
http://www.itu.int/rec/T-REC-X.509-200508-I/en
Well it's a similar text, but the differences make it a lot clearer 
about what the intent is :

8.4.2.1 Basic constraints extension
This field indicates if the subject may act as a CA, with the certified 
public key being used to verify certificate
signatures. [...]
The cA component indicates if the certified public key may be used to 
verify certificate signatures.

So here we are, one should only set cA=true on keys that are intended to 
sign other certificates.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 17 Apr 2008 01:30:53 +0200

Jean-Marc Desperrier wrote:
> This field indicates if the subject may act as a CA, with the 
> certified public key being used to verify certificate
> signatures. [...]
> So here we are, one should only set cA=true on keys that are intended 
> to sign other certificates.
>
I had a talk about this with Peter on monday.

He has noticed an additional point; the path validation algorithm in 
X509/200508 does not require to check the key usage extension.
All certs that have CA=true are valid to sign other certificates.

We threfore have a very clear contradiction between x509 and the 
following in RFC3280

About x509, Peter thinks, and I agree with him, that it would be best to 
issue a Technical Corrigendum to align it with RFC3280 and require the 
checking of KeyUsage in path validation.
But still, that leaves potentially many implementations that use the 
current path validation and will consider any cA=true cert as valid to 
issue other cert.

My point of view on this subject (I know Peter strongly disagrees) is 
that setting ca=True on CA certificates that contain public keys not 
intended to validate other certs is not terribly useful.
AFAIK existing usage is not to set it to true.
Verisign does not set it to true on it's OCSP responders.
The Microsoft CAdoes not set it to true on key recovery certificates.
I've never seen until any vendor setting it to true on their non-cert 
signing, non-crl signing certs.

I'd strongly be in favor of simply removing that text, and recommend 
instead to set cA to be set to TRUE only for public keys that can sign 
other certs.
I don't see the gain of allowing it to be set for other key pairs that 
justifies the potential risk it gives for any existing application that 
would do path validation according to x509 instead of according to RFC3280.

Also, about my point that the current text should understood as meaning 
that only certs that have the same DN as the CA can have cA set to true, 
I was beginning to think that maybe it was far fetched and I was 
overinterpreting the meaning of 'subject', but there's another part of 
the text that leads to the same conclusion  :

4.1.2.6  Subject

    [...] If
    all certificates issued by the subject CA. [...]

So if the cert has cA set to TRUE, the subject is a CA. And if the 
subject is a CA, the subject field MUST be populated with the DN the CA 
uses when signing certificates.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 21 Apr 2008 14:06:57 +0200

Hello, is there someone how wants to comment on what Marc is indicating.
I am not sure having the latest version of X509 (maybe there are amendments,
big reports etc.)

 From what I see the definitions of the path validation algorithm
don't seem to be the same in pkix and x509?

Jean-Marc Desperrier wrote:
> About x509, Peter thinks, and I agree with him, that it would be best 
> to issue a Technical Corrigendum to align it with RFC3280 and require 
> the checking of KeyUsage in path validation.
> justifies the potential risk it gives for any existing application 
> that would do path validation according to x509 instead of according 
> to RFC3280.
>
> Also, about my point that the current text should understood as 
> meaning that only certs that have the same DN as the CA can have cA 
> set to true, I was beginning to think that maybe it was far fetched 
> and I was overinterpreting the meaning of 'subject', but there's 
> another part of the text that leads to the same conclusion  :
>
> 4.1.2.6  Subject
>
>    [...] If
> subject is a CA, the subject field MUST be populated with the DN the 
> CA uses when signing certificates.
>
>

-- 
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: Peter Sylvester <[email-masked]>
Date: Mon, 21 Apr 2008 19:11:04 +0200

I admit having been surprised by the text of the path validation in 
>   signatures on certificates.
I don't think so:  This is just text to introduce the extension. The 
definition later is
quite clear: If you want  a cert to be usable for certsigning then CA 
must be true.
but this condition is may not be sufficiant because one must check all 
oher extensions
according the rules, in particular keyusage. I

If you make keyusage critical, or if you are a 3280 conforming system that
MUST support keyusage, then a cert that does not have keysuage cert sign
will not be mistaken as something that can sign a anothre cert.
This is also the case in X509 at least if the extension is critical.

> the checking of KeyUsage in path validation.
After rereading X509, I do not thinh that there is a problem with X509, 
at least not more than
with the SHOULD of making keyusage critical in PKIX.
> intended to validate other certs is not terribly useful.
I have no opinion about whether this is terribly useful or not.

> AFAIK existing usage is not to set it to true.
Well, at least the text in RFC 3280 seem to indicate that there
are certficates whether the contrary is true.
> instead to set cA to be set to TRUE only for public keys that can sign 
This is not in X509 and is not in RFC 3280.
> that would do path validation according to x509 instead of according 
As long as you set keyusgae critical, there should not be any risk. And 
even if keysuage is
not critical, I doubt that there are many implementations that do not 
understand keyusage.

In the particular profils that we are talking about keyusage MUST be present
and critical, so there is no danger
> CA uses when signing certificates.
Nobody requires that this CA will ever issue certs under that name.