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

[Stephen Kent <kent@xxxxxxx>]

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.

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

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.
> > I see no point in continuing the discussion.
>
>
> 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.

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

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

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.

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

agreed, this is still unresolved.

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

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?

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

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.

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

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

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

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