From: David Woodhouse Sent: Sunday, September 19, 2004 9:41 AM
<...>
The idea that all MUA's would have to change to deal with
displaying
multiple signed parts in different colors, as well as noting parts whose signature doesn't validate does not bode well for adoption.That's a purely optional optimisation. If any scheme _required_ such
a
thing to be implemented by all recipients, the scheme would of
course
be doomed.I knew you felt that way, I was playing devil's advocate. Since no
MUA
today would know how to deal with the multiple signatures anyway, it would have to be an MTA process and the message would either be
accepted
or rejected. The end user would have no way of knowing who signed
what,
only that the MTA figured out that everything was legitimate. My questions is how valuable are the multiple signatures if the end user has no way of knowing who really added and signed what parts?But the end user _can_ know who signed what, if they happen to use an MUA which supports that, and if they care. If an MUA did this it should probably use the signature corresponding to the From: header by default, and should need to be _asked_ for any other signature.
Well, I don't think you can have it both ways. Either there is wide MUA support for this or there isn't. Since it is a completely new scheme, we have to assume that there is no MUA support for it. In that case, doesn't my example show that this scheme actually _facilitates_ fraud when the user has a conventional MUA? When there is an MUA that shows the user who signed what, it is a terrific, general purpose anti-forgery tool. The multiple signatures are a very interesting problem and your approach to it appears workable. As long as there is an MUA that can show what has occured, the only objection that I have is that it permits reordering of parts, which can change the meaning of a message when the parts come from different people. The main overall problem I see is that it requires a special MUA to prevent you from being fooled by malicious parties. <...>
While I am aware that junk is often added at both ends of the link, I was unaware of forwarders who actually do that.
<...>
Current practice for many mailing lists, yes. Not really for 'forwarders'. And no, in general PGP/MIME and S/MIME don't survive. If they _did_, we could just start publishing some kind of record which says "All mail from dwmw2(_at_)infradead(_dot_)org will be GPG-signed", and give recipients the chance to reject for lack of signature. But that would be utterly broken in the real world today, just like certain other schemes we've discussed :)
I didn't think forwarders did this, so we are really just talking about mailing lists, which is a well-known problem. As far as using an existing protocol that already works, I believe that the in-line version of PGP signatures survive mailing lists, though they are not pretty to look at. I can verify that S/MIME does not survive mailing lists, unless there is a variant of it that I am unaware of. I signed this one with S/MIME. -- Seth Goodman
smime.p7s
Description: S/MIME cryptographic signature