S/MIME or PGP/MIME?
Fri Dec 7 20:56:02 2001
Len Sassaman <firstname.lastname@example.org> writes:
> On Fri, 7 Dec 2001, Simon Josefsson wrote:
>> > Another point to note, of course, is that there is no way to prevent
>> > people from using 40 bit encryption when sending S/MIME messages to you,
>> > due to a number of technical mistakes in the S/MIME standard.
>> There is no way to prevent people from using 0 bit encryption (that
>> is, when they forget to push the "encrypt" button) when sending
>> PGP/MIME messages to you either.
> Yes, but at least the user is aware of this.
A good client should make the user aware when he is using weak crypto
>> A good S/MIME enabled mailer would never use weak crypto.
> Define "good". I tend to think of "good" as "complying with standards",
> and in that sense, all good S/MIME implementations would use weak crypto.
A "good" client would be standards compliant AND protect the interests
of the user.
> Let's assume, however, that your client doesn't use 40 bit keys. You still
> have no control over what type of S/MIME enabled mailer I am using. If I
> am using one that defaults to 40 bit, you can't do anything about it.
> Contrast this with OpenPGP (which never had 40 bit crypto in the first
> place) which lets the public key owner exclude individual ciphers from
> being used. If I don't trust CAST5, I can instruct all OpenPGP clients
> never to use it when encrypting to my key.
> If S/MIME had that sort of functionality, the fact that it requires
> support for 40 bit crypto would not be so dangerous.
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.
On the other hand, I believe you can achive something similar using
SMIMECapabilities when using S/MIME?
Further, the S/MIME spec does not say you must support sending using
weak crypto. RFC 2633 even says
Before sending a message, the sending agent MUST decide whether it is
willing to use weak encryption for the particular data in the
message. If the sending agent decides that weak encryption is
unacceptable for this data, then the sending agent MUST NOT use a
weak algorithm such as RC2/40. The decision to use or not use weak
encryption overrides any other decision in this section about which
encryption algorithm to use.
so I think this risk is slightly exaggerated here.