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