S/MIME Version 3 Message Specification
obsoleted by
- rfc-3851 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
Extracted elements (34)
S/MIME uses transfer encoding to ensure only 7-bit MIME entities are secured, even for enveloped data not exposed to transport, so that a trusted gateway can strip the envelope and forward the signed inner message to recipients in non-8-bit-clean environments without invalidating the signature.
The multipart/signed format is preferred for sending because recipients without S/MIME software can still view the message content, whereas the application/pkcs7-mime SignedData format is opaque to non-S/MIME recipients but is reliably verifiable if unmodified in transit.
When a group of recipients has non-overlapping encryption capabilities, the sending agent is forced to send multiple messages. Sending the same content with both strong and weak encryption is a security risk, as an attacker can learn the plaintext by decrypting the weaker copy.
A proper S/MIME implementation MUST use the MIME types and MUST NOT rely on file extensions for identification, though file extensions (.p7m, .p7s, .p7c) are provided as a convenience for gateway environments that strip MIME type information.
S/MIME version 3 agents should attempt maximum interoperability with S/MIME version 2 agents (RFC 2311-2315). S/MIME v2 clients can only verify signatures using rsaEncryption and only decrypt content encryption keys using rsaEncryption.
Some early S/MIME implementations emitted 'rsa-md5' and 'rsa-sha1' for the micalg parameter. Receiving agents SHOULD be able to recover gracefully from an unrecognized micalg parameter value.
A receiving agent MUST provide some certificate retrieval mechanism to gain access to certificates for recipients of digital envelopes.
A user agent MUST NOT generate RSA key pairs less than 512 bits long. RSA key pairs SHOULD be at least 768 bits; receiving agents SHOULD be able to verify signatures with keys of any size over 512 bits.
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.
Before sending a message, the sending agent MUST decide whether weak encryption is acceptable. If weak encryption is unacceptable, the sending agent MUST NOT use a weak algorithm such as RC2/40.
Capabilities list entries with signing times far in the future or from messages whose signatures could not be verified MUST NOT be accepted.
If a multipart/signed entity is EVER to be transmitted over standard Internet SMTP or other 7-bit-constrained transport, it MUST have transfer encoding applied so it is represented as 7-bit text.
MIME entities MUST be canonicalized (converted to canonical form) for both enveloping and signing. Text entities must use <CR><LF> line endings and a registered charset.
Receiving agents MUST be able to handle zero or one instance of each signed attribute (signingTime, sMIMECapabilities, sMIMEEncryptionKeyPreference). Sending agents SHOULD generate one instance of each in every S/MIME message.
S/MIME agents MUST be capable of generating separate DH and DSS key pairs. Each key pair MUST be generated from a good source of non-deterministic random input, and private keys MUST be protected securely.
S/MIME v3 requires the use of SignerInfo version 1; the issuerAndSerialNumber CHOICE MUST be used for SignerIdentifier.
Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. UTCTime year field YY >= 50 is interpreted as 19YY; YY < 50 as 20YY.
Sending agents MUST use the id-data content type identifier for message content that has had security services applied. The CMS signedData encapContentInfo eContentType MUST include the id-data OID.
Sending agents MUST use the signedData content type to apply a digital signature to a message or, in the degenerate case with no signature information, to convey certificates.
Sending and receiving agents MUST support Diffie-Hellman for key encryption. Receiving and sending agents SHOULD support rsaEncryption for key encryption.
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC (tripleDES). Receiving agents SHOULD support RC2/40 for backward compatibility.
Sending and receiving agents MUST support id-dsa (DSS) for signature algorithms, with algorithm parameters MUST be absent (not encoded as NULL). Receiving agents SHOULD support rsaEncryption.
Sending and receiving agents MUST support SHA-1 for digest algorithms. Receiving agents SHOULD support MD5 for backward compatibility with S/MIME v2 SignedData objects.
The multipart/signed protocol parameter MUST be 'application/pkcs7-signature'. Quotation marks are required because MIME requires the '/' character in parameter values to be quoted.
The SMIMECapabilities attribute MUST be a SignedAttribute and MUST NOT be an UnsignedAttribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of SMIMECapabilities, and it MUST only include a single AttributeValue.
The SMIMEEncryptionKeyPreference attribute MUST be a SignedAttribute, MUST NOT be an UnsignedAttribute, and SignedAttributes MUST NOT include multiple instances of this attribute.
The SMIMECapabilities attribute announces the sender's supported algorithms in order of preference, grouped by category (signature, symmetric, key encipherment). OIDs are listed for table-lookup and binary comparison.
The SMIMEEncryptionKeyPreference attribute (id-aa-encrypKeyPref) allows the signer to unambiguously identify which certificate holds their preferred encryption key, expressed as issuerAndSerialNumber, recipientKeyId, or subjectAltKeyIdentifier.
40-bit encryption (e.g., RC2/40) is considered weak and offers little security over plaintext. Sending and receiving agents should inform users of the relative cryptographic strength of messages, and weak encryption should never be used unless the only alternative is no encryption.
Modification of EnvelopedData ciphertext can go undetected when authentication is not also used. Sending enveloped-only messages without a surrounding or inner SignedData does not provide data integrity.
When signing then encrypting, the signatories are securely hidden by the envelope. When encrypting then signing, signatories are exposed but signatures can be verified without a private key; however, a careful attacker may alter unauthenticated portions of the encrypted message.
The application/pkcs7-mime MIME type carries CMS objects (envelopedData, signedData). It SHOULD include the optional 'smime-type' parameter and 'name'/'filename' parameters with extensions .p7m (signedData/envelopedData), .p7c (certs-only), or .p7s (signature).
The multipart/signed format uses two parts: the first contains the signed MIME entity; the second contains the detached CMS SignedData object as application/pkcs7-signature with the micalg parameter indicating the digest algorithm used (md5, sha1, or unknown).
The RC2-CBC-parameter encodes as a SEQUENCE of rc2ParameterVersion INTEGER and iv OCTET STRING (8 bytes). For 40-, 64-, and 128-bit effective key sizes, rc2ParameterVersion values are 160, 120, and 58 respectively.