Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 13 must, 4 should, 5 may.
3 Email Server Certificate Verification Rules
- MUSTDuring a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3, or ManageSieve client) MUST check its understanding of the server identity (client's reference identifiers) against the server's identity as presented in the server Certificate message in order to prevent man-in-the-middle attacks.
- MUSTFor DNS-ID and CN-ID identifier types, the client MUST use one or more of the following as "reference identifiers": (a) the domain portion of the user's email address, (b) the hostname it used to open the connection (without CNAME canonicalization).
- MAYThe client MAY also use (c) a value securely derived from (a) or (b), such as using "secure" DNSSEC [RFC4033] [RFC4034] [RFC4035] validated lookup.
- MUSTWhen using email service discovery procedure specified in [RFC6186], the client MUST also use the domain portion of the user's email address as another "reference identifier" to compare against an SRV-ID identifier in the server certificate.
- REQUIREDSupport for the DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]) is REQUIRED in email client software implementations.
- REQUIREDSupport for the SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) is REQUIRED for email client software implementations that support [RFC6186].
- MUST NOTA URI-ID identifier type (subjectAltName of uniformResourceIdentifier type [RFC5280]) MUST NOT be used by clients for server verification, as URI-IDs were not historically used for email.
- MAYFor backward compatibility with deployed software, a CN-ID identifier type (CN attribute from the subject name, see [RFC6125]) MAY be used for server identity verification.
- MAYThe "*" wildcard character MAY be used as the left-most name component of a DNS-ID or CN-ID in the certificate.
- MUST NOTNote that the wildcard character MUST NOT be used as a fragment of the left-most name component (e.g., "*oo.example.com", "f*o.example.com", or "foo*.example.com").
4 Compliance Checklist for Certification Authorities
- MUSTCAs MUST support issuance of server certificates with a DNS-ID identifier type (subjectAltName of dNSName type [RFC5280]).
- MUSTCAs MUST support issuance of server certificates with an SRV-ID identifier type (subjectAltName of SRVName type [RFC4985]) for each type of email service.
- MUSTFor backward compatibility with a deployed client base, CAs MUST support issuance of server certificates with a CN-ID identifier type (CN attribute from the subject name, see [RFC6125]).
- MAYCAs MAY allow "*" (wildcard) as the left-most name component of a DNS-ID or CN-ID in server certificates it issues.
4.1 Notes on Handling of Delegated Email Services by Certification
- MUST NOTIn particular, CAs that can't verify such authorization (whether for a particular domain or in general) MUST NOT include such email SRV-IDs/DNS-IDs in certificates they issue.
- SHOULDA CA willing to sign a certificate containing a particular DNS-ID SHOULD also support signing a certificate containing one or more of the email SRV-IDs for the same domain because the SRV-ID effectively provides more restricted access to an email service for the domain (as opposed to unrestricted use of any services for the same domain, as specified by the DNS-ID).
5 Compliance Checklist for Mail Service Providers and Certificate
- MUSTMUST include the DNS-ID identifier type in Certificate Signing Requests for the host name(s) where the email server(s) are running.
- SHOULDThey SHOULD include the DNS-ID identifier type in Certificate Signing Requests for the domain portion of served email addresses.
- MUSTMUST include the SRV-ID identifier type for each type of email service in Certificate Signing Requests if the email services provided are discoverable using DNS SRV as specified in [RFC6186].
- SHOULDSHOULD include the CN-ID identifier type for the host name where the email server(s) is running in Certificate Signing Requests for backward compatibility with deployed email clients.
- MAYMAY include "*" (wildcard) as the left-most name component of a DNS-ID or CN-ID in Certificate Signing Requests.
9.2 Informative References
- SHOULDWhen the reference identity is an IP address, the iPAddress subjectAltName SHOULD be used by the client for comparison.