[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Certificate Path Validation
Denis:
My interpretation of X.509 and RFC 3280 is that the validity period and
other checks in the trust anchor can be ignored during path validation.
An implementation that checks the validity period and other field is
still compliant. It is simply doing checks that are not required.
-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: Monday, August 12, 2002 5:26 AM
To: Santosh Chokhani; 'Sharon Boeyen'
Cc: ietf-pkix@xxxxxxx
Subject: Re: Certificate Path Validation
Santosh and Sharon,
> Sharon: Not only do I agree with you, but an appropriate
> interpretation of both the X.509 and RFC 3280 is that aside from
> getting the following information from the trust anchor, no fields in
> the base trust anchor certificate (e.g., validity period) need to be
> processed:
>
> * Issuer DN
> * Signature Algorithm
> * Public key
> * Parameters, if applicable
It is just obvious that the trust anchor shall be valid for the time the
checking is being done.
Note the basic path validation described in RFC3280 does *not* allow
validation in the past since it still says:
"6.1.1 Inputs. This algorithm assumes the following seven inputs are
provided to the path processing logic: (...) (b) the current
date/time."
:-(
When CMP is being used, self-signed certificates can be used to make
sure that the trust anchor is currentltly valid and to smoothly change
the trust anchor.
Here again, self-signed certificates are not mandatory to be used, but
if they are used, then their validity period shall not be ignored.
In reply to Sharon, I have seen no text to say that some extensions in
self-signed certificates shall be ignored. If we had to do something
(which I do not currently think) then the approach should be to
constrain the format of self-signed certificates and to say that
self-signed certificate SHALL NOT contain or SHALL only contain such or
such extension, ... and we have not done that, AFAIK.
Denis
> *
>
> -----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 Validation
>
> From 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/6N12223CertEnhancem
ent4thWD.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
>