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. 220.127.116.11. 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 18.104.22.168 and 22.214.171.124 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. 126.96.36.199. 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. 188.8.131.52. 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.