Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
draft-ietf-lamps-rfc5751-bis-12

Received changes through RFC Editor sync (created alias RFC 8551, changed abstract to 'This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0.  S/MIME provides a consistent way to send and receive secure MIME data.  Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.  Encryption provides data confidentiality.  Compression can be used to reduce data size.  This document obsoletes RFC 5751.', changed pages to 63, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-04-30, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-lamps-rfc5751-bis and RFC 5751)

[Ballot comment]
Thanks for addressing the discuss point; original ballot comments retained below.

I suspect it's too late for changing this to be a good idea, but
using "authenticated enveloped" and in the same breath talking about how it
does not provide proof of origination ("wait, isn't that authentication?),
but it does provide "a level of authentication", is kind of confusing for
the reader.  Could "integrity protection" be used to distinguish the AEAD
property from proof-of-origin authentication?

Similarly, it might be helpful to use the term "AEAD" before the security
considerations section.

Should the Abstract/Introduction mention that AEAD encryption provides non-malleability?

Section-by-Section comments follow.

Section 1

nit: Does FAX need to be all-caps?

Section 1.1

  In order to create S/MIME messages, an S/MIME agent MUST follow the
  specifications in this document, as well as the specifications listed
  in the Cryptographic Message Syntax document [CMS], [RFC3370],
  [RFC4056], [RFC3560], and [RFC5754].

nit: is that "[CMS] documents" plural?

I have been observing growing unease with Postel's Principle over time;
it's less clear that blindly repeating it is the best position to take.

Section 1.2

BER does not appear to be used in the body text?

Section 1.5

I recognize this is historical text, but to modern readers, there is not a
single "the AES symmetric encryption algorithm" -- there are CBC modes and
GCM modes, and v4.0 distinguishes between them.  Should this text get
clarified about the difference?

Section 2.5.2

  The OIDs that correspond to algorithms SHOULD use the same OID as the
  actual algorithm, except in the case where the algorithm usage is
  ambiguous from the OID.  For instance, in an earlier specification,
  rsaEncryption was ambiguous because it could refer to either a
  signature algorithm or a key encipherment algorithm.  In the event
  that an OID is ambiguous, it needs to be arbitrated by the maintainer
  of the registered SMIMECapabilities list as to which type of
  algorithm will use the OID, and a new OID MUST be allocated under the
  smimeCapabilities OID to satisfy the other use of the OID.

(nit?) "the other use" implies there will only ever be one other (two
total), which is perhaps needlessly limiting.

Section 2.7.2

With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
what to make of "such as" in these statements -- what are the attributes
that would qualify for sufficient similarity to match the "such as", other
than equality?

Section 3.1

  In order to protect outer, non-content-related message header fields
  (for instance, the "Subject", "To", "From", and "Cc" fields), the
  sending client MAY wrap a full MIME message in a message/rfc822
  wrapper in order to apply S/MIME security services to these header
  fields.  It is up to the receiving client to decide how to present
  this "inner" header along with the unprotected "outer" header.  It is
  RECOMMENDED that a distinction be made between the location of the
  header.

nit: I'm not sure this last sentence is grammatical.  Do we want "between
the locations", or "a visible distinction be made for the different
possible locations of the header", or something else?

Section 3.1.2

  In the case where S/MIME implementations can determine that all
  intended recipients are capable of handling inner (all but the
  outermost) binary MIME objects SHOULD use binary encoding as opposed
  to a 7-bit-safe transfer encoding for the inner entities.

nit: I think that some words got dropped in here; the sentence doesn't really
parse.  I guess there's a missing "implementations" in "implementations
SHOULD use"?

Section 3.3

  but not signed messages does not provide for data integrity.  The
  Enveloped-Only structure does not support authenticated symmetric
  algorithms, use the .Authenticated Enveloped structure for these
  algorithms.  [...]

nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
comma splice.)

Section 3.5.3.2

I agree with Adam that there should be some notation in the table
or adjacent to it that some algorithms are present only for historical
compatibility and should be considered deprecated/insecure/risky/whatever.

Section 6

  Some cryptographic algorithms such as RC2 offer little actual
  security over sending plaintext.  Other algorithms such as TripleDES,
  provide security but are no longer considered to be state of the art.
  S/MIME requires the use of current state of the art algorithms such
  as AES and provides the ability to announce starter cryptographic
  capabilities to parties with whom you communicate. [...]

