Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with (tiny) nits

Yours,
Daniel


--- 1.7. Changes for S/MIME v4.0

"""
Update the content encryption algorithms (Section 2.7 and Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark tripleDES as historic.
"""

In section AES-CBC has its status set to MUST-. "removed" sounds to me as MUST NOT status. In that case, I believe sunsetting or something equivalent might be more appropriated than removed.

TripleDES is mentioned in section 2.7.2 I believe it would be appropriated to also mention these algorithms in section 2.7 with a MUST NOT.

It might be also appropriated to mention that these algorithm concerns the messages being sent and received while old emails may still be decrypted with there old algorithms.

Note that the two latest comments are being discussed in the review thread of version 07.


I understand that AES-CBC is being mentioned for compatibility reasons with older S/MIME versions, but that AES-CTR as well as enveloped-data type are expected to be rolled out in the next or next next next version.

--- section 2.7.1

"""
Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
"""

I am a bit worried by the text that seems to provide an enable weak encryption check box. Maybe it should be stated that weak encryption SHOULD NOT be used.

(same in section 2.7.2)


--- 3.1.2 Transfer encoding

I see the 7-bit transfer encoding as a legacy mechanisms. While this seems to me out of scope of S/MIME to roll it out and make binary encoding as the base, I am wondering if that is something to consider for next version of MIME for example ?

--- 3.5.3.2 Creating a multipart/signed Message

I believe that MD5 SHA1, SHA224 are not deprecated to verify the old messages, but should not be used for the new sent/received messages.


--- 4 Certificate Processing

I am wondering if some recommendations so the security associated to the certification is greater or equal to teh security associated to the message. At least when the comparison is possible.

---section 4.2

It is strange not to have MUST for 2048 <= key size <= 4096. I understand why, but it also means that we may not have interoperability between the Signature Generation and Signature Verification. 

idem for section 4.4