Subject: Basic Constraints -- pathLenConstraint clarification

From: "Carl Tietjen" <[email-masked]>
Date: Mon, 14 May 2007 18:38:48 -0700

Hi,

I thought I should get an official clarification about the Basic Constraints extension.  What does it mean to not have the pathLenConstraint set?

From my reading of RFC 3280 (as well as RFC 2459) my understanding is that when the pathLenConstraint is not set, it is asserted that the CA can create an unlimited number of subordinate CAs (i.e. it means the path length is unlimited).

We have a CA implementor that claims that when the pathLenConstraint is not set, it does not mean unlimited, rather that it should just be ignored.

_____

My arguments for it meaning unlimited follow:

In RFC 3280 4.2.1.10 we read the definition of Basic Constraints: "The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate."(emphases added).  So by definition the basic constraints extension asserts whether the certificate is a CA, and it's maximum certification path.
Later in the section, it repeats this by saying "...In this case, it gives the maximum number of non-self-issued certificates that may follow this certificate in a valid certification path." (emphases added).

The fact that the definition says that it supplies the maximum depth is important because this fact has bearing of what it means when the pathLenConstraint does not appear.  As the RFC states, "Where pathLenConstraint does not appear, no limit is imposed." 

Because of the definition of basic constraints, we see that when the extension is encoded in the certificate, some path length value is set, whether explicitly by setting a specific number, or implicitly by not setting a value (either way, by definition, it is telling us what it's maximum depth is).  So when the pathLenConstraint is not set, the assertion is that the maximum depth is "no limit..."

In addition, if we look at RFC 2459, 4.2.1.10 we see a slightly different wording, "Where pathLenConstraint does not appear, there is no limit to the allowed length of the certification path."   So if a CA creates a certificate without the pathLenConstraint set, it asserts that there is "no limit to the allowed length of the certification path".  Or in my words, it asserts that the path length is unlimited.

_______

The CA implementor argues that when the pathLenConstraint is not set it does not mean unlimited, it should just be ignored because in RFC 3280 section 6.1.4 it states:
" (m)  If pathLengthConstraint is present in the certificate and is less than max_path_length, set max_path_length to the value of pathLengthConstraint."   Emphasis on "If pathLengthConstraint is present...". 

And also because in section 8.4.2.1 of ITU-T X.509 section 8.4.2.1 it states:
"--if the value of cA is set to true and pathLenConstraint is present then the certificate-using system shall check that the certification path being processed is consistent with the value of pathLenConstraint."  Emphasis on "and pathLenConstraint is present". 

Can you please clarify what it means when the pathLenConstraint is not set?

_______

FYI -- This also brings up an issue with the steps of the Certificate Path Validation algorithm (6.1.4 l and 6.1.4 m) for processing the pathLenConstraint (other than that section (m) spells pathLenConstraint incorrectly as pathLengthConstraint). 

Consider a chain of 4 certificates with the following Basic Constraints
1) CA, 5
2) CA, 2
3) CA, 7
4) end-entity.

It is clear that certificate #3 should never have been issued by CA #2 because it asserts a pathLenConstraint that is not true.  However if you follow the steps of the Certificate Path Validation, the algorithm would accept this chain as valid.  

It does not seem like that this is something the algorithm should allow.

Thanks in advance,

Carl

Carl Tietjen
Senior Software Engineer
[email-masked]
801 861-7255

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 15 May 2007 07:55:04 -0700

Hi Carl,
 
I'm not sure I understand the distinction you are making between ignore
and unlimited.  In the absence of any path length constraints, the path
length is not constrained.  You could view this as unlimited length or
as ignoring the path length.  The idea and end result are the same in
either case, no?
 
In your example,

I assume the numbers on the right side are the path length constraints?
If so, I see nothing wrong with this path.  The constraint tells you the
number of intermediate certificates that may follow after the CA cert
containing the constraint.  In your example, only 1 intermediate
certificate follows CA #2, so this is ok.
 
Reading your email, I think the sentence you quoted:
 
"The basic constraints extension identifies whether the subject of the
certificate is a CA and the maximum depth of valid certification paths
that include this certificate."
 
could be (incorrectly) interpreted to mean that the constraint applies
to the entire path and not only to the part of the path that follows the
constrained certificate.  Perhaps this sentence could be made clearer.
However, the sentence a bit below it describes the intended behavior
perfectly:
 
"In this case, it gives the maximum number of non-self-issued
intermediate certificates that may follow this certificate in a valid
certification path."
 
Note that you left out the word "intermediate" in your quote below, that
is why I bolded it.  If you follow the rule correctly, your example
could actually contain 1 more CA cert before the end entity and still be
valid.  All the following examples would be valid:
 
Assume "0) Root CA" is present for each. 
"-" indicates that no pathLenConstraint is present.
 
1) CA, 5
2) CA, 2
3) CA, 7
4) CA, -
5) EE
 
1) CA, 0
2) EE
 
1) CA, -
2) CA, -
3) CA, 0
5) EE
 
1) CA, -
2) CA, -
3) CA, 1
4) CA, -
5) EE

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Tietjen
Sent: Monday, May 14, 2007 9:39 PM
To: [email-masked]
Subject: Basic Constraints -- pathLenConstraint clarification

Hi,
 
I thought I should get an official clarification about the Basic
Constraints extension.  What does it mean to not have the
pathLenConstraint set?
 
From my reading of RFC 3280 (as well as RFC 2459) my understanding is
that when the pathLenConstraint is not set, it is asserted that the CA
can create an unlimited number of subordinate CAs (i.e. it means the
path length is unlimited).
 
We have a CA implementor that claims that when the pathLenConstraint is
not set, it does not mean unlimited, rather that it should just be
ignored.
 
_____

In RFC 3280 4.2.1.10 we read the definition of Basic Constraints: "The
basic constraints extension identifies whether the subject of the
certificate is a CA and the maximum depth of valid certification paths
that include this certificate."(emphases added).  So by definition the
basic constraints extension asserts whether the certificate is a CA, and
it's maximum certification path.
Later in the section, it repeats this by saying "...In this case, it
gives the maximum number of non-self-issued certificates that may follow
this certificate in a valid certification path." (emphases added).
 
The fact that the definition says that it supplies the maximum depth is
important because this fact has bearing of what it means when the
pathLenConstraint does not appear.  As the RFC states, "Where
pathLenConstraint does not appear, no limit is imposed." 
 
Because of the definition of basic constraints, we see that when the
extension is encoded in the certificate, some path length value is set,
whether explicitly by setting a specific number, or implicitly by not
setting a value (either way, by definition, it is telling us what it's
maximum depth is).  So when the pathLenConstraint is not set, the
assertion is that the maximum depth is "no limit..."
 
In addition, if we look at RFC 2459, 4.2.1.10 we see a slightly
different wording, "Where pathLenConstraint does not appear, there is no
limit to the allowed length of the certification path."   So if a CA
creates a certificate without the pathLenConstraint set, it asserts that
there is "no limit to the allowed length of the certification path".  Or
in my words, it asserts that the path length is unlimited.
 
_______
 
The CA implementor argues that when the pathLenConstraint is not set it
does not mean unlimited, it should just be ignored because in RFC 3280
section 6.1.4 it states:
" (m)  If pathLengthConstraint is present in the certificate and is less
than max_path_length, set max_path_length to the value of
pathLengthConstraint."   Emphasis on "If pathLengthConstraint is
present...". 

And also because in section 8.4.2.1 of ITU-T X.509 section 8.4.2.1 it
states:
"--if the value of cA is set to true and pathLenConstraint is present
then the certificate-using system shall check that the certification
path being processed is consistent with the value of pathLenConstraint."
Emphasis on "and pathLenConstraint is present". 

Can you please clarify what it means when the pathLenConstraint is not
set?
 
_______
 
FYI -- This also brings up an issue with the steps of the Certificate
Path Validation algorithm (6.1.4 l and 6.1.4 m) for processing the
pathLenConstraint (other than that section (m) spells pathLenConstraint
incorrectly as pathLengthConstraint). 

It is clear that certificate #3 should never have been issued by CA #2
because it asserts a pathLenConstraint that is not true.  However if you
follow the steps of the Certificate Path Validation, the algorithm would
accept this chain as valid.  

Thanks in advance,
 
Carl

Carl Tietjen
Senior Software Engineer
[email-masked]
801 861-7255
  <http://www.novell.com/linux>

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 May 2007 15:57:52 -0400

Carl,

I believe that there is a misunderstanding of the purpose of the path
length constraint.  If I, as the operator of the NIST CA, issue a CA
certificate to the Novell CA and include constraints in that
certificate (path length constraint, name constraint, etc.), I am not
asserting a limit on what certificates the Novell CA may issue.  I am
simply asserting a limit on what certificates I want my relying parties
to accept.  So, if the basicConstraints extension in the certificate I
issue includes a pathLenConstraint of 0, it simply means that I only
want NIST relying parties to accept certificates issued by the Novell
CA itself.  My including the pathLenConstraint in no way suggests that
the Novell CA is not permitted to certificates to other CAs.  Novell
may issue certificates to certificates to other organizations' CAs so
that the certificates issued by those other organizations may be
accepted by Novell relying parties.  The result would be that Novell
relying parties, using the Novell CA as a trust anchor would accept
certificates issued by the other organizations' CAs.  NIST relying
parties, using the NIST CA as a trust anchor, would accept certificates
issued by the Novell CA itself, but would reject certificates issued by
the other CAs that had been issued a certificate by the Novell CA.

Dave

Carl Tietjen wrote:

Hi,

From my reading of RFC 3280 (as well as RFC 2459) my
understanding is that when the pathLenConstraint is not set, it is
asserted that the CA can create an unlimited number of subordinate
CAs (i.e. it means the path length is unlimited).

We have a CA implementor that claims that when the
pathLenConstraint is not set, it does not mean unlimited, rather that
it should just be ignored.

_____

In RFC 3280 4.2.1.10 we read the definition of Basic
Constraints: "The basic constraints extension identifies whether the
subject of the certificate is a CA and the maximum depth of valid
certification paths that include this certificate."(emphases
added).  So by definition the basic constraints extension asserts
whether the certificate is a CA, and it's maximum certification path.

Later in the section, it repeats this by saying "...In this
case, it gives the maximum number of non-self-issued
certificates that may follow this certificate in a valid certification
path." (emphases added).

The fact that the definition says that it supplies the maximum
depth is important because this fact has bearing of what it means when
the pathLenConstraint does not appear.  As the RFC states, "Where
pathLenConstraint does not appear, no limit is imposed."

Because of the definition of basic constraints, we see that when
the extension is encoded in the certificate, some path length value
is set, whether explicitly by setting a specific number, or implicitly
by not setting a value (either way, by definition, it is telling us
what it's maximum depth is).  So when the pathLenConstraint is not set,
the assertion is that the maximum depth is "no limit..."

In addition, if we look at RFC 2459, 4.2.1.10 we see a slightly
different wording, "Where pathLenConstraint does not appear, there is
no limit to the allowed length of the certification path."   So if a CA
creates a certificate without the pathLenConstraint set, it asserts
that there is "no limit to the allowed length of the certification
path".  Or in my words, it asserts that the path length is unlimited.

_______

The CA implementor argues that when the pathLenConstraint is not
set it does not mean unlimited, it should just be ignored because in
RFC 3280 section 6.1.4 it states:

" (m)  If pathLengthConstraint is
present in the certificate and is less
than max_path_length, set max_path_length to the value of pathLengthConstraint."   Emphasis on "If pathLengthConstraint is
present...".

And also because in section 8.4.2.1 of ITU-T X.509 section
8.4.2.1 it states:

"--if the value of cA is set to true and pathLenConstraint is
present then the certificate-using system
shall check that the certification
path being processed is consistent with the value of pathLenConstraint."  Emphasis on "and
pathLenConstraint is present".

Can you please clarify what it means when the pathLenConstraint
is not set?

_______

FYI -- This also brings up an issue with the steps of the
Certificate Path Validation algorithm (6.1.4 l and 6.1.4 m) for
processing the pathLenConstraint (other than that section (m) spells
pathLenConstraint incorrectly as pathLengthConstraint).

Consider a chain of 4 certificates with the following Basic
Constraints

1) CA, 5

2) CA, 2

3) CA, 7

4) end-entity.

It is clear that certificate #3 should never have been issued by
CA #2 because it asserts a pathLenConstraint that is not true.  However
if you follow the steps of the Certificate Path Validation, the
algorithm would accept this chain as valid.

It does not seem like that this is something the
algorithm should allow.

Thanks in advance,

Carl

Carl Tietjen

Senior Software Engineer

[email-masked]

801 861-7255

---

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 16 May 2007 17:05:09 +0200

Hi.

Carl Tietjen wrote:
> not set, it does not mean unlimited, rather that it should just be ignored.

The argument that Carl and I have is if the following chain is valid:

1) TrustAnchor:     pathLenConstraint 5
2) SubCA1:          pathLenConstraint 2
3) SubCA2:          no pathLenConstraint
4) EE-Certificate

My understanding of the path validation algorithm in RFC 3280 section 
6.1.4 m) and of ITU-T X.509 section 8.4.2.1 is that its a valid chain; 
SubCA2 is bound by the pathLenConstraint from its upper CAs and thus 
does not need an explicit own pathLenConstraint of 1 or 0.

The NIST test suite (http://csrc.nist.gov/pki/PKITesting.html) has a 
similar chain in Section "4.6.13 Valid pathLenConstraint Test13", also 
marked as valid.

Juergen

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 16 May 2007 10:06:29 -0700

The chain is valid.  It would still be valid if there was one more layer
of CA below SubCA1 since path length is 2.  Path length is NOT how many
certificates can follow, but how many CA certificates can follow.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Juergen Brauckmann
Sent: Wednesday, May 16, 2007 11:05 AM
To: [email-masked]
Subject: Re: Basic Constraints -- pathLenConstraint clarification

Hi.

ignored.

Juergen

---

From: [email-masked]
Date: Wed, 16 May 2007 22:01:33 +0300 (EEST)

Is it valid, if constraint length values are inconsistent in the example
below:
1) CA, 5
2) CA, 2
3) CA, 7
4) end-entity.

