[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: