Subject: RE: Basic constraints processing for SSL

From: Laurence Lundblade <[email-masked]>
Date: Thu, 15 Aug 2002 16:54:25 -0700

At 11:11 AM 8/13/2002 -0400, Sharon Boeyen wrote:

>Just to add the X.509 voice to this discussion. With respect to the self 
>signed certificates, the statement made by Russ below was reinforced some 
>time ago through the processing of a defect report (DR) against the base 
>X.509 standard. As a result of that DR, the following sentence was added 
>to 12.4.3 of X.509:
>
>"Self-signed certificates, if encountered in the path, are ignored."

So does this mean that the validity dates in trusted roots and/or 
self-signed certs are to be ignored, or is this part of a distinct trust 
anchor validation process? It seems like a bad thing to ignore the validity 
dates in trust anchors.

Similarly, does that mean the pathLen part of BasicConstraints should be 
ignored during path validation? The 3rd paragraph of section 6 in RFC 3280 
sort of implies that trusted roots aren't entirely ignored when it says 
"The algorithm requires the public key of the CA, the CA's name and any 
**constraints upon the set of paths** which may be validated using this 
key". 21 of the root certs in IE have pathLen. The value varies from 1 to 10.

I'm still having trouble with the term "CA certificate". Sort of seems like 
everyone knows what it is but me :-).  So if I pretend I have a "CA 
certificate" in my pocket, what do I have?
a) A trust anchor (but not necessarily self-signed)
b) A self signed cert
c) A cert that's NOT an end entity
d) An intermediate/branch cert (which obviously can't be self signed)
e) One with the CA=TRUE in BasicConstraints (if so can a cert without 
BasicConstraints ever be a "CA certificate")
f) Some combination of the above

Dean made the comment that it doesn't say what to do when BasicConstraints 
aren't present. This was generally (not just BasicConstraings) the 
difficult part - when the certs you get diverge from the standards and you 
know you have to process them. Adding that sort of text to the document (or 
a BCP document) would certainly be valuable.

LL

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 16 Aug 2002 09:26:54 -0400

Laurence:

>anchor validation process? It seems like a bad thing to ignore the 
>validity dates in trust anchors.

The RFC does not require an implementor to use self-signed certificates to 
distribute trust anchor information.  Many vendors use this technique 
because it is a convenient way to bundle the information needed to define a 
trust anchor.  It also includes other information that is not needed to 
specify a trust anchor (by the definition in the RFC).

The validity period is the most obvious example.  Given the number of trust 
anchors that are embedded in brousers, the validity period provides an 
important service.  If the list were very small, say two or three, then the 
validity period would not be nearly as important.

>key". 21 of the root certs in IE have pathLen. The value varies from 1 to 10.

This is another example.  An implementation that ignored the 
BasicConstraints associated with the self-signed certificate that defines a 
trust anchor would be compliant with the RFC.  However, an implementation 
that enforced the BasicConstraints associated with the self-signed 
certificate that defines a trust anchor would also be compliant with the RFC.

>I'm still having trouble with the term "CA certificate". Sort of seems 
>like everyone knows what it is but me :-).  So if I pretend I have a "CA 

A CA certificate is not a trust anchor, and it is not the end entity 
certificate.  The CA certificate is any other certificate within the 
certification path.

Russ

---

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

Laurence,

[Sharon]

> > signed certificates, the statement made by Russ below was reinforced
> > some time ago through the processing of a defect report (DR) against the
> > base X.509 standard. As a result of that DR, the following sentence was
> > added to 12.4.3 of X.509:
> >
 
> validity dates in trust anchors.

I fully agree. A self-signed certificate needs to include a validity period
otherwise it would not be a certificate !

So, if a self-signed certificate is used as a trust anchor, the validity
period cannot be ignored.

Now, if a self-signed certificate is NOT used as a trust anchor, it would
still make sense to add a validity period to the three current elements:

 - CA name,
 - PK algo and value, 
 - PK parameters.

> key". 

Path length is certainly a value that some CAs want to constrain, whatever
the local additional conditions of the RP may be.

To summarize, validity period has always to be considered.
Path length is to be considered if present in a self-signed certificate.

> 21 of the root certs in IE have pathLen. The value varies from 1 to
> 10.
> 

> a) A trust anchor (but not necessarily self-signed)

No. A trust anchor is not a certificate. 

> b) A self signed cert

Yes.

> c) A cert that's NOT an end entity

We do not have that kind of distinction. We can however know that a
certificate belongs to a CA, using the basic constraints extension.  

> d) An intermediate/branch cert (which obviously can't be self signed)

Yes.

> e) One with the CA=TRUE in BasicConstraints 

Yes.

> (if so can a cert without BasicConstraints ever be a "CA certificate")

No.

> f) Some combination of the above

No.
 
> aren't present. 

RFC 3280 states:

   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.  This extension MAY appear as a critical
   or non-critical extension in CA certificates that contain public keys
   used exclusively for purposes other than validating digital
   signatures on certificates. 

I would recognize that I do not recall the reason for the MAY. :-)

Denis

> This was generally (not just BasicConstraings) the
> know you have to process them. Adding that sort of text to the document
> (or a BCP document) would certainly be valuable.
> 
> LL