IETF conflict review for draft-jenkins-cnsa-smime-profile
conflict-review-jenkins-cnsa-smime-profile-00

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-jenkins-cnsa-smime-profile@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-jenkins-cnsa-smime-profile-01

The IESG has completed a review of draft-jenkins-cnsa-smime-profile-01
consistent with RFC5742.

The IESG has no problem with the publication of 'Using Commercial National
Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail
Extensions'  as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG
LAMPS, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-jenkins-cnsa-smime-profile/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-jenkins-cnsa-smime-profile/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
Some commentary from my review of the draft; nothing particularly noteworthy.

Section 4

  Within the CMS signed-data content type, signature algorithm
  identifiers are located in the SignerInfo signatureAlgorithm field of
  SignedData.  [...]

nit: the grammatical construction here is a bit hard to parse unless one is
very familiar with the CMS structures involved; perhaps "signature algorithm
identifiers are located in the signatureAlgorithm field of SignerInfo
structures contained within the SignedData"?

Section 5

On the face of it, a sole requirement for SHA-384 is in conflict with the
agility requirements of BCP 201 (which of course is not binding upon ISE
documents anyway).  But since this is in the broader context of profiling
CMS and S/MIME to meet CNSA requirements, it's likely that implementations
will have the requisite flexibility, and that the profiling is just being
used to restrict that flexibility at this point in time, and the
requirements may change in the future.  The text perhaps could clarify that
distinction, though I don't think it's critical to change.

Section 7.1.1

  In CNSA Suite for S/MIME, exactly one iteration is needed; the
  Counter is not incremented.  The key-encryption key (KEK) MUST be the
  first (leftmost) 256 bits of the SHA-384 output value:


        KEK = the leftmost 256 bits of
                  SHA-384 ( Z || 0x00000001 || ECC-CMS-SharedInfo )


  In CNSA Suite for S/MIME, the key-encryption key MUST be the most
  significant 256 bits of the SHA-384 output value.

nit: the paragraphs before and after the expression defining KEK seem redundant.

Section 7.1.2

  using ephemeral-static ECDH.  Section 8 of [RFC5753] specifies the
  CMS conventions for using AES Key Wrap with a pairwise key generated
  through ephemeral-static ECDH.  CNSA Suite compliant S/MIME
  implementations MUST follow these conventions.
  [...]
  The KeyWrapAlgorithm MUST be id-aes256-wrap-pad.  The required
  algorithm identifier, specified in [RFC5649], is:

I note that only id-aes256-wrap is listed in RFC 5753 for the
"Implementations that support EnvelopedData with the ephemeral-static ECDH
standard primitive" list of "MAY support" primitives, but it does say "other
algorithms MAY also be supported" so that's not problematic.

Section 8

It's a little surprising to not see any guidance about EnvelopedData (CBC)
vs. AuthEnvelopedData (GCM).

Section 8.2

  In CNSA Suite for S/MIME AES-256 in GCM mode MUST be used.

I don't see a parallel directive to this in Section 8.1, and it's perhaps
unclear about the scope in which it applies (i.e., does it apply to all CNSA
S/MIME usage, rendering the CBC support obsolete?).

I note that RFC 5084 RECOMMENDs an auth tag length of 12 bytes, but we use
16 bytes here (which is stronger, so there's no conflict).

  The initialization vector (aes-nonce) MUST be generated in accordance
  with [SP80038D].  AES-GCM loses security catastrophically if a nonce

nit: a section reference within SP80038D might be nice; we're looking at
Section 8.2 there as well (by coincidence)?