2.  CMS Options

   CMS allows for a wide variety of options in content, attributes, and
   algorithm support.  This section puts forth a number of support
   requirements and recommendations in order to achieve a base level of
   interoperability among all S/MIME implementations.  [RFC3370] and
   [RFC5754] provide additional details regarding the use of the
   cryptographic algorithms.  [ESS] provides additional details
   regarding the use of additional attributes.

2.1.  DigestAlgorithmIdentifier

   The algorithms here are used for digesting the body of the message
   and are not the same as the digest algorithms used as part of the
   signature algorithms.  The result of this is placed in the
   message-digest attribute of the signed attributes.  It is RECOMMENDED
   that the algorithm used for digesting the body of the message be of
   similar strength to, or greater strength than, the signature
   algorithm.

   Sending and receiving agents:

   -  MUST support SHA-256.

   -  MUST support SHA-512.

   [RFC5754] provides the details for using these algorithms with
   S/MIME.

2.2.  SignatureAlgorithmIdentifier

   There are different sets of requirements placed on receiving and
   sending agents.  By having the different requirements, the maximum
   amount of interoperability is achieved, as it allows for specialized
   protection of private key material but maximum signature validation.

   Receiving agents:

   -  MUST support ECDSA with curve P-256 and SHA-256.

   -  MUST support EdDSA with curve25519 using PureEdDSA mode [RFC8419].

   -  MUST- support RSA PKCS #1 v1.5 with SHA-256.

   -  SHOULD support the RSA Probabilistic Signature Scheme (RSASSA-PSS)
      with SHA-256.

   Sending agents:

   -  MUST support at least one of the following algorithms: ECDSA with
      curve P-256 and SHA-256, or EdDSA with curve25519 using PureEdDSA
      mode.

   -  MUST- support RSA PKCS #1 v1.5 with SHA-256.

   -  SHOULD support RSASSA-PSS with SHA-256.

   See Section 4.1 for information on key size and algorithm references.

2.3.  KeyEncryptionAlgorithmIdentifier

   Receiving and sending agents:

   -  MUST support Elliptic Curve Diffie-Hellman (ECDH) ephemeral-static
      mode for P-256, as specified in [RFC5753].

   -  MUST support ECDH ephemeral-static mode for X25519 using HKDF-256
      ("HKDF" stands for "HMAC-based Key Derivation Function") for the
      KDF, as specified in [RFC8418].

   -  MUST- support RSA encryption, as specified in [RFC3370].

   -  SHOULD+ support RSA Encryption Scheme - Optimal Asymmetric
      Encryption Padding (RSAES-OAEP), as specified in [RFC3560].

   When ECDH ephemeral-static is used, a key wrap algorithm is also
   specified in the KeyEncryptionAlgorithmIdentifier [RFC5652].  The
   underlying encryption functions for the key wrap and content-
   encryption algorithms [RFC3370] [RFC3565] and the key sizes for the
   two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
   with AES-128 content-encryption algorithm).  As both 128-bit and
   256-bit AES modes are mandatory to implement as content-encryption
   algorithms (Section 2.7), both the AES-128 and AES-256 key wrap
   algorithms MUST be supported when ECDH ephemeral-static is used.
   Recipients MAY enforce this but MUST use the weaker of the two as
   part of any cryptographic strength computations they might do.

   Appendix B provides information on algorithm support in older
   versions of S/MIME.

2.4.  General Syntax

   There are several CMS content types.  Of these, only the Data,
   SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData
   content types are currently used for S/MIME.

2.4.1.  Data Content Type

   Sending agents MUST use the id-data content type identifier to
   identify the "inner" MIME message content.  For example, when
   applying a digital signature to MIME data, the CMS SignedData
   encapContentInfo eContentType MUST include the id-data object
   identifier (OID), and the media type MUST be stored in the SignedData
   encapContentInfo eContent OCTET STRING (unless the sending agent is
   using multipart/signed, in which case the eContent is absent, per
   Section 3.5.3 of this document).  As another example, when applying
   encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
   contentType MUST include the id-data OID and the encrypted MIME
   content MUST be stored in the EnvelopedData encryptedContentInfo
   encryptedContent OCTET STRING.

2.4.2.  SignedData Content Type

   Sending agents MUST use the SignedData content type to apply a
   digital signature to a message or, in a degenerate case where there
   is no signature information, to convey certificates.  Applying a
   signature to a message provides authentication, message integrity,
   and non-repudiation of origin.

