idnits 2.17.1 draft-ietf-uta-email-tls-certs-08.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 : ---------------------------------------------------------------------------- -- 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 17, 2015) is 3052 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 (~~), 1 warning (==), 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 17, 2015 5 approved) 6 Intended status: Standards Track 7 Expires: June 19, 2016 9 Updated TLS Server Identity Check Procedure for Email Related Protocols 10 draft-ietf-uta-email-tls-certs-08 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 June 19, 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 SRV-ID by Certification Authorities 5 58 5. Compliance Checklist for Mail Service Providers and 59 Certificate Signing Request generation tools . . . . . . . . 6 60 5.1. Notes on hosting multiple domains . . . . . . . . . . . . 6 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Operational Considerations . . . . . . . . . . . . . . . . . 8 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 10.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is 75 described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] 76 respectively. Each of the documents describes slightly different 77 rules for server certificate identity verification (or doesn't define 78 any rules at all). In reality, email client and server developers 79 implement many of these protocols at the same time, so it would be 80 good to define modern and consistent rules for verifying email server 81 identities using TLS. 83 This document describes the updated TLS server identity verification 84 procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], 85 POP [RFC1939] and ManageSieve [RFC5804] clients. Section 3 of this 86 document replaces Section 2.4 of [RFC2595]. 88 Note that this document doesn't apply to use of TLS in MTA-to-MTA 89 SMTP. 91 This document provides a consistent TLS server identity verification 92 procedure across multiple email related protocols. This should make 93 it easier for Certification Authorities and ISPs to deploy TLS for 94 email use, and would enable email client developers to write more 95 secure code. 97 2. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 The following terms or concepts are used through the document: 105 reference identifier: (formally defined in [RFC6125]) One of the 106 domain names that the email client (an SMTP, IMAP, POP3 or 107 ManageSieve client) associates with the target email server. For 108 some identifier types, the identifier can also include an 109 application service type for performing name checks on the server 110 certificate. When name checks are applicable, at least one of the 111 reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or 112 if none are present the [RFC6125] CN-ID) of the server 113 certificate. 115 CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] 116 for details). For convenience, their short definitions from 117 [RFC6125] are listed below: 119 CN-ID = a Relative Distinguished Name (RDN) in the certificate 120 subject field that contains one and only one attribute-type-and- 121 value pair of type Common Name (CN), where the value matches the 122 overall form of a domain name (informally, dot- separated letter- 123 digit-hyphen labels). 125 DNS-ID = a subjectAltName entry of type dNSName 127 SRV-ID = a subjectAltName entry of type otherName whose name form 128 is SRVName 130 URI-ID = a subjectAltName entry of type uniformResourceIdentifier 131 whose value includes both (i) a "scheme" and (ii) a "host" 132 component (or its equivalent) that matches the "reg-name" rule 133 (where the quoted terms represent the associated [RFC5234] 134 productions from [RFC3986]). 136 3. Email Server Certificate Verification Rules 138 During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 139 or ManageSieve client) MUST check its understanding of the server 140 hostname against the server's identity as presented in the server 141 Certificate message, in order to prevent man-in-the-middle attacks. 142 This check is only performed after the server certificate passes 143 certification path validation as described in Section 6 of [RFC5280]. 144 Matching is performed according to the rules specified in Section 6 145 of [RFC6125], including "certificate pinning" and the procedure on 146 failure to match. The following inputs are used by the verification 147 procedure used in [RFC6125]: 149 1. For DNS-ID and CN-ID identifier types the client MUST use one or 150 more of the following as "reference identifiers": (a) the domain 151 portion of the user's email address, (b) the hostname it used to 152 open the connection (without CNAME canonicalization). The client 153 MAY also use (c) a value securely derived from (a) or (b), such 154 as using "secure" DNSSEC [RFC4033][RFC4034][RFC4035] validated 155 lookup. 157 2. When using email service discovery procedure specified in 158 [RFC6186] the client MUST also use the domain portion of the 159 user's email address as another "reference identifier" to compare 160 against SRV-ID identifier in the server certificate. 162 The rules and guidelines defined in [RFC6125] apply to an email 163 server certificate, with the following supplemental rules: 165 1. Support for the DNS-ID identifier type (subjectAltName of dNSName 166 type [RFC5280]) is REQUIRED in Email client software 167 implementations. 169 2. Support for the SRV-ID identifier type (subjectAltName of SRVName 170 type [RFC4985]) is REQUIRED for email client software 171 implementations that support [RFC6186]. List of SRV-ID types for 172 email services is specified in [RFC6186]. For the ManageSieve 173 protocol the service name "sieve" is used. 175 3. URI-ID identifier type (subjectAltName of 176 uniformResourceIdentifier type [RFC5280]) MUST NOT be used by 177 clients for server verification, as URI-ID were not historically 178 used for email. 180 4. For backward compatibility with deployed software CN-ID 181 identifier type (CN attribute from the subject name, see 182 [RFC6125]) MAY be used for server identity verification. 184 5. Email protocols allow use of certain wildcards in identifiers 185 presented by email servers. The "*" wildcard character MAY be 186 used as the left-most name component of DNS-ID or CN-ID in the 187 certificate. For example, a DNS-ID of *.example.com would match 188 a.example.com, foo.example.com, etc. but would not match 189 example.com. Note that the wildcard character MUST NOT be used 190 as a fragment of the left-most name component (e.g., 191 *oo.example.com, f*o.example.com, or foo*.example.com). 193 4. Compliance Checklist for Certification Authorities 195 1. CA MUST support issuance of server certificates with DNS-ID 196 identifier type (subjectAltName of dNSName type [RFC5280]). 198 2. CA MUST support issuance of server certificates with SRV-ID 199 identifier type (subjectAltName of SRVName type [RFC4985]) for 200 each type of email service. See Section 4.1 for more discussion 201 on what this means for Certification Authorities. 203 3. For backward compatibility with deployed client base, CA MUST 204 support issuance of server certificates with CN-ID identifier 205 type (CN attribute from the subject name, see [RFC6125]). 207 4. CA MAY allow "*" (wildcard) as the left-most name component of 208 DNS-ID or CN-ID in server certificates it issues. 210 4.1. Notes on handling of SRV-ID by Certification Authorities 212 [RFC6186] provides an easy way for organizations to autoconfigure 213 email clients. It also allows for delegation of email services to an 214 email hosting provider. When connecting to such delegated hosting 215 service an email client that attempts to verify TLS server identity 216 needs to know that if it connects to imap.hosting.example.net that 217 such server is authorized to provide email access for an email such 218 as alice@example.org. In absence of SRV-IDs, users of compliant 219 email clients would be forced to manually confirm exception, because 220 the TLS server certificate verification procedures specified in this 221 document would result in failure to match the TLS server certificate 222 against the expected domain(s). One way to provide such 223 authorization is for the TLS certificate for imap.hosting.example.net 224 to include SRV-ID(s) (or DNS-ID) for the example.org domain. 225 (Another way is for SRV lookups to be protected by DNSSEC, but this 226 solution depends on DNSSEC and thus is not discussed in this 227 document. A future update to this document might rectify this.) 229 The ability to issue certificates that contain SRV-ID implies the 230 ability to verify that entities requesting them are authorized to run 231 email service for these SRV-IDs. In particular, certification 232 authorities that can't verify such authorization MUST NOT include 233 email SRV-IDs in certificates they issue. This document doesn't 234 specify exact mechanism(s) that can be used to achieve this. 235 However, a few special case recommendations are listed below. 237 A certification authority willing to sign a certificate containing a 238 particular DNS-ID SHOULD also support signing a certificate 239 containing one or more of email SRV-IDs for the same domain, because 240 the SRV-ID effectively provides more restricted access to an email 241 service for the domain (as opposed to unrestricted use of any 242 services for the same domain, as specified by DNS-ID). 244 A certification authority which also provides DNS service for a 245 domain can use DNS information to validate SRV-IDs for the domain. 247 5. Compliance Checklist for Mail Service Providers and Certificate 248 Signing Request generation tools 250 1. MUST include the DNS-ID identifier type in Certificate Signing 251 Requests for the host name(s) where the email server(s) are 252 running. SHOULD include the DNS-ID identifier type in 253 Certificate Signing Requests for the domain portion of served 254 email addresses. 256 2. If the email services provided are discoverable using DNS SRV as 257 specified in [RFC6186], the Mail Service Provider MUST include 258 the SRV-ID identifier type for each type of email service in 259 Certificate Signing Requests. 261 3. SHOULD include CN-ID identifier type for the host name where the 262 email server(s) is running in Certificate Signing Requests for 263 backward compatibility with deployed email clients. (Note, a 264 certificate can only include a single CN-ID, so if a mail service 265 is running on multiple hosts, either each host has to use 266 different certificate with its own CN-ID, a single certificate 267 with multiple DNS-IDs, or a single certificate with wildcard in 268 CN-ID can be used). 270 4. MAY include "*" (wildcard) as the left-most name component of 271 DNS-ID or CN-ID in Certificate Signing Requests. 273 5.1. Notes on hosting multiple domains 275 A server that hosts multiple domains needs to do one of the following 276 (or some combination thereof): 278 1. Use DNS SRV records to redirect each hosted email service to a 279 fixed domain, deploy TLS certificate(s) for that single domain, 280 and instruct users to configure their clients with appropriate 281 pinning (unless the SRV records can always be obtained via 282 DNSSEC). Some email clients come with preloaded list of pinned 283 certificates for some popular domains, which can avoid the need 284 for manual confirmation. 286 2. Use a single TLS certificate that includes a complete list of all 287 the domains it is serving. 289 3. Serve each domain on its own IP/port, using separate TLS 290 certificates on each IP/port. 292 4. Use Server Name Indication (SNI) TLS extension [RFC6066] to 293 select the right certificate to return during TLS negotiation. 294 Each domain has its own TLS certificate in this case. 296 Each of these deployment choices have their scaling disadvantages 297 when the list of domains changes. Use of DNS SRV without SRV-ID 298 requires manual confirmation from users. While preloading pinned 299 certificates avoids the need for manual confirmation, this 300 information can get stale quickly or would require support for a new 301 mechanism for distributing preloaded pinned certificates. A single 302 certificate (the second choice) requires that when a domain is added, 303 then a new Certificate Signing Request that includes a complete list 304 of all the domains needs to be issued and passed to a CA in order to 305 generate a new certificate. Separate IP/port can avoid regenerating 306 the certificate, but requires more transport layer resources. Use of 307 TLS SNI requires each email client to support it. 309 Several Mail Service Providers host hundreds and even thousands of 310 domains. This document, as well as its predecessors RFC 2595, RFC 311 3207, RFC 3501 and RFC 5804 don't address scaling issues caused by 312 use of TLS in multi-tenanted environments. Further work is needed to 313 address this issue, possibly using DNSSEC or something like POSH 314 [RFC7711]. 316 6. Examples 318 Consider an IMAP-accessible email server which supports both IMAP and 319 IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email 320 addresses of the form "user@example.net". A certificate for this 321 service needs to include DNS-IDs of "example.net" (because it is the 322 domain portion of emails) and "mail.example.net" (this is what a user 323 of this server enters manually, if not using [RFC6186]). It might 324 also include CN-ID of "mail.example.net" for backward compatibility 325 with deployed infrastructure. 327 Consider the IMAP-accessible email server from the previous paragraph 328 which is additionally discoverable via DNS SRV lookups in domain 329 "example.net" (DNS SRV records "_imap._tcp.example.net" and 330 "_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity 331 types specified above, a certificate for this service also needs to 332 include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the 333 IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). 334 See [RFC6186] for more details. (Note that unlike DNS SRV there is 335 no "_tcp" component in SRV-IDs). 337 Consider the IMAP-accessible email server from the first paragraph 338 which is running on a host also known as "mycompany.example.com". In 339 addition to DNS-ID identity types specified above, a certificate for 340 this service also needs to include DNS-ID of "mycompany.example.com" 341 (this is what a user of this server enters manually, if not using 342 [RFC6186]). It might also include CN-ID of "mycompany.example.com" 343 instead of the CN-ID "mail.example.net" for backward compatibility 344 with deployed infrastructure. (This is so, because a certificate can 345 only include a single CN-ID) 347 Consider an SMTP Submission server at the host "submit.example.net" 348 servicing email addresses of the form "user@example.net" and 349 discoverable via DNS SRV lookups in domain "example.net" (DNS SRV 350 records "_submission._tcp.example.net"). A certificate for this 351 service needs to include SRV-IDs of "_submission.example.net" (see 352 [RFC6186]) along with DNS-IDs of "example.net" and 353 "submit.example.net". It might also include CN-ID of 354 "submit.example.net" for backward compatibility with deployed 355 infrastructure. 357 Consider a host "mail.example.net" servicing email addresses of the 358 form "user@example.net" and discoverable via DNS SRV lookups in 359 domain "example.net", which runs SMTP Submission, IMAPS and POP3S 360 (POP3-over-TLS) and ManageSieve services. Each of the servers can 361 use their own certificate specific to their service (see examples 362 above). Alternatively they can all share a single certificate that 363 would include SRV-IDs of "_submission.example.net", 364 "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" 365 along with DNS-IDs of "example.net" and "mail.example.net". It might 366 also include CN-ID of "mail.example.net" for backward compatibility 367 with deployed infrastructure. 369 7. Operational Considerations 371 Section 5 covers operational considerations (in particular use of DNS 372 SRV for autoconfiguration) related to generating TLS certificiates 373 for email servers so that they can be successfully verified by email 374 clients. Additionally, Section 5.1 talks about operational 375 considerations related to hosting multiple domains. 377 8. IANA Considerations 379 This document doesn't require any action from IANA. 381 9. Security Considerations 383 The goal of this document is to improve interoperability and thus 384 security of email clients wishing to access email servers over TLS 385 protected email protocols, by specifying a consistent set of rules 386 that email service providers, email client writers and Certification 387 Authorities can use when creating server certificates. 389 TLS Server Identity Check for Email relies on use of trustworthy DNS 390 hostnames when constructing "reference identifiers" that are checked 391 against an email server certificate. Such trustworthy names are 392 either entered manually (for example if they are advertised on a Mail 393 Service Provider's website), explicitly confirmed by the user (e.g. 394 if they are a target of a DNS SRV lookup) or derived using a secure 395 third party service (e.g. DNSSEC-protected SRV records which are 396 verified by the client or trusted local resolver). Future work in 397 this area might benefit from integration with DANE [RFC6698], but it 398 is not covered by this document. 400 10. References 402 10.1. Normative References 404 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 405 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 406 . 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 414 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 415 February 2002, . 417 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 418 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 419 . 421 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 422 Subject Alternative Name for Expression of Service Name", 423 RFC 4985, DOI 10.17487/RFC4985, August 2007, 424 . 426 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 427 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 428 July 2010, . 430 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 431 Housley, R., and W. Polk, "Internet X.509 Public Key 432 Infrastructure Certificate and Certificate Revocation List 433 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 434 . 436 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 437 Verification of Domain-Based Application Service Identity 438 within Internet Public Key Infrastructure Using X.509 439 (PKIX) Certificates in the Context of Transport Layer 440 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 441 2011, . 443 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 444 Submission/Access Services", RFC 6186, 445 DOI 10.17487/RFC6186, March 2011, 446 . 448 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 449 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 450 . 452 10.2. Informative References 454 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 455 RFC 2595, DOI 10.17487/RFC2595, June 1999, 456 . 458 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 459 Resource Identifier (URI): Generic Syntax", STD 66, 460 RFC 3986, DOI 10.17487/RFC3986, January 2005, 461 . 463 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 464 Rose, "DNS Security Introduction and Requirements", 465 RFC 4033, DOI 10.17487/RFC4033, March 2005, 466 . 468 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 469 Rose, "Resource Records for the DNS Security Extensions", 470 RFC 4034, DOI 10.17487/RFC4034, March 2005, 471 . 473 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 474 Rose, "Protocol Modifications for the DNS Security 475 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 476 . 478 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 479 Specifications: ABNF", STD 68, RFC 5234, 480 DOI 10.17487/RFC5234, January 2008, 481 . 483 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 484 Extensions: Extension Definitions", RFC 6066, 485 DOI 10.17487/RFC6066, January 2011, 486 . 488 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 489 of Named Entities (DANE) Transport Layer Security (TLS) 490 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 491 2012, . 493 [RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 494 (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, 495 . 497 Appendix A. Acknowledgements 499 Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ 500 Housley, Alessandro Vesely, Harald Alvestrand and John Levine for 501 comments on this document. 503 The editor of this document copied lots of text from RFC 2595 and RFC 504 6125, so the hard work of editors of these document is appreciated. 506 Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 508 [[Note to RFC Editor: Please delete this section before publication]] 510 Added another example, clarified that subjectAltName and DNS SRV are 511 using slightly different syntax. 513 As any certificate can only include one CN-ID, corrected examples. 515 Split rules to talk seperately about requirements on MUAs, CAs and 516 MSPs/CSR generation tools. 518 Updated Introduction section. 520 Author's Address 522 Alexey Melnikov 523 Isode Ltd 524 14 Castle Mews 525 Hampton, Middlesex TW12 2NP 526 UK 528 EMail: Alexey.Melnikov@isode.com