If CA1 may have 5 CA certificates and one of them is CA3, how can CA3 have
7 CA certificates?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 16 May 2007 13:11:09 -0700

Yes.  It is still valid.

It is incorrect to think of the values as inconsistent.  For example,
each of these CAs could be in different domains and could use path
length as a control on the number layers of CAs they are willing to
trust.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, May 16, 2007 3:02 PM
To: [email-masked]
Subject: RE: Basic Constraints -- pathLenConstraint clarification

 Is it valid, if constraint length values are inconsistent in the
example
below:
1) CA, 5
2) CA, 2
3) CA, 7
4) end-entity.

If CA1 may have 5 CA certificates and one of them is CA3, how can CA3
have
7 CA certificates?

---

From: Paul Nelson <[email-masked]>
Date: Wed, 16 May 2007 15:37:38 -0500

> If CA1 may have 5 CA certificates and one of them is CA3, how can CA3 have

It can't.  Read RFC 3280, section 6.1 - The third CA's pathLengthConstraint
is effectively ignored.

6.1.2       (k) max_path_length:  this integer is initialized to n, is
      decremented for each non-self-issued certificate in the path, and
      may be reduced to the value in the path length constraint field
      within the basic constraints extension of a CA certificate.
and
6.1.4
      (l)  If the certificate was not self-issued, verify that
      max_path_length is greater than zero and decrement max_path_length
      by 1.

      (m)  If pathLengthConstraint is present in the certificate and is
      less than max_path_length, set max_path_length to the value of
      pathLengthConstraint.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 16 May 2007 14:17:40 -0700

I did not answer part of the following question.

Q: If CA1 may have 5 CA certificates and one of them is CA3, how can CA3
have 7 CA certificates?

A: There may be other ways to get to CA 3,  In the example, I am
assuming that CA2 --> CA3 certificate has value of 7.  If CA 2 is
certified by some one other than CA 1, say CA X and CA X --> CA 2 does
not constrain CA 2, then, CA 2 --> CA 3 value of 7 becomes the limit.

Also, see Dave Cooper's posting on this thread.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, May 16, 2007 4:11 PM
To: [email-masked]
Subject: RE: Basic Constraints -- pathLenConstraint clarification

Yes.  It is still valid.

---

From: "Carl Tietjen" <[email-masked]>
Date: Mon, 21 May 2007 13:35:20 -0700

Dave,

Thanks for you response.

I understand what you are saying, however I don't see where your argument (or definition of what the purpose of the path length constraint) comes from.  It seems like you are saying that a sub-CA which has been issued a certificate with constraints in it is not bound by that constraint.  This seems illogical.

In your example, you say "I [the NICT CA] am simply asserting a limit on what certificates I want my relying parties to accept.",  which I agree with.  

You also say "I am not asserting a limit on what certificates the Novell CA may issue.", which I disagree with (with a caveat).

If the certificate path includes the NIST CA, (which is what my question is all about) then the NIST CA does constrain which certificates the Novell CA could issue.

And if the Novell CA wishes to issue certificates which are not bound by the constraint imposed by the NIST CA, then the Novell CA would use a different certificate to issue those certificates (i.e. either a self-signed certificate or a certificate signed by a different CA which did not constrain it.)

____________

The root of the issue here is the definition of the Basic Constraints extension.  

From RFC 3280 4.2.1.10 "The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate...the pathLenConstraint field...gives the maximum number of non-self-issued intermediate certificates what may follow this certificate in a valid certification path."

So if we have the following path:
name    Basic Constraints, path constraint:
CA 1)    CA, 5
CA 2)    CA, 2
CA 3)    CA, 7
CA 4)    end-entity

In this example, CA 2 has issued a certificate to CA 3 that I believe is invalid.  It is invalid because CA 2 has incorrectly asserted that the maximum number of non-self-issued intermediate certificates which may follow CA 3's certificate in a valid certification path is 7.

Given the certificate path, certificate #3 is invalid on it's face because it asserts something that is not true (i.e. Any path which includes CA1, CA2, CA3, and 7 more subCA's is invalid). 

I would like to emphasize that the definition of basic constraints says that the pathLenConstraint field gives the maximum number of subCA certificates which may follow in a valid path.  

_______________

Please do use the algorithm in section 6.1.4 as evidence as to whether what I said is correct or not, as my claim is that the algorithm if flawed.  