I can't figure out what "starter" means, here.

  Modification of the ciphertext in EnvelopedData can go undetected if
  authentication is not also used, which is the case when sending
  EnvelopedData without wrapping it in SignedData or enclosing
  SignedData within it.  This is one of the reasons for moving from
  EnvelopedData to AuthEnvelopedData as the authenticated encryption
  algorithms provide the authentication without needing the SignedData
  layer.

nit: I think a comma before "as the" would help the last sentence.

When talking about compression oracles, do we want to explicitly say that a
common way to do so is to compress attacker-controlled data in the same
corpus as the attacker's target data?

  mail clients deal with HTML and multipart/mixed messages.  Clients
  MUST require that a text/html content type is a complete HTML
  document (per [RFC1866]).  Clients SHOULD treat each of the different
  pieces of the multipart/mixed construct as being of different
  origins.  Clients MUST treat each encrypted or signed piece of a MIME
  message as being of different origins both from unprotected content
  and from each other.

Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed
to just the normal English usage of the word)?

Appendix B

  This appendix contains a number of references to documents that have
  been obsoleted or replaced, this is intentional as frequently the
  updated documents do not have the same information in them.

nit: comma splice

Appendix B.2

  -  Hash functions used to validate signatures on historic messages
      may longer be considered to be secure.  (See below.)  While there
      are not currently any known practical pre-image or second pre-
      image attacks against MD5 or SHA-1, the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.  [...]

nit: there seems to be (at least) a missing verb in this last sentence.

      [...] If a message is
      known to be historic, that it it has been in the possession of the
      client for some time, then it might still be considered to be
      secure.

nit: maybe "and it has been"

[Ballot discuss]
This is not necessarily a flaw in the document, I just want to ensure that the decision to use the phrase
"for political reasons" to describe a technical decision made in an IETF-stream RFC is a decision that
is consciously approved by the IESG.  (I could not find any precedent for such a usage.)

[Ballot comment]
I suspect it's too late for changing this to be a good idea, but
using "authenticated enveloped" and in the same breath talking about how it
does not provide proof of origination ("wait, isn't that authentication?),
but it does provide "a level of authentication", is kind of confusing for
the reader.  Could "integrity protection" be used to distinguish the AEAD
property from proof-of-origin authentication?

Similarly, it might be helpful to use the term "AEAD" before the security
considerations section.

Should the Abstract/Introduction mention that AEAD encryption provides non-malleability?

Section-by-Section comments follow.

Section 1

nit: Does FAX need to be all-caps?

Section 1.1

  In order to create S/MIME messages, an S/MIME agent MUST follow the
  specifications in this document, as well as the specifications listed
  in the Cryptographic Message Syntax document [CMS], [RFC3370],
  [RFC4056], [RFC3560], and [RFC5754].

nit: is that "[CMS] documents" plural?

I have been observing growing unease with Postel's Principle over time;
it's less clear that blindly repeating it is the best position to take.

Section 1.2

BER does not appear to be used in the body text?

Section 1.5

I recognize this is historical text, but to modern readers, there is not a
single "the AES symmetric encryption algorithm" -- there are CBC modes and
GCM modes, and v4.0 distinguishes between them.  Should this text get
clarified about the difference?

Section 2.5.2

  The OIDs that correspond to algorithms SHOULD use the same OID as the
  actual algorithm, except in the case where the algorithm usage is
  ambiguous from the OID.  For instance, in an earlier specification,
  rsaEncryption was ambiguous because it could refer to either a
  signature algorithm or a key encipherment algorithm.  In the event
  that an OID is ambiguous, it needs to be arbitrated by the maintainer
  of the registered SMIMECapabilities list as to which type of
  algorithm will use the OID, and a new OID MUST be allocated under the
  smimeCapabilities OID to satisfy the other use of the OID.

(nit?) "the other use" implies there will only ever be one other (two
total), which is perhaps needlessly limiting.

Section 2.7.2

With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
what to make of "such as" in these statements -- what are the attributes
that would qualify for sufficient similarity to match the "such as", other
than equality?

Section 3.1

  In order to protect outer, non-content-related message header fields
  (for instance, the "Subject", "To", "From", and "Cc" fields), the
  sending client MAY wrap a full MIME message in a message/rfc822
  wrapper in order to apply S/MIME security services to these header
  fields.  It is up to the receiving client to decide how to present
  this "inner" header along with the unprotected "outer" header.  It is
  RECOMMENDED that a distinction be made between the location of the
  header.

nit: I'm not sure this last sentence is grammatical.  Do we want "between
the locations", or "a visible distinction be made for the different
possible locations of the header", or something else?

Section 3.1.2

  In the case where S/MIME implementations can determine that all
  intended recipients are capable of handling inner (all but the
  outermost) binary MIME objects SHOULD use binary encoding as opposed
  to a 7-bit-safe transfer encoding for the inner entities.

nit: I think that some words got dropped in here; the sentence doesn't really
parse.  I guess there's a missing "implementations" in "implementations
SHOULD use"?

Section 3.3

  but not signed messages does not provide for data integrity.  The
  Enveloped-Only structure does not support authenticated symmetric
  algorithms, use the .Authenticated Enveloped structure for these
  algorithms.  [...]

nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
comma splice.)

