[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: USENIX PGP key signing service
[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. 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".)
Wei Dai
References: