Signing keys for nyms
-----BEGIN PGP SIGNED MESSAGE----- Eric Hughes writes, regarding the problem of determining whether the key of a "nym" is valid:
If a provider of any sort is the sole means of access to a series of communications, there will be the possibility of tampering. If some public key must issue forth through this channel only, it is possible to alter the pseudonym's public key each time it is passed throught that channel. Since every protocol which uses communications only through the server won't work, every solution needs another channel.
Eric goes on to describe a solution based on sending the key through two different channels, with a return message via the pseudonym server channel. I think this is a good solution, but there is the possibility that the evil pseudonym server could corrupt the return message so that the nym did not find out that his key was being mangled (although other people would find out, which may be good enough). A more general solution is to use more than one pseudonym server. Assuming they aren't both colluding, you can send your nym1 key to nym2, and vice versa. By providing two or more channels back to you as well as out from you, you are able to detect corruption of your messages. Eric suggested that if the pseudonym server signed the user's key, then corruption of the key could be proven to third parties. I'm not sure this is the case, because it would seem that a user could falsely incriminate a pseudonym server by claiming that he had never created the key which the pseudonym server signed, that it was a bogus key. I suppose reputations would have to play a role then, in weighing the credibility of the pseudonym server against that of the nym. Hal hfinney@shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNm4NagTA69YIUw3AQFGOwQApSwLHzBfQKStZd6g/17dsL3WUtgCvy6D OyQjFQ3dRd6VRGrEaQ7aRbnae9If0NqF2qbaxeHAKNP/Uiyo/cGBWvFjAxWeVyY0 hddLRBygxIyqjkDkxAEBGaYRruly8TC4TEU45ChwSUz2Smh0rDm8S2GINgXe340P a1peTNDPSlI= =Ywbw -----END PGP SIGNATURE-----
re: my protocol for determining whether your pseudonym server is spoofing your public key distribution.
Eric goes on to describe a solution based on sending the key through two different channels, with a return message via the pseudonym server channel. I think this is a good solution, but there is the possibility that the evil pseudonym server could corrupt the return message so that the nym did not find out that his key was being mangled (although other people would find out, which may be good enough).
The pseudonym server may deny service, that is either refuse to pass the email at all or corrupt the container (a piece of email) so that no message is sent. As the owner of the pseudonym tries the protocol multiple times and never gets a response, alteration at the server become more plausible. What the pseudonym server cannot do is read the contents of the incoming message. If this message contains a bit of data that was not passed through the server, either a signature made by the match-and-remail server or by an arbitrary number passed through the anonymous channel, then the pseudonym server cannot make a valid message to substitute for the return message. The pseudonym server can substitute any arbitrary message it cares to, since it does have the pseudonym's true public key, but it cannot know what to put in such a message, either because it does not hold the private key of the M&R server or because it has never seen the arbitrary number passed out of the other channel.
Eric suggested that if the pseudonym server signed the user's key, then corruption of the key could be proven to third parties.
If the pseudonym server is signing keys, it will have to send one certificate on the true key to the owner of the pseudonym and one certificate on the false key. The certificates have different keys and the same identifier. This pair of certificates, exhibited side by side, is prima facie evidence of alteration of keys. This is the situation that I was speaking of.
I'm not sure this is the case, because it would seem that a user could falsely incriminate a pseudonym server by claiming that he had never created the key which the pseudonym server signed, that it was a bogus key.
The certificate that a pseudonym provider signs asserts the following: "I certify that this key K is a key of name N who can be reached at address A for which I provide final delivery." Let us assume that the pseudonym server is propagating a false key; we may also assume that the false key has a certificate as above. If the pseudonym owner is not using a public key, they're screwed. The identity is the public key, not the email address, which is only a form of delivery. The server is asserting that a cryptographic identity is reachable at that address, but the pseudonym owner thinks that mail delivery is sufficient to prove identity. In fact, a cryptographic identity _is_ reachable at that address, it's just that that identity is not the one whose mailbox it is. In Hal's situation, the pseudonym owner claims that the server is distributing a false key. Immediately after such an claim, the first question will be "Well, where is your public key and the certificate made by the server?" Unless the pseudonym owner can exhibit these, the accusation holds no weight. Eric
participants (2)
-
hfinney＠shell.portal.com -
hughes＠ah.com