Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling
obsoletes
- rfc-5750 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling
Extracted elements (27)
DSA was dropped in S/MIME v4.0 as part of a general movement from finite-field to elliptic-curve cryptography. Additionally, issues related to non-deterministic generation of the parameter 'k' in DSA created security risks. ECDSA and EdDSA are the preferred replacements.
PKCS #6 extended certificates are prohibited because they are not in widespread use and because PKIX certificate extensions address much of the same functionality and flexibility. Version 1 ACs are prohibited because they are not widely implemented and have been superseded by version 2 ACs.
S/MIME v4.0 agents ought to attempt maximum interoperability with agents for prior versions (v2, v3, v3.1, v3.2). Historic algorithms (RSA/DSA with SHA-1, RSA with MD5) SHOULD NOT be used for new artifacts but may be needed to process historic S/MIME messages or files.
Agents SHOULD store CRLs received in messages for use in processing later messages. Receiving and sending agents SHOULD retrieve and utilize CRL information every time a certificate is verified as part of a certification path validation even if the certificate was already verified in the past.
All subject and issuer names MUST be populated (not an empty SEQUENCE) in S/MIME-compliant X.509 certificates, except that the subject distinguished name in an end entity's certificate MAY be an empty SEQUENCE, in which case the subjectAltName extension will include the subject's identifier and 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 using it to verify a signature, encrypt a content-encryption key, or form a pairwise symmetric key.
For ASCII email addresses, the domain component MUST be compared using a case-insensitive function. The local name component SHOULD be compared using a case-insensitive function. The pkcs-9-at-emailAddress attribute MUST be encoded as IA5String with an upper bound of 255 characters.
For RSA and RSASSA-PSS key sizes during certificate and CRL signature verification: keys <= 2047 bits SHOULD NOT be used; keys 2048–4096 bits MUST be supported; keys > 4096 bits MAY be supported. RSA keys of less than 2048 bits are considered cryptographically insecure.
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 containing a key usage extension without at least one of the digitalSignature or nonRepudiation bits set. If the key usage extension is absent, receiving clients MUST presume both bits are set.
If the extended key usage extension is present, interpersonal-message S/MIME receiving agents MUST check that it contains either the id-kp-emailProtection OID 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 in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide explicit alternate processing if this comparison fails.
Receiving agents MUST recognize and accept certificates that contain no email address. Receiving agents MUST recognize both ASCII and internationalized email addresses in the subjectAltName extension and MUST recognize email addresses in the distinguished name field in the PKCS #9 emailAddress attribute.
Receiving agents MUST support chaining based on the distinguished name fields. Sending agents SHOULD include at least one chain of certificates up to, but not including, a CA that the sender believes the recipient may trust as authoritative.
Receiving agents MUST support ECDSA with curve P-256 with SHA-256, MUST support EdDSA with curve25519 using PureEdDSA mode, and MUST- support RSA PKCS #1 v1.5 with SHA-256. Agents SHOULD support RSASSA-PSS with SHA-256 and SHOULD use deterministic generation for the ECDSA parameter 'k' per RFC 6979.
Receiving agents MUST support the CRL format defined in RFC 5280 and MUST support both v1 and v2 CRLs. All agents MUST be capable of performing revocation checks using CRLs as specified in RFC 5280 and 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 (ACs).
S/MIME agents MUST verify that a public key is valid before using it, and MUST use PKIX certificates to do so as described in RFC 5280. S/MIME agents MUST meet the certificate-processing requirements in this document in addition to those in RFC 5280.
Sending and receiving agents MUST correctly handle the basicConstraints, keyUsage, authorityKeyIdentifier, subjectKeyIdentifier, and subjectAltName certificate extensions when they appear in end-entity and CA certificates. Certificates issued for S/MIME SHOULD NOT contain any critical extensions other than those listed.
Sending and receiving agents MUST NOT use PKCS #6 extended certificates. Receiving agents MUST be able to parse and process a message containing PKCS #6 extended certificates, although ignoring those certificates is expected behavior. Sending agents MUST NOT send version 1 ACs.
The email address SHOULD be in the subjectAltName extension and SHOULD NOT be in the subject distinguished name. If the local portion of the email address is ASCII it MUST be encoded using the rfc822Name CHOICE; if not ASCII it MUST be encoded using the otherName CHOICE as described in RFC 8398.
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. When decrypting, if an SMIMEEncryptionKeyPreference attribute is found in an encapsulating SignedData, it SHALL be used to identify the originator's certificate.
The pkcs-9-at-emailAddress object identifier (OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }) is used to carry ASCII Internet mail addresses in X.509 certificates, encoded as IA5String with an upper bound of 255 characters.
An S/MIME message sender could deliberately include an older unexpired CRL that does not contain recently revoked certificates, leading an agent to accept a revoked certificate. Agents SHOULD ensure they consult the most recently issued CRL for a CA when validating certificate paths.
Attacker-specified CDP and/or AIA addresses in fake certificates could be used to mount denial-of-service attacks or to allow the originator to detect receipt of the message even if signature verification fails. Caution should be taken when processing certificates that have not first been validated to a trust anchor.
RSA keys of less than 2048 bits are considered cryptographically insecure. If an implementation supports verification of certificates or CRLs generated with RSA or DSA keys of less than 2048 bits, it MUST warn the user. Server implementations where user warnings are not appropriate SHOULD reject messages with weak cryptography.
The signingTime attribute could be deliberately set to a time where the receiving agent would use a CRL that does not contain a revocation for the signing certificate, or use a certificate that has expired or is not yet valid. Agents should use a reliable time—normally the current time—for certificate validity checks.