RE: Issues with S/MIME Message Specification

["Robert R. Jueneman" <[e-mail]>]

Eric,

Thanks for your comments.  I hadn't considered the possible difference in scope between the S/MIME Message Specification and the CMS, but I can see that CMS might have broader applicability, and hence, differing requirements.

I was also unaware of the fact that an information RFC had been published on RC2, and withdraw my comments on that accordingly.

With respect to the issue of bcc'ing the originator on an encrypted message, although I suppose it is possible that the originator doesn't have a public encryption key, this seems mildly unlikely, so I am more inclined to agree with William Whyte's comment.

I wish I could find where I read that statement -- I thought it was in one of the RFC's, but I can't find it.

Regards,

Bob

---------------------------
Robert R. Jueneman
Novell, Inc.

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Tuesday, May 18, 1999 2:03 PM
>To: [e-mail]
>Cc: The IESG; RFC Editor; [e-mail]
>Subject: Re: Issues with S/MIME Message Specification
>
>
>"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]]
>