Subject: [pkix] clarification of pathLenConstraint

From: "Hu, Jun (Jun)" <[email-masked]>
Date: Tue, 12 Apr 2011 13:42:15 -0500

Hi,
I have a certificate path like following:

Root-CA(pathlen=0) --> CA1(pathlen=0) --> user_cert

Root-CA is a self-issued CA, Root-CA signs CA1 and CA1 signs user_cert, both Root-CA and CA1 has pathLenConstraint=0.

So the question is: 
Is the user_cert valid in this case?

Following text in section 4.2.1.9 of RFC5280 seems to suggest user_cert in this case is not valid
"A pathLenConstraint of zero indicates that no non-self-issued intermediate CA certificates may follow in a valid certification path."

But then following text in section 6.1 seems to suggest the opposite: 
"These self-issued certificates are not counted when evaluating path length or name constraints."
Because if Root-CA is not counted, the CA1(pathlen=0)-->user_cert is a valid cert path. 

So I am bit confused here ...

---------------
Hu Jun

---

From: Thomas Pornin <[email-masked]>
Date: Tue, 12 Apr 2011 14:54:50 -0400

On Tue, 2011-04-12 at 13:42 -0500, Hu, Jun (Jun) wrote:
> Root-CA is a self-issued CA

RFC 5280 does not really recognize the concept of "self-signed root CA".
Certificate validation begins with a "trust anchor", which consists in a
public key and a name, and also some parameters detailed in section
6.1.1. None of these parameters is a limit on subsequent path length.
The "max_path_length" variable is initialized to the total path length
(in section 6.1.2, clause (k)).

It is _traditional_ to encode trust anchors (and some other validation
inputs) as self-signed certificates. However, this is out of scope of
RFC 5280. The storage format for a trust anchor has no influence on the
validation process. In particular, the Basic Constraints Extension which
may be present in the self-signed root certificate will be completely
ignored.

As per RFC 5280 rules, your path shall be considered as valid.

	--Thomas Pornin

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 12 Apr 2011 15:08:06 -0400

It is unclear in the scenario that you describe below whether the 
self-issued certificate that was issued by Root-CA is self-signed, so 
the answer is that it depends.

If Root-CA is not a self-signed certificate, then this path is not valid 
since the first certificate in the path includes a constraint of 
pathLenConstraint=0 and that certificate is followed in the path by a 
non-self-issued intermediate certificate.  [The path would be valid if 
the second certificate in the path, CA1, were self-issued.]

If Root-CA is a self-signed certificate, then this certification path 
really only consists of two certificates: CA1 and user_cert.  In this 
case, Root-CA is just the source of trust anchor information (Section 
6.1.1 (d)) and (as is stated in Section 6.1) is not part of the 
prospective certification path.  In this case, a path validation 
algorithm would be to permitted to ignore the constraints information in 
the self-signed certificate, which would lead to its considering the 
path to be valid.

One would have to wonder, though, why a CA would place a constraint of 
pathLenConstraint=0 in its self-signed certificate and then proceed to 
issue a CA certificate.  Did it change its mind about issuing CA 
certificates after generating and distributing the self-signed 
certificate?  Are the CA certificates only intended to be accepted by 
relying parties that use Root-CA as an intermediate CA and not as a 
trust anchor?

---

From: "Hu, Jun (Jun)" <[email-masked]>
Date: Tue, 12 Apr 2011 17:29:34 -0500

Thanks for the clarification. The Root-CA I was using is a self-signed certificate. 

One thing maybe worth to mention:
I imported these certificates into windows xp like following:
Self signed Root-CA into Trusted Root Certification Authorities
CA1 into Intermediate Certificate Authorities 
user_cert into Other People 

Then it seems windows consider user_cert is invalid, here is the screen shoot: http://tinypic.com/r/16izc44/7

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Apr 2011 18:57:25 +1200

>As per RFC 5280 rules, your path shall be considered as valid.

You really need to qualify this a bit more, although I guess the "as per RFC 
5280 rules" is one qualification :-).  The real-life version though is:

  If the implementation ignores path-length constraints, it's valid.  If the 
  implementation doesn't ignore path-length constraints and pays attention to 
  extensions in root certs, it's not valid.  If the implementation doesn't 
  ignore path-length constraints but ignores extensions in TAs, it's back to 
  not valid again.

A more succint summary would be:

  It's a coin-toss.

I guess it all comes down to whether the original poster was interested in
what's valid in theory vs. what will actually happen in practice.

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 14 Apr 2011 07:49:45 -0400

Here's mine - there's no point in putting path length constraints 
into self-signed certificates unless you expect them to be processed by an 
engine which implements an initial value for path length.  RFC 5280 
doesn't really favor such engines, although RFC 5914 does allow path 
length in the CertPathControls structure.  That extension in a self-signed 
certificate is almost meaningless to a 5280 engine.
        Maybe we should put an extra variable for the length into RFC 5280 
6.1.1 and change 6.1.2-k to use it.  I would say that you could initialize 
max_path_length to 32K-1 (or "a positive integer greater than any path 
length supported by the validation engine") as easily as to N, since the 
only thing that matters about its value is it staying positive.

                Tom Gindin

From:
Peter Gutmann <[email-masked]>
To:
[email-masked], [email-masked]
Cc:
[email-masked]
Date:
04/13/2011 02:57 AM
Subject:
Re: [pkix] clarification of pathLenConstraint
Sent by:
[email-masked]

>As per RFC 5280 rules, your path shall be considered as valid.

You really need to qualify this a bit more, although I guess the "as per 
RFC 
5280 rules" is one qualification :-).  The real-life version though is:

  If the implementation ignores path-length constraints, it's valid.  If 
the 
  implementation doesn't ignore path-length constraints and pays attention 
to 
  extensions in root certs, it's not valid.  If the implementation doesn't 

  ignore path-length constraints but ignores extensions in TAs, it's back 
to 
  not valid again.

  It's a coin-toss.

Peter.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Carl Wallace <[email-masked]>
Date: Thu, 14 Apr 2011 08:03:36 -0400

>only thing that matters about its value is it staying positive.

RFC 5937 describes how to use the path length value from a TA during path
processing.