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

From: Stephen Kent <[email-masked]>
Date: Sat, 28 Apr 2001 17:31:08 -0400

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

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 May 2001 18:11:05 -0400

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 May 2001 18:45:26 -0400

Dave,

I provided an analysis of the evolution of CRL signing from V1 + V2 
certs, to the changes you cite re V3 certs.  You have chosen to 
ignore large parts of this analysis, and focus on text in the current 
version of X.509 that emphasizes syntactic details but not the larger 
semantic context. You have not adressed the fact that both X.509 and 
RFC 2459 make repeated references to "authorities" or CAs re CRL 
issuance. You have received feedback from Sharon, and I think several 
of the 2459 authors have weighed in on this topic during the 
multi-week debate.

I see no point in continuing the discussion.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 16 May 2001 12:31:48 -0400

Steve,

Santosh has stated that setting both the cA flag and the cRLSign
bit provides no security advantage over setting the cRLSign bit only.

Tom Gindin has said:
>   Just BTW, my reasoning is similar to Santosh's.  I would like to
> mention that the reasons for issuing a distinct CMP certificate for a CA
> are even stronger than those for a distinct CRL certificate.  However, it
> is not obvious whether this should be classed as a CA certificate since a
> certificate to be used with CMP looks more like a standard server
> certificate.

Russ Housley has said:
> Dave:
>
> Your first two arguments seem to be compelling.
>
> Russ
>
> At 11:42 AM 4/30/2001 -0400, you [David Kemp] wrote:
> >
> >1) Previously, conforming clients could validate a CRL if the cRLSign
> >    bit is asserted and the cA flag is not asserted.  This change
> >    would declare such clients to be non-conforming.
> >
> >2) [snip]
> >    My position is that no additional flag is needed in either the CA or
> >    the AA case.  If the CRL signer has a valid certificate with the
> >    cRLSign bit set, then it is an authority because the certificate
> >    signer (or it's parent) has said so. Requiring two flags in the
> >    same certificate is no more secure than requiring one.

Denis Pinkas has said:
> As far as I remember, originally the cA boolean in the basic constraints 
> extension only allowed to make the difference between leaf  certificates and 
> CA certificates. This boolean now seems to be be used with a different 
> meaning (and, maybe, we should change its meaning - not the syntax). 
>
> Could someone say again, why that change was requested and 
> what are the real benefits of that change ? 

You have ignored David Cooper's point that the CA signs the certificate
containing the cRLSign bit, and therefore relying parties know
conclusively that a certificate with cRLSign asserted (and cA not
necessarily asserted) contains the public key that the CA uses to
sign CRLs.  This is the semantic context that matters - as you say,
the CA is responsible for signing CRLs.  The CA can unambiguously
designate the key RPs use to validate its CRLs by setting only the
cRLSign bit in a self-issued certificate.

I believe it is time for you to call for a straw poll on whether
to make extensive changes to the texts of PKIX and X.509 to
require the cA flag to be set in certificates used to validate CRLs

By my count, at least 5 people believe there is no need for such
a change:

Santosh Chokhani
David Cooper
Denis Pinkas
Russ Housley
Dave Kemp

I have not heard from Tim Polk since Russ' conversion :-), and I can't
determine a position from postings by Tom Ginden and Sharon Boeyen.

Dave

----------------- Begin Included Message ---------------------------

> Date: Tue, 15 May 2001 18:45:26 -0400
> To: "David A. Cooper" <[email-masked]>
> From: Stephen Kent <[email-masked]>
> Subject: Re: cA flag and CRL issuers (was Re: Last Call:   
draft-ietf-pkix-new-part1-06.txt comments)
> Cc: [email-masked]

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 16 May 2001 10:46:45 -0400

Steve,

My interest is in ensuring that the PKIX Certificate and CRL Profile is correct, consistent, and complete. If these issues are not of interest to you, then feel free to ignore this message.

At 06:45 PM 5/15/01 -0400, Stephen Kent wrote:
>Dave,
>
>I provided an analysis of the evolution of CRL signing from V1 + V2 certs, to the changes you cite re V3 certs.

As far as I am concerned, v1 and v2 is irrelevant. Extensions did not exist prior to v3, so neither v1 nor v2 could have included any requirements with respect to the proper setting of the cA bit in the basicConstraints extension.

>You have chosen to ignore large parts of this analysis, and focus on text in the current version of X.509 that emphasizes syntactic details but not the larger semantic context.

We are discussing the cA bit. I have quoted the text from X.509 that provides the semantics for the cA bit numerous times. You have chosen to ignore this text.

>You have not adressed the fact that both X.509 and RFC 2459 make repeated references to "authorities" or CAs re CRL issuance. You have received feedback from Sharon, and I think several of the 2459 authors have weighed in on this topic during the multi-week debate.
>

Based on the discussions that have occurred in this thread it seems to me that there are a number of issues in X.509 and PKIX that need to be resolved:

1) Who can issue CRLs?

         a) There seems to be consensus that it is acceptable for an entity that does
             not sign certificates to sign CRLs.

         b) There has been suggestion that the standards only allow for authorities to issue CRLs.

         c) X.509 defines an authority as "[a]n entity, responsible for the issuance of certificates.
              Two types are defined in this Specification; certification authority which issues public-key
             certificates and attribute authority which issues attribute certificates."

             X.509 similarly defines an CA as "An authority trusted by one or more users to create and
             assign public-key certificates. Optionally the certification authority may create the users’ keys."
             An attribute authority is defined to be "[a]n authority which assigns privileges by issuing
             attribute certificates".

     So, if we wish to allow entities to sign CRLs but not certificates, we either need to allow for entities
     other than authorities to issue CRLs or we need to redefine the terms CA, AA, and authority to include
     include entities that do not issue certificates.

