Re: cA flag and CRL issuers (was Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments)

[Stephen Kent <kent@xxxxxxx>]

David,

> Steve,
>
> If we are going to change PKIX to require the cA bit in 
> basicConstraints to be set even when the subject public key can only 
> be used to verify signatures on CRLs, then we need to be sure that 
> the text clearly explains to readers when the cA bit should or 
> should not be set. Currently new-part1-06 states that "[t]he cA bit 
> indicates if the certified public key may be used to verify 
> signatures on other certificates." The clearly is not accurate, 
> since if the cA bit is set one still does not know whether the 
> subject public key may be used to verify signatures on certificates. 
> One must look at the keyUsage extension to make that determination.
>
> I think it would be helpful to the discussion that we are having if 
> you would clearly state your interpretation of the meaning of the cA 
> bit in basicConstraints.

First, it's not an issue of "my interpretation."  As I noted earlier, 
prior to v3 certs and v2 CRLs, there was no way that anyone could 
interpret the text to suggest that a non-CA entity could issue a CRL. 
V3 certs and v2 CRLs might admit this possibility, syntactically, but 
no text in X.509 nor 2459 identifies a new entity type that could 
issue CRLs, and thus the syntactic ambiguity is not supported by the 
semantics expressed by the rest of the text that describes PKI 
components and responsibilities. So, the status quo is that only CAs 
sign CRLs.  The suggestion is to change this. I am comfortable if we 
do that, but only if we go back and introduce a new entity that can 
sign a CRL and not be a CA. So, my "interpretation" of the CA bit is 
simple; it identifies a cert as belonging to a CA and used to 
validate certs or CRLs. This is consistent with the notion that the 
bit needs to be set whenever the processing of the object using the 
public key from the cert is constrained by the presence or absence of 
that bit.

>  From what I have read so far, it appears that you believe that the 
> cA bit should be used to indicate if the subject of the certificate 
> is a CA. But, if this is the case, then new-part1-06 still does not 
> accurately reflect your notion of the cA bit. Currently the text 
> states that the cA bit may only be set if the keyCertSign bit or the 
> cRLSign bit in keyUsage is set. 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.

This is an example where the processing of the signature on the 
signed object is not constrained by the presence or absence of the CA 
bit. I think the text you cite about setting the CA bit ONLY when 
other bits are set should be reviewed; it may be fine as is, but we 
need to decide whether we backed into this characterization or 
whether we mean exactly what it says.


> So, should the cA bit be used to indicate if the certificate subject 
> is a CA or to indicate that the subject public key may be used to 
> verify signatures on certificates and/or CRLs? If the latter, then 
> not all certificates issued to CAs will have the cA bit set.

A fair question. My answer above would say that not all certs 
employed by a CA would have to have the bit set, e.g., because some 
objects signed using a key associated with a CA are employed in 
protocols that do not mandate checking the CA flag.

Steve