Jon Callas wrote:
David Chaum has a patent on a variation on this idea, and he gave a talk
at PGP several years ago in which he advocated that recipient-verifiable
signatures are very useful, and in fact ought to be the default for
an email encryption system like PGP. As others in this thread have
commented, often you don't want to sign something such that you can
be bound by it later, but you do want to assure the recipient that the
message is authentic. Only rarely do you want to make a signature that
anyone can read.
Unfortunately I think that adding a new flavor of signature would tend
to create confusion among users who at best barely understand public
key cryptography. The new kind of signature would have very different
security properties and usage scenarios, so it would add additional
complexity for people to deal with.
Could we do something both simple and useful, however?
For example, if I send a message to Alice, the signature could be made
safely as a combo of my key and Alice's key. It would not be a
misrepresentation in Alice's MUA for it to assume I signed it. You'd have
to be careful in the UI, but I think it could be done. It might be able to
be extended to multiple recipients, but with two it might be an easy
hand-wave.
What is the difference between a "recipient-verifiable signature" and
a MAC?
One of the properties of a digital signature mechanism is that it
is computationally infeasible for any entity other than the signer
to find, for any message, a signature value that is valid for that
message. [HAC, p.23]
Thus it would seem that a "signature" that can't be bound later
to the signer is an oxymoron. Why not just call it an authentication
code, where it is accepted that anyone who can verify a MAC has
the information necessary to create it.