Section 3.5.3.2

I agree with Adam that there should be some notation in the table
or adjacent to it that some algorithms are present only for historical
compatibility and should be considered deprecated/insecure/risky/whatever.

Section 6

  Some cryptographic algorithms such as RC2 offer little actual
  security over sending plaintext.  Other algorithms such as TripleDES,
  provide security but are no longer considered to be state of the art.
  S/MIME requires the use of current state of the art algorithms such
  as AES and provides the ability to announce starter cryptographic
  capabilities to parties with whom you communicate. [...]

I can't figure out what "starter" means, here.

  Modification of the ciphertext in EnvelopedData can go undetected if
  authentication is not also used, which is the case when sending
  EnvelopedData without wrapping it in SignedData or enclosing
  SignedData within it.  This is one of the reasons for moving from
  EnvelopedData to AuthEnvelopedData as the authenticated encryption
  algorithms provide the authentication without needing the SignedData
  layer.

nit: I think a comma before "as the" would help the last sentence.

When talking about compression oracles, do we want to explicitly say that a
common way to do so is to compress attacker-controlled data in the same
corpus as the attacker's target data?

  mail clients deal with HTML and multipart/mixed messages.  Clients
  MUST require that a text/html content type is a complete HTML
  document (per [RFC1866]).  Clients SHOULD treat each of the different
  pieces of the multipart/mixed construct as being of different
  origins.  Clients MUST treat each encrypted or signed piece of a MIME
  message as being of different origins both from unprotected content
  and from each other.

Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed
to just the normal English usage of the word)?

Appendix B

  This appendix contains a number of references to documents that have
  been obsoleted or replaced, this is intentional as frequently the
  updated documents do not have the same information in them.

nit: comma splice

Appendix B.2

  -  Hash functions used to validate signatures on historic messages
      may longer be considered to be secure.  (See below.)  While there
      are not currently any known practical pre-image or second pre-
      image attacks against MD5 or SHA-1, the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.  [...]

nit: there seems to be (at least) a missing verb in this last sentence.

      [...] If a message is
      known to be historic, that it it has been in the possession of the
      client for some time, then it might still be considered to be
      secure.

nit: maybe "and it has been"

[Ballot comment]
In Appendix B:

This is a sentence fragment: "the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.

also s/that it it/that is it/

