On Fri, 12 Sep 2003 20:12:13 EDT, Sergey Babkin said: > Many ISPs (and IT departments) already require the users to enter > a password to send e-mail. So the mail server knows reasonably > well who the sender is. What it can do now is write this user > information into the e-mail's headers, then calculate the checksum > of the whole message and sign it with the mail server's key > (and possibly do the same thing for the identity-relation portion > of the header). When the addressee receives the e-mail, he can > look up the server's private key and check the signatures, to make > sure that the sender is who he claims he is. There's a good reason not to do this - what you're really signing may not be what you thought. If the server is signing the mail with its own key, what you've established is the statement "The mail server said fred@foo.com sent it". Notice we haven't actually proven that fred did anything - we've proven the (effectively) hearsay assertion by the mail server". Now let's think about this - what if the server is *lying* to us? There's several threat models here: 1) If the server is compromised, you basically just lost *all* confidence in all the signatures. The reason that things like smart cards are attractive is that compromise of one only loses one user's key, not the entire organization's. 2) I set up a rogue mailserver at mail.foo.com. I send a forged mail with a bogus From:, and sign "yes, this mail is From: bogus@nowhere.com". You then look up my mailserver's key and check, and trust the claim. What's wrong here? Basically, you've equated "A mail server just said what it sent was the truth" with "it actually is the truth". You could probably create a variant where you only trust the mail server's assertion if its key was itself signed by a third party with an endorsement of the form "This mail server is in fact allowed to assert the source of mail for the foo.com domain only", and then only trust it if it's foo.com mail, and not nowhere.com mail. I'd hate to deal with any mail to/from an e-mail outsourcer like psmtp.com however. Their certs will be *huge* - I think they provide service for well over 100K domains. So I'd have to either fetch a multi-megabyte cert to verify a 2K mail, or I need a caching system for certs. There's little to no joy in that, especially since we're trying to fix a broken model in the first place... A much better model would be finding a way to easily/painlessly push the cert management back to the MUA where it belongs.
Attachment:
pgp00309.pgp
Description: PGP signature