On Tue, 1 Feb 2005, Jim Fenton wrote:
William,
I think you're arguing in favor of your earlier ideas on MIME encapsulation,
They are all still there in a way, I made sure META can do all the same
signing as could be done with META Signatures. Being able to specifically
"sign" mime part(s) with MTA-generated signature is very important for
larger project I'm working on, and separation of signing headers and mime
part is also extremely important for it (so for me how authorization info
is distributed i.e. fingerprint or public key is less of issue, I can use
either one just fine even if I have some small preference for fingerprint
in dns).
but as I read it all of the things you're describing are dealt with if
the mailing list (or whatever munges the message) re-signs it after
modification.
We're trying to create signature that can survive all common redirection
systems and does not require to be re-signed at every MTA, i.e. multi-hop
signature - otherwise, as Mike Thomas has pointed several times, why are
we bothering with new mail security architecture if we could easily use
STARTTLS and exchange of certificates for each hop?
Also the issue here is that our system should not penalize the few mail
lists that actually correctly handle S/MIME and PGP/MIME (for some older
mail lists IIM signature would have survived if they just add data to the
end, but S/MIME might not have).
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/