Blake and S/MIME WG Members:
I do have a few comments.
1. Section 2.5.2 says:
There is a list of OIDs (OIDs Used with S/MIME) that is centrally
maintained and is separate from this draft. The list of OIDs is
maintained by the Internet Mail Consortium at <http://www.imc.org/ietf-
smime/oids.html>.
This is true, and it is fine. However, I think that we should state that all
of the OIDs assosciated with the MUST and SHOULD implement algorithms are at
the end of this document. This is important for configuration control.
Further, the ESS document states that the registry will be transitioned to the
IANA (or ICANN). I think that the two documents should send the same message.
2. Section 2.7 says:
Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES].
Receiving agents SHOULD support encryption and decryption using the
RC2 [RC2] or a compatible algorithm at a key size of 40 bits,
hereinafter called "RC2/40".
Since RC2 is described in an RFC, can we drop "or a compatible algorithm"?
3. Section 2.7.3 says:
If a sending agent is composing an encrypted message to a group of
recipients where the encryption capabilities of some of the recipients
do not overlap, the sending agent is forced to send more than one
message. It should be noted that if the sending agent chooses to send
a message encrypted with a strong algorithm, and then send the same
message encrypted with a weak algorithm, someone watching the
communications channel can decipher the contents of the strongly-
encrypted message simply by decrypting the weakly-encrypted message.
I think that we should provide rationale why this is not the circumstance to
use the mandatory to implment algorithm.
Also, I think that "can" is too strong. We should say "may be able to." You
are really saying that the message text can be recovered from the weakly
encrypted message in lieu of the stringly encrypted one. This is clearly
true. There are too many other variables to assert thet the weakly encrypted
message provides enough information to recover the key used for the strongly
encrypted one. A strong cipher algorithm should not be vulnerable to known
plaintext attacks.
4. Section 3.2.2 says:
If no common string is assigned. Then the common string of
"OID.<oid>" is recommended.
I agree. However, an example is needed since people write OIDs in more than
one way. I assume that petiods between each number is the intended style.
Suggestion: DES40 would be "OID.1.3.6.1.5.5.7.6.1".
5. Section 5 says:
If a sending agent is sending the same message using different
strengths of cryptography, an attacker watching the communications
channel can determine the contents of the strongly-encrypted message
by decrypting the weakly-encrypted version. In other words, a sender
should not send a copy of a message using weaker cryptography than
they would use for the original of the message.
You are raising a good point here. However, I would like a small change. In
the 3rd line, I think that "can" should be changed to "may be able to." If
enough things are changed (subject line, etc), then the attacker may not be
able to tell that the two plaintexts are the same.
6. In section 4.1, you talk about random numbers. I suggest that you add a
reference to:
RANDOM Eastlake, D.; S. Crocker; J. Schiller. Randomness
Recommendations for Security. RFC 1750. December 1994.
Russ