Subject: Re: Problem with PKIX part 1 basicConstraints

From: "Aram Perez" <[email-masked]>
Date: Tue, 17 Nov 1998 13:06:11 -0800

Another soapbox sermon ;-)

[Stand on soapbox]
PKI is a "key management solution" that greatly eases the key management
problems associated with cryptography but it does not eliminate all of them.
Symmetric cryptography, when using good key management principles (i.e. only
two parties share the same symmetric key), has the inherent problem that the
number of keys needed for a given set of parties grows geometrically. For
example, two parties need 1 key, three parties need 3 keys, four parties
need 6 keys, five parties need 10 keys, etc. Another problem is that a key
has to be manually exchanged, usually by some sort of face-to-face contact
or via a trusted third party (or parties).

When Diffie-Hellman first proposed public key encryption, the idea was that
an individual could "publish" his/her public key (after all, it is "public")
so that it would solve the manual key distribution problem. First, a party
only needs a public key pair (for key exchange) no matter how many parties
are involved. And it would no longer be necessary to have a face-to-face key
exchange since two parties could use each other's public keys to exchange a
symmetric key. Well in theory this works fine but not in practice. Why,
because if both parties are communicating purely electronically, how do they
know that they received the correct public key for the other party and not
the public key from a "man-in-the-middle"?

Well, we being engineers, came up with an easy solution, we created
"certificate authorities" (CAs) which sign public keys so that the keys can
be "trusted". So now a party receiving a public key (in a certificate) can
verify the key by following the chain (or web) of signers to the the CA.
This still leaves the problem of how do you know that the CAs public key
(i.e. the root certificate) is valid and therefore "trusted". I maintain
that the only way of trusting a root certificate is via some sort of manual
(i.e. out-of-band) method. There is no purely electronic way of verifying
root certificates. But I would rather manually verify a "handful" of root
certificates than a large number of public and/or symmetric keys.

Most people who download a browser that comes with root certificates
(whether IE, Navigator or whichever) do not know that they should "manually"
verify the root certificates by checking "fingerprints". If I download IE
from a non-Microsoft site, how do I know that the root certificates have not
been modified (or a bogus one inserted)? I also find it ironic that it is
very hard to find out Verisign's fingerprints from their Web site. Ditto for
GTE CyberTrust.

In conclusion (before the tomatoes start flying ;-), whether you have an
extension or not, you need to manually verify root certificates with some
out-of-band information. And like Tim wrote: "The solutions are to improve
the client software and educate the users". (But the how is not easy.)

[Get down from soapbox]

Regards,
Aram Perez

>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
>
>
>At 01:08 PM 11/17/98, Peter Gutmann wrote:
>>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: Alex Deacon <[email-masked]>
Date: Wed, 18 Nov 1998 08:30:20 -0800

> I also find it ironic that it is
> very hard to find out Verisign's fingerprints from their Web site. 

See https://www.verisign.com/repository/root.html fingerprints of
VeriSign's root certificates.

Alex