[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/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
>