FYI -- The algorithm clearly is not without fault, because the algorithm uses the term "pathLengthConstraint" when it should be using the term "pathLenConstraint"  -- (i.e. if someone did exactly what the algorithm said to do, all pathLenConstraint's would be ignored).

Thanks,

Carl

Carl Tietjen
Senior Software Engineer
[email-masked]
801 861-7255

>>> On 5/15/2007 at 12:57 PM, in message <[email-masked]>, "David A. Cooper" <[email-masked]> wrote:

Carl,

I believe that there is a misunderstanding of the purpose of the path length constraint.  If I, as the operator of the NIST CA, issue a CA certificate to the Novell CA and include constraints in that certificate (path length constraint, name constraint, etc.), I am not asserting a limit on what certificates the Novell CA may issue.  I am simply asserting a limit on what certificates I want my relying parties to accept.  So, if the basicConstraints extension in the certificate I issue includes a pathLenConstraint of 0, it simply means that I only want NIST relying parties to accept certificates issued by the Novell CA itself.  My including the pathLenConstraint in no way suggests that the Novell CA is not permitted to certificates to other CAs.  Novell may issue certificates to certificates to other organizations' CAs so that the certificates issued by those other organizations may be accepted by Novell relying parties.  The result would be that Novell relying parties, using the Novell CA as a trust anchor would accept certificates issued by the other organizations' CAs.  NIST relying parties, using the NIST CA as a trust anchor, would accept certificates issued by the Novell CA itself, but would reject certificates issued by the other CAs that had been issued a certificate by the Novell CA.

Dave

Carl Tietjen wrote: 
Hi,

_____

_______

_______

Thanks in advance,

Carl

Carl Tietjen
Senior Software Engineer
[email-masked]
801 861-7255

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 21 May 2007 18:09:26 -0400

Carl,

> FYI -- The algorithm clearly is not without fault, because the 
> algorithm uses the term "pathLengthConstraint" when it should be using 
> the term "pathLenConstraint"  -- (i.e. if someone did exactly what the 
> algorithm said to do, all pathLenConstraint's would be ignored).
I believe that if you look at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-08.txt 
you will see that this error has been corrected in the draft update to 
RFC 3280.

I agree with you that in a hierarchical PKI, the sample certification 
path that you present would be illogical, but not all PKIs are 
hierarchical.  In the example that I was using, the Novell CA is not 
subordinate to the NIST CA, the two CAs are peers.  NIST may issue a CA 
certificate from the NIST CA to the Novell CA in order to be able to 
validate certificates issued by the Novell CA, but that does not make 
the Novell CA subordinate to the NIST CA.

> From RFC 3280 4.2.1.10 "The basic constraints extension identifies 
> whether the subject of the certificate is a CA and the maximum depth 
> of valid certification paths that include this certificate...the 
> pathLenConstraint field...gives the maximum number of non-self-issued 
> intermediate certificates what may follow this certificate in a valid 
> certification path."
Notice that both of the the sentences that you quote include the phrase 
"this certificate".  The pathLenConstraint field specifies the maximum 
depth of valid certification paths that include _this certificate_.  
Certification paths that include certificates issued by the subject but 
that do not include this certificate are not affected by the constraint.

So, in my example, the pathLenConstraint specifies the maximum depth of 
valid certification paths that include the certificate issued by the 
NIST CA to the Novell CA, and thus limits the set of certificates that 
people who use the NIST CA as a trust anchor may accept, but it does not 
impose a limit on certification paths that do not include this 
certificate (e.g., paths in which the Novell CA is the trust anhcor).

Dave

Carl Tietjen wrote:
> Dave,
>  
> Thanks for you response.
>  
> I understand what you are saying, however I don't see where 
> your argument (or definition of what the purpose of the path length 
> constraint) comes from.  It seems like you are saying that a sub-CA 
> which has been issued a certificate with constraints in it is not 
> bound by that constraint.  This seems illogical.
>  
> In your example, you say "I [the NICT CA] am simply asserting a limit 
> on what certificates I want my relying parties to accept.",  which I 
> agree with. 
>  
> You also say "I am not asserting a limit on what certificates the 
> Novell CA may issue.", which I disagree with (with a caveat).
>  
> If the certificate path includes the NIST CA, (which is what my 
> question is all about) then the NIST CA does constrain which 
> certificates the Novell CA could issue.
>  
> And if the Novell CA wishes to issue certificates which are not bound 
> by the constraint imposed by the NIST CA, then the Novell CA would use 
> a different certificate to issue those certificates (i.e. either a 
> self-signed certificate or a certificate signed by a different CA 
> which did not constrain it.)
>  
> ____________
>  
>  
> From RFC 3280 4.2.1.10 "The basic constraints extension identifies 
> whether the subject of the certificate is a CA and the maximum depth 
> of valid certification paths that include this certificate...the 
> pathLenConstraint field...gives the maximum number of non-self-issued 
> intermediate certificates what may follow this certificate in a valid 
> certification path."
>  
> In this example, CA 2 has issued a certificate to CA 3 that I believe 
> is invalid.  It is invalid because CA 2 has incorrectly asserted that 
> the maximum number of non-self-issued intermediate certificates which 
> may follow CA 3's certificate in a valid certification path is 7.
>  
> Given the certificate path, certificate #3 is invalid on it's face 
> because it asserts something that is not true (i.e. Any path which 
> includes CA1, CA2, CA3, and 7 more subCA's is invalid).
>  
> I would like to emphasize that the definition of basic constraints 
> says that the pathLenConstraint field gives the maximum number of 
> subCA certificates which may follow in a valid path. 
>  
> _______________
>  
> Please do use the algorithm in section 6.1.4 as evidence as to whether 
> what I said is correct or not, as my claim is that the algorithm if 
> flawed. 
>  
> FYI -- The algorithm clearly is not without fault, because the 
> algorithm uses the term "pathLengthConstraint" when it should be using 
> the term "pathLenConstraint"  -- (i.e. if someone did exactly what the 
> algorithm said to do, all pathLenConstraint's would be ignored).
>  
>  
> Thanks,
>  
> Carl
>  
> Carl Tietjen
> Senior Software Engineer
> [email-masked] <mailto:[email-masked]>
> 801 861-7255
> >>> On 5/15/2007 at 12:57 PM, in message <[email-masked]>, 
> "David A. Cooper" <[email-masked]> wrote:
> Carl,
>
> simply asserting a limit on what certificates I want my relying 
> parties to accept.  So, if the basicConstraints extension in the 
> certificate I issue includes a pathLenConstraint of 0, it simply means 
> that I only want NIST relying parties to accept certificates issued by 
> the Novell CA itself.  My including the pathLenConstraint in no way 
> suggests that the Novell CA is not permitted to certificates to other 
> CAs.  Novell may issue certificates to certificates to other 
> organizations' CAs so that the certificates issued by those other 
> organizations may be accepted by Novell relying parties.  The result 
> would be that Novell relying parties, using the Novell CA as a trust 
> anchor would accept certificates issued by the other organizations' 
> CAs.  NIST relying parties, using the NIST CA as a trust anchor, would 
> accept certificates issued by the Novell CA itself, but would reject 
> certificates issued by the other CAs that had been issued a 
> certificate by the Novell CA.
>
> Dave
>
> Carl Tietjen wrote:
>> Hi,
>>  
>> that when the pathLenConstraint is not set, it is asserted that the 
>> CA can create an unlimited number of subordinate CAs (i.e. it means 
>> the path length is unlimited).
>>  
>> We have a CA implementor that claims that when the pathLenConstraint 
>> is not set, it does not mean unlimited, rather that it should just be 
>> ignored.
>>  
>> _____
>>  
>> My arguments for it meaning *unlimited* follow:
>>  
>> In RFC 3280 4.2.1.10 we read the definition of Basic Constraints: 
>> "The basic constraints extension identifies whether the subject of 
>> the certificate is a CA *and the maximum depth of valid certification 
>> paths that include this certificate*."(emphases added).  So by 
>> definition the basic constraints extension asserts whether the 
>> certificate is a CA, and it's maximum certification path.
>> gives the *maximum* number of non-self-issued certificates that may 
>> follow this certificate in a valid certification path." (emphases added).
>>  
>> The fact that the definition says that it supplies the maximum depth 
>> is important because this fact has bearing of what it means when the 
>> extension is encoded in the certificate, some path length value 
>> is set, whether explicitly by setting a specific number, or 
>> implicitly by not setting a value (either way, by definition, it is 
>> telling us what it's maximum depth is).  So when the 
>> pathLenConstraint is not set, the assertion is that the maximum depth 
>> is "no limit..."
>>  
>> no limit to the allowed length of the certification path."   So if a 
>> CA creates a certificate without the pathLenConstraint set, it 
>> asserts that there is "no limit to the allowed length of the 
>> certification path".  Or in my words, it asserts that the path length 
>> is *unlimited*.
>>  
>> _______
>>  
>> The CA implementor argues that when the pathLenConstraint is not set 
>> it does not mean unlimited, it should just be ignored because in RFC 
>> 3280 section 6.1.4 it states:
>> " (m)  If pathLengthConstraint is present in the certificate and 
>> is less than max_path_length, set max_path_length to the value 
>> of pathLengthConstraint."   *Emphasis on "If pathLengthConstraint is 
>> present...".*
>> path being processed is consistent with the value of 
>> pathLenConstraint."  *Emphasis on "and pathLenConstraint is present".*
>>  
>>  
>> Path Validation algorithm (6.1.4 l and 6.1.4 m) for 
>> It is clear that certificate #3 should never have been issued by CA 
>> #2 because it asserts a pathLenConstraint that is not true.  However 
>> [email-masked] <mailto:[email-masked]>
>> 801 861-7255

---

From: "Carl Tietjen" <[email-masked]>
Date: Mon, 21 May 2007 17:34:33 -0700

Dave,

I'm glad to see that the draft update has fixed the pathLengthConstraint flaw.

>>   I agree with you that in a hierarchical PKI, the sample certification path that you present would be illogical, but not all 
>>   PKIs are hierarchical.

I agree that two CA's can be peers, however the certificates that they issue cannot be. Given any certification path, every certificate is subordinate to another certificate or it is the trusted anchor.  For a given certificate path there is no such thing as a peer -- it is always a hierarchy.  

>>    Notice that both of the sentences that you quote include the phrase "this certificate".  The pathLenConstraint field specifies
>>    the maximum depth of valid certification paths that include this certificate.  Certification paths that include certificates issued by
>>    the subject but that do not include this certificate are not affected by the constraint.

>>    So, in my example, the pathLenConstraint specifies the maximum depth of valid certification paths that include the certificate
>>    issued by the NIST CA to the Novell CA, and thus limits the set of certificates that people who use the NIST CA as a trust anchor
>>    may accept, but it does not impose a limit on certification paths that do not include this certificate (e.g., paths in which the 
>>    Novell CA is the trust anchor).

I understand that it says "this certificate".  My point is that the NIST CA is included in the path.  (I am not concerned with the case where it is not included in the path, as we are in agreement over what is valid then.)

My second point is that in the case where the NIST CA was not to be included in the path, and the Novell CA did not want to be constrained by the NIST CA, a different certificate would be used (i.e. one signed by another CA or a self-signed one) rather than creating an inconsistent certificate.

My third point is that when the Novell CA issues a certificate to a sub-ordinate, it should not issue one that violates the constraints that are put on it, neither should it issue a certificate which misrepresents the constraints.

To illustrate, if in the following example, the NIST CA is CA 1 and the Novell CA is CA 2:

CA 1)    CA, 5        (NIST CA)
CA 2)    CA, 2        (Novell CA)
CA 3)    CA, 7
CA 4)    end-entity

When CA 3 asks the Novell CA to issue it a certificate, the Novell CA should not issue a certificate with a path length greater than 1 (using the identified certificates)  because doing so violates the constraints imposed by the NIST CA.  If it wishes to create a certificate, with a path length of 7, it should use a different certificate (one which would allow this constraint to be valid) to do so.  Otherwise, it is just inviting subordinate CA's to issue certificates which are invalid.

Perhaps a different example would better illustrate my points.

CA 1)    CA, 5        (NIST CA)
CA 2)    CA, 0        (Novell CA)
CA 3)    CA, 7
CA 4)    end-entity

