Subject: Re: Problem with PKIX part 1 basicConstraints

From: [email-masked] (Peter Gutmann)
Date: Tue, 17 Nov 1998 13:08:11 (NZDT)

Tim Polk <[email-masked]> wrote:

>If the basic constraints extension is not present, certificate processing
>is consistent with v1 or v2 certificates.  If out-of-band information
>specifies the subject is a CA, it's a CA.  If out of band information is
>not available, the user of the certificate assumes the subject is NOT a
>CA.

Assertion: If basicConstraints is not present, current software typically
           assumes the subject is a CA.
Proof: Create a self-signed certificate without basicConstraints, load it
       into MSIE or Netscape, and see what happens.

>3) If an end entity wishes to accept a certificate without a
>basicConstraints extension as a CA certificate, it must rely on
>out-of-band information.  In this case, the responsibility lies on the
>certificate user and the source of the out-of-band information, not on
>the certificate issuer.  The certificate issuer attests to the binding of
>subject and key, not the subject's status as a CA.

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.

Peter.

---

From: Tim Polk <[email-masked]>
Date: Tue, 17 Nov 1998 09:49:13 -0500

Peter,

Both MSIE and Netscape are relying on the user's judgement: the user *must*
have out-of-band information that the subject is a trustworthy CA, or they
wouldn't install it as a site certificate, would they??? (If I could
remember how to make a smiley face, I'd insert it here!)

The basicConstraints extension does not fix this problem, though.  If NIST
used that extension (and marked it critical) in end entity certificates,
that prevents me from using my NIST certificate to claim CA status.  I
don't really need that for the browser scenario.  If I can generate new
certs, I can generate my own.  When I generate my self-signed certificate I
might as well include the basicConstraints extension. If I could get folks
to accept it without that extension, they'll certainly accept with that
extension.

Clearly, the safest choice would be to select a single trusted CA (or a
very small number) as the beginning (end?) of all valid paths and only
accept a subject as a CA if the basicConstraints extension is present.
(That is, never accept a subject as CA based on out-of-band information.)
User selected trust points are always fraught with danger.  The solutions
are to improve the client software and educate the users, in my opinion.

How?  Now that's a tough question!

Tim