Re: Certificate Path Validation

[Steve Hanna <steve.hanna@xxxxxxx>]

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