2) In which directory attributes should certificates that are issued to subjects that are CAs be placed?

         a) RFC 2587 states that certificates issued to end entities must be placed in the userCertificate
             attribute and that certificates issued to CAs must be placed in the cACertificate and/or
             crossCertificatePair attributes (with specific rules on when each of these attributes is to
             be populated).

         b) RFC 2587 also states  that "none of the ... CA certificates shall include a basicConstraints
             extension with the cA value set to FALSE".

         c) There has been no consensus that the cA value in basicConstraints must be set to TRUE
             whenever the certificate subject is a CA. This lack of consensus is particularly the case
             when the certificate contains a keyUsage extension with neither the keyCertSign nor the
             cRLSign bit set. (I believe that Tim Polk has proposed changing the standards to require
             the cA value to be set to TRUE whenever the subject is a CA, but there has been no
             consensus that such a change should  be made).

     So, either we need to change X.509 and PKIX to state that the cA bit in basicConstraints indicates
     whether the certificate subject is a CA or LDAP schema needs to be clarified to clearly indicate in
     which attribute(s) certificates issued to CAs should be placed when basicConstraints is present but
     cA is set to FALSE (e.g., if the subject public key is used to sign CMP transactions, but not to sign
     certificates or CRLs).

What does the cA bit in basicConstraints mean?

     As a result of the changes from new-part1-05 to new-part1-06, the text in the PKIX profile describing
     the cA bit is contradictory. It states: "The cA bit indicates if the certified public key may be used to
     verify signatures on other certificates. If the cA bit is asserted, then either the keyCertSign bit or the
     cRLSign bit in the key usage extension (see 4.2.1.3) MUST also be asserted."

     The first sentence, which is essentially copied from X.509, states that the bit indicates whether the
     subject public key may be used to verify signatures on certificates. The next sentence, however,
     seems to contradict this by stating that the cA bit may be set to TRUE even if the subject public key
     may not be used to verify signatures on certificates (if the subject public key may be used to verify
     signatures on CRLs).

     Of course, if there were a requirement to only set the cRLSign bit in KeyUsage if the keyCertSign bit
     is also set, then there would be no contradiction. If this were the case, then the cA bit really would
     indicate is the subject public key may be used to verify signatures on certificates. However, there has
     certainly been agreement that it should be acceptable to specify that a key may be used to verify
     signatures on CRLs but not certificates. So, we must either revert to the new-part1-05 text which
     clearly ties the cA bit to the keyCertSign bit, or we must redefine the cA bit in both X.509 and PKIX.

