Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling
obsoleted by
- rfc-5750 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
obsoletes
- rfc-2632 — S/MIME Version 3 Certificate Handling
Extracted elements (29)
PKCS #6 extended certificates are prohibited because PKIX certificate extensions address much of the same functionality, making PKCS #6 redundant and not in widespread use.
Receiving agents SHOULD NOT simply trust any self-signed certificate as a valid CA but SHOULD use some other mechanism (e.g., pre-configured trust anchors) to determine CA trustworthiness, since self-signing alone provides no assurance of authority.
The email address is preferred in the subjectAltName extension rather than the subject distinguished name to align with RFC 2822 address handling and modern PKIX practices; certificates without any email address have no requirement to verify against a message's From/Sender header.
S/MIME version 3.1 agents should attempt maximum interoperability with prior S/MIME versions (v2 per RFC 2311–2315, v3 per RFC 2630–2634). The changes from v3 include mandatory support for v1/v2 CRLs, overlapping CA validity periods, and prohibition of v1 attribute certificates.
When certificates contain DSA public keys, the DSA parameters may be located only in the root certificate, requiring the recipient to possess both the end-entity and root certificates to perform signature verification. This is a valid reason to transmit the root certificate in a message.
A receiving agent MUST be capable of verifying signatures on certificates and CRLs made with id-dsa-with-sha1, md5WithRSAEncryption, and sha1WithRSAEncryption with key sizes from 512 to 2048 bits. md2WithRSAEncryption MAY be supported.
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 (not an empty SEQUENCE) in S/MIME-compliant X.509 identity certificates, except that the subject DN in an end-entity certificate MAY be empty if subjectAltName is present and marked critical.
Any RFC-2822 email addresses present in the subjectAltName extension MUST be encoded using the rfc822Name CHOICE of the GeneralName type. Multiple RFC-2822 email addresses MAY be present.
Certificate, CRL, and path validation MUST be performed as per RFC 3280 when validating a correspondent's public key before using it for signature verification, key encryption (RSA), or pairwise key formation (Diffie-Hellman).
If a key usage extension is included in a PKIX certificate, 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 has the key usage extension without either the digitalSignature or nonRepudiation bit set.
If the extended key usage extension is present, interpersonal message S/MIME receiving agents MUST check that it contains either the emailProtection or the anyExtendedKeyUsage OID as defined in RFC 3280.
If the key usage extension is not specified, receiving clients MUST presume that the digitalSignature and nonRepudiation bits are set.
Receiving agents MUST be able to handle an arbitrary number of certificates of arbitrary relationship in arbitrary order, and MUST support chaining based on distinguished name fields.
Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate.
Receiving agents MUST support the CRL format defined in RFC 3280. Both v1 and v2 CRLs MUST be supported. All agents MUST be capable of performing revocation checks using CRLs and MUST perform revocation status checking per RFC 3280.
Receiving agents MUST support v1 X.509 and v3 X.509 identity certificates as profiled in RFC 3280. Receiving agents SHOULD support X.509 version 2 attribute certificates.
S/MIME agents MUST verify that a public key is valid before using it to provide security services, and MUST use PKIX certificates to validate public keys as described in RFC 3280.
Sending and receiving agents MUST correctly handle basicConstraints, keyUsage, authorityKeyIdentifier, subjectKeyIdentifier, and subjectAltName 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, which have been superseded by version 2.
The email address SHOULD be in the subjectAltName extension and SHOULD NOT be in the subject distinguished name. Receiving agents MUST recognize email addresses in both the subjectAltName field and in the PKCS #9 emailAddress attribute, which MUST be encoded as IA5String.
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 set to direct a receiving agent to an outdated CRL.
End-entity certificates MAY include an Internet mail address as an addr-spec per RFC 2822. The preferred location is the subjectAltName extension; the PKCS #9 emailAddress attribute in the subject DN is also recognized for compatibility.
The basicConstraints extension delimits whether a certificate is for a CA or an end entity. CA certificates SHOULD contain this extension; end-entity certificates SHOULD NOT.
The CertificateSet structure in CMS-formatted S/MIME messages carries certificates in arbitrary order; a sending agent SHOULD include the user's public key certificates and associated issuer certificates to facilitate chain building by the recipient.
The extended key usage extension narrows the permitted uses of a key to the intersection of itself and the key usage extension. For S/MIME, emailProtection or anyExtendedKeyUsage OIDs are required in interpersonal messaging contexts.
MD2 is discouraged for new certificate signatures because Rogier and Chauvaud (SAC '95) demonstrated an attack that can nearly find collisions; md2WithRSAEncryption MAY still be used to verify existing signatures since finding collisions does not enable forging messages with a previously computed hash.
When certificate processing fails (e.g., no matching email address, no trusted chain, expired certificate, revoked certificate, unavailable CRL), processing software MUST take immediate and noticeable steps to inform the end user rather than silently proceeding.
When multiple unexpired CRLs exist for a CA, an agent consulting CRLs SHOULD ensure it uses the most recently issued CRL, since an S/MIME message sender could deliberately include an older unexpired CRL that omits recently revoked certificates.