Now that you have it working, in retrospect, how easy could it have been, if you had understood what you were doing and had done it right? Is it an inherently intractable problem, involving editing the registry, copying and pasting certificates from one obscure program into another, and performing multiple steps? Or is it just a matter of finding the right option and turning it on?

How many steps is it, if you do it right? Suppose you walk up to a new install of your mail agent and have to get S/MIME working on it, are you going to just throw up your hands in despair and say, this will take hours? Or can you sit down and get it done in a minute or two?

I don't know for sure that S/MIME encrypts first and then signs the ciphertext, but if it does then there's a worse problem than any you've mentioned. An active attacker can remove the signature from the ciphertext and sign it himself, which will cause problems if anyone is using the signature as proof of authorship (not that they should be).

PGP allow you to sign without encrypting and vice versa. If you do both, then PGP applies the signature first and then encrypts. The threat here is that the intended recipient can then re-transmit a signed message. Unless there's envelope information covered by the signature, great mischief can ensue: imagine the wrong person getting a signed message saying "pay the bearer $8,000 from my checking account--signature from Alice--" or "I love you and I want to rip your clothes off --signature from Alice's husband--".

Details at http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html including info about which protocols are subject to which threats and protocol enhancements to prevent them.

Notice that both threats depend on the philosophical definition of a message. How much is in the text, and how much is in the context? Are To:, From: and Date: part of the message? Will the recipient assume that the signer and the author are the same person?

Fred, that's a fascinating reference. I disagree with the premises of the paper though, the author is making the same mistake as all of the protocols that he cites: he has not defined what the semantic meaning of a signature is. Is it a message integrity check? Is it a proof that if came from some key? A user's confirmation that it was seen? Or is there higher meaning there?

Deep within we find out that "...so as to achieve basic symmetric-key security guarantees that users expect. The recipient needs proof that the signer and the encryptor were the same person..." So I guess that on the one hand, he assumed that "what users expect" was the purpose of the signature, and OTOH, he says that it is to prove that the whole message as seen came from one person (and wasn't seen / fiddled by some other).

Ironing these details out is critical (in software engineering, these details are known as 'requirements'). In Europe, in some places, using signatures will be seen in a different, legally binding light. In Estonia, for example, by law, a will&last testament is legal if affixed with a digital signature. Does that mean an S/MIME signed email can be used?

And finally:

"We suggest that the messaging standards all erred by treating public-key encryption and digital signatures as if they were fully independent operations."

Well, I treat them as separate because I want the signature to ride alone. But there, I've defined what I mean by signature - it's an authorisation. Further, for my app, the server doesn't really care if the outer layer is stripped off at all ... that's the sender's problem.

Cypherpunk,

in answer to your question: I view it as intractable for users without a fairly significant change in UI steps. Jim outlines some of the things here: http://blog.jim.com/?postid=7 but all of these steps - to make it work for people who haven't got all day to muck around with crypto - all these steps require code changes and UI changes. It will take years for this to filter through.

(Scientifically, I don't have a view of how many steps it took. It was in the dozens. The original setup was so fast I couldn't keep up with what was going on, and even then the expert got it wrong, he missed a step.)

I've been thinking about this tonight. I posted this to gnupg-users@gnupg.org:

> I have a message that was encrypted and signed in one step. When I
> decrypt it, I can read the message and see that the signature is valid.
> So far so good.
>
> I would now like to relay this message to a third party so he can verify
> the signature too. But as far as I know, GPG has no way to do this.

Atom Smasher replied:

> there's no reason it can't be done, but i don't know of any application
> that can do it.
>
> for now, the only way to do it is to extract the session key from the
> message (--show-session-key) and send that along with the encrypted
> message to your 3rd party. they can use "--override-session-key" to
> decrypt the message and verify the signature.
>
> in most cases the session key should be encrypted (to your 3rd party),
> because anyone who gets a hold of the session key can read the message.

So I tried it and it worked like a charm. For example:

% gpg --show-session-key "

Now I don't intend to use this feature routinely in the operation of my system. However, it is nice to have in the rare case that a serious dispute arises.

I'm well aware that I could simply require users to sign first, then encrypt in two separate steps, and I could peel back the two layers on my end, but that's a hassle for everyone.

I just thought this might be helpful to you and decided to pass along my findings.