S/MIME or PGP/MIME?

[Len Sassaman]

On Fri, 7 Dec 2001, Simon Josefsson wrote:


> A good client should make the user aware when he is using weak crypto
> as well.

True, but irrelevant, because Alice doesn't control what software Bob is
running.

> A "good" client would be standards compliant AND protect the interests
> of the user.

Same as above.

> This is a good point, the OpenPGP standards allows you to convey the
> preferred encryption algorithm and key size to use to the person that
> wants to communicate with you.

Not just preferred -- it permits you to disallow ciphers, period.

> On the other hand, I believe you can achive something similar using
> SMIMECapabilities when using S/MIME?

Yes, you can, though this is shoe-horned in as an afterthought, and not
all clients understand it. So you're back to the original problem of
trusting that the people with whom you are communicating are using a
"good" client.

> Further, the S/MIME spec does not say you must support sending using
> weak crypto.  RFC 2633 even says

2.7:  "Receiving agents SHOULD support encryption and decryption using the
   RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
   hereinafter called "RC2/40"."

And,

1.4 Compatibility with Prior Practice of S/MIME

   S/MIME version 3 agents should attempt to have the greatest
   interoperability possible with S/MIME version 2 agents.

Which, in effect, means that v3 inherits all of the flaws of v2 in many
cases.

I think v3 fixed the fact that S/MIME messages store the signature
outside the encrypted envelope. Heh. In PEM, you couldn't even send
"encrypted, not signed" messages. So, progress is getting made, slowly...
but when security matters, no risk can be brushed off as "exaggerated."