2.4.3.  EnvelopedData Content Type

   This content type is used to apply data confidentiality to a message.
   In order to distribute the symmetric key, a sender needs to have
   access to a public key for each intended message recipient to use
   this service.

2.4.4.  AuthEnvelopedData Content Type

   This content type is used to apply data confidentiality and message
   integrity to a message.  This content type does not provide
   authentication or non-repudiation.  In order to distribute the
   symmetric key, a sender needs to have access to a public key for each
   intended message recipient to use this service.

2.4.5.  CompressedData Content Type

   This content type is used to apply data compression to a message.
   This content type does not provide authentication, message integrity,
   non-repudiation, or data confidentiality; it is only used to reduce
   the message's size.

   See Section 3.7 for further guidance on the use of this type in
   conjunction with other CMS types.

2.5.  Attributes and the SignerInfo Type

   The SignerInfo type allows the inclusion of unsigned and signed
   attributes along with a signature.  These attributes can be required
   for the processing of messages (e.g., message digest), information
   the signer supplied (e.g., SMIME capabilities) that should be
   processed, or attributes that are not relevant to the current
   situation (e.g., mlExpansionHistory [RFC2634] for mail viewers).

   Receiving agents MUST be able to handle zero or one instance of each
   of the signed attributes listed here.  Sending agents SHOULD generate
   one instance of each of the following signed attributes in each
   S/MIME message:

   -  Signing time (Section 2.5.1 in this document)

   -  SMIME capabilities (Section 2.5.2 in this document)

   -  Encryption key Preference (Section 2.5.3 in this document)

   -  Message digest (Section 11.2 in [RFC5652])

   -  Content type (Section 11.1 in [RFC5652])

   Further, receiving agents SHOULD be able to handle zero or one
   instance of the signingCertificate and signingCertificateV2 signed
   attributes, as defined in Section 5 of RFC 2634 [ESS] and Section 3
   of RFC 5035 [ESS], respectively.

   Sending agents SHOULD generate one instance of the signingCertificate
   or signingCertificateV2 signed attribute in each SignerInfo
   structure.

   Additional attributes and values for these attributes might be
   defined in the future.  Receiving agents SHOULD handle attributes or
   values that they do not recognize in a graceful manner.

   Interactive sending agents that include signed attributes that are
   not listed here SHOULD display those attributes to the user, so that
   the user is aware of all of the data being signed.

2.5.1.  Signing Time Attribute

   The signingTime attribute is used to convey the time that a message
   was signed.  The time of signing will most likely be created by a
   signer and therefore is only as trustworthy as that signer.

   Sending agents MUST encode signing time through the year 2049 as
   UTCTime; signing times in 2050 or later MUST be encoded as
   GeneralizedTime.  When the UTCTime CHOICE is used, S/MIME agents MUST
   interpret the year field (YY) as follows:

      If YY is greater than or equal to 50, the year is interpreted as
      19YY; if YY is less than 50, the year is interpreted as 20YY.

   Receiving agents MUST be able to process signingTime attributes that
   are encoded in either UTCTime or GeneralizedTime.

