Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
obsoleted by
- rfc-5751 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
obsoletes
- rfc-2633 — S/MIME Version 3 Message Specification
Extracted elements (30)
Signing-then-encrypting obscures signatories via enveloping but prevents signature verification without decryption. Encrypting-then-signing exposes signatories but allows signature verification without the private key, which is useful for automated gateway verification environments.
Transfer encoding to 7-bit is recommended for all secured MIME entities (not just clear-signed) so that a trusted gateway removing the envelope but not the signature can forward the signed content through non-8-bit-clean transports without corrupting or invalidating the signature.
CompressedData (smime-type=compressed-data) was introduced in S/MIME v3.1 and is not recognized by earlier S/MIME agents. The id-cap-preferBinaryInside capability OID from [CMSCOMPR] is the preferred method for negotiating CompressedData support.
Messages using subjectKeyIdentifier in SignerIdentifier cannot be read by S/MIME v2 clients. S/MIME v2 clients can only decrypt with rsaEncryption and only verify signatures using rsaEncryption with SHA-1 or MD5; they do not implement id-dsa-with-sha1.
A multipart/signed entity transmitted over 7-bit SMTP infrastructure MUST have transfer encoding applied so it is represented as 7-bit text. MIME entities that are already 7-bit need no encoding; 8-bit and binary data MUST use quoted-printable or base64.
All generated key pairs MUST use a good source of non-deterministic random input, and private keys MUST be protected securely. RSA key pairs MUST NOT be less than 512 bits; a minimum of 768 bits is RECOMMENDED.
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME messages within reasonable resource limits. Sending agents MUST decide whether weak encryption is acceptable before sending and MUST NOT use RC2/40 if weak encryption is deemed unacceptable.
For application/pkcs7-signature (detached signature), the SignedData encapContentInfo eContent field MUST be absent; signerInfos contains the signatures for the MIME entity in the first part of the multipart/signed.
For multipart/signed messages, the protocol parameter MUST be "application/pkcs7-signature" (quotation marks required because '/' in the parameter value MUST be quoted per MIME). The micalg parameter MUST list multiple digest algorithms separated by commas if applicable.
If present, the SMIMECapabilities attribute MUST be a SignedAttribute and MUST NOT be an UnsignedAttribute. A signerInfo MUST NOT include multiple instances of the SMIMECapabilities attribute, and it MUST contain exactly one AttributeValue.
If present, the SMIMEEncryptionKeyPreference attribute MUST be a SignedAttribute and MUST NOT be an UnsignedAttribute. A signerInfo MUST NOT include multiple instances, and there MUST be exactly one AttributeValue.
MIME entities MUST be converted to canonical form before signing, enveloping, or compressing. Text entities MUST have line endings canonicalized to <CR><LF> and character sets canonicalized; multi-representation charsets such as ISO-2022 MUST use their canonical representation.
Receiving agents MUST support id-dsa-with-sha1 and rsaEncryption for signature verification. Algorithm parameters for id-dsa-with-sha1 MUST be absent (not encoded as NULL). Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
S/MIME v3.1 implementations MUST support both issuerAndSerialNumber and subjectKeyIdentifier for SignerIdentifier. Implementations MUST be prepared for multiple certificates sharing the same subjectKeyIdentifier and MUST try each during verification before indicating an error.
Sending agents MUST encode signing time through year 2049 as UTCTime; times in 2050 or later MUST be encoded as GeneralizedTime. In UTCTime, YY >= 50 is interpreted as 19YY; YY < 50 is interpreted as 20YY.
Sending agents MUST use the id-data content type OID to identify the inner MIME message content in both SignedData encapContentInfo eContentType and EnvelopedData encryptedContentInfo contentType.
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC (tripleDES). AES at 128-, 192-, and 256-bit key sizes SHOULD be supported. Receiving agents SHOULD support RC2/40 for backward compatibility.
Sending and receiving agents MUST support rsaEncryption for key encryption (key wrapping). Diffie-Hellman in ephemeral-static mode SHOULD also be supported.
Sending and receiving agents MUST support SHA-1 for DigestAlgorithmIdentifier. Receiving agents SHOULD support MD5 for backward compatibility with MD5-digested S/MIME v2 SignedData objects.
The application/pkcs7-mime MIME type carries CMS EnvelopedData (smime-type=enveloped-data, .p7m), SignedData (smime-type=signed-data, .p7m), CompressedData (smime-type=compressed-data, .p7z), and degenerate SignedData for certificates/CRLs (smime-type=certs-only, .p7c).
The micalg parameter in multipart/signed identifies the message digest algorithm(s) used for the MIC: sha1, md5, sha256, sha384, sha512, or 'unknown'. It enables one-pass signature verification. Multiple algorithms MUST be comma-separated.
The smime-type parameter on application/pkcs7-mime indicates the security operation (enveloped-data, signed-data, certs-only, compressed-data) without requiring ASN.1 decoding, serving as a hint for mail clients to display 'signed' or 'encrypted' status.
The SMIMECapabilities signed attribute announces an ordered list of supported cryptographic algorithms (signature, symmetric, key encipherment) and optional features (e.g., id-cap-preferBinaryInside) to enable recipients to select the strongest mutually supported algorithm for future messages.
The SMIMEEncryptionKeyPreference signed attribute unambiguously identifies which of the signer's certificates holds the preferred encryption key, supporting clients that use separate signing and encryption keys. Receiving agents SHOULD store this preference when the signature is valid.
40-bit encryption (e.g., RC2/40) is considered weak and offers little security over plaintext. A sender SHOULD NOT send the same message encrypted with both strong and weak algorithms simultaneously, as an attacker can learn the strongly-encrypted message content by decrypting the weakly-encrypted copy.
PKCS #1 v1.5 implementations are vulnerable to the adaptive chosen ciphertext (Million Message Attack); see RFC 3218. Diffie-Hellman in prime-order subgroups is vulnerable to small-subgroup attacks; countermeasures are described in RFC 2785.
Sending EnvelopedData without wrapping in SignedData provides no data integrity protection; ciphertext can be modified in ways that yield a valid but semantically altered plaintext. Authentication should be combined with encryption.
For the RC2 SMIMECapability, capabilityID MUST be rc2-cbc and the parameters field MUST contain an INTEGER representing the effective key length in bits (e.g., 128 for 128-bit RC2), NOT the RC2 parameter version value (e.g., not 58).
SMIMECapability is encoded as a SEQUENCE { capabilityID OBJECT IDENTIFIER, parameters ANY DEFINED BY capabilityID OPTIONAL }. SMIMECapabilities is SEQUENCE OF SMIMECapability. Parameters MUST be omitted (not encoded as NULL) when there are no differentiating parameters for a given OID.
SMIMEEncryptionKeyPreference is encoded as a CHOICE of issuerAndSerialNumber [0] IssuerAndSerialNumber, receipentKeyId [1] RecipientKeyIdentifier, or subjectAltKeyIdentifier [2] SubjectKeyIdentifier, under OID id-aa-encrypKeyPref (id-aa 11).