"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 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 ekr(_at_)rtfm(_dot_)com]