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.

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.

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.

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

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.

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.