There may be other issues that I am not recalling at the moment.

We need to step back and try to view this standard from the perspective of someone who is new to X.509. We cannot expect that everyone who makes use of the X.509 standard will have read through all of the messages on the PKIX mailing list. If the X.509 certificate generation and processing rules can not be unambiguously determined from the written standards, then the standards need to be fixed. Arguments to the effect of "the standard says X, but it really means Y, and to see why Y is the correct interpretation you'll need to read the relevant discussions from the PKIX mailing list from April of 1998." Similarly, claims that people should somehow determine the processing rules by looking at the "larger semantic context" instead of "text in the current version of X.509 that emphasizes syntactic details" are unacceptable. If the syntactic details are incorrect, then we should fix them. We can not have a standard that provides incorrect "syntactic details" and then expect people to correctly implement the standard based on an interpretation of the "larger semantic context".

Dave

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 May 2001 16:41:02 -0400

Dave,

We have a fundamental disagreement here. You have posited that there 
is no need to change the text to make it clear that a non-CA entity 
can sign CRLs. We have heard from Sharon, who clearly stated that the 
intent of the authors of X.509 was to impose such a requirement, and 
I think Tim said the same. Russ, I think may have concurred, even 
though he now agrees with your reasoning about what is a reasonable 
interpretation going forward.

What we have here is analogous to a lawyer proposing an 
interpretation of a law, but not being willing to examine the 
legislative history. That's simply mot acceptable. I won't argue 
whether it is appropriate to CHANGE to a scheme in which there is no 
need to check the CA flag when validating the signature on a CRL. if 
we have arrived at a consensus that this is OK, then fine. But, it is 
clearly a change relative to the expressed intent of the authors of 
previous versions of the standards and thus it merits an explicit 
change to the text of the next rev of the standards.

As per the message text cites you forwarded, I don't interpret any of 
the quotes as supportive of your contention that there is no need to 
change the text of these standards when if we drop the CA flag bit 
requirement.  Most of these messages are supportive of the change 
(some are taken out of context and so it's hard to tell even if that 
is the case).  None of these addresses the issue you raise.

So, no, I will not call for a poll on the question you pose because 
it ignores the stated intent of the authors and flies in the face of 
a reasonable interpretation of all preceding text by an intelligent 
reader.  One cannot vote to change history, and I will not conduct a 
poll to determine if people want to change history.

The only question o the table is whether we want to remove the 
implied restriction that used to exist, and thus accept the editing 
changes that it implies.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 May 2001 18:03:27 -0400

David,

>Steve,
>
>My interest is in ensuring that the PKIX Certificate and CRL Profile 
>is correct, consistent, and complete. If these issues are not of 
>interest to you, then feel free to ignore this message.

I wrote the first Internet standard on PKI (RFC 1422) almost 10 years 
ago. If I didn't share the goals you cite, I would not still be 
working on this stuff.  I respect your desire to make this document a 
good one, but I am frustrated by what I perceive as a very narrow 
reading of selected portions of the previous standards in support of 
your point of view re one aspect of this topic.

>>certs, to the changes you cite re V3 certs.
>
>As far as I am concerned, v1 and v2 is irrelevant. Extensions did 
>not exist prior to v3, so neither v1 nor v2 could have included any 
>requirements with respect to the proper setting of the cA bit in the 
>basicConstraints extension.

I cite the previous versions only because they establish context for 
v3. Note that ITU has a strong tradition of not making changes that 
are not backward compatible. Evidence of that abounds. Thus, it is 
appropriate to interpret each revised version of an ITU standard in 
such a context.

