Subject: RE: Certificate Path Validation

From: Sharon Boeyen <[email-masked]>
Date: Fri, 9 Aug 2002 13:58:35 -0400

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/6N12223CertEnhancement4
thWD.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:[email-masked]]
Sent: Friday, August 09, 2002 9:51 AM
To: Denis Pinkas
Cc: Sunil Agrawal; [email-masked]
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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 9 Aug 2002 21:18:48 -0400

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: Friday, August 09, 2002 1:59 PM
To: 'Steve Hanna'; Denis Pinkas
Cc: Sunil Agrawal; [email-masked]
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:[email-masked]] 
Sent: Friday, August 09, 2002 9:51 AM 
To: Denis Pinkas 
Cc: Sunil Agrawal; [email-masked] 
Subject: Re: Certificate Path Validation 

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 12 Aug 2002 11:26:04 +0200

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

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

>    *
>      From: [email-masked]
>      [mailto:[email-masked]] On Behalf Of Sharon Boeyen
>
>      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.
>
>      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.
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 12 Aug 2002 08:05:42 -0400

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:[email-masked]] 
Sent: Monday, August 12, 2002 5:26 AM
To: Santosh Chokhani; 'Sharon Boeyen'
Cc: [email-masked]
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

"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

ent4thWD.doc

---

From: Jeff Jacoby <[email-masked]>
Date: Mon, 12 Aug 2002 09:11:56 -0700

Denis Pinkas wrote:
> interpretation of

However, the third paragraph in section 6.1 says:

  "The algorithm presented in this section validates the certificate
   with respect to the current date and time.  A conformant
   implementation MAY also support validation with respect to some point
   in the past.  Note that mechanisms are not available for validating a
   certificate with respect to a time outside the certificate validity
   period."

Jeff

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 12 Aug 2002 18:26:05 +0200

Jeff,

(...)

>    certificate with respect to a time outside the certificate validity

Thanks for this remainder. Implementations MUST support validation for the
current time, but MAY also support validation in the past.

Denis