[Ballot discuss]
[Only reviewed the diff from RFC 5751 so far, but putting a position in the datatracker now in case I don't have time to go back]

This is not necessarily a flaw in the document, I just want to ensure that the decision to use the phrase
"for political reasons" to describe a technical decision made in an IETF-stream RFC is a decision that
is consciously approved by the IESG.  (I could not find any precedent for such a usage.)

[Ballot comment]
I suspect it's too late for changing this to be a good idea, but
using "authenticated enveloped" and in the same breath talking about how it
does not provide proof of origination ("wait, isn't that authentication?),
but it does provide "a level of authentication", is kind of confusing for
the reader.  Could "integrity protection" be used to distinguish the AEAD
property from proof-of-origin authentication?

Similarly, it might be helpful to use the term "AEAD" before the security
considerations section.

Section-by-Section comments follow.

Section 2.7.2

With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
what to make of "such as" in these statements -- what are the attributes
that would qualify for sufficient similarity to match the "such as", other
than equality?

Section 3.1

  In order to protect outer, non-content-related message header fields
  (for instance, the "Subject", "To", "From", and "Cc" fields), the
  sending client MAY wrap a full MIME message in a message/rfc822
  wrapper in order to apply S/MIME security services to these header
  fields.  It is up to the receiving client to decide how to present
  this "inner" header along with the unprotected "outer" header.  It is
  RECOMMENDED that a distinction be made between the location of the
  header.

nit: I'm not sure this last sentence is grammatical.  Do we want "between
the locations", or "a visible distinction be made for the different
possible locations of the header", or something else?

Section 3.1.2

  In the case where S/MIME implementations can determine that all
  intended recipients are capable of handling inner (all but the
  outermost) binary MIME objects SHOULD use binary encoding as opposed
  to a 7-bit-safe transfer encoding for the inner entities.

nit: I think that some words got dropped in here; the sentence doesn't really
parse.  I guess there's a missing "implementations" in "implementations
SHOULD use"?

Section 3.3

  but not signed messages does not provide for data integrity.  The
  Enveloped-Only structure does not support authenticated symmetric
  algorithms, use the .Authenticated Enveloped structure for these
  algorithms.  [...]

nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
comma splice.)

Section 3.5.3.2

I agree with Adam that there should be some notation in the table
or adjacent to it that some algorithms are present only for historical
compatibility and should be considered deprecated/insecure/risky/whatever.

Section 6

  Some cryptographic algorithms such as RC2 offer little actual
  security over sending plaintext.  Other algorithms such as TripleDES,
  provide security but are no longer considered to be state of the art.
  S/MIME requires the use of current state of the art algorithms such
  as AES and provides the ability to announce starter cryptographic
  capabilities to parties with whom you communicate. [...]

I can't figure out what "starter" means, here.

  Modification of the ciphertext in EnvelopedData can go undetected if
  authentication is not also used, which is the case when sending
  EnvelopedData without wrapping it in SignedData or enclosing
  SignedData within it.  This is one of the reasons for moving from
  EnvelopedData to AuthEnvelopedData as the authenticated encryption
  algorithms provide the authentication without needing the SignedData
  layer.

nit: I think a comma before "as the" would help the last sentence.

When talking about compression oracles, do we want to explicitly say that a
common way to do so is to compress attacker-controlled data in the same
corpus as the attacker's target data?

  mail clients deal with HTML and multipart/mixed messages.  Clients
  MUST require that a text/html content type is a complete HTML
  document (per [RFC1866]).  Clients SHOULD treat each of the different
  pieces of the multipart/mixed construct as being of different
  origins.  Clients MUST treat each encrypted or signed piece of a MIME
  message as being of different origins both from unprotected content
  and from each other.

Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed
to just the normal English usage of the word)?

Appendix B

  This appendix contains a number of references to documents that have
  been obsoleted or replaced, this is intentional as frequently the
  updated documents do not have the same information in them.

nit: comma splice

Appendix B.2

  -  Hash functions used to validate signatures on historic messages
      may longer be considered to be secure.  (See below.)  While there
      are not currently any known practical pre-image or second pre-
      image attacks against MD5 or SHA-1, the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.  [...]

nit: there seems to be (at least) a missing verb in this last sentence.

      [...] If a message is
      known to be historic, that it it has been in the possession of the
      client for some time, then it might still be considered to be
      secure.

nit: maybe "and it has been"

[Ballot comment]
I'm balloting "yes", but have some minor comments substantive comments and a number of editorial comments. I mainly reviewed the diff from RFC 5751.

Substantive Comments:

§2.3, 2nd to last paragraph: I don't understand what it means to say recipients MAY enforce a "MUST be supported" requirement. Am I correct to assume the "MUST use the weaker" only applies if the sender used both key-wrap algorithms?

§3.1.2, 2nd paragraph: The addition of "As a rule, ..." doesn't seem to add information, but it does undermine the SHOULD that immediately follows. (I'd count this as an editorial comment, but I think undermining a SHOULD is a material issue.)

Editorial Comments:

- IDNits complains about some unused references. Please check. (They may be due to the specification-group references, which I think are fine).

§1.5: I have trouble parsing the first paragraph. Is the comma in "... MUST implement, key wrap algorithm... " intentional?

§2.2, Receiving agent requirements, 4th bullet: Spurious "." and white space at beginning.

§2.5.2: "The presence
  of an algorithm based SMIME Capability attribute in this sequence
  implies that the sender can deal with the algorithm as well as
  understanding the ASN.1 structures associated with that algorithm."
s/understanding/understands

§2.5.3, 2nd paragraph: "If a signature is detected to violate
  these requirements, the signature SHOULD be treated as failing."

"detected to violate" is awkward. Perhaps "determined to violate", "detected to be violating", or "detected as violating"?

§3.1:
- first paragraph: "A MIME entity can be a sub-part, sub-parts of a
  MIME message, or the whole MIME message with all of its sub-parts."