In this case, everyone would agree that the certificate for CA 3 would be invalid.  And it is invalid because of the constraint that the NIST CA put on the Novell CA.  Again the NIST CA does not stop the Novell CA from issuing a valid certificate to CA 3, but the Novell CA cannot use the NIST certificate, it must use a different one.   My point is that there really is no difference between these two examples.  In both cases, use of the NIST CA certificate does constrain the Novell CA.   But in both cases, the Novell CA is free to create certificates without the constraint (i.e. to act as a peer) if it uses a different certificate.

Carl

>>> On 5/21/2007 at 3:09 PM, in message <[email-masked]>, "David A. Cooper" <[email-masked]> wrote:

Carl,

FYI -- The algorithm clearly is not without fault, because the algorithm uses the term "pathLengthConstraint" when it should be using the term "pathLenConstraint"  -- (i.e. if someone did exactly what the algorithm said to do, all pathLenConstraint's would be ignored).
I believe that if you look at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-08.txt you will see that this error has been corrected in the draft update to RFC 3280.

I agree with you that in a hierarchical PKI, the sample certification path that you present would be illogical, but not all PKIs are hierarchical.  In the example that I was using, the Novell CA is not subordinate to the NIST CA, the two CAs are peers.  NIST may issue a CA certificate from the NIST CA to the Novell CA in order to be able to validate certificates issued by the Novell CA, but that does not make the Novell CA subordinate to the NIST CA.

From RFC 3280 4.2.1.10 "The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate...the pathLenConstraint field...gives the maximum number of non-self-issued intermediate certificates what may follow this certificate in a valid certification path."
Notice that both of the the sentences that you quote include the phrase "this certificate".  The pathLenConstraint field specifies the maximum depth of valid certification paths that include this certificate.  Certification paths that include certificates issued by the subject but that do not include this certificate are not affected by the constraint.

So, in my example, the pathLenConstraint specifies the maximum depth of valid certification paths that include the certificate issued by the NIST CA to the Novell CA, and thus limits the set of certificates that people who use the NIST CA as a trust anchor may accept, but it does not impose a limit on certification paths that do not include this certificate (e.g., paths in which the Novell CA is the trust anhcor).

Dave

Carl Tietjen wrote: 
Dave,

Thanks for you response.

____________

_______________

Thanks,

Carl

Carl Tietjen
Senior Software Engineer
[email-masked]
801 861-7255

Carl,

Dave

Carl Tietjen wrote: 
Hi,

_____

_______

_______

Thanks in advance,

Carl

Carl Tietjen
Senior Software Engineer
[email-masked]
801 861-7255

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 22 May 2007 10:08:05 +0200

On Mon, May 21, 2007 at 05:34:33PM -0700, Carl Tietjen wrote:
> When CA 3 asks the Novell CA to issue it a certificate, the Novell CA
> should not issue a certificate with a path length greater than 1
> (using the identified certificates)  because doing so violates the
> constraints imposed by the NIST CA.  If it wishes to create a
> certificate, with a path length of 7, it should use a different
> certificate (one which would allow this constraint to be valid) to do
> so.  Otherwise, it is just inviting subordinate CA's to issue
> certificates which are invalid.

Actually, in that example, the Novell CA does not issue the certificate
for CA 3 by using its certificate, but by using its private key. The
certificate for CA 3 will contain the name of Novell CA, and will be
signed by a private key owned by Novell CA.

The "CA 2" certificate has been issued by NIST CA to Novell CA, for use
by people who have the NIST CA as trust anchor (or some anchor above it)
and wish to validate certificates with paths going through Novell CA.
This does not preclude the existence of other certificates issued to
Novell CA, with the same subject name and public key, but with different
constraints.

Let's take the example again, with more notations and an additional
entity called ACME CA.

-- NIST CA has a public key Ki, represented in certificate Ci, which
has a Basic Constraints extension with maximum path length 5. We assume
that Ci has been signed by a trust anchor.

-- ACME CA has a public key Ka, represented in certificate Ca, which
has a Basic Constraints extension with maximum path length 12. We assume
that Ca has been signed by a trust anchor (possibly but not necessarily
the same than the one which signed the NIST CA certificate).

-- Novell CA has a public key Kn. That public key is represented in _two_
certificates:
   ** certificate Cx was signed by NIST CA with key Ki; it has a
      Basic Constraints extension with maximum path length 2.
   ** certificate Cy was signed by ACME CA with key Ka; it has a
      Basic Constraints extension with maximum path length 10.
Both these certificates contain the public key Kn and the name of
Novell CA.

-- CA 3 has a public key K3, represented in certificate C3, which has a
Basic Constraints extension with maximum path length 7. The C3
certificate was signed by key Kn by Novell CA. The C3 certificate
"issuerDN" field contains the name of Novell CA.

-- The EE certificate Ce was signed by CA 3 with key K3.

With these certificates, we can use _two_ paths down to the EE certificate:
one goes through Ci->Cx->C3->Ce, the other is Ca->Cy->C3->Ce.

The point of this example is that when NIST or ACME issues a CA
certificate to Novell, they vest some power upon Novell, namely the
power to transfer trust on certificates issued by Novell CA. But that
mandate goes with some constraints which the pathLenConstraint field
specifies. These constraints are enforced at path validation time
because they apply on the path which is constructed by the entity which
wants to validate the EE certificate. These are not intrinsic
constraints on what Novell CA may issue, by decision of NIST or ACME;
the Cx and Cy certificates may have been issued _after_ Novell CA has
issued C3, and quite possibly Novell was not even notified by NIST or
ACME that such certificates were issued. The Cx (respectively Cy)
certificate represents some trust delegation by NIST (respectively
ACME), not a promise by Novell (possibly, Novell passed some kind of
deal with NIST and/or ACME, but this is not a necessity and is out of
scope of this discussion).

To sum up, the pathLenConstraint is a _constraint_. If C3 has a path
length constraint of 7, then it has the following meaning: Novell
delegates trust to CA 3 but for no more than 7 levels. Novell does not
_guarantee_ in any way that all paths up to 7 levels are good: the trust
which Novell delegates was obtained from entities higher in the path
(e.g. NIST CA or ACME CA) which may enforce additional constraints. In
any way, Novell did not issue certificates because it was (or will be)
trusted: Novell knows who it is and trusts itself. Trust is a property
which is handled and verified by the entity which validates the path.

	--Thomas Pornin