There actually is a cryptographically sound technique that helps
here, I was talking about it with a cryptographer at work last
week while reading RFC 2630, and not getting the difference
between authenticated and signed data.
S/MIME only uses the signed and enveloped types from CMS, but RFC2630
specifies authenticated as well. Its not well described there, but it is a
way of "signing" something using a key agreement algorithm, such that the
signature can ONLY be verified by using the sender or the receiver's
private key.
Now, since the receiver knows he didn't authenticate it, he knows the
sender must have.
What this gives you is repudiation. If I authenticate something to
you, you know I authenticated it. But if you forward it somebody
else, they can't verify the signature, they have no way of knowing
for sure that I authenticated it, and I can deny it. Even if the
recipients private key is compromised, they still can't prove
that *I* authenticated it, since either one of us can create the
"signature", all they know is one of us made the authenticated data.
I hope my explanation was clear, its easier on a white board!
This CMS authenticated data is only possible with key agreement
algorithms, i.e., you can't do it with RSA. I could be wrong
about it not being a defined payload for S/MIME, but I don't
think so. Too bad. It also has a very odd "feature" or "bug" when you
authenticate the same content to multiple receivers in the CMS message.
I'll explain if anybody is interested.
Sam
Quoteing roessler(_at_)does-not-exist(_dot_)org, on Wed, Apr 10, 2002 at
06:06:51PM +0200:
On 2002-04-10 10:46:26 -0400, Paul Shields wrote:
Should we have a selectable option on sign-encrypt that specifies
that the signature must be removed from the plaintext after
verifying it?
What, precisely, prevents the recipient's implementation from
ignoring that flag?
In the suggestions circulated in this thread, some folks are making
the same basic design error all over the place: You want to place
trust in software which is under the complete control of an
individual you don't trust. Don't do it. It's impossible.
The features which are being suggested _may_ help against
unintentional errors the recipient may make (like, storing, by
accident, the wrong love letters on the wrong hard drive, which [I
seem to recall] was the original reasoning behind the "for your eyes
only" [or whatever it was called] function of pgp 2).
They don't, however, help against malicious behavior on the
recipient's side.
--
Thomas Roessler
<roessler(_at_)does-not-exist(_dot_)org>
--
Sam Roberts <sroberts(_at_)uniserve(_dot_)com> (Vivez sans temps mort!)