Subject: Certificate Path Validation

From: Sunil Agrawal <[email-masked]>
Date: Fri, 02 Aug 2002 12:17:19 -0700

Dear PKIX WG:

I need some help on Certificate Path Validation.

If my trust anchor is a non self signed certificate, what should be the 
contents
of the initial permitted_subtrees.

permitted_subtrees is defined as "a set of root names for each name type 
(e.g.,
X.500 distinguished names, email addresses, or ip addresses) defining a set of
subtrees within which all subject names in subsequent certificates in the 
certification
path MUST fall".

The RFC 3280, section 6.1.2, subsection b, says

"the initial value for the set for Distinguished Names is the set of all 
Distinguished
names;"

So is the RFC recommending ignoring the Name constraints extension (if 
present) in
the CA certificates that are higher in the hierarchy that the trust anchor ?

Is the recommendation same for excluded_subtrees and other policies?

TIA,
Sunil

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 09 Aug 2002 15:00:03 +0200

Sunil,

> contents of the initial permitted_subtrees.

Any name restriction, if any, you want to apply for that trust anchor.

> (e.g., X.500 distinguished names, email addresses, or ip addresses) 
> defining a set of subtrees within which all subject names in subsequent 
> certificates in the certification path MUST fall".
> 
> Distinguished names;"
 
> present) in the CA certificates that are higher in the hierarchy that 
> the trust anchor ?

There exist no "CA certificates that are higher in the hierarchy that the
trust anchor". So the sentence is not correct.

If the trust anchor contains name restrictions, then they MUST be used as
part of the initial permitted_subtrees. In addition, you can apply
additional name restrictions. This means that the initial permitted_subtrees
conditions may come both from name restritions contained in the self-signed
certificate (if any) and from name restrictions external to the trust anchor
(which may or may not be specified in the form of a self-signed
certificate). 
 
> Is the recommendation same for excluded_subtrees and other policies?

The same phylosohy applies.

Regards,

Denis

---

From: Steve Hanna <[email-masked]>
Date: Fri, 09 Aug 2002 09:50:38 -0400

I agree with most things that Denis wrote, however...

Denis Pinkas wrote:
> If the trust anchor contains name restrictions, then they MUST be
> used as part of the initial permitted_subtrees.

This does not agree with RFC 3280, which says in section 6.1.2,
subsection b that "the initial value [for the permitted_subtrees
state variable] for the set for Distinguished Names is the set of
all Distinguished names; the initial value for the set of RFC822
names is the set of all RFC822 names, etc." Section 6.2 says that
"an implementation MAY modify the algorithm to apply name
constraints to a specific trust anchor during the initialization
phase", so this is permitted but not part of the Basic Path
Validation algorithm described in section 6.1.

Denis also wrote:
> In addition, you can apply additional name restrictions. This
> means that the initial permitted_subtrees conditions may come
> both from name restritions contained in the self-signed
> certificate (if any) and from name restrictions external
> to the trust nchor (which may or may not be specified in
> the form of a self-signed certificate).

Again, RFC 3280 allows implementations to do this as a supplement
to the Basic Path Validation algorithm. In fact, they are allowed
to apply *any* additional restrictions on valid paths that they
like. Section 6.1 says "an application MAY augment this algorithm
to further limit the set of valid paths." Applying additional
name constraints to trust anchors is just one example.

To provide some background, this topic has been discussed before
on the PKIX list (as have most PKI-related topics). Some people
believe that it's helpful to apply name constraints to trust
anchors to handle the case when they're only trusted for part
of the namespace. Others feel that this is best handled by
having a CA issue cross-certificates that contain those name
constraints and then making that CA be the trust anchor. The
former solution avoids the need to establish another CA. The
latter solution allows the constraints to be changed (or additional
trust links established) without requiring every application
to update its trust anchors. This issue was resolved by having
RFC 3280 describe a Basic Path Validation algorithm that is
mandatory to implement and optional extensions to it, such as
name constraints on trust anchors.

-Steve