>  >You have chosen to ignore large parts of this analysis, and focus 
>on text in the current version of X.509 that emphasizes syntactic 
>details but not the larger semantic context.
>
>We are discussing the cA bit. I have quoted the text from X.509 that 
>provides the semantics for the cA bit numerous times. You have 
>chosen to ignore this text.

As I noted in my response to Dave Kemp, you are arguing like a lawyer 
who tries to build a case around one fragment of a law, ignoring the 
legislative history that expresses the intent of the lawmakers. 
Sharon's message several weeks ago clearly stated that intent.

>  >You have not adressed the fact that both X.509 and RFC 2459 make 
>repeated references to "authorities" or CAs re CRL issuance. You 
>have received feedback from Sharon, and I think several of the 2459 
>authors have weighed in on this topic during the multi-week debate.
>>
>Based on the discussions that have occurred in this thread it seems 
>to me that there are a number of issues in X.509 and PKIX that need 
>to be resolved:
>
>
>1) Who can issue CRLs?
>

It's more than a suggestion; it is a well-documented intent of the 
authors' of the standards in question.

>               Two types are defined in this Specification; 
>certification authority which issues public-key
>              assign public-key certificates. Optionally the 
>certification authority may create the users’ keys."
>      So, if we wish to allow entities to sign CRLs but not 
>certificates, we either need to allow for entities

One might be able to retain the definitions of CA and AA and add a 
new authority, but I think it probably would be clearer to refine the 
CA and AA definitions to make it clear that these entities may 
explicitly authorize another, newly named authority type, to issue 
just CRLs.

>          b) RFC 2587 also states  that "none of the ... CA 
>certificates shall include a basicConstraints

agreed, this is still unresolved.

>sign CMP transactions, but not to sign

This is a valid concern, relevant to how we decide the CA flag issue. 
Have we adequately addressed the problem of where to place the cert 
used to verify a CRL under the circumstances that we're exploring?

>      the cA bit is contradictory. It states: "The cA bit indicates 
>if the certified public key may be used to
>      verify signatures on other certificates. If the cA bit is 
>asserted, then either the keyCertSign bit or the
>      The first sentence, which is essentially copied from X.509, 
>states that the bit indicates whether the
>      subject public key may be used to verify signatures on 
>certificates. The next sentence, however,

yes, the text in question needs to be made consistent. one could do 
so in several ways, one of which would be to change the definition of 
the CA flag.

>      indicate is the subject public key may be used to verify 
>signatures on certificates. However, there has
>      clearly ties the cA bit to the keyCertSign bit, or we must 
>redefine the cA bit in both X.509 and PKIX.

yes, there is consensus that we want to be able to have a key that is 
used to verify CRLs but not certs.

>We need to step back and try to view this standard from the 
>perspective of someone who is new to X.509. We cannot expect that 
>everyone who makes use of the X.509 standard will have read through 
>all of the messages on the PKIX mailing list. If the X.509 
>certificate generation and processing rules can not be unambiguously 
>determined from the written standards, then the standards need to be 
>fixed. Arguments to the effect of "the standard says X, but it 
>really means Y, and to see why Y is the correct interpretation 
>you'll need to read the relevant discussions from the PKIX mailing 
>list from April of 1998." Similarly, claims that people should 
>somehow determine the processing rules by looking at the "larger 
>semantic context" instead of "text in the current version of X.509 
>that emphasizes syntactic details" are unacceptable. If the 
>syntactic details are incorrect, then we should fix them. We can not 
>have a standard that provides incorrect "syntactic details" and then 
>expect people !
>!
>!
>to correctly implement the standard based on an interpretation of 
>the "larger semantic context".

I agree that it should not be necessary for people to read the 
background material to understand a standard, but it is quite 
reasonable to expect people creating a revised version of the 
standard to be cognizant of such background.

I agree that the current standards (X.509 and RFC 2459) have proven 
to be somewhat ambiguous with regard to the issue of what class of 
entities are allowed to issue CRLs. You and others have cited text 
that, if read in isolation, supports the notion that a non-CA entity 
could sign a CRL. However, this text is not consistent with the 
persistent, repeated references to CAs (or CAs and AAs) as the issuer 
of CRLs that appear throughout the standards in question. So, I don't 
agree that the ambiguity is a great as you assert. Nonetheless, we 
both agree that the goal is to move forward with a new version that 
is unambiguous.

