Subject: Re: Changes to RFC2459

From: [email-masked] (Peter Gutmann)
Date: Sun, 4 Apr 1999 01:34:23 (NZST)

Stephen Kent <[email-masked]>
 
>This is consistent with PKIX, which calls for the extension to be present and
>non-NULL for a CA cert, but recommends that it be absent for an EE cert.  It
>is consistent with X.509, which requires the extension to always be present and
>non-null for a CA, but suggests that it be present and NULL for an EE.  X.509
>also suggests that if the extension is not present, then a system may choose
>to employ other means to determine if it is an EE or a CA cert.  But, in that
>case, you're back to looking at other fields ...
>
>What's the problem?
 
We went through this whole thing less than six months ago.  Here's what I 
posted the last time this came round:
 
-- Snip --
 
Both MSIE and Netscape treat self-signed certs without basicConstraits as 
CA's by default (in fact I don't know of any way to get them to *not* 
treat the cert owners as CA's).
 
MSIE: "You have been offered a new site certificate to place in your list
       of trusted issuers..."
Netscape: "You are about to go through the process of accepting a
           certificate authority..."
 
Leaving out the basicConstraints makes the assumption that relying parties
are using PKIX-compliant software, and that the software will DTRT when it
finds one of these certs.  I think this is leaving what could be a critical
security issue more or less to chance - all I need to do is find some
software which happens to not follow PKIX's implied behaviour and I can go
ahead and issue my own certs and let the entire world in the door.
 
-- Snip --
                              
Leading to the following entry in the X.509 style guide:
 
-- Snip --
 
PKIX
 
  PKIX requires that end entity certificates not have a basicConstraints
  extension, which leaves the handling of the CA status of the certificate to
  chance.  Several popular applications treat these certificates as CA
  certificates for backwards-compatibility with X.509v1 CA certificates which
  didn't include basicConstraints, but in practice it's not really possible to
  determine how these certificates will be treated.  Because of this, it's not
  possible to issue a PKIX-compliant end entity certificate and know how it'll
  be treated once it's in circulation.
 
  One use for this feature is that it may be used as a cryptographically strong
  random number generator.  For each crypto key an application would issue 128
  basicConstraint-less certificates, hand them out to different
  implementations/users, and use their CA/non-CA interpretation as one bit of a
  session key.  This should yield close to 128 bits of pure entropy in each
  key.
 
-- Snip --
 
Peter.

---

From: Michael Sierchio <[email-masked]>
Date: Sat, 03 Apr 1999 09:30:01 -0800

> treat the cert owners as CA's).

My impression is that, in the case of Netscape,  it's the MIME type
that causes a cert to be treated as a CA:  application/x-x509-ca-cert,
and not all of these are self-signed.

---

From: Moshe Litvin <[email-masked]>
Date: Mon, 05 Apr 1999 07:46:42 +0200

Peter Gutmann wrote:

-- Snip --

-- Snip --

Since PKIX allows end entity certificates with basicConstraints - it is only SHOULD
NOT and not MUST NOT - it is possible to do it.

Moshe

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 1999 13:26:03 -0400

Peter,

>ahead and issue my own certs and let the entire world in the door.

I thought the debate we are having was focused on the differences between
compliance with X.509 and PKIX.  Since neither standard REQUIRES inclusion
of basic constraints for an EE, conformance to either standard does not
completely solve the problem of the browser vendors having made the
decision you cited, right?

Is the concern that an EE might provide a self-signed cert to one of these
browsers and have it interpreted as a CA vs. an EE cert?   Obviously, since
it is self-signed, an EE could elect to include a basic constraints
extension with a CA flag if the intent is to deceive the browser user.  So,
is the argument, that PKIX should require an EE cert to have a NULL basic
constraints extension so that an EE can be declared compliant with PKIX and
still not cause these browsers to misinterpret a self-signed cert under
these circumstances?

If that's the argument, then we need to consider such a change based on at
least these issues:
	- under what circumstances would an EE use a self-signed cert? note
	 that PKIX always describes self-signed certs in the context of CAs,
	  not of EEs.  X.509 makes NO mention of self-signed certs
	- should PKIX change to accommodate current browser conventions that
	are still ambiguous with regard to strict adherence to X.509?

Steve