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

Re: USENIX PGP key signing service



At 07:01 PM 5/30/96 -0700, Wei Dai wrote:

>Sorry for the misunderstanding.  But I think this meaning is still
>somewhat ambigous.  See below.

I'm glad you provided the clarification -- caught my sloppiness.  You're
right.  My procedure did *not* satisfy your #1.

>My previous message tried to argue that the process you suggested
>does not allow for example 1 and that stating the meaning in this explicit
>form makes this fact clearer.

Yup.

>Let me try again.  Suppose Alice want to communicate with Bob, and the
>only thing Alice knows about Bob is that his e-mail address is
>bob@foo.com.  Alice has an USENIX certificate that says "If you believe
>entity x has e-mail address bob@foo.com, then you should believe that
>entity x owns public key ..." If the process that generated this
>certificate is the one you described, then Alice should NOT use the
>certificate to infer that Bob owns the given key. If she does, then she
>could be open to the following attack: 
>
>Mallet enters the USENIX signing process and truthfully provides all the
>information except for the e-mail address, which he says is bob@foo.com. 
>When the secret S2 is e-mailed to bob@foo.com, Mallet intercepts it and
>then forges a reply that appears to come from bob@foo.com.  Now Mallet has
>a certificate that says "If you believe entity x has e-mail address
>bob@foo.com, then you should believe that entity x owns public key ..." 
>but the given public key is Mallet's, not Bob's. 

Yes -- and here's why:

All certificates transfer or delegate authority.  They are one-way
processes.  I specified a method for establishing

        A -> B

and you're using it as if it said

        B -> A

(where I'm using "->" to mean "yields", as in a trusted database lookup).

There is a bond between the private key and the key's owner which is very
strong (assuming the key and key password were well protected).  So, we have

        Key <-> Owner

Since the owner can not act directly in cyberspace (not being a digital
entity himself) but the key can, I will show this as

        (key(=owner))

meaning that the key stands for the owner in cyberspace dealings (again,
assuming the key was protected well enough).

This applies to both a signature key and a confidentiality key.

If *you* define the owner by way of his cyberspace stand-in (his public
key), then all you need to do is encrypt a message in that key (==for that
owner) and broadcast it.  If the owner gets it, he can read it.  If anyone
else gets it, they can't.  So, you don't care what e-mail address you use --
except in the interest of saving net bandwidth and avoiding flames.

What you wanted, however, was to define the owner by way of his e-mail address.

I gave you:

        (key(=owner)) -> (e-mail)

but you wanted

        (e-mail) -> (key(=owner))

each of these -> relationships requires a certificate of some form.  The
certificate should be issued by the owner of the left side.  In

        (key) -> (e-mail)

the cert is signed by the key.  It is the final authority on what e-mail
address(es) it can use to receive encrypted mail.

In

        (e-mail) -> (key)

the cert needs to be signed by the authority for the e-mail space -- e.g., a
company- or ISP- sysadmin.  Note that in this case, USENIX is *not* an
authority.  It can not testify to this mapping.  It *can* testify to the
mappings:

        (member ID) -> (e-mail)
and
        (member ID) -> (key)

if it employs the process Neal described (and I diddled with).

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091              Tel: (703) 620-4200                         |
+--------------------------------------------------------------------------+


Follow-Ups: