[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: X.509, S/MIME, and evolution of PGP


>Date: Tue, 03 Oct 1995 11:37:22 -0700
>From: Bill Stewart <[email protected]>

>At 10:24 AM 10/3/95 EDT, Carl Ellison <[email protected]> wrote:
>>I hear you but I object.
>>Going along with the majority may be the fastest way to get a result out
>>but it's morally wrong.
>A zillion and a half people are about to get the next version of Netscape,
>which uses X.509 certificates, and they can get free Verisign personna
>certificates to go with them; stores can get inexpensive ones.
>They will use this for secure email, like it or not,
>and as they discover the need for better certification (when there's
>money involved), they'll go get it.  Wherever they can.

Yup.  Verisign is probably going to fight hard to keep their certificate
model.  On top of them, there's the US Postal Service and a few others,
fighting over the chance to set up a certificate hierarchy.

The whole world is thinking of physical people and of tying things to those
people.  They think of names as the only handle on (pointer to) people.
...so they see certificates as right and proper.  We need to show them a
better way.  (Tie attributes through the key to the person -- not through
the person to the key.)

>The question is, will they get a Web of Trust model from us,
>or will they stick to the hierarchical model?  

As several have pointed out, a certificate structure (X.509, PGP or mine)
can be used in a hierarchy, if you want it, or not if you don't.  We don't
care.  What I care about is that a signed thing (one link in a chain of
assertions) speak directly to what it is signing ("this key is good for
_________") or ("the person who demonstrated to me that he knew the private
key for this key has red hair and wore glasses") -- rather than try to
sidle up to existing people structures (by tying to names of people) and
then, on discovering that the people-structures aren't as strong as the
digital signatures, make the people structures stronger (e.g., by unique ID
number on a national ID card, with thumbprints for verification).

>						If we get something
>halfway decent out there, fast enough, ideally with support
>or toleration from Netscape, people will at least have distributed trust
>models in their worldview, and will insist that the tools they use and
>build around it be compatible.  Otherwise, almost all of them _will_ be
>using the hierarchical-only structure, and the next big Internet application
>needs security will latch onto the now-big software base, and may not
>be as decent as Netscape about the trust models they accept.

Yes -- I agree.  We should get cracking on this.

>If you can define a better relational trust model than the Web stuff,
>fast enough to avoid this, great!  Go for it.  But it'll be much easier
>to get something like that adopted in a non-hierarchical world than in
>a world of Drivers' Licenses on the Information Superhypeway. 

I'm still talking web of trust -- only I'm removing the person's name (or
e-mail address) as a link between the assertion and the key.

Haven't I described this well enough?  Do I need to write it up in more

How about some analogies?

I could have a driver's license (giving my name and address), a piece of
paper saying that I (at my address) own bank account number 01732 at First
Security Bank, and a certificate from Verisign also giving my name and
address.  This ties my public key to my driver's license (assuming I'm the
only Carl Ellison at my address (which I wasn't, as a kid) and that I don't

Alternatively, I can have First Security Bank open account 01732 for me and
create a certificate binding my public key to that account number.  Now, I
can use that key to sign anonymous checks.  (The bank knows me, perhaps,
but the payee doesn't need to.)  To tie my name to the public key, I sign
my own certificate saying ``The person who knows the private key for
61E2DE7FCB9D7984E9C8048BA63221A2 goes by the name "Carl Ellison" and
receives mail at "[email protected]".''  I don't need anyone else to attest to
the validity of that statement because it's uni-directional (from key to my
name), not the other way.  It's only the other assertion direction which
requires some witnesses to attest to validity, because the name is not
capable of doing a digital signature without a key.  [That is, if you were
to go the other direction (which is what X.509 or PGP try to do), you need
to sign a key with a name (DN or UserID).  You can't sign with a DN or
UserID.  You can sign with a key.  So, you have to fall back on human
witnesses to use their keys to sign in place of the name (DN or UserID) and
you have to decide how to trust those witnesses.  If you reverse the arrow
of assertion, this particular problem goes away.]

 - Carl

|Carl M. Ellison      [email protected]    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |

Version: 2.6.2