7Internet Engineering Task Force (IETF) A. Melnikov
8Request for Comments: 7817 Isode Ltd
9Updates: 2595, 3207, 3501, 5804 March 2016
10Category: Standards Track
14 Updated Transport Layer Security (TLS) Server Identity Check Procedure
15 for Email-Related Protocols
19 This document describes the Transport Layer Security (TLS) server
20 identity verification procedure for SMTP Submission, IMAP, POP, and
21 ManageSieve clients. It replaces Section 2.4 (Server Identity Check)
22 of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS
23 Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations)
24 of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc7817.
42 Copyright (c) 2016 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58Melnikov Standards Track [Page 1]
60RFC 7817 TLS Server Identity Check for Email March 2016
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
67 3. Email Server Certificate Verification Rules . . . . . . . . . 3
68 4. Compliance Checklist for Certification Authorities . . . . . 5
69 4.1. Notes on Handling of Delegated Email Services by
70 Certification Authorities . . . . . . . . . . . . . . . . 5
71 5. Compliance Checklist for Mail Service Providers and
72 Certificate Signing Request Generation Tools . . . . . . . . 6
73 5.1. Notes on Hosting Multiple Domains . . . . . . . . . . . . 7
74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
75 7. Operational Considerations . . . . . . . . . . . . . . . . . 9
76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
79 9.2. Informative References . . . . . . . . . . . . . . . . . 11
80 Appendix A. Changes to RFCs 2595, 3207, 3501, and 5804 . . . . . 12
81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
86 Use of TLS by SMTP Submission, IMAP, POP, and ManageSieve clients is
87 described in [RFC3207], [RFC3501], [RFC2595], and [RFC5804],
88 respectively. Each of the documents describes slightly different
89 rules for server certificate identity verification (or doesn't define
90 any rules at all). In reality, email client and server developers
91 implement many of these protocols at the same time, so it would be
92 good to define modern and consistent rules for verifying email server
95 This document describes the updated TLS server identity verification
96 procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501],
97 POP [RFC1939], and ManageSieve [RFC5804] clients. Section 3 of this
98 document replaces Section 2.4 of [RFC2595].
100 Note that this document doesn't apply to use of TLS in MTA-to-MTA
103 This document provides a consistent TLS server identity verification
104 procedure across multiple email-related protocols. This should make
105 it easier for Certification Authorities (CAs) and ISPs to deploy TLS
106 for email use and would enable email client developers to write more
114Melnikov Standards Track [Page 2]
116RFC 7817 TLS Server Identity Check for Email March 2016
1192. Conventions Used in This Document
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in [RFC2119].
125 The following terms or concepts are used through the document:
127 reference identifier: One of the domain names that the email client
128 (an SMTP, IMAP, POP3, or ManageSieve client) associates with the
129 target email server. For some identifier types, the identifier
130 also includes an application service type. Reference identifiers
131 are used for performing name checks on server certificates. (This
132 term is formally defined in [RFC6125].)
134 CN-ID, DNS-ID, SRV-ID, and URI-ID are identifier types (see [RFC6125]
135 for details). For convenience, their short definitions from
136 [RFC6125] are listed below:
138 CN-ID: A Relative Distinguished Name (RDN) in the certificate
139 subject field that contains one and only one attribute-type-and-
140 value pair of type Common Name (CN), where the value matches the
141 overall form of a domain name (informally, dot-separated, letter-
142 digit-hyphen labels).
144 DNS-ID: A subjectAltName entry of type dNSName
146 SRV-ID: A subjectAltName entry of type otherName whose name form is
149 URI-ID: A subjectAltName entry of type uniformResourceIdentifier
150 whose value includes both (i) a "scheme" and (ii) a "host"
151 component (or its equivalent) that matches the "reg-name" rule
152 (where the quoted terms represent the associated [RFC5234]
153 productions from [RFC3986]).
1553. Email Server Certificate Verification Rules
157 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3,
158 or ManageSieve client) MUST check its understanding of the server
159 identity (client's reference identifiers) against the server's
160 identity as presented in the server Certificate message in order to
161 prevent man-in-the-middle attacks. This check is only performed
162 after the server certificate passes certification path validation as
163 described in Section 6 of [RFC5280]. Matching is performed according
164 to the rules specified in Section 6 of [RFC6125], including the
165 relative order of matching of different identifier types,
166 "certificate pinning", and the procedure on failure to match. The
170Melnikov Standards Track [Page 3]
172RFC 7817 TLS Server Identity Check for Email March 2016
175 following inputs are used by the verification procedure used in
178 1. For DNS-ID and CN-ID identifier types, the client MUST use one or
179 more of the following as "reference identifiers": (a) the domain
180 portion of the user's email address, (b) the hostname it used to
181 open the connection (without CNAME canonicalization). The client
182 MAY also use (c) a value securely derived from (a) or (b), such
183 as using "secure" DNSSEC [RFC4033] [RFC4034] [RFC4035] validated
186 2. When using email service discovery procedure specified in
187 [RFC6186], the client MUST also use the domain portion of the
188 user's email address as another "reference identifier" to compare
189 against an SRV-ID identifier in the server certificate.
191 The rules and guidelines defined in [RFC6125] apply to an email
192 server certificate with the following supplemental rules:
194 1. Support for the DNS-ID identifier type (subjectAltName of dNSName
195 type [RFC5280]) is REQUIRED in email client software
198 2. Support for the SRV-ID identifier type (subjectAltName of SRVName
199 type [RFC4985]) is REQUIRED for email client software
200 implementations that support [RFC6186]. A list of SRV-ID types
201 for email services is specified in [RFC6186]. For the
202 ManageSieve protocol, the service name "sieve" is used.
204 3. A URI-ID identifier type (subjectAltName of
205 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by
206 clients for server verification, as URI-IDs were not historically
209 4. For backward compatibility with deployed software, a CN-ID
210 identifier type (CN attribute from the subject name, see
211 [RFC6125]) MAY be used for server identity verification.
213 5. Email protocols allow use of certain wildcards in identifiers
214 presented by email servers. The "*" wildcard character MAY be
215 used as the left-most name component of a DNS-ID or CN-ID in the
216 certificate. For example, a DNS-ID of "*.example.com" would
217 match "a.example.com", "foo.example.com", etc., but would not
218 match "example.com". Note that the wildcard character MUST NOT
219 be used as a fragment of the left-most name component (e.g.,
220 "*oo.example.com", "f*o.example.com", or "foo*.example.com").
226Melnikov Standards Track [Page 4]
228RFC 7817 TLS Server Identity Check for Email March 2016
2314. Compliance Checklist for Certification Authorities
233 1. CAs MUST support issuance of server certificates with a DNS-ID
234 identifier type (subjectAltName of dNSName type [RFC5280]).
235 (Note that some DNS-IDs may refer to domain portions of email
236 addresses, so they might not have corresponding A/AAAA DNS
239 2. CAs MUST support issuance of server certificates with an SRV-ID
240 identifier type (subjectAltName of SRVName type [RFC4985]) for
241 each type of email service. See Section 4.1 for more discussion
242 on what this means for CAs.
244 3. For backward compatibility with a deployed client base, CAs MUST
245 support issuance of server certificates with a CN-ID identifier
246 type (CN attribute from the subject name, see [RFC6125]).
248 4. CAs MAY allow "*" (wildcard) as the left-most name component of a
249 DNS-ID or CN-ID in server certificates it issues.
2514.1. Notes on Handling of Delegated Email Services by Certification
254 [RFC6186] provides an easy way for organizations to autoconfigure
255 email clients. It also allows for delegation of email services to an
256 email hosting provider. When connecting to such delegated hosting
257 service, an email client that attempts to verify TLS server identity
258 needs to know that if it connects to "imap.hosting.example.net", such
259 server is authorized to provide email access for an email such as
260 alice@example.org. In absence of SRV-IDs, users of compliant email
261 clients would be forced to manually confirm exceptions because the
262 TLS server certificate verification procedures specified in this
263 document would result in failure to match the TLS server certificate
264 against the expected domain(s). One way to provide such
265 authorization is for the TLS certificate for
266 "imap.hosting.example.net" to include SRV-ID(s) (or a DNS-ID) for the
267 "example.org" domain. Note that another way is for DNS Service
268 Record (SRV) lookups to be protected by DNSSEC, but this solution
269 depends on ubiquitous use of DNSSEC and availability of DNSSEC-aware
270 APIs and thus is not discussed in this document. A future update to
271 this document might rectify this.
273 A CA that receives a Certificate Signing Request containing multiple
274 unrelated DNS-IDs and/or SRV-IDs (e.g., a DNS-ID of "example.org" and
275 a DNS-ID of "example.com") needs to verify that the entity that
276 supplied such Certificate Signing Request is authorized to provide
277 email service for all requested domains.
282Melnikov Standards Track [Page 5]
284RFC 7817 TLS Server Identity Check for Email March 2016
287 The ability to issue certificates that contain an SRV-ID (or a DNS-ID
288 for the domain part of email addresses) implies the ability to verify
289 that entities requesting them are authorized to run email service for
290 these SRV-IDs/DNS-IDs. In particular, CAs that can't verify such
291 authorization (whether for a particular domain or in general) MUST
292 NOT include such email SRV-IDs/DNS-IDs in certificates they issue.
293 This document doesn't specify exact mechanism(s) that can be used to
294 achieve this. However, a few special case recommendations are listed
297 A CA willing to sign a certificate containing a particular DNS-ID
298 SHOULD also support signing a certificate containing one or more of
299 the email SRV-IDs for the same domain because the SRV-ID effectively
300 provides more restricted access to an email service for the domain
301 (as opposed to unrestricted use of any services for the same domain,
302 as specified by the DNS-ID).
304 A CA that also provides DNS service for a domain can use DNS
305 information to validate SRV-IDs/DNS-IDs for the domain.
307 A CA that is also a Mail Service Provider for a hosted domain can use
308 that knowledge to validate SRV-IDs/DNS-IDs for the domain.
3105. Compliance Checklist for Mail Service Providers and Certificate
311 Signing Request Generation Tools
313 Mail Service Providers and Certificate Signing Request generation
316 1. MUST include the DNS-ID identifier type in Certificate Signing
317 Requests for the host name(s) where the email server(s) are
318 running. They SHOULD include the DNS-ID identifier type in
319 Certificate Signing Requests for the domain portion of served
322 2. MUST include the SRV-ID identifier type for each type of email
323 service in Certificate Signing Requests if the email services
324 provided are discoverable using DNS SRV as specified in
327 3. SHOULD include the CN-ID identifier type for the host name where
328 the email server(s) is running in Certificate Signing Requests
329 for backward compatibility with deployed email clients. (Note, a
330 certificate can only include a single CN-ID, so if a mail service
331 is running on multiple hosts, either each host has to use
332 different certificate with its own CN-ID, a single certificate
333 with multiple DNS-IDs, or a single certificate with wildcard in a
338Melnikov Standards Track [Page 6]
340RFC 7817 TLS Server Identity Check for Email March 2016
343 4. MAY include "*" (wildcard) as the left-most name component of a
344 DNS-ID or CN-ID in Certificate Signing Requests.
3465.1. Notes on Hosting Multiple Domains
348 A server that hosts multiple domains needs to do one of the following
349 (or some combination thereof):
351 1. Use DNS SRV records to redirect each hosted email service to a
352 fixed domain, deploy TLS certificate(s) for that single domain,
353 and instruct users to configure their clients with appropriate
354 pinning (unless the SRV records can always be obtained via
355 DNSSEC). Some email clients come with preloaded lists of pinned
356 certificates for some popular domains; this can avoid the need
357 for manual confirmation.
359 2. Use a single TLS certificate that includes a complete list of all
360 the domains it is serving.
362 3. Serve each domain on its own IP/port, using separate TLS
363 certificates on each IP/port.
365 4. Use the Server Name Indication (SNI) TLS extension [RFC6066] to
366 select the right certificate to return during TLS negotiation.
367 Each domain has its own TLS certificate in this case.
369 Each of these deployment choices have their scaling disadvantages
370 when the list of domains changes. Use of DNS SRV without an SRV-ID
371 requires manual confirmation from users. While preloading pinned
372 certificates avoids the need for manual confirmation, this
373 information can get stale quickly or would require support for a new
374 mechanism for distributing preloaded pinned certificates. A single
375 certificate (the second choice) requires that when a domain is added,
376 then a new Certificate Signing Request that includes a complete list
377 of all the domains needs to be issued and passed to a CA in order to
378 generate a new certificate. A separate IP/port can avoid
379 regenerating the certificate but requires more transport layer
380 resources. Use of TLS SNI requires each email client to use it.
382 Several Mail Service Providers host hundreds and even thousands of
383 domains. This document, as well as its predecessors, RFCs 2595,
384 3207, 3501, and 5804, don't address scaling issues caused by use of
385 TLS in multi-tenanted environments. Further work is needed to
386 address this issue, possibly using DNSSEC or something like PKIX over
387 Secure HTTP (POSH) [RFC7711].
394Melnikov Standards Track [Page 7]
396RFC 7817 TLS Server Identity Check for Email March 2016
401 Consider an IMAP-accessible email server that supports both IMAP and
402 IMAP-over-TLS (IMAPS) at the host "mail.example.net" servicing email
403 addresses of the form "user@example.net". A certificate for this
404 service needs to include DNS-IDs of "example.net" (because it is the
405 domain portion of emails) and "mail.example.net" (this is what a user
406 of this server enters manually if not using [RFC6186]). It might
407 also include a CN-ID of "mail.example.net" for backward compatibility
408 with deployed infrastructure.
410 Consider the IMAP-accessible email server from the previous paragraph
411 that is additionally discoverable via DNS SRV lookups in domain
412 "example.net" (using DNS SRV records "_imap._tcp.example.net" and
413 "_imaps._tcp.example.net"). In addition to the DNS-ID/CN-ID identity
414 types specified above, a certificate for this service also needs to
415 include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the
416 IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port).
417 See [RFC6186] for more details. (Note that unlike DNS SRV there is
418 no "_tcp" component in SRV-IDs).
420 Consider the IMAP-accessible email server from the first paragraph
421 that is running on a host also known as "mycompany.example.com". In
422 addition to the DNS-ID identity types specified above, a certificate
423 for this service also needs to include a DNS-ID of
424 "mycompany.example.com" (this is what a user of this server enters
425 manually if not using [RFC6186]). It might also include a CN-ID of
426 "mycompany.example.com" instead of the CN-ID "mail.example.net" for
427 backward compatibility with deployed infrastructure. (This is so,
428 because a certificate can only include a single CN-ID)
430 Consider an SMTP Submission server at the host "submit.example.net"
431 servicing email addresses of the form "user@example.net" and
432 discoverable via DNS SRV lookups in domain "example.net" (using DNS
433 SRV record "_submission._tcp.example.net"). A certificate for this
434 service needs to include SRV-IDs of "_submission.example.net" (see
435 [RFC6186]) along with DNS-IDs of "example.net" and
436 "submit.example.net". It might also include a CN-ID of
437 "submit.example.net" for backward compatibility with deployed
440 Consider a host "mail.example.net" servicing email addresses of the
441 form "user@example.net" and discoverable via DNS SRV lookups in
442 domain "example.net", which runs SMTP Submission, IMAPS and POP3S
443 (POP3-over-TLS), and ManageSieve services. Each of the servers can
444 use their own certificate specific to their service (see examples
445 above). Alternatively, they can all share a single certificate that
446 would include SRV-IDs of "_submission.example.net",
450Melnikov Standards Track [Page 8]
452RFC 7817 TLS Server Identity Check for Email March 2016
455 "_imaps.example.net", "_pop3s.example.net", and "_sieve.example.net"
456 along with DNS-IDs of "example.net" and "mail.example.net". It might
457 also include a CN-ID of "mail.example.net" for backward compatibility
458 with deployed infrastructure.
4607. Operational Considerations
462 Section 5 covers operational considerations (in particular, use of
463 DNS SRV for autoconfiguration) related to generating TLS certificates
464 for email servers so that they can be successfully verified by email
465 clients. Additionally, Section 5.1 talks about operational
466 considerations related to hosting multiple domains.
4688. Security Considerations
470 The goal of this document is to improve interoperability and thus
471 security of email clients wishing to access email servers over TLS-
472 protected email protocols by specifying a consistent set of rules
473 that email service providers, email client writers, and CAs can use
474 when creating server certificates.
476 The TLS server identity check for email relies on use of trustworthy
477 DNS hostnames when constructing "reference identifiers" that are
478 checked against an email server certificate. Such trustworthy names
479 are either entered manually (for example, if they are advertised on a
480 Mail Service Provider's website), explicitly confirmed by the user
481 (e.g., if they are a target of a DNS SRV lookup), or derived using a
482 secure third party service (e.g., DNSSEC-protected SRV records that
483 are verified by the client or trusted local resolver). Future work
484 in this area might benefit from integration with DNS-Based
485 Authentication of Named Entities (DANE) [RFC6698], but it is not
486 covered by this document.
4909.1. Normative References
492 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
493 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
494 <http://www.rfc-editor.org/info/rfc1939>.
496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
497 Requirement Levels", BCP 14, RFC 2119,
498 DOI 10.17487/RFC2119, March 1997,
499 <http://www.rfc-editor.org/info/rfc2119>.
506Melnikov Standards Track [Page 9]
508RFC 7817 TLS Server Identity Check for Email March 2016
511 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
512 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
513 February 2002, <http://www.rfc-editor.org/info/rfc3207>.
515 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
516 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
517 <http://www.rfc-editor.org/info/rfc3501>.
519 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure
520 Subject Alternative Name for Expression of Service Name",
521 RFC 4985, DOI 10.17487/RFC4985, August 2007,
522 <http://www.rfc-editor.org/info/rfc4985>.
524 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
525 Housley, R., and W. Polk, "Internet X.509 Public Key
526 Infrastructure Certificate and Certificate Revocation List
527 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
528 <http://www.rfc-editor.org/info/rfc5280>.
530 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
531 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
532 July 2010, <http://www.rfc-editor.org/info/rfc5804>.
534 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
535 Extensions: Extension Definitions", RFC 6066,
536 DOI 10.17487/RFC6066, January 2011,
537 <http://www.rfc-editor.org/info/rfc6066>.
539 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
540 Verification of Domain-Based Application Service Identity
541 within Internet Public Key Infrastructure Using X.509
542 (PKIX) Certificates in the Context of Transport Layer
543 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
544 2011, <http://www.rfc-editor.org/info/rfc6125>.
546 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
547 Submission/Access Services", RFC 6186,
548 DOI 10.17487/RFC6186, March 2011,
549 <http://www.rfc-editor.org/info/rfc6186>.
551 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
552 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
553 <http://www.rfc-editor.org/info/rfc6409>.
562Melnikov Standards Track [Page 10]
564RFC 7817 TLS Server Identity Check for Email March 2016
5679.2. Informative References
569 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
570 RFC 2595, DOI 10.17487/RFC2595, June 1999,
571 <http://www.rfc-editor.org/info/rfc2595>.
573 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
574 Resource Identifier (URI): Generic Syntax", STD 66,
575 RFC 3986, DOI 10.17487/RFC3986, January 2005,
576 <http://www.rfc-editor.org/info/rfc3986>.
578 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
579 Rose, "DNS Security Introduction and Requirements",
580 RFC 4033, DOI 10.17487/RFC4033, March 2005,
581 <http://www.rfc-editor.org/info/rfc4033>.
583 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
584 Rose, "Resource Records for the DNS Security Extensions",
585 RFC 4034, DOI 10.17487/RFC4034, March 2005,
586 <http://www.rfc-editor.org/info/rfc4034>.
588 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
589 Rose, "Protocol Modifications for the DNS Security
590 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
591 <http://www.rfc-editor.org/info/rfc4035>.
593 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
594 Specifications: ABNF", STD 68, RFC 5234,
595 DOI 10.17487/RFC5234, January 2008,
596 <http://www.rfc-editor.org/info/rfc5234>.
598 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
599 of Named Entities (DANE) Transport Layer Security (TLS)
600 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
601 2012, <http://www.rfc-editor.org/info/rfc6698>.
603 [RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP
604 (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015,
605 <http://www.rfc-editor.org/info/rfc7711>.
618Melnikov Standards Track [Page 11]
620RFC 7817 TLS Server Identity Check for Email March 2016
623Appendix A. Changes to RFCs 2595, 3207, 3501, and 5804
625 This section lists detailed changes this document applies to RFCs
626 2595, 3207, 3501, and 5804.
628 The entire Section 2.4 of RFC 2595 is replaced with the following
631 During the TLS negotiation, the client checks its understanding of
632 the server identity against the provided server's identity as
633 specified in Section 3 of [RFC7817].
635 The 3rd paragraph (and its subparagraphs) in Section 11.1 of RFC 3501
636 is replaced with the following text:
638 During the TLS negotiation, the IMAP client checks its
639 understanding of the server identity against the provided server's
640 identity as specified in Section 3 of [RFC7817].
642 The 3rd paragraph (and its subparagraphs) in Section 4.1 of RFC 3207
643 is replaced with the following text:
645 During the TLS negotiation, the Submission client checks its
646 understanding of the server identity against the provided server's
647 identity as specified in Section 3 of [RFC7817].
649 Sections 2.2.1 and 2.2.1.1 of RFC 5804 are replaced with the
652 During the TLS negotiation, the ManageSieve client checks its
653 understanding of the server identity against the server's identity
654 as specified in Section 3 of [RFC7817]. When the reference
655 identity is an IP address, the iPAddress subjectAltName SHOULD be
656 used by the client for comparison. The comparison is performed as
657 described in Section 2.2.1.2 of RFC 5804.
674Melnikov Standards Track [Page 12]
676RFC 7817 TLS Server Identity Check for Email March 2016
681 Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ
682 Housley, Alessandro Vesely, Harald Alvestrand, and John Levine for
683 comments on this document.
685 The editor of this document copied lots of text from RFCs 2595 and
686 6125, so the hard work of editors of these documents is appreciated.
693 Hampton, Middlesex TW12 2NP
696 EMail: Alexey.Melnikov@isode.com
730Melnikov Standards Track [Page 13]