I'm not sure how to parse the first comma. Is the intent of that part that the entity can be sub-part or sub-parts of a message?

- 2nd to last paragraph: " It is up to the receiving client to decide how to present
  this "inner" header along with the unprotected "outer" header.  It is
  RECOMMENDED that a distinction be made between the location of the
  header."
The last sentence partially contradicts the first one. Also, can the last sentence be phrased in active voice, to strengthen the connection to the client as the actor?

§3.3, first paragraph: "The
  Enveloped-Only structure does not support authenticated symmetric
  algorithms, use the .Authenticated Enveloped structure for these
  algorithms. "
Comma splice.

§6:

- " Many people assume that the use of an authenticated encryption
  algorithm is all that is needed to be in a situation where the sender
  of the message will be authenticated."
Convoluted sentence. The phrase "needed to be in a situation where" seems like a complicated way of expressing something like "needed to consider the sender to be authenticated"

- "... create a message that the first recipient would
      believe is from the sender by stripping them as a recipient from
      the message.": The antecedent of "them" is ambiguous.

- "A direct path needs to exist from the starting key to the key used
      as the content encryption key (CEK) which guarantees that no third
      party could have seen the resulting CEK."
s/which/that

- "A direct path needs to exist from the starting key to the key used
      as the content encryption key (CEK) which guarantees that no third
      party could have seen the resulting CEK."
Comma splice.

- "There
  is a document [RFC6278] which defined how to use static-static key
  agreement with CMS so that is readably doable. "
s/which/that. Also, the _existing_ "that" has an unclear antecedent.

- "New key agreement algorithms that directly
  created the CEK without creating an intervening KEK would need to be
  defined."

Should "would need" simply be "need"?

- "Compression oracle attacks require an adaptive
  input to the process and attack the unknown content of a message
  based on the length of the compressed output, this means that no
  attack on the encryption key is necessarily required."
Comma splice.

- "The other attack that is highlighted in [Efail] is an error in how
  mail clients deal with HTML and multipart/mixed messages. "
I don't think the "error" is the "attack". perhaps s/"is an error"/"involves an error"?

- Appendix D: "Some of the examples in this document were stolen from [RFC4134]."

Can this say something like "copied from" or "borrowed from"?

[Ballot comment]
Thanks to everyone who put work into updating this document. I have one comment
that is either substantive or me just being confused, and several editorial
nits.

---------------------------------------------------------------------------

§3.5.3.2:

>  The values to be placed in the micalg parameter SHOULD be from the
>  following:
>
>  Algorithm Value Used
>  MD5      md5
>  SHA-1    sha-1
>  SHA-224  sha-224
>  SHA-256  sha-256
>  SHA-384  sha-384
>  SHA-512  sha-512
>  Any other (defined separately in algorithm profile or "unknown" if
>            not defined)

The example then goes on to demonstrate the use of "micalg=sha-1".  This is
probably a misunderstanding on my part, but I thought that this document was
intending to mark MD5 and SHA-1 as historic for digesting content (cf. §1.7
and §B.1). Wouldn't that mean they should be annotated as deprecated in some
way here? I would have also expected the example to use sha-256 or sha-512.

---------------------------------------------------------------------------

§2.2:

>  -  .  SHOULD support RSASSA-PSS with SHA-256.

There appears to be an extra "." at the beginning of this bullet

---------------------------------------------------------------------------

§3.1:

>  S/MIME is used to secure MIME entities.  A MIME message is composed
>  of a MIME header and a MIME body, the body can consist of a single
>  part or of multiple parts.

Nit: "...MIME body. The body can..."

---------------------------------------------------------------------------

§3.3:

>  The
>  Enveloped-Only structure does not support authenticated symmetric
>  algorithms, use the .Authenticated Enveloped structure for these
>  algorithms.

Two nits: "...symmetric algorithms. Use the Authenticated..."
                                  ^        ^
---------------------------------------------------------------------------

§6:

>  S/MIME implementations almost universally use ephemeral-static rather
>  than static-static key agreement and do not use a shared secret for
>  encryption, this means that the first precondition is not met.

Nit: "...encryption. This means..."

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

The IANA Services Operator has completed its review of draft-ietf-lamps-rfc5751-bis-07. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the existing registration for pkcs7-mime will have its reference changed to [ RFC-to-be ].

In addition, the existing template for that registration, available here:

https://www.iana.org/assignments/media-types/application/pkcs7-mime

will be updated with the following information:

Type name: application

Subtype Name: pkcs7-mime

Required Parameters: NONE

Optional Parameters: smime-type/signed-data
smime-type/enveloped-data
smime-type/compressed-data
smime-type/certs-only
name

Encoding Considerations: See Section 3 of this document

Security Considerations: See Section 6 of this document

Interoperability Considerations: See Sections 1-6 of this document

Published Specification: RFC 2311, RFC 2633, and this document

Applications that use this media type: Security applications

Additional information: NONE

Person & email to contact for further information: iesg@ietf.org

Intended usage: COMMON

Restrictions on usage: NONE

Author: Sean Turner

Change Controller: S/MIME working group delegated from the IESG

Second, also in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the existing registration for pkcs7-signature will have its reference changed to [ RFC-to-be ].

In addition, the existing template for that registration, available here:

https://www.iana.org/assignments/media-types/application/pkcs7-signature

will be updated with the following information:

Type name: application

Subtype Name: pkcs7-signature

Required Parameters: NONE

Optional Parameters: NONE

Encoding Considerations: See Section 3 of this document

Security Considerations: See Section 6 of this document

Interoperability Considerations: See Sections 1-6 of this document

Published Specification: RFC 2311, RFC 2633, and this document

Applications that use this media type: Security applications

Additional information: NONE

Person & email to contact for further information: iesg@ietf.org

Intended usage: COMMON

Restrictions on usage: NONE

Author: Sean Turner

Change Controller: S/MIME working group delegated from the IESG

Third, in the Parameter Values for the smime-type Parameter registry on the MIME Media Type Sub-Parameter Registries page located at:

https://www.iana.org/assignments/media-type-sub-parameters/

a single, new value is to be registered as follows:

smime-type Value: authEnveloped-data
Reference: [[ RFC-to-be ], Section 3.2.2]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-04-27):

From: The IESG
To: IETF-Announce
CC: lamps-chairs@ietf.org, ekr@rtfm.com, Russ Housley , housley@vigilsec.com, draft-ietf-lamps-rfc5751-bis@ietf.org, spasm@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: -
'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
  Message Specification'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-04-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines Secure/Multipurpose Internet Mail Extensions
  (S/MIME) version 4.0.  S/MIME provides a consistent way to send and
  receive secure MIME data.  Digital signatures provide authentication,
  message integrity, and non-repudiation with proof of origin.
  Encryption provides data confidentiality.  Compression can be used to
  reduce data size.  This document obsoletes RFC 5751.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-lamps-rfc5751-bis-06


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will obsolete RFC 5751, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

    This document specifies the message handling for S/MIME 4.0.
    The changes since S/MIME 3.2 include required support for
    authenticated encryption, increased RSA key sizes, moving old
    cryptographic algorithms to historic status, and requiring support
    for AES-256 GCM, ChaCha200-Poly1305, SHA-512, ECDSA with P-256,
    EdDSA, and Ed25519.

  Working Group Summary:

    There is strong consensus for this document in the LAMPS WG.

  Document Quality:

    S/MIME has wide support, and several implementers have said that
    they will implement the new features in this document.

  Personnel:

    Russ Housley is the document shepherd.
    Eric Rescorla is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.  All issues raised have been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  Several people that were involved in the S/MIME WG were part of the
  review that took place during LAMPS WG Last Call.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  These following IPR disclosures were issued against earlier versions
  of the S/MIME specifications.  They have not hindered widespread
  implementation.

    https://datatracker.ietf.org/ipr/166/
    https://datatracker.ietf.org/ipr/1004/
    https://datatracker.ietf.org/ipr/1153/
    https://datatracker.ietf.org/ipr/1154/


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is strong consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will obsolete RFC5751.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  The application/pkcs7-mime media type was registered a very long
  time ago.  This document adds the authEnveloped-data smime-type
  to support authenticated encryption.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.  The section that shows the changes made to the progression
  of S/MIME specifications uses the RFC numbers of the obsoleted
  specifications in the section headings, but they do not also
  appear in square brackets, so IDnits does not think that they
  belong in the reference section.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  There are not any normative references to documents that are not
  ready for advancement.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are downward normative reference to Informational RFC 5753,
  but it is already in the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will obsolete RFC 5751.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  The updates to the IANA registries are clear.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The ASN.1 module contained in Appendix A is unchanged from RFC 3851,
  except for the comment associated with prefersBinaryInside.  Thus,
  there is no reason to run another syntax check.