CN-ID support is retained as a MAY for clients and a MUST for CAs purely for backward compatibility with the large deployed base of email clients; it is not the preferred mechanism and new deployments should use DNS-ID or SRV-ID.

tls, email, pkix

DNSSEC-protected SRV lookups are acknowledged as an alternative authorization mechanism for delegated hosting, but are not mandated because the solution depends on ubiquitous DNSSEC deployment and DNSSEC-aware APIs, which were not sufficiently available at the time of writing.

tls, email, dns, security

The document consolidates previously inconsistent TLS server identity verification rules across RFC 2595 (IMAP/POP/ACAP), RFC 3207 (SMTP STARTTLS), RFC 3501 (IMAP), and RFC 5804 (ManageSieve) into a single consistent procedure to ease implementation for developers who implement multiple protocols simultaneously.

tls, email

URI-IDs are explicitly prohibited for email server verification because URI-IDs were not historically used for email protocols. This avoids introducing a new identifier type that deployed infrastructure does not support.

tls, email, pkix

A certificate can include only a single CN-ID. If a mail service runs on multiple hosts, each host must either use a different certificate with its own CN-ID, use a single certificate with multiple DNS-IDs, or use a single certificate with a wildcard CN-ID.

tls, email, pkix

For ManageSieve over TLS, when the reference identity is an IP address, the iPAddress subjectAltName SHOULD be used by the client for comparison, per the updated text replacing RFC 5804 Sections 2.2.1 and 2.2.1.1.

tls, email, pkix

This document does not apply to use of TLS in MTA-to-MTA SMTP; it covers only SMTP Submission (RFC 6409), IMAP, POP, and ManageSieve clients.

tls, email

When a delegated email hosting provider (e.g., 'imap.hosting.example.net') serves email for another domain (e.g., 'example.org'), the TLS certificate must include SRV-IDs or DNS-IDs for the served domain to avoid mandatory manual user confirmation of certificate exceptions.

tls, email, pkix, dns

A URI-ID identifier type (subjectAltName of uniformResourceIdentifier type) MUST NOT be used by clients for server verification, as URI-IDs were not historically used for email.

tls, email, pkix

CAs MUST support issuance of server certificates with a DNS-ID identifier type and with an SRV-ID identifier type for each type of email service. CAs that cannot verify authorization for a particular domain MUST NOT include email SRV-IDs/DNS-IDs in certificates they issue.

tls, email, pkix, security

During TLS negotiation, an email client (SMTP, IMAP, POP3, or ManageSieve) MUST check its understanding of the server identity against the server's identity as presented in the Certificate message to prevent man-in-the-middle attacks. This check is only performed after the server certificate passes certification path validation per RFC 5280.

tls, email, security, pkix

For backward compatibility with deployed software, a CN-ID identifier type (CN attribute from the subject name) MAY be used for server identity verification.

tls, email, pkix

For 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, or (b) the hostname used to open the connection (without CNAME canonicalization). The client MAY also use a value securely derived from (a) or (b) via DNSSEC.

tls, email, dns, pkix

Mail Service Providers and Certificate Signing Request generation tools MUST include the DNS-ID identifier type in CSRs for host names where email servers run, and MUST include SRV-ID for each email service type if discoverable via RFC 6186 DNS SRV.

tls, email, pkix

Support for the DNS-ID identifier type (subjectAltName of dNSName type) is REQUIRED in email client software implementations.

tls, email, pkix

Support for the SRV-ID identifier type (subjectAltName of SRVName type per RFC 4985) is REQUIRED for email client software implementations that support RFC 6186 service discovery. For the ManageSieve protocol, the service name 'sieve' is used.

tls, email, pkix

The '*' wildcard character MAY be used as the left-most name component of a DNS-ID or CN-ID in the certificate, but MUST NOT be used as a fragment of the left-most name component (e.g., '*oo.example.com' or 'foo*.example.com' are prohibited).

tls, email, pkix

When using the email service discovery procedure specified in RFC 6186, the client MUST also use the domain portion of the user's email address as a reference identifier to compare against an SRV-ID in the server certificate.

tls, email, dns, pkix

Four identifier types are used for server certificate name matching: CN-ID (Common Name RDN from certificate subject), DNS-ID (subjectAltName dNSName), SRV-ID (subjectAltName otherName of SRVName form per RFC 4985), and URI-ID (subjectAltName uniformResourceIdentifier with scheme and host).

tls, email, pkix

Reference identifier is defined as one of the domain names that the email client associates with the target email server. For some identifier types it also includes an application service type. Reference identifiers are used for performing name checks on server certificates per RFC 6125.

tls, email, pkix

CAs that cannot verify that a requesting entity is authorized to run email service for a set of SRV-IDs or DNS-IDs MUST NOT include those identifiers in issued certificates, to prevent unauthorized parties from obtaining certificates that would pass server identity checks.

tls, email, security, pkix

TLS server identity checks for email rely on trustworthy DNS hostnames as reference identifiers. Such trustworthy names must be either manually entered, explicitly user-confirmed, or derived via a secure service such as DNSSEC-protected SRV records. Future work may integrate DANE (RFC 6698) for stronger binding.

tls, email, security, dns