S/MIME Version 3 Certificate Handling
obsoleted by
- rfc-3850 — Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling
Extracted elements (28)
For DSA certificates, parameters may be located in the root certificate, which may require transmitting the root certificate so recipients can perform signature verification — a valid reason to include root CA certificates in messages.
PKCS #6 Extended Certificates are prohibited in S/MIME v3 because PKCS #6 is not in widespread use and PKIX certificate extensions address much of the same functionality and flexibility that PKCS #6 was intended to provide.
Sending agents SHOULD include certificate chains in outgoing messages to increase the likelihood that recipients can establish trust, especially when sending to new recipients or those without access to a shared directory. This can be omitted when a group has established certificate sharing by other means.
Receiving S/MIME agents SHOULD be able to handle messages without certificates using a database or directory lookup scheme, since senders may omit certificates when correspondents share access via other means.
S/MIME version 3 agents should attempt the greatest interoperability possible with S/MIME version 2 agents, as described in RFC 2311 through RFC 2315.
A receiving agent MUST be capable of verifying signatures on certificates and CRLs made with id-dsa-with-sha1 [DSS].
Agents MUST handle multiple valid CA certificates containing the same subject name and the same public keys but with overlapping validity intervals.
All agents MUST be capable of performing revocation checks using CRLs as specified in [KEYM], and MUST perform revocation status checking in accordance with [KEYM]. Receiving agents MUST recognize CRLs in received S/MIME messages.
All subject and issuer names MUST be populated (not an empty SEQUENCE) in S/MIME-compliant PKIX certificates, except that the subject DN in an end-entity certificate MAY be empty if the subjectAltName extension includes the subject's identifier and is marked critical.
Certificate, CRL, and chain validation MUST be performed as per [KEYM] when validating a correspondent's public key before using it for signature verification, key encipherment, or pairwise key formation.
For DH key exchange certificates, if keyAgreement is set and the key is used to decrypt data, the agent MUST only use the key if encipherOnly is 0; if used to encrypt data, it MUST only use the key if decipherOnly is 0.
If a key usage extension is included in a PKIX certificate, then it MUST be marked as critical.
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.
Receiving agents MUST check that the address in the From or Sender header 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 support chaining based on the distinguished name fields when building certificate chains.
Receiving agents MUST support PKIX v1 and PKIX v3 certificates. Sending and receiving agents MUST NOT use PKCS #6 extended certificates.
Receiving agents MUST support the CRL format defined in [KEYM]. If sending agents include CRLs in outgoing messages, the CRL format defined in [KEYM] MUST be used.
RFC-822 email addresses in the SubjectAltName extension MUST be encoded using the rfc822Name CHOICE of the GeneralName type; multiple addresses MAY be present.
S/MIME agents MUST certify that a public key is valid before using it to provide security services. Agents MUST use PKIX certificates to validate public keys as described in the PKIX Certificate and CRL Profile [KEYM].
Sending and receiving agents MUST correctly handle the Basic Constraints, Key Usage, authorityKeyID, subjectKeyID, and subjectAltNames certificate extensions when they appear in end-user certificates.
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 the Distinguished Name PKCS #9 emailAddress attribute.
End-entity certificates MAY include an Internet mail address; the address must be an addr-spec per RFC 822 Section 6.1. The preferred location is the subjectAltName extension rather than the subject distinguished name.
The basicConstraints extension delimits the role of a certificate in a chain: CA certificates SHOULD contain it to identify them as issuing authorities; end-entity certificates SHOULD NOT contain it.
The CertificateSet in a CMS message may contain an arbitrary number of certificates in arbitrary order, potentially representing a chain from sender to a root CA or unrelated certificates included for convenience.
The keyUsage extension limits the technical purposes for which a certificate's public key may be used; CA certificates may restrict the key to signing certificates and CRLs. The extension MUST be marked critical if present.
Certificates issued for the S/MIME environment SHOULD NOT contain critical extensions other than Basic Constraints, Key Usage, authorityKeyID, subjectKeyID, and subjectAltNames; other extensions SHOULD be marked non-critical to avoid processing failures.
If a certificate is not provably valid and associated with a message, processing software should take immediate and noticeable steps to inform the end user. Failure conditions include: no matching email address, no chain to a trusted CA, inability to check the CRL, an expired or revoked certificate, or an invalid/expired CRL.
Receiving agents SHOULD NOT simply trust any self-signed certificate as a valid CA, but SHOULD use some other mechanism to determine if it is a CA that should be trusted, to prevent certificate spoofing attacks.