Subject: Re: Open Issue in Part1: path length constraints

From: "David P. Kemp" <[email-masked]>
Date: Fri, 23 Feb 2001 13:16:26 -0500 (EST)

Steve,

> From: Steve Hanna <[email-masked]>
> 
> The original text said:
> 
>    The pathLenConstraint field is meaningful only if cA is set to TRUE.
>    In this case, it gives the maximum number of CA certificates that may
>    follow this certificate in a certification path. A value of zero
>    indicates that only an end-entity certificate may follow in the path.
> 
> The revised text says:
> 
>    The pathLenConstraint field is meaningful only if cA is set to TRUE.
>    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.
> 
> 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.)

X.509 says of the Basic Constraints extension: "the cA component
indicates if the certified public key may be used to verify
certificate signatures."    It does not indicate that the public
key may not be used to verify other (CRL, message) signatures.

I believe the parenthetical note in the revised text is helpful,
but it would read better if it were at the end:

    The pathLenConstraint field is meaningful only if cA is set to
    TRUE.  In this case, it gives the maximum number of CA certificates
    that may follow this certificate in a certification path.
    A pathLenConstraint of zero indicates that only an end-entity
    certificate may follow in the path.  (Note: One end-entity
    certificate will follow the final CA certificate in the path.
    The last certificate in a path is an end-entity certificate,
    whether the subject of the certificate is a CA or not.)

(The last certificate in a path is not just "considered" an
end-entity certificate, it is one.  Proof by construction.)

---

From: Steve Hanna <[email-masked]>
Date: Wed, 28 Feb 2001 13:28:46 -0500

> private key to sign correspondence, but X.509 doesn't prohibit unhygenic

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.

---

From: Steve Hanna <[email-masked]>
Date: Wed, 28 Feb 2001 13:33:56 -0500

Steve Hanna wrote:
> 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.

I forgot that David Cooper also sent email favoring the new-part1
semantics. Sorry! That makes three Davids in favor of the new-part1
semantics and Steve and John in favor of the RFC 2459 semantics. Still
closely divided.

-Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Feb 2001 14:32:49 -0500

Steve,

Last week Hoyt Kesterson sent a message to the PKIX list pointing out some defect reports against X.509. One of these, DR 272, deals with path length constraints:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf

DR 272 proposes adding some new text to X.509 to help clarify the meaning of path length constraints in public key and attribute certificates. From my reading of the text, there seems to be an assumption that every certification path will end with an end-entity certificate as in the following sentence:

                 The constraint controls the number of non self-issued CA certificates between
                 the CA certificate containing the constraint and the end-entity certificate.

Hoyt's message states that DR 272 has not yet been submitted for formal voting, but that it will be soon. We should keep this in mind when deciding on the text to use in new-part1 so we can ensure that X.509 and new-part1 are both clear and consistent in this area.

Dave

At 01:28 PM 2/28/01 -0500, Steve Hanna wrote:
>I have not seen anything approaching rough consensus on the basic

---

From: David Simonetti <[email-masked]>
Date: Wed, 28 Feb 2001 18:00:35 -0500

Let's make this a fair fight and make it three on three.  This David agrees with
Steve and John.

In Tim's original message:

"CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
certificates issued by "B", but does not trust "B" to issue certificates to
other CAs.  "A" includes basic constraints in the certificate it issues to
"B" with cA = TRUE and pathLen = 0."

""B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
trusts "C" to issue end entity certificates. So, "B" includes basic
constraints in the certificate it issues to "B" with cA = TRUE."

Let me begin by stating that I really dislike this scenario.  Theoretically this
is possible, but why would anyone architect such a design?  If I really had to
address this scenario, a design that fits within the current semantics would be
one that creates a distinct "personality" for issuing the CRLs which could be
issued an end entity certificate with the cRLSign bit set.

Stay with the current semantics and stop trying to break things that really
aren't broken.

Dave S.

--
David Simonetti
Securify (www.securify.com), 410-356-2260