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

["David A. Cooper" <david.cooper@xxxxxxxx>]

At 05:31 PM 4/28/01 -0400, Stephen Kent wrote:
> 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.

I still can not find any text that justifies the requirements that you
claim to exist. X.509 clearly states:

        

The
cA component indicates if the certified public key
may be used to verify certificate signatures

        

if the
value of cA is not set to true then the certified
public key shall not be used to verify a

        

certificate
signature

        

If this
extension is not present, or is flagged non-critical and is not
recognized by a

        

certificate-using
system, then the certificate is to be considered an end-entity
certificate

        

and cannot
be used to verify certificate signatures

These statement clearly impose a requirement on certificate issuers to
include basicConstraints with cA=true if the subject public key in the
certificate is to be used to verify signatures on certificates. The third
quote seems to impose a requirement on relying parties to check for the
presence of basicConstraints with cA=true before using a subject public
key to verify signatures on certificates. Where is the corresponding text
for CRLs?

You seem to suggest that the requirement exists implicitly as a result of
a requirement for only CAs to issue CRLs. However, according to the text
in X.509, the cA bit does not indicate whether or not the certificate
subject is a CA. It only indicates whether the particular subject public
key may be used to verify signatures on certificates.

I think the proper interpretation of a requirement that only CAs can
issue CRLs is that it imposes a requirement on certificate issuers to
only set the cRLSign bit in a certificate if the subject is a CA. If only
CAs can issue CRLs, and certificate has the cRLSign bit set, then the
relying party should be able to conclude that the subject of the
certificate is a CA. Given this, why should the relying party need to
check to see if the cA bit is set (a bit that merely indicates whether
the subject public key can be used to verify signatures on certificates)?
There are certainly no security implications.

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

Again, other than for verifying the signature on a certificate, where is
the use of a public key to verify a signature constrained by the presence
or absence of the cA bit? You claim that X.509 requires CRL issuers to be
CAs, but that is not sufficient to demonstrate a requirement with respect
the cA bit. If X.509 stated that the cA bit indicates whether the subject
is a CA, then perhaps you would be correct in claiming that such a
processing requirement exists. However, X.509 is very clear about the
meaning of the cA bit, and it states that the cA bit is simply an
indicator of whether the subject public key may be used to verify
signatures on certificates.

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

So, does this mean that the cA bit is not fully defined? There are some
cases where the bit should definitely be set, others where it should
definitely not be set, and then other times when proper value for the bit
is undetermined. Somehow a definition of "the cA flag should be set
when the subject public key may be employed in protocols that mandate
checking the cA flag" seems inappropriate.

The cA bit should be a source of information. CAs should know when the
bit should or should not be set and relying parties should know what it
means when the bit is or is not set. How can certificate processing
requirements be meaningful if the data in the certificates that is used
in the processing has no meaning?

Dave