Subject: RE: question about certificate path length

From: Frank Balluffi <[email-masked]>
Date: Tue, 17 Oct 2000 05:46:58 -0700

Hiroyuki,

I believe that your understanding is correct.

Note that draft-ietf-pkix-new-part1-02.txt's definition of the basic
constraints extension (section 4.2.1.10) clears up ambiguities found in RFC
2459's definition. For example, draft-ietf-pkix-new-part1-02.txt states:

This extension MAY appear as a critical or non-critical extension in end
entity certificates.

where RFC 2459 says:

This extension SHOULD NOT appear in end entity certificates.

Frank

In the case of validating Cert_b as  EE certificate, the 
> certificate path is
> Cert_a -> Cert_b,

When validating

section 3

   end entity:  user of PKI certificates and/or end user system that
                is the subject of a certificate;

4.2.1.10  
   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.

   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.

> -----Original Message-----
> From: Hiroyuki Sakakibara [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 2:55 AM
> To: [email-masked]
> Subject: question about certificate path length
> 
> 
> Hi.
> 
> I have a question about difference between "certificate path 
> length" and
> "pathLenConstraint field in the basicConstraint extension".
> 
> >Internet X.509 Public Key Infrastructure
> >Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> >July 14, 2000
> 
> >4.2.1.10  Basic Constraints
> >"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."
> 
> SNIP
> 
> >6.1 Basic Path Validation
> 
> >To meet this goal, the path validation process verifies, among other
> >things, that a prospective certification path (a sequence of n certi-
> >ficates) satisfies the following conditions:
> >      (i) for all x in {1, ..., n-1}, the subject of certificate x is
> >      the issuer of certificate x+1;
> >      (ii) certificate 1 is issued by the trust anchor;
> >      (iii) certificate n is the end entity certificate; and
> >      (iv) for all x in {1, ..., n}, the certificate was valid at the
> >      time in question.
> SNIP
> >(inputs)
> >(a) a prospective certification path of length n;
> 
> >State variable initialization
> >(l) max_path_length:  this integer is initialized to n, and is
> >      reset by the path length constraint field within the basic con-
> >      straints extension of a CA certificate.
> 
> Referencing "Internet X.509 Public Key Infrastructure
> Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> July 14, 2000"
>  I will describe my understanding.
> 
> For example,
> 
> CAa : trust anchor
> CAb : subordinate CA of CAa
> CAc : subordinate CA of CAb
> CAd : subordinate CA of CAc
> EE   : subordinate user of CAd
> 
> Cert_a : CAa's self-signed certificate
> Cert_b : CAb's certificate issued by CAa
> Cert_c : CAb's certificate issued by CAb
> Cert_d : CAb's certificate issued by CAc
> Cert_user : user's certificate issued by CAd
> 
> In this case, certificate path is
> 
> Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user
> 
> therefore, the length of the certificate path is "5".
> 
> On the other hand, if CAa restricts the number of subordinates
> CAs, 3, actually to CAd in this case, the pathLenConstraint value
> in Cert_a is 3.
> 
> because
> 
> >4.2.1.10  Basic Constraints
> >"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."
> 
> So, in general, the length of the certificate path means 
> that, the number of
> chained
> certificates, from the trust anchor CA's certificate to EE( 
> user or CA)
> certificate,
> as shown above
> ( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).
> 
> In the case of validating Cert_b as  EE certificate, the 
> certificate path is
> Cert_a -> Cert_b,
> therefore the length of the certificate path is 2.
> 
> Consequently, if someone handles the Cert_a as the trust anchor CA's
> certificate,
> he sees that the maximam path length is 5, because pathLenConstraint
> in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then 
> gets the length as
> 5.
> 
> Am I misunderstanding ?
> 
> ---------------------------------------
> Hiroyuki Sakakibara
> MITSUBISHI ELECTRIC CORPORATION
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> PHONE: +81-467-41-2183
> FAX:   +81-467-41-2185
> E-mail : [email-masked]
>

---

From: "Hiroyuki Sakakibara" <[email-masked]>
Date: Thu, 19 Oct 2000 13:19:38 +0900

Mr.Frank Balluffi

Thank you very much for your relpy.

I have refered the X.509 document
cited in draft-ietf-pkix-new-part1-02.txt.
In the document, while the relationship between a delegation
path length and the pathLenConstraint component of the basicAttrConstraints
is clear,
but the relationship between a certification path length and the the
pathLenConstraint
component of the basicConstraints seemes to be not clear, I think.

So,  the description of the certification path length in
the 6.1 Basic Path Validation in draft-ietf-pkix-new-part1-02.txt
is clearer to me.

# I mistakenly have described "certification path" as "certificate path" in
# my posted mail. "certification path" is correct.

Hiroyuki Sakakibara.

> Hiroyuki, draft-ietf-pkix-new-part1-02.txt
>
> > certificates, from the trust anchor CA's certificate to