I'm looking to the 2459 editors to propose text that is consistent, 
allows for separate keys for cert and CRL signing, and that makes it 
clear what class of entity is authorized to sign CRLs for certs 
issued by a specified CA. Given the extent of the analysis that we 
have endured, it is clear that the new reader of the document should 
not be expected to infer correct answer to this last question if we 
merely state in the context of the definition of the CA flag that it 
need not be asserted in a cert used to verify a CRL. There are too 
many places where we refer to CAs (and AAs in X.509) as the entities 
who sign CRLs.

I said earlier that I can live with a change to the specs, a 
clarification if you prefer, that makes it explicit that we wish to 
state that non-CA entities can be authorized to sign CRLs. But, I 
also noted that we have to agree to make the changes throughout the 
document to make this clear, and that amounts to a lot of editing. 
Also, we it would be preferable to get our X.509 friends to agree to 
these changes, so that we remain in synch. As I have said several 
time before, I prefer the original intent as articulated by the 
authors of these documents, but I can live with the change so long as 
we are very explicit about that change.

Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 21 May 2001 10:54:06 -0400

Hi Steve,

I certainly agree that the intent of X.509, from v1 to the present, was
that a CA entity is the ultimate and sole authority for revoking the
certificates that it issues.

However, Tim has proposed changing the text of PKIX to require the cA
flag to be set in every certificate whose subject is a CA entity.
Such a change is unnecessary.

The question is:

 * When a CA entity uses one public key to sign certificates
 * and a different public key to sign CRLs, must the cA flag be set
 * in the certificate containing the public key used to sign CRLs?

I say no.  David Cooper, Santosh, Sharon, Denis, Tom, and others
can answer this question explicitly for themselves; I will refrain
from interpreting their words.

----

A related discussion concerns the ability of a non-CA authority
(an AA) to sign CRLs for the non-PKCs (ACs) that it issues.
Since non-public-key X.509 certificates did not exist before v3, there
is no historical author's intent concerning the issuance and revocation
of such certificates.  But it is no stretch of the imagination to
believe that had the question been asked, the original authors would
have said that the issuer of a non-PKC is the ultimate and sole
authority for revoking that non-PKC.  In both the PKC and non-PKC
cases, the issuer of a certificate can designate or delegate a public
key to be used for revoking that certificate by setting the cRLSign bit.
The issuer's authority and ability to revoke does not depend on,
or benefit from, the existence or state of the cA flag in the
basic constraints extension.

This related discussion of historical intent is interesting, but
I am *not* calling for a straw poll to interpret historical intent,
or to write new text to clarify historical intent.

I posit that there is no need to change the text to require
the cA bit to be set in certificates used to validate CRLs containing
PKCs.  The current text does not require the cA bit to be set, and
there is no need to add such a requirement.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 May 2001 08:25:36 -0400

Dave,

>from interpreting their words.

This is a big part of the question at hand, but not the whole 
question. If we do agree that the cA flag need not be set in a cert 
used by a CA who signs a CRL, then what about a non-CA entity that 
signs a CRL? What do we call it?  Also, it might be clear that the 
entity signing the CRL was a CA (w/o the cA flag set), because the 
entity has the same name as the CA who signed the certs in question, 
i.e., we're dealing with a self-issued cert. But, what if the name is 
different? In that latter case, we need to make an explicit statement 
about the role of the entity in question, starting with naming that 
role.

I agree that a very broad interpretation of the requirement to set 
the cA flag runs into problems, but so do the key usage bits in some 
contexts. For example, if a CA signs a cert request message in CMP, 
requesting a cross-cert from another CA, isn't this use of the CA 
private key for POP a contradiction of the key usage bits in the 
self-signed cert issued by the CA to itself?

Steve