Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions
draft-jenkins-cnsa-smime-profile-03

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-jenkins-cnsa-smime-profile-01 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

draft-jenkins-cnsa-smime-profile has been present for publication as
an Informational RFC on the Independent Submissions Stream.

This document is part of a set that describe the US government's
requirements for security implementations. The documents are profiles
of IETF Standards Track RFCs that show which optional elements are
needed in implementations/deployments that satisfy the requirements.
Thus, these documents do not downgrade any requirements language in
IETF work, but occasionally make more stringent requirements.

Other documents in the set are:
- RFC 8603
- draft-jenkins-cnsa-cmc-profile (RFC Editor Queue)
- draft-cooley-cnsa-dtls-tls-profile (in ISE processing)

This draft has received reviews from Jonathan Hammell and ISE and has
been updated accordingly. Jonathan's review is included below.

Note that this document (like the others in the series) makes it clear
that it is a US government profile and states the purpose of
publication.

== Jonathan Hammell

Summary:

This document specifies a profile for Secure/Multipurpose Internet Mail
Extensions (S/MIME) providing configuration and compatibility guidelines
for the NSA Commercial National Security Algorithm (CNSA) Suite.

I believe the draft is clear and well written.  Since there are many of
possible variations in configuring S/MIME, I think this profile is useful
as a best current practice.  I provide a few minor issues and editorial
comments, but I believe once these are addressed that it should be
published.


Major issues: No major issues found.

Minor issues:

Section 7.1.2: Should there be guidance on the generation or uniqueness of
the ukm?

Section 7.2, first paragraph: Where is "block type" further described?  I
don't find that term in RFC 8017.

Section 7.2.1, second paragraph: Allow authenticated-enveloped-data content
type as well.

Section 7.2.2, second paragraph: Allow authenticated-enveloped-data content
type as well.

Section 8.2, last paragraph: Should there be a recommended length for
aes-nonce?

Section 9: Security Considerations should include a paragraph on the EFAIL
attack as in RFC 8551, recommending the use of authenticated-enveloped-data
with AES-GCM over enveloped-data with AES-CBC.

General: I think there could be more guidance on the use of the
SMIMECapabilities attribute.  It is mentioned in Section 7.2.2, but nowhere
else.


Nits/editorial comments:

Section 2, first paragraph: "USG" abbreviation is not defined.

Section 7.1.2, fourth paragraph, entityUInfo: It would be helpful to state
that the user key material (ukm) field is in the KeyAgreeRecipientInfo
structure.

Section 7.1.2, second-last paragraph: Text is duplicated (in meaning) from
the third-last paragraph.

Section 11.1: Reference [ID.rfc5751-bis] for S/MIME 4.0 message
specification should be updated to RFC 8551.

Section 11.1: Reference [SEC1] should be updated to version 2.0 published
May 2009.