Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
obsoleted by
- rfc-8550 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling
obsoletes
- rfc-3850 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling
Extracted elements (30)
Email addresses SHOULD be placed in the subjectAltName extension rather than the subject DN because subjectAltName is the preferred means in S/MIME for conveying email addresses. Certificates with an empty subject DN are valid if subjectAltName is present and marked critical.
Sending agents SHOULD include certificates for the user's public keys and associated issuer certificates in outgoing messages to increase the likelihood that recipients can establish trust, particularly when sending to new recipients or those lacking directory access.
The 4096-bit RSA key size requirement for certificate and CRL verification is larger than the 2048-bit requirement for message operations because many root CAs in certificate stores have already issued root certificates with 4096-bit keys, and 4096-bit keys are normally only used by root certificates to lengthen their validity period.
Receiving agents MUST recognize email addresses in both the subjectAltName field and the Distinguished Name field in the PKCS #9 emailAddress attribute, and MUST recognize and accept certificates that contain no email address.
S/MIME version 3.2 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME (v2, v3, v3.1). S/MIME v3, v3.1, and v3.2 are backwards compatible with v2 certificate handling except for dropped RC2/40 and added DSA and RSASSA-PSS requirements.
Agents MUST handle multiple valid CA certificates containing the same subject name and the same public keys but with overlapping validity intervals.
All subject and issuer names MUST be populated (i.e., not an empty SEQUENCE) in S/MIME-compliant X.509 certificates, except that the subject DN in an end-entity certificate MAY be an empty SEQUENCE, in which case the subjectAltName MUST be marked as critical.
Certificate, CRL, and path validation MUST be performed as per RFC 5280 when validating a correspondent's public key before providing security services such as verifying a signature, encrypting a content-encryption key, or forming a pairwise symmetric key.
Certificates MUST contain a basicConstraints extension in CA certificates, and SHOULD NOT contain that extension in end-entity certificates, per RFC 5280.
For RSA and RSASSA-PSS, key sizes from 1024 to 4096 bits MUST be supported for certificate and CRL signature verification. Keys <= 1023 bits MAY be supported. For DSA, key sizes from 1024 to 3072 bits MUST be supported.
If a key usage extension is included in a PKIX certificate, then it MUST be marked as critical. S/MIME receiving agents MUST NOT accept the signature of a message if it was verified using a certificate that contains the key usage extension without either the digitalSignature or nonRepudiation bit set.
If the extended key usage extension is present in the certificate, then interpersonal message S/MIME receiving agents MUST check that it contains either the emailProtection or the anyExtendedKeyUsage OID as defined in RFC 5280.
Receiving agents MUST be able to handle an arbitrary number of certificates of arbitrary relationship to the message sender and to each other in arbitrary order. A receiving agent MUST be able to handle an arbitrarily large number of certificates and chains.
Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate.
Receiving agents MUST support chaining based on the distinguished name fields. Agents SHOULD NOT simply trust any self-signed certificates as valid CAs, but SHOULD use some other mechanism to determine if this is a CA that should be trusted.
Receiving agents MUST support RSA with SHA-256 for certificate and CRL signature verification. SHOULD+ support DSA with SHA-256 and RSASSA-PSS with SHA-256. RSA with SHA-1, DSA with SHA-1, and RSA with MD5 are SHOULD-.
Receiving agents MUST support the CRL format defined in RFC 5280. Both v1 and v2 CRLs MUST be supported. All agents MUST perform revocation status checking in accordance with RFC 5280.
Receiving agents MUST support v1 X.509 and v3 X.509 certificates as profiled in RFC 5280. Receiving agents SHOULD support X.509 version 2 attribute certificates.
S/MIME agents MUST use PKIX certificates to validate public keys as described in RFC 5280, and MUST meet the certificate processing requirements in this document in addition to those in RFC 5280.
Sending and receiving agents MUST correctly handle the basic constraints, key usage, authority key identifier, subject key identifier, and subject alternative names certificate extensions when they appear in end-entity and CA certificates.
Sending and receiving agents MUST NOT use PKCS #6 extended certificates. Sending agents MUST NOT send version 1 attribute certificates, as both have been superseded.
The email address SHOULD be in the subjectAltName extension and SHOULD NOT be in the subject distinguished name. Sending agents SHOULD make the address in the From or Sender header match an Internet mail address in the signer's certificate.
When verifying a signature, if a signingCertificate attribute (RFC 2634) or signingCertificateV2 attribute (RFC 5035) is found in an S/MIME message, it SHALL be used to identify the signer's certificate. Otherwise, identification uses issuerAndSerialNumber or subjectKeyIdentifier.
Email addresses in certificates MUST be encoded using the rfc822Name CHOICE of the GeneralName type in the subjectAltName extension. Multiple email addresses MAY be present since SubjectAltName is a SEQUENCE OF GeneralName.
The PKCS #9 emailAddress attribute (OID: pkcs-9-at-emailAddress ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }) is recognized for email address in the Distinguished Name field; it MUST be encoded as IA5String with an upper bound of 255 characters.
When decrypting an encrypted message, if a SMIMEEncryptionKeyPreference attribute is found in an encapsulating SignedData, it SHALL be used to identify the originator's certificate found in OriginatorInfo.
An S/MIME message sender could deliberately include an older unexpired CRL in a message to direct an agent to use out-of-date revocation status. Agents consulting CRLs SHOULD ensure that the most recently issued CRL for a CA is consulted.
Attacker-crafted certificates may mount denial-of-service attacks via keys requiring excessive cryptographic processing, extensive CDP/AIA address lists, or fake CDP/AIA addresses that reveal message receipt even when signature verification fails.
RSA and DSA keys of less than 1024 bits are considered cryptographically insecure. If an implementation supports verification of certificates or CRLs signed with such keys, it MUST warn the user. Server implementations SHOULD reject messages with weak cryptography.
When determining the time for a certificate validity check, the SigningTime attribute found in an S/MIME message MUST NOT be used unless it is from a trusted agent, as it could be deliberately set to direct checking of a stale CRL or cause improper validity period results.