Re: Open Issue in Part1: path length constraints

[Steve Hanna <steve.hanna@xxxxxxx>]

"David P. Kemp" wrote:
> > From: Steve Hanna <steve.hanna@xxxxxxx>
> > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > *unless* it is the last certificate in a path. I suppose this is only a
> > wording problem, but I find this wording *less* clear than the old
> > wording.
> 
> The oddness arises because you are applying the label "CA certificate"
> to the certificate based on its contents instead of its usage.
> 
> If a certificate contains cA=TRUE and
> keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> than one purpose.  It is a CA certificate when validating the signature
> of a certificate, and it is an EE certificate when validating the
> signature of a CRL or a message.  (A CA should not use a cert-signing
> private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> practices.)

So you're saying that a certificate with cA=TRUE is an end-entity
certificate when it appears at the end of a certificate chain and a CA
certificate otherwise? The same certificate is both a CA certificate and
an end-entity certificate? This seems to be contrary to the way these
terms have been used in the past and the way they are used in X.509, RFC
2459, new-part1, and throughout the industry.

X.509 defines a CA-certificate as a "certificate for one CA issued by
another CA" and an end-entity certificate as a "certificate issued by a
CA to a subject that is not an issuer of other public-key certificates".
RFC 2459 does not have a glossary, but it does say that CA certificates
are "all certificates including the basic constraints extension ...
where the value of cA is TRUE." new-part1 contains similar language.

Attempting to redefine CA certificate and end-entity certificate in this
way will be immensely confusing. If the working group wishes to change
the semantics of the pathLenConstraint field so that a CA certificate at
the end of the path is not counted for the purposes of this constraint,
so be it. But don't try to change the meaning of CA certificate to be "A
certificate whose subject is a CA (except when such a certificate
appears at the end of a path, in which case the certificate is an
end-entity certificate)." Just change the description of the
pathLenConstraint field so that it limits the number of intermediate CA
certificates, not the total number of CA certificates. Instead of the
current text:

   In this case, it gives the maximum number of CA certificates that may
   follow this certificate in a certification path. (Note: One end-
   entity certificate will follow the final CA certificate in the path.
   The last certificate in a path is considered an end-entity
   certificate, whether the subject of the certificate is a CA or not.)
   A pathLenConstrinat of zero indicates that only an end-entity
   certificate may follow in the path. Where it appears, the
   pathLenConstraint field MUST be greater than or equal to zero. Where
   pathLenConstraint does not appear, there is no limit to the allowed
   length of the certification path.

I suggest the following:

   In this case, it gives the maximum number of intermediate CA
   certificates that may follow this certificate in a certification
   path. (Note: One final certificate will follow the final intermediate
   CA certificate in the path. This certificate may be either a CA
   certificate or an end-entity certificate.) A pathLenConstraint of
   zero indicates that no intermediate CA certificates may follow in the
   path. Where it appears, the pathLenConstraint field MUST be greater
   than or equal to zero. Where pathLenConstraint does not appear, there
   is no limit to the allowed length of the certification path.

-Steve

P.S. I have not seen anything approaching rough consensus on the basic
question of which of these semantics we should use. John Linn and I have
sent email favoring the RFC 2459 semantics (pathLenConstraint being the
maximum number of subsequent CA certificates allowed). You and David
Cross have sent email favoring the new-part1 semantics
(pathLenConstraint being the maximum number of intermediate certificates
allowed). If there is no further discussion on the list, we may need to
check consensus in Minneapolis.