-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Sharon Boeyen
Sent: Friday, August 09, 2002 1:59 PM
To: 'Steve Hanna'; Denis Pinkas
Cc: Sunil Agrawal; ietf-pkix@xxxxxxx
Subject: RE: Certificate Path ValidationFrom a 509 standpoint I agree with Steve. I remember a defect that we
progressed to make it clear that extensions in a self-signed cert are NOT
used during path validation. I don't have it at my fingertips but could dig it up if necessary.As for name constraints, this is one area where, unlike all those related to policy, the path validation procedure does NOT have an input variable whereby a particular value can be input as the initial set of permitted/excluded subtrees. Cross-certificates are the only way to impose such restrictions in the standard. In 10.3 of X.509 2000 note that the initialization step for path validation sets the permitted subtrees variable to unbounded and sets the excluded subtrees variable to an empty set.
Note that in the current set of proposed enhancements to X.509, ( ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output/6N12223CertEnhancement4thWD.doc )Issue number 5 proposes an enhancement that would allow the permitted and excluded subtree variables to be initialized to values other than unbounded and empty set respectively. However that is not yet standardized, nor is it related to extensions in self-signed certs.
-----Original Message-----
From: Steve Hanna [mailto:steve.hanna@xxxxxxx]
Sent: Friday, August 09, 2002 9:51 AM
To: Denis Pinkas
Cc: Sunil Agrawal; ietf-pkix@xxxxxxx
Subject: Re: Certificate Path Validation
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