[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: USENIX PGP key signing service
At 02:04 PM 5/30/96 -0700, Wei Dai wrote:
>[cc: coderpunks removed]
>
>Carl wrote:
>
>> So, you don't get any fingerprints at the booth. Instead, you generate two
>> secrets, S1 and S2 -- give S1 to the person, log S1 and S2 in your records
>> alongside their name and USENIX member number. You pgp -cat encrypt S2
>> using S1 as the key. You send that message to the user's indicated e-mail
>> address. That user decrypts that message and sends back S2, signed. When
>> you get that and verify it, you sign the user's key, send it to him and
>> post it to the key servers. You use a USENIX key whose only UserID is a
>> URL instead of an e-mail address and at that URL you list the meaning of
>> the signature.
>
>If you start using certificates with meanings this complex, it becomes
>nearly impossible to do automated trust management with these
>certificates. Even manual trust management becomes difficult if the user
>is not a cryptographer.
The process I gave above binds a key to both a verified human (by USENIX's
process of checking drivers' license, etc.) *and* an e-mail account. The
meaning is simple. "Carl Ellison, a USENIX member, uses this signature key
and receives mail at cme@cybercash.com". The process of becoming assured of
that Meaning is not the Meaning.
>Suppose I would like to communicate with someone,
>but the only information I know about him is his e-mail address. If I
>find a certificate of the above form with that e-mail address on it and I
>trust the signer of the certificate, I may think that I can use the
>attached public key securely. But I would be wrong because with the above
>protocol, a USENIX member can get an arbitrary e-mail address in his
>USENIX certificate.
>
>I think it would make things much easier if the only meaning used for
>certificates are of the form:
>"If you believe a, then you should believe b." where a and b can be
>arbitrary statements.
>
>Examples:
>
>1. If you believe entity x has the e-mail address weidai@eskimo.com, then
>you should believe entity x owns public key ...
>
>2. If you believe entity x owns public key ... then you should believe
>entity x is a competent plumber and charges a reasonable fee for plumbing
>services.
>
>(Here "owns public key y" is a shorthand for "knows the secret key
>associated with public key y".)
I think you're raising an important point.
The relationship established by some process is not necessarily
bi-directional. The fact that Carl Ellison receives mail at
cme@cybercash.com does not mean that all mail from cme@cybercash.com comes
from Carl Ellison.
I like to think of certificates as devices to transfer authority. They
don't transfer it bi-directionally, unless you're very careful in your
process, so the Meaning in the cert needs to specify not just a binding but
a direction.
For example, to transfer authority from a signature key to an e-mail
address, all you need is a message signed by that key saying that the person
who owns the key can recieve mail at that address. To create the
other-direction meaning -- that the person the world has experienced as
having sent mail from a given e-mail address now has a signature key X is a
much more difficult thing to establish. First of all, you need competent
witnesses who know the person who sent mail from that address -- and they
have to testify that that person now has a key -- and you have to trust them
-- etc. This is the old CA problem.
The difference here is the direction of flow. In the first case, it's from
cyberspace into physical space. In the second, it's from physical space
into cyberspace. If all of those e-mail messages had been signed in the
second case, however, it would be a cyberspace-to-cyberspace problem and the
solution would be trivial -- requiring no outside certification at all.
----
That aside, I agree with you. The meaning of a cert needs to be somthing
simple like your two examples. The process I suggested for USENIX allows
your example 1 directly. It also allows
3. If you believe X is a USENIX member with the name Carl Ellison, then
you should believe that X owns public key ...
----
- 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: