Signing keys for nyms

[hughes@ah.com (Eric Hughes)]

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