2.5.2.  SMIMECapabilities Attribute

   The SMIMECapabilities attribute includes signature algorithms (such
   as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128
   CBC"), authenticated symmetric algorithms (such as "AES-128 GCM"),
   and key encipherment algorithms (such as "rsaEncryption").  The
   presence of an SMIMECapability attribute containing an algorithm
   implies that the sender can deal with the algorithm as well as
   understand the ASN.1 structures associated with that algorithm.
   There are also several identifiers that indicate support for other
   optional features such as binary encoding and compression.  The
   SMIMECapabilities attribute was designed to be flexible and
   extensible so that, in the future, a means of identifying other
   capabilities and preferences such as certificates can be added in a
   way that will not cause current clients to break.

   If present, the SMIMECapabilities attribute MUST be a
   SignedAttribute.  CMS defines SignedAttributes as a SET OF Attribute.
   The SignedAttributes in a signerInfo MUST include a single instance
   of the SMIMECapabilities attribute.  CMS defines the ASN.1 syntax for
   Attribute to include attrValues SET OF AttributeValue.  An
   SMIMECapabilities attribute MUST only include a single instance of
   AttributeValue.  If a signature is detected as violating these
   requirements, the signature SHOULD be treated as failing.

   The semantics of the SMIMECapabilities attribute specify a partial
   list as to what the client announcing the SMIMECapabilities can
   support.  A client does not have to list every capability it
   supports, and it need not list all its capabilities so that the
   capabilities list doesn't get too long.  In an SMIMECapabilities
   attribute, the OIDs are listed in order of their preference but
   SHOULD be separated logically along the lines of their categories
   (signature algorithms, symmetric algorithms, key encipherment
   algorithms, etc.).

   The structure of the SMIMECapabilities attribute is to facilitate
   simple table lookups and binary comparisons in order to determine
   matches.  For instance, the encoding for the SMIMECapability for
   sha256WithRSAEncryption includes rather than omits the NULL
   parameter.  Because of the requirement for identical encoding,
   individuals documenting algorithms to be used in the
   SMIMECapabilities attribute SHOULD explicitly document the correct
   byte sequence for the common cases.

   For any capability, the associated parameters for the OID MUST
   specify all of the parameters necessary to differentiate between two
   instances of the same algorithm.

   The same OID that is used to identify an algorithm SHOULD also be
   used in the SMIMECapability for that algorithm.  There are cases
   where a single OID can correspond to multiple algorithms.  In these
   cases, a single algorithm MUST be assigned to the SMIMECapability
   using that OID.  Additional OIDs from the smimeCapabilities OID tree
   are then allocated for the other algorithms usages.  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.

   The registered SMIMECapabilities list specifies the parameters for
   OIDs that need them, most notably key lengths in the case of
   variable-length symmetric ciphers.  In the event that there are no
   differentiating parameters for a particular OID, the parameters MUST
   be omitted and MUST NOT be encoded as NULL.  Additional values for
   the SMIMECapabilities attribute might be defined in the future.
   Receiving agents MUST handle an SMIMECapabilities object that has
   values that it does not recognize in a graceful manner.

   Section 2.7.1 explains a strategy for caching capabilities.

2.5.3.  Encryption Key Preference Attribute

   The encryption key preference attribute allows the signer to
   unambiguously describe which of the signer's certificates has the
   signer's preferred encryption key.  This attribute is designed to
   enhance behavior for interoperating with those clients that use
   separate keys for encryption and signing.  This attribute is used to
   convey to anyone viewing the attribute which of the listed
   certificates is appropriate for encrypting a session key for future
   encrypted messages.

   If present, the SMIMEEncryptionKeyPreference attribute MUST be a
   SignedAttribute.  CMS defines SignedAttributes as a SET OF Attribute.
   The SignedAttributes in a signerInfo MUST include a single instance
   of the SMIMEEncryptionKeyPreference attribute.  CMS defines the ASN.1
   syntax for Attribute to include attrValues SET OF AttributeValue.  An
   SMIMEEncryptionKeyPreference attribute MUST only include a single
   instance of AttributeValue.  If a signature is detected as violating
   these requirements, the signature SHOULD be treated as failing.

   The sending agent SHOULD include the referenced certificate in the
   set of certificates included in the signed message if this attribute
   is used.  The certificate MAY be omitted if it has been previously
   made available to the receiving agent.  Sending agents SHOULD use
   this attribute if the commonly used or preferred encryption
   certificate is not the same as the certificate used to sign the
   message.

   Receiving agents SHOULD store the preference data if the signature on
   the message is valid and the signing time is greater than the
   currently stored value.  (As with the SMIMECapabilities, the clock
   skew SHOULD be checked and the data not used if the skew is too
   great.)  Receiving agents SHOULD respect the sender's encryption key
   preference attribute if possible.  This, however, represents only a
   preference, and the receiving agent can use any certificate in
   replying to the sender that is valid.

   Section 2.7.1 explains a strategy for caching preference data.

2.5.3.1.  Selection of Recipient Key Management Certificate

   In order to determine the key management certificate to be used when
   sending a future CMS EnvelopedData message for a particular
   recipient, the following steps SHOULD be followed:

   -  If an SMIMEEncryptionKeyPreference attribute is found in a
      SignedData object received from the desired recipient, this
      identifies the X.509 certificate that SHOULD be used as the X.509
      key management certificate for the recipient.

   -  If an SMIMEEncryptionKeyPreference attribute is not found in a
      SignedData object received from the desired recipient, the set of
      X.509 certificates SHOULD be searched for an X.509 certificate
      with the same subject name as the signer of an X.509 certificate
      that can be used for key management.

   -  Or, use some other method of determining the user's key management
      key.  If an X.509 key management certificate is not found, then
      encryption cannot be done with the signer of the message.  If
      multiple X.509 key management certificates are found, the S/MIME
      agent can make an arbitrary choice between them.

2.6.  SignerIdentifier SignerInfo Type

   S/MIME v4.0 implementations MUST support both issuerAndSerialNumber
   and subjectKeyIdentifier.  Messages that use the subjectKeyIdentifier
   choice cannot be read by S/MIME v2 clients.

   It is important to understand that some certificates use a value for
   subjectKeyIdentifier that is not suitable for uniquely identifying a
   certificate.  Implementations MUST be prepared for multiple
   certificates for potentially different entities to have the same
   value for subjectKeyIdentifier and MUST be prepared to try each
   matching certificate during signature verification before indicating
   an error condition.

2.7.  ContentEncryptionAlgorithmIdentifier

   Sending and receiving agents:

   -  MUST support encryption and decryption with AES-128 GCM and
      AES-256 GCM [RFC5084].

   -  MUST- support encryption and decryption with AES-128 CBC
      [RFC3565].

   -  SHOULD+ support encryption and decryption with ChaCha20-Poly1305
      [RFC7905].

2.7.1.  Deciding Which Encryption Method to Use

   When a sending agent creates an encrypted message, it has to decide
   which type of encryption to use.  The decision process involves using
   information garnered from the capabilities lists included in messages
   received from the recipient, as well as out-of-band information such
   as private agreements, user preferences, legal restrictions, and
   so on.

   Section 2.5.2 defines a method by which a sending agent can
   optionally announce, among other things, its decrypting capabilities
   in its order of preference.  The following method for processing and
   remembering the encryption capabilities attribute in incoming signed
   messages SHOULD be used.

   -  If the receiving agent has not yet created a list of capabilities
      for the sender's public key, then, after verifying the signature
      on the incoming message and checking the timestamp, the receiving
      agent SHOULD create a new list containing at least the signing
      time and the symmetric capabilities.

   -  If such a list already exists, the receiving agent SHOULD verify
      that the signing time in the incoming message is greater than the
      signing time stored in the list and that the signature is valid.
      If so, the receiving agent SHOULD update both the signing time and
      capabilities in the list.  Values of the signing time that lie far
      in the future (that is, a greater discrepancy than any reasonable
      clock skew), or a capabilities list in messages whose signature
      could not be verified, MUST NOT be accepted.

   The list of capabilities SHOULD be stored for future use in creating
   messages.

   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.

   Sections 2.7.1.1 and 2.7.1.2 describe the decisions a sending agent
   SHOULD use when choosing which type of encryption will be applied to
   a message.  These rules are ordered, so the sending agent SHOULD make
   its decision in the order given.

2.7.1.1.  Rule 1: Known Capabilities

   If the sending agent has received a set of capabilities from the
   recipient for the message the agent is about to encrypt, then the
   sending agent SHOULD use that information by selecting the first
   capability in the list (that is, the capability most preferred by the
   intended recipient) that the sending agent knows how to encrypt.  The
   sending agent SHOULD use one of the capabilities in the list if the
   agent reasonably expects the recipient to be able to decrypt the
   message.

2.7.1.2.  Rule 2: Unknown Capabilities, Unknown Version of S/MIME

   If the following two conditions are met, the sending agent SHOULD use
   AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required
   by S/MIME v4.0:

   -  The sending agent has no knowledge of the encryption capabilities
      of the recipient.

   -  The sending agent has no knowledge of the version of S/MIME used
      or supported by the recipient.

   If the sending agent chooses not to use AES-256 GCM in this step,
   given the presumption is that a client implementing AES-GCM would do
   both AES-256 and AES-128, it SHOULD use AES-128 CBC.

2.7.2.  Choosing Weak Encryption

   Algorithms such as RC2 are considered to be weak encryption
   algorithms.  Algorithms such as TripleDES are not state of the art
   and are considered to be weaker algorithms than AES.  A sending agent
   that is controlled by a human SHOULD allow a human sender to
   determine the risks of sending data using a weaker encryption
   algorithm before sending the data, and possibly allow the human to
   use a stronger encryption algorithm such as AES GCM or AES CBC even
   if there is a possibility that the recipient will not be able to
   process that algorithm.

2.7.3.  Multiple Recipients

   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.  Please note 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 could learn the contents of the strongly
   encrypted message simply by decrypting the weakly encrypted message.