idnits 2.17.1 draft-ietf-uta-email-tls-certs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2595, but the abstract doesn't seem to directly say this. It does mention RFC2595 though, so this could be OK. -- The draft header indicates that this document updates RFC5804, but the abstract doesn't seem to directly say this. It does mention RFC5804 though, so this could be OK. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to directly say this. It does mention RFC3501 though, so this could be OK. -- The draft header indicates that this document updates RFC3207, but the abstract doesn't seem to directly say this. It does mention RFC3207 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2595, updated by this document, for RFC5378 checks: 1997-08-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 29, 2015) is 3038 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Updates: 2595, 3207, 3501, 5804 (if December 29, 2015 5 approved) 6 Intended status: Standards Track 7 Expires: July 1, 2016 9 Updated TLS Server Identity Check Procedure for Email Related Protocols 10 draft-ietf-uta-email-tls-certs-09 12 Abstract 14 This document describes TLS server identity verification procedure 15 for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces 16 Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates 17 Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 1, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Email Server Certificate Verification Rules . . . . . . . . . 3 56 4. Compliance Checklist for Certification Authorities . . . . . 5 57 4.1. Notes on handling of delegated email services by 58 Certification Authorities . . . . . . . . . . . . . . . . 5 59 5. Compliance Checklist for Mail Service Providers and 60 Certificate Signing Request generation tools . . . . . . . . 6 61 5.1. Notes on hosting multiple domains . . . . . . . . . . . . 7 62 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Operational Considerations . . . . . . . . . . . . . . . . . 9 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 70 Appendix B. Changes to RFC 2595, RFC 3207, RFC 3501, RFC 5804 . 12 71 Appendix C. Changes since draft-ietf-uta-email-tls-certs-00 . . 13 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is 77 described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] 78 respectively. Each of the documents describes slightly different 79 rules for server certificate identity verification (or doesn't define 80 any rules at all). In reality, email client and server developers 81 implement many of these protocols at the same time, so it would be 82 good to define modern and consistent rules for verifying email server 83 identities using TLS. 85 This document describes the updated TLS server identity verification 86 procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], 87 POP [RFC1939] and ManageSieve [RFC5804] clients. Section 3 of this 88 document replaces Section 2.4 of [RFC2595]. 90 Note that this document doesn't apply to use of TLS in MTA-to-MTA 91 SMTP. 93 This document provides a consistent TLS server identity verification 94 procedure across multiple email related protocols. This should make 95 it easier for Certification Authorities and ISPs to deploy TLS for 96 email use, and would enable email client developers to write more 97 secure code. 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 The following terms or concepts are used through the document: 107 reference identifier: (formally defined in [RFC6125]) One of the 108 domain names that the email client (an SMTP, IMAP, POP3 or 109 ManageSieve client) associates with the target email server. For 110 some identifier types, the identifier also includes an application 111 service type. Reference identifiers are used for performing name 112 checks on server certificates. 114 CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] 115 for details). For convenience, their short definitions from 116 [RFC6125] are listed below: 118 CN-ID = a Relative Distinguished Name (RDN) in the certificate 119 subject field that contains one and only one attribute-type-and- 120 value pair of type Common Name (CN), where the value matches the 121 overall form of a domain name (informally, dot- separated letter- 122 digit-hyphen labels). 124 DNS-ID = a subjectAltName entry of type dNSName 126 SRV-ID = a subjectAltName entry of type otherName whose name form 127 is SRVName 129 URI-ID = a subjectAltName entry of type uniformResourceIdentifier 130 whose value includes both (i) a "scheme" and (ii) a "host" 131 component (or its equivalent) that matches the "reg-name" rule 132 (where the quoted terms represent the associated [RFC5234] 133 productions from [RFC3986]). 135 3. Email Server Certificate Verification Rules 137 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 138 or ManageSieve client) MUST check its understanding of the server 139 identity (client's reference identifiers) against the server's 140 identity as presented in the server Certificate message, in order to 141 prevent man-in-the-middle attacks. This check is only performed 142 after the server certificate passes certification path validation as 143 described in Section 6 of [RFC5280]. Matching is performed according 144 to the rules specified in Section 6 of [RFC6125], including the 145 relative order of matching of different identifier types, 146 "certificate pinning" and the procedure on failure to match. The 147 following inputs are used by the verification procedure used in 148 [RFC6125]: 150 1. For DNS-ID and CN-ID identifier types the client MUST use one or 151 more of the following as "reference identifiers": (a) the domain 152 portion of the user's email address, (b) the hostname it used to 153 open the connection (without CNAME canonicalization). The client 154 MAY also use (c) a value securely derived from (a) or (b), such 155 as using "secure" DNSSEC [RFC4033][RFC4034][RFC4035] validated 156 lookup. 158 2. When using email service discovery procedure specified in 159 [RFC6186] the client MUST also use the domain portion of the 160 user's email address as another "reference identifier" to compare 161 against SRV-ID identifier in the server certificate. 163 The rules and guidelines defined in [RFC6125] apply to an email 164 server certificate, with the following supplemental rules: 166 1. Support for the DNS-ID identifier type (subjectAltName of dNSName 167 type [RFC5280]) is REQUIRED in Email client software 168 implementations. 170 2. Support for the SRV-ID identifier type (subjectAltName of SRVName 171 type [RFC4985]) is REQUIRED for email client software 172 implementations that support [RFC6186]. List of SRV-ID types for 173 email services is specified in [RFC6186]. For the ManageSieve 174 protocol the service name "sieve" is used. 176 3. URI-ID identifier type (subjectAltName of 177 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by 178 clients for server verification, as URI-ID were not historically 179 used for email. 181 4. For backward compatibility with deployed software CN-ID 182 identifier type (CN attribute from the subject name, see 183 [RFC6125]) MAY be used for server identity verification. 185 5. Email protocols allow use of certain wildcards in identifiers 186 presented by email servers. The "*" wildcard character MAY be 187 used as the left-most name component of DNS-ID or CN-ID in the 188 certificate. For example, a DNS-ID of *.example.com would match 189 a.example.com, foo.example.com, etc. but would not match 190 example.com. Note that the wildcard character MUST NOT be used 191 as a fragment of the left-most name component (e.g., 192 *oo.example.com, f*o.example.com, or foo*.example.com). 194 4. Compliance Checklist for Certification Authorities 196 1. CA MUST support issuance of server certificates with DNS-ID 197 identifier type (subjectAltName of dNSName type [RFC5280]). 198 (Note that some DNS-IDs may refer to domain portions of email 199 addresses, so they might not have corresponding A/AAAA DNS 200 records.) 202 2. CA MUST support issuance of server certificates with SRV-ID 203 identifier type (subjectAltName of SRVName type [RFC4985]) for 204 each type of email service. See Section 4.1 for more discussion 205 on what this means for Certification Authorities. 207 3. For backward compatibility with deployed client base, CA MUST 208 support issuance of server certificates with CN-ID identifier 209 type (CN attribute from the subject name, see [RFC6125]). 211 4. CA MAY allow "*" (wildcard) as the left-most name component of 212 DNS-ID or CN-ID in server certificates it issues. 214 4.1. Notes on handling of delegated email services by Certification 215 Authorities 217 [RFC6186] provides an easy way for organizations to autoconfigure 218 email clients. It also allows for delegation of email services to an 219 email hosting provider. When connecting to such delegated hosting 220 service an email client that attempts to verify TLS server identity 221 needs to know that if it connects to imap.hosting.example.net that 222 such server is authorized to provide email access for an email such 223 as alice@example.org. In absence of SRV-IDs, users of compliant 224 email clients would be forced to manually confirm exception, because 225 the TLS server certificate verification procedures specified in this 226 document would result in failure to match the TLS server certificate 227 against the expected domain(s). One way to provide such 228 authorization is for the TLS certificate for imap.hosting.example.net 229 to include SRV-ID(s) (or DNS-ID) for the example.org domain. 230 (Another way is for DNS SRV lookups to be protected by DNSSEC, but 231 this solution depends on ubiquitous use of DNSSEC and availability of 232 DNSSEC-aware APIs and thus is not discussed in this document. A 233 future update to this document might rectify this.) 235 A certification authority that receives a Certificate Signing Request 236 containing multiple unrelated DNS-IDs and/or SRV-IDs (e.g. DNS-ID of 237 example.org and DNS-ID of example.com) needs to verify that the 238 entity that supplied such Certificate Signing Request is authorized 239 to provide email service for all requested domains. 241 The ability to issue certificates that contain an SRV-ID (or a DNS-ID 242 for the domain part of email addresses) implies the ability to verify 243 that entities requesting them are authorized to run email service for 244 these SRV-IDs/DNS-IDs. In particular, certification authorities that 245 can't verify such authorization (whether for a particular domain or 246 in general) MUST NOT include such email SRV-IDs/DNS-IDs in 247 certificates they issue. This document doesn't specify exact 248 mechanism(s) that can be used to achieve this. However, a few 249 special case recommendations are listed below. 251 A certification authority willing to sign a certificate containing a 252 particular DNS-ID SHOULD also support signing a certificate 253 containing one or more of email SRV-IDs for the same domain, because 254 the SRV-ID effectively provides more restricted access to an email 255 service for the domain (as opposed to unrestricted use of any 256 services for the same domain, as specified by DNS-ID). 258 A certification authority which also provides DNS service for a 259 domain can use DNS information to validate SRV-IDs/DNS-IDs for the 260 domain. 262 A certification authority which is also a Mail Service Provider for a 263 hosted domain can use that knowdledge to validate SRV-IDs/DNS-IDs for 264 the domain. 266 5. Compliance Checklist for Mail Service Providers and Certificate 267 Signing Request generation tools 269 Mail Service Providers and Certificate Signing Request generation 270 tools 272 1. MUST include the DNS-ID identifier type in Certificate Signing 273 Requests for the host name(s) where the email server(s) are 274 running. They SHOULD include the DNS-ID identifier type in 275 Certificate Signing Requests for the domain portion of served 276 email addresses. 278 2. If the email services provided are discoverable using DNS SRV as 279 specified in [RFC6186], the Mail Service Provider MUST include 280 the SRV-ID identifier type for each type of email service in 281 Certificate Signing Requests. 283 3. SHOULD include CN-ID identifier type for the host name where the 284 email server(s) is running in Certificate Signing Requests for 285 backward compatibility with deployed email clients. (Note, a 286 certificate can only include a single CN-ID, so if a mail service 287 is running on multiple hosts, either each host has to use 288 different certificate with its own CN-ID, a single certificate 289 with multiple DNS-IDs, or a single certificate with wildcard in 290 CN-ID can be used). 292 4. MAY include "*" (wildcard) as the left-most name component of 293 DNS-ID or CN-ID in Certificate Signing Requests. 295 5.1. Notes on hosting multiple domains 297 A server that hosts multiple domains needs to do one of the following 298 (or some combination thereof): 300 1. Use DNS SRV records to redirect each hosted email service to a 301 fixed domain, deploy TLS certificate(s) for that single domain, 302 and instruct users to configure their clients with appropriate 303 pinning (unless the SRV records can always be obtained via 304 DNSSEC). Some email clients come with preloaded list of pinned 305 certificates for some popular domains, which can avoid the need 306 for manual confirmation. 308 2. Use a single TLS certificate that includes a complete list of all 309 the domains it is serving. 311 3. Serve each domain on its own IP/port, using separate TLS 312 certificates on each IP/port. 314 4. Use Server Name Indication (SNI) TLS extension [RFC6066] to 315 select the right certificate to return during TLS negotiation. 316 Each domain has its own TLS certificate in this case. 318 Each of these deployment choices have their scaling disadvantages 319 when the list of domains changes. Use of DNS SRV without SRV-ID 320 requires manual confirmation from users. While preloading pinned 321 certificates avoids the need for manual confirmation, this 322 information can get stale quickly or would require support for a new 323 mechanism for distributing preloaded pinned certificates. A single 324 certificate (the second choice) requires that when a domain is added, 325 then a new Certificate Signing Request that includes a complete list 326 of all the domains needs to be issued and passed to a CA in order to 327 generate a new certificate. Separate IP/port can avoid regenerating 328 the certificate, but requires more transport layer resources. Use of 329 TLS SNI requires each email client to use it. 331 Several Mail Service Providers host hundreds and even thousands of 332 domains. This document, as well as its predecessors RFC 2595, RFC 333 3207, RFC 3501 and RFC 5804 don't address scaling issues caused by 334 use of TLS in multi-tenanted environments. Further work is needed to 335 address this issue, possibly using DNSSEC or something like POSH 336 [RFC7711]. 338 6. Examples 340 Consider an IMAP-accessible email server which supports both IMAP and 341 IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email 342 addresses of the form "user@example.net". A certificate for this 343 service needs to include DNS-IDs of "example.net" (because it is the 344 domain portion of emails) and "mail.example.net" (this is what a user 345 of this server enters manually, if not using [RFC6186]). It might 346 also include CN-ID of "mail.example.net" for backward compatibility 347 with deployed infrastructure. 349 Consider the IMAP-accessible email server from the previous paragraph 350 which is additionally discoverable via DNS SRV lookups in domain 351 "example.net" (DNS SRV records "_imap._tcp.example.net" and 352 "_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity 353 types specified above, a certificate for this service also needs to 354 include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the 355 IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). 356 See [RFC6186] for more details. (Note that unlike DNS SRV there is 357 no "_tcp" component in SRV-IDs). 359 Consider the IMAP-accessible email server from the first paragraph 360 which is running on a host also known as "mycompany.example.com". In 361 addition to DNS-ID identity types specified above, a certificate for 362 this service also needs to include DNS-ID of "mycompany.example.com" 363 (this is what a user of this server enters manually, if not using 364 [RFC6186]). It might also include CN-ID of "mycompany.example.com" 365 instead of the CN-ID "mail.example.net" for backward compatibility 366 with deployed infrastructure. (This is so, because a certificate can 367 only include a single CN-ID) 369 Consider an SMTP Submission server at the host "submit.example.net" 370 servicing email addresses of the form "user@example.net" and 371 discoverable via DNS SRV lookups in domain "example.net" (DNS SRV 372 records "_submission._tcp.example.net"). A certificate for this 373 service needs to include SRV-IDs of "_submission.example.net" (see 374 [RFC6186]) along with DNS-IDs of "example.net" and 375 "submit.example.net". It might also include CN-ID of 376 "submit.example.net" for backward compatibility with deployed 377 infrastructure. 379 Consider a host "mail.example.net" servicing email addresses of the 380 form "user@example.net" and discoverable via DNS SRV lookups in 381 domain "example.net", which runs SMTP Submission, IMAPS and POP3S 382 (POP3-over-TLS) and ManageSieve services. Each of the servers can 383 use their own certificate specific to their service (see examples 384 above). Alternatively they can all share a single certificate that 385 would include SRV-IDs of "_submission.example.net", 386 "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" 387 along with DNS-IDs of "example.net" and "mail.example.net". It might 388 also include CN-ID of "mail.example.net" for backward compatibility 389 with deployed infrastructure. 391 7. Operational Considerations 393 Section 5 covers operational considerations (in particular use of DNS 394 SRV for autoconfiguration) related to generating TLS certificiates 395 for email servers so that they can be successfully verified by email 396 clients. Additionally, Section 5.1 talks about operational 397 considerations related to hosting multiple domains. 399 8. IANA Considerations 401 This document doesn't require any action from IANA. 403 9. Security Considerations 405 The goal of this document is to improve interoperability and thus 406 security of email clients wishing to access email servers over TLS 407 protected email protocols, by specifying a consistent set of rules 408 that email service providers, email client writers and Certification 409 Authorities can use when creating server certificates. 411 TLS Server Identity Check for Email relies on use of trustworthy DNS 412 hostnames when constructing "reference identifiers" that are checked 413 against an email server certificate. Such trustworthy names are 414 either entered manually (for example if they are advertised on a Mail 415 Service Provider's website), explicitly confirmed by the user (e.g. 416 if they are a target of a DNS SRV lookup) or derived using a secure 417 third party service (e.g. DNSSEC-protected SRV records which are 418 verified by the client or trusted local resolver). Future work in 419 this area might benefit from integration with DANE [RFC6698], but it 420 is not covered by this document. 422 10. References 424 10.1. Normative References 426 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 427 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 428 . 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 436 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 437 February 2002, . 439 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 440 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 441 . 443 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 444 Subject Alternative Name for Expression of Service Name", 445 RFC 4985, DOI 10.17487/RFC4985, August 2007, 446 . 448 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 449 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 450 July 2010, . 452 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 453 Housley, R., and W. Polk, "Internet X.509 Public Key 454 Infrastructure Certificate and Certificate Revocation List 455 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 456 . 458 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 459 Extensions: Extension Definitions", RFC 6066, 460 DOI 10.17487/RFC6066, January 2011, 461 . 463 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 464 Verification of Domain-Based Application Service Identity 465 within Internet Public Key Infrastructure Using X.509 466 (PKIX) Certificates in the Context of Transport Layer 467 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 468 2011, . 470 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 471 Submission/Access Services", RFC 6186, 472 DOI 10.17487/RFC6186, March 2011, 473 . 475 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 476 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 477 . 479 10.2. Informative References 481 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 482 RFC 2595, DOI 10.17487/RFC2595, June 1999, 483 . 485 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 486 Resource Identifier (URI): Generic Syntax", STD 66, 487 RFC 3986, DOI 10.17487/RFC3986, January 2005, 488 . 490 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 491 Rose, "DNS Security Introduction and Requirements", 492 RFC 4033, DOI 10.17487/RFC4033, March 2005, 493 . 495 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 496 Rose, "Resource Records for the DNS Security Extensions", 497 RFC 4034, DOI 10.17487/RFC4034, March 2005, 498 . 500 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 501 Rose, "Protocol Modifications for the DNS Security 502 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 503 . 505 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 506 Specifications: ABNF", STD 68, RFC 5234, 507 DOI 10.17487/RFC5234, January 2008, 508 . 510 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 511 of Named Entities (DANE) Transport Layer Security (TLS) 512 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 513 2012, . 515 [RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 516 (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, 517 . 519 Appendix A. Acknowledgements 521 Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ 522 Housley, Alessandro Vesely, Harald Alvestrand and John Levine for 523 comments on this document. 525 The editor of this document copied lots of text from RFC 2595 and RFC 526 6125, so the hard work of editors of these document is appreciated. 528 Appendix B. Changes to RFC 2595, RFC 3207, RFC 3501, RFC 5804 530 This section lists detailed changes this document applies to RFC 531 2595, RFC 3207, RFC 3501 and RFC 5804. 533 The entire Section 2.4 of RFC 2595 is replaced with the following 534 text: 536 During the TLS negotiation, the client checks its understanding of 537 the server identity against the provided server's identity as 538 specified in Section 3. 540 The 3rd paragraph (and its subparagraphs) in Section 11.1 of RFC 3501 541 is replaced with the following text: 543 During the TLS negotiation, the IMAP client checks its 544 understanding of the server identity against the provided server's 545 identity as specified in Section 3. 547 The 3rd paragraph (and its subparagraphs) in Section 4.1 of RFC 3207 548 is replaced with the following text: 550 During the TLS negotiation, the Submission client checks its 551 understanding of the server identity against the provided server's 552 identity as specified in Section 3. 554 Sections 2.2.1 and 2.2.1.1 of RFC 5804 are replaced with the 555 following text: 557 During the TLS negotiation, the ManageSieve client checks its 558 understanding of the server identity against the server's identity 559 as specified in Section 3. When the reference identity is an IP 560 address, the iPAddress subjectAltName SHOULD be used by the client 561 for comparison. The comparison is performed as described in 562 Section 2.2.1.2 of RFC 5804. 564 Appendix C. Changes since draft-ietf-uta-email-tls-certs-00 566 [[Note to RFC Editor: Please delete this section before publication]] 568 Added another example, clarified that subjectAltName and DNS SRV are 569 using slightly different syntax. 571 As any certificate can only include one CN-ID, corrected examples. 573 Split rules to talk seperately about requirements on MUAs, CAs and 574 MSPs/CSR generation tools. 576 Updated Introduction section. 578 Author's Address 580 Alexey Melnikov 581 Isode Ltd 582 14 Castle Mews 583 Hampton, Middlesex TW12 2NP 584 UK 586 EMail: Alexey.Melnikov@isode.com