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

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

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

         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