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.
Robert R. Jueneman
From: ekr(_at_)rtfm(_dot_)com [mailto:ekr(_at_)rtfm(_dot_)com]
Sent: Tuesday, May 18, 1999 2:03 PM
Cc: The IESG; RFC Editor; ietf-smime(_at_)imc(_dot_)org
Subject: Re: Issues with S/MIME Message Specification
"Robert R. Jueneman" <bjueneman(_at_)novell(_dot_)com> 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
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
rsaEncryption, whereas the Cryptographic Message Syntax , para 12.2, says
that CMS implementations "may" support RSA. Neither mentions RSA with
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
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
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]
Robert R. Jueneman.vcf