Re: Issues with S/MIME Message Specification

[EKR <[e-mail]>]

"Robert R. Jueneman" <[e-mail]> writes:
> Regarding the S/MIME Version 3 Message Specification,
> draft-ietf-smime-msg-08.txt, I believe that all MUSTs and SHOULDs
> regarding specific cryptographic algorithms should be removed from this
> document, and contained only in the Cryptographic Message Syntax document.
> I can see no reason at all why such things should be specified twice -- it
> just makes conformance checking all that much more difficult.  An example
> of this kind of difficulty is para 2.2 of the S/MIME Message
> Specification, which says that sending and receiving agents SHOULD support
> rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says
> that CMS implementations "may" support RSA.  Neither mentions RSA with
> OAEP.
CMS and S/MIME MSG intentionally have different requirements.
In order to preserve backwards compatibility with S/MIMEv2,
implementations SHOULD implement RSA. CMS implementations that
do not need to be used in the S/MIME context may very well
have no need to use RSA.

> The second part of 2.7 specifies that receiving agents SHOULD support
> RC2/40 "or a compatible algorithm at a key size of 40 bits..." This
> recommendation suffers from two major problems, in my view. First, it is
> LESS secure than 56-bit DES, which is now acceptable world-wide (with
> perhaps one or two minor exceptions -- not quite clear) for data
> encryption.
The purpose of this is once again for compatability with S/MIME v2 
which required RC2. 

>  And second, it is a proprietary, trade-secret algorithm. 
This statement is incorrect. See RFC-2268:

2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest.
     January 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL)

> Finally, somewhere in these documents there is a statement regarding the
> advisability of including the content encryption key encrypted in the
> originator's public key, but despite rereading the documents multiple
> times I can't find that text again.  As I recall, the text said that this
> SHOULD be done.  I would argue that this should be changed to MUST, for I
> can't imagine a situation where the originator of an encrypted message
> would not want to be able to read his own message, for example in an
> outgoing or Sent-Mail queue. He might need to be able to decrypted, and
> even retract it in order to resend it with modifications.  It would not be
> reasonable to rely on the originator to bcc herself to gain this
> capability -- it ought to be required by the spec.
I disagree. Firstly, it's entirely possible that the originator
does not have a public key suitable for data encryption -- he
might have a signature only key. Secondly, encrypted content keys
take up a not-insignificant amount of space in the message. Mandating
this serves no interoperability requirement and therefore 
it's inappropriate.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]