Comments: Digitally-Signed Mail in e-Commerce - FC05 survey

If there where a real use of signatures meaning that the application interfaced with it based on user defined scenarios then the liability for improper usage could be placed squarely in the user court.

Posted by Jimbo at March 25, 2005 09:28 PM

S/MIME should not be used for commercial applications, as it first encrypts and then signs, meaning that no signed cleartext can be used for subsequent dispute resolution. There's no way to prove the signature to a third party, if the traffic is encrypted (which it should be).

For email security OpenPGP is the way to go. It is no coincidence, that the user-base of OpenPGP is at least an order of magnitude larger than that of S/MIME. And this despite the fact that S/MIME support is built into every major email client out of the box, while OpenPGP support has to be installed as an add-on for most, where it is available at all. Yet, people seem to be willing to go with the less convenient installation, because of the mutitude of advantages that OpenPGP offers.

Commercial CAs are single points of failure, sometimes plagued with severe conflicts of interests and incentive incompatibility problems. Even if some bank uses S/MIME, it should operate its own CA. There's no justification for extending trust to some other CA: it invites additional risks, adds costs, while having very few if any benefits.

But I maintain that OpenPGP is vastly superior to S/MIME both in the flexibility of its trust model and in its use of cryptographic primitives.

Posted by Daniel A. Nagy at March 26, 2005 05:53 AM

You have got to be kidding - decryption loses the signature? So if you decrypt on receipt, then re-encrypt locally as a good app should, you have no way of keeping the sig!

What were these guys smoking...

OK, so I agree with my earlier recommendation of never signing unless you have some notion of what that means. Simply don't sign.

But wait ... I am told that to use S/MIME one has to sign in order to distribute the key! OK, so limping along here. Send blank signed messages to distribute keys, but turn signing off for other messages. That still works.

Posted by Iang at March 26, 2005 07:47 AM

Daniel, can you have a look at this link:

http://www.faqs.org/rfcs/rfc2633.html
3.5 Signing and Encrypting

And tell me whether you still agree that "S/MIME encrypts then signs?" It seems to be at the choice of the implementation, as that section says you can nest arbitrarily.

iang

Posted by RFC2633 at March 26, 2005 01:30 PM

Yes, my fault. I confused S/MIME with PEM, both of which are based on the same X.509-based trust model and certificate format, buth are otherwise quite different.
S/MIME allows for both orders of signature and encryption. PEM first encrypts then signs.
S/MIME uses PEM certificates.

HTTPS also loses the signature after decryption, and I guess there's a good reason why the banking industry supported this solution: you cannot show your banking statement as a proof, but you can still believe it yourself. If you want to present a proof of your balance to a third party: pay the bank.

Posted by Daniel A. Nagy at March 28, 2005 01:15 PM

I have received many S/MIME clearsigned messages over the years. I always read my mail in text mode so it is easy to recognize them. The large signature attachments (which include the signer's certificate) are distinctive, as are the types of the MIME body parts.

FYI, a clearsigned message is one where the text is still readable even to someone who doesn't have compliant signature software. It is the preferred mode for messages that are signed but not encrypted.

I've never received an S/MIME encrypted+signed message, of course, since I have no S/MIME decryption key. I don't know whether common mailers like Outlook or OE would auto-switch to encrypt+sign if they happened to find a cert matching the recipient of the message being prepared. But I do know that S/MIME has the power to create signed-only messages.

Posted by Cypherpunk at March 28, 2005 02:44 PM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x56466651b4d8) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.