<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

<!--////Needs fixing: updates="2595, 3207, 3501, 5804"-->
<rfc ipr="trust200902" category="std"
     docName="draft-melnikov-uta-dnssec-email-tls-certs-00">
  <front>
    <title abbrev="DNSSEC-based TLS Server Identity Check for Email">
      Updated DNSSEC-based TLS Server Identity Check Procedure for Email Related Protocols
    </title>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization>Isode Ltd</organization>
      <address>
	      <postal>
	        <street>14 Castle Mews</street>
	        <city>Hampton</city>
	        <region>Middlesex</region>
	        <code>TW12 2NP</code>
	        <country>UK</country>
	      </postal>
	      <email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
    
    <date year="2016" />
    
    <keyword>SMTP</keyword>
    <keyword>Submission</keyword>
    <keyword>IMAP</keyword>
    <keyword>POP</keyword>
    <keyword>ManageSieve</keyword>

    <abstract>
      <t>
        This document describes DNSSEC-based TLS server identity verification procedure for SMTP Submission,
        IMAP, POP and ManageSieve clients.
        <!--
        It replaces Section 2.4 of RFC 2595,
        updates Section 4.1 of RFC 3207, updates Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.
        -->
      </t>
    </abstract>
    
  </front>
  <middle>
      
    <section title="Introduction">

	<t>
   Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is described in <xref target="RFC3207"/>,
   <xref target="RFC3501"/>, <xref target="RFC2595"/> and <xref target="RFC5804"/> respectively.
   Each of the documents describes slightly different rules for server certificate identity verification
   (or doesn't define any rules at all). In reality, email client and server developers implement many of
   these protocols at the same time, so it would be good to define modern and consistent rules for verifying
   email server identities using TLS.
	</t>

	<t>
	 This document describes the updated TLS server identity verification procedure
	 for SMTP Submission <xref target="RFC6409"/> <xref target="RFC3207"/>, IMAP <xref target="RFC3501"/>,
	 POP <xref target="RFC1939"/> and ManageSieve <xref target="RFC5804"/> clients.
	 It replaces Section 2.4 of RFC 2595.
   <!--////More work is needed on what exactly is updated, etc-->
	</t>

	<t>
	 Note that this document doesn't apply to use of TLS in MTA-to-MTA SMTP.
	</t>
	
	<t>
    This document provides a consistent TLS server identity
    verification procedure across multiple email related protocols.
    This should make it easier for Certification Authorities and ISPs to deploy TLS
    for email use, and would enable email client developers to write more secure
    code.
  </t>
	
    </section>
    
    <section title="Conventions Used in This Document">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	    this document are to be interpreted as described in
	    <xref target="RFC2119"/>.</t>

      <t>
        The following terms or concepts are used through the document:

        <list style='hanging'>
          <t hangText='reference identifier:'>
            (formally defined in <xref target='RFC6125'/>) One
            of the domain names that the email client (an SMTP, IMAP, POP3
            or ManageSieve client) associates with the target email server.
            For some identifier types, the identifier also
            includes an application service type.
            Reference identifiers are used for performing name checks on
            server certificates.
<!--///Not sure where this text came from and whether it is actually helpful.
            When name checks are applicable, at least one of the
            reference identifiers MUST match an <xref target='RFC6125'/> DNS-ID or SRV-ID (or if none
            are present the <xref target='RFC6125'/> CN-ID) of the server certificate.
-->
          </t>
        </list>
      </t>

      <t>CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see <xref target='RFC6125'/> for details).
      For convenience, their short definitions from <xref target='RFC6125'/> are listed below:

      <list>
        <t>CN-ID = a Relative Distinguished Name (RDN) in the certificate
        subject field that contains one and only one attribute-type-and-value
        pair of type Common Name (CN), where the value
        matches the overall form of a domain name (informally, dot-
        separated letter-digit-hyphen labels).</t>

        <t>DNS-ID = a subjectAltName entry of type dNSName</t>

        <t>SRV-ID = a subjectAltName entry of type otherName whose name
        form is SRVName</t>

        <t>URI-ID = a subjectAltName entry of type
        uniformResourceIdentifier whose value includes both (i) a
        "scheme" and (ii) a "host" component (or its equivalent) that
        matches the "reg-name" rule (where the quoted terms represent
        the associated <xref target='RFC5234'/> productions from <xref target='RFC3986'/>).</t>
      </list>
      </t>

      <t>This documents uses the phrase 'RRSet is "insecure"' as defined in Section 2.1.1 of <xref target='RFC7672'/>.
      Similarly, 'RRSet is "secure"' if it is not "insecure".   
   <!--
      For example, SRV is "secure"        If DNSSEC protected SRV lookup (and all CNAME leading to it) are "secure",
   -->
      </t>

    </section>
      
      
   <section title="Email Server Certificate Verification Rules" anchor="rules">

     <t>
   During 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. This check is only performed after the server certificate passes
   certification path validation as described in Section 6 of <xref target='RFC5280'/>.
   Matching is performed according to the rules specified in
   Section 6 of <xref target='RFC6125'/>,
   including the relative order of matching of different identifier types, "certificate pinning" and the procedure on failure to match.
   The following inputs are used by the verification procedure used in
   <xref target='RFC6125'/>:
   
<list style="numbers">

       <t>
       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,
       (b) the hostname it used to open the connection (without CNAME canonicalization).
       The client MAY also use (c) a value securely derived from (a) or (b), such as
       using "secure" DNSSEC <xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/>
       validated lookup or a value obtained from the local hostname file.
  <!--////Also allow subdomain of the original domain, as per RFC 6186?-->
     </t>
         
       <t>
       When using email service discovery procedure specified in <xref target="RFC6186"/>
<!--////Downgrade the MUST in case the client only wants to use DNSSEC?-->
       the client MUST also use the domain portion of the user's email address as another "reference identifier"
       to compare against SRV-ID identifier in the server certificate.
       
       If DNSSEC protected SRV lookup (and all CNAME leading to it) are "secure",
       the email client MAY also use the resulting hostname from such lookup
       as DNS-ID/CN-ID reference identifier types.
       (This also corresponds to the case (c) above.)
   
  <!--////Victor thinks that this really needs DANE.
        Also allow subdomain of the original domain, as per RFC 6186?-->
       </t>

</list>
       
     </t>

	<t>    
   The rules and guidelines defined in <xref target='RFC6125'/>
   apply to an email server certificate, with the following supplemental rules:
   
<list style="numbers">
    
<!--From RFC 2595/3501:
     If a subjectAltName extension of type dNSName is present in the
     certificate, it SHOULD be used as the source of the server's
     identity.
-->
    
      <t>
      Support for the DNS-ID identifier type (subjectAltName of dNSName type <xref target="RFC5280"/>) is REQUIRED
      in Email client software implementations.
      </t>

      <t>
<!--////Downgrade the first "REQUIRED" to "SHOULD"? Or qualify it as "if want non DNSSEC validation"?-->
      Support for the SRV-ID identifier type (subjectAltName of SRVName type <xref target="RFC4985"/>) is REQUIRED for
      email client software implementations that support <xref target="RFC6186"/> and don't rely on DNSSEC protection of DNS SRV records.
      List of SRV-ID types for email services is specified in <xref target="RFC6186"/>.
      For the ManageSieve protocol the service name "sieve" is used.
      </t>
    
      <t>URI-ID identifier type (subjectAltName of uniformResourceIdentifier type <xref target="RFC5280"/>) MUST NOT be used by clients for server verification, as
      URI-ID were not historically used for email.</t>

      <t>For backward compatibility with deployed software CN-ID identifier type (CN attribute from the subject name, see <xref target='RFC6125'/>)
         MAY be used for server identity verification.</t>
	  
      <t>Email protocols allow use of certain wildcards in identifiers
      presented by email servers.
      The "*" wildcard character MAY be used as the left-most name
      component of DNS-ID or CN-ID in the certificate.
      For example, a DNS-ID of *.example.com would
      match a.example.com, foo.example.com, etc. but would not match
      example.com.
      Note 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).
<!--////
      <cref>Should the rules on "*" only matching one level be relaxed to cope with some existing deployments?</cref>
-->
      </t>
    
</list>
	    
	</t>
	
    </section>


    <section title="Compliance Checklist for Certification Authorities">

      <t>
        <list style="numbers">

          <t>
            CA MUST support issuance of server certificates with DNS-ID identifier type (subjectAltName of dNSName type <xref target="RFC5280"/>).
            (Note that some DNS-IDs may refer to domain portions of email addresses, so they might not have corresponding A/AAAA DNS records.)
          </t>

          <t>
            <!--////Downgrade to SHOULD?-->
            CA MUST support issuance of server certificates with SRV-ID identifier type (subjectAltName of SRVName type <xref target="RFC4985"/>)
            for each type of email service.
            <cref>
              Or add another alternative condition like "MUST be able to validate DNSSEC protected SRV RRs and allow results of their resolution
              to be included as other DNS-IDs? Do we even need to impose and DNSSEC requirements on CAs in this area?
            </cref>
          </t>

          <t>
            For backward compatibility with deployed client base, CA MUST support issuance of server certificates with CN-ID identifier type (CN attribute from the subject name, see <xref target='RFC6125'/>).
          </t>
          
          <t>
            CA MAY allow "*" (wildcard) as the left-most name component of DNS-ID or CN-ID in server certificates it issues.
          </t>

        </list>

      </t>
      
      <section title="Notes on handling of delegated email services by Certification Authorities" anchor="ca-delegated">

        <t>
        <xref target="RFC6186"/> provides an easy way for organizations<!--domains?--> to autoconfigure
        email clients. It also allows for delegation of email services to an email hosting provider.
        When connecting to such delegated hosting service an email client that attempts to verify
        TLS server identity needs to know that if it connects to imap.hosting.example.net that
        such server is authorized to provide email access for an email such as alice@example.org.
        In absence of SRV-IDs, users of compliant email clients would be forced to manually confirm exception,
        because the TLS server certificate verification procedures specified in this document would result in failure
        to match the TLS server certificate against the expected domain(s).
        
        One way to provide such authorization is for the TLS certificate for imap.hosting.example.net
        to include SRV-ID(s) (or DNS-ID) for the example.org domain.
        
        Another way is for DNS SRV lookups to be protected by DNSSEC.
        </t>

        <t>
        A certification authority that receives a Certificate Signing Request containing multiple unrelated DNS-IDs and/or SRV-IDs
        (e.g. DNS-ID of example.org and DNS-ID of example.com) needs to verify that the entity that supplied such
        Certificate Signing Request is authorized to provide email service for all requested domains.
  <!--////Suggest DNSSEC validation of SRV records when verifying DNS-IDs that such SRV records point to?-->        
        
        <!--////CAs can either reject the request if they can't validate a single DNS-ID/SRV-ID from the set or
        it can only issue a certificate for DNS-IDs/SRV-IDs for which authorization can be verified.-->
        </t>        
        
        <t>The ability to issue certificates that contain an SRV-ID (or a DNS-ID for the domain part of email addresses)
        implies the ability to verify that entities requesting them are authorized to run email service for these SRV-IDs/DNS-IDs.
        In particular, certification authorities 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.
        This document doesn't specify exact mechanism(s) that can be used to achieve this. However,
        a few special case recommendations are listed below.</t>

        <t>
        A certification authority willing to sign a certificate containing a particular DNS-ID SHOULD
        also support signing a certificate containing one or more of 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 DNS-ID).
        </t>

        <t>
        A certification authority which also provides DNS service for a domain can
        use DNS information to validate SRV-IDs/DNS-IDs for the domain.
        </t>

        <t>
        A certification authority which is also a Mail Service Provider for a hosted domain can
        use that knowdledge to validate SRV-IDs/DNS-IDs for the domain.
        </t>

        <!--////Are their risks here? Should we recommend use of Public Domain Suffix list or something like that?
            Otherwise subdomains might be able to "steal" mail servers from ISPs.
            
        <t>A certification authority MAY treat a certificate for a subdomain of example.com
        (e.g. imap.sub1.example.com or imap.example.com)
        that contains one or more SRV-ID for example.com as validated.
        -->
        
      </section>

    </section>

    <section title="Compliance Checklist for Mail Service Providers and Certificate Signing Request generation tools" anchor="msp">

<!--///Should Certificate Signing Request generation tools have a separate section, as they effectively
       are REQUIRED to support everything listed below?-->      

      <t>
        Mail Service Providers and Certificate Signing Request generation tools
        
        <list style="numbers">

          <t>
            MUST include the DNS-ID identifier type in
            Certificate Signing Requests for
            the host name(s) where the email server(s) are running.

            <!--////Note that the following implies that CAs need to verify ownership of a domain,
                for which there might not be any corresponding A/AAAA DNS record, only MX records. -->
            <!--////Is this only useful when RFC 6186 is used?-->
            They SHOULD include the DNS-ID identifier type in
            Certificate Signing Requests for the domain portion of served email addresses.
          </t>

          <t>
            If the email services provided are discoverable using DNS SRV as specified in <xref target="RFC6186"/>,
            the Mail Service Provider MUST (a) include the SRV-ID identifier type
            for each type of email service in Certificate Signing Requests and/or
            (b) make sure that relevant SRV records are DNSSEC protected and "secure".
       <!--Alexey: So the general principle is that the server can do either (or both, to allow more client implementation choices)
           and the client does both-->
          </t>

          <t>
            SHOULD include 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.
            (Note, a certificate can only include a single CN-ID, so if a mail service is running on multiple hosts,
            either each host has to use different certificate with its own CN-ID, a single certificate with multiple
            DNS-IDs, or a single certificate with wildcard in CN-ID can be used).
          </t>

          <t>
            MAY include "*" (wildcard) as the left-most name component of DNS-ID or CN-ID in Certificate Signing Requests.
          </t>

        </list>

      </t>

      <section title="Notes on hosting multiple domains" anchor="msp-hosted">

<!--Harald Alvestrand wrote:

        If I understand RFC 6186 correctly, a (possibly large scale) IMAP email
        service provider that wishes to serve a new domain "example org"
        according to RFC 6186 must do two things:

        - Update internal tables of its servers with inforamation about that domain.
        - Populate the DNS of the domain served with an _imap record.

        If I understand this draft correctly, the server will have to do one
        more thing:

        - Change its certificate to include a complete list of all the domains
        it is serving, and have its CA sign off on that certificate.

        The reason it cannot provide one certificate per served domain is that
        neither this specification nor any other specification I have found says
        that the client MUST include any distinguishing information (such as a
        Server Name Indication) that says what name it is expecting the server
        to provide service for.
-->

        <t>A server that hosts multiple domains needs to do one of the following (or some combination thereof):

        <list style='numbers'>
          
          <t>
          Use DNS SRV records to redirect each hosted email service to a fixed domain,
          deploy TLS certificate(s) for that single domain, and instruct users to
          configure their clients with appropriate pinning (unless the SRV records
          can always be obtained via DNSSEC). Some email clients come with preloaded
          list of pinned certificates for some popular domains, which can avoid the need
          for manual confirmation.
          </t>
          
          <t>
          Use a single TLS certificate that includes a complete list of all the domains
          it is serving.
          </t>

          <t>
          Serve each domain on its own IP/port, using separate TLS certificates on each IP/port.
          </t>

          <t>
          <!--////Alexey: At the moment none of the email specs requires it. But maybe it is something that the draft should
          encourage.-->
          Use Server Name Indication (SNI) TLS extension <xref target='RFC6066'/> to select the right certificate
          to return during TLS negotiation. Each domain has its own TLS certificate in this case.
          </t>

        </list>
        </t>

        <t>
        Each of these deployment choices have their scaling or operational disadvantages when the list of domains changes.
        Use of DNS SRV without SRV-ID requires manual confirmation from users or ubiquitous availability of DNSSEC and its APIs.
<!--DNSSEC addresses that:        
        While preloading pinned
        certificates avoids the need for manual confirmation, this information can get stale quickly
        or would require support for a new mechanism for distributing preloaded pinned certificates.
-->
        A single certificate (the second choice) requires that when a domain is added,
        then a new Certificate Signing Request that includes a complete list of all the domains
        needs to be issued and passed to a CA in order to generate a new certificate.
        <!--////Also, the certificate can be potentially very large.-->
        Separate IP/port can avoid regenerating the certificate, but requires more transport layer resources.
        Use of TLS SNI requires each email client to use it.
        </t>

        <t>
        Several Mail Service Providers host hundreds and even thousands of domains.
        DNSSEC protected SRV records can address scaling issues caused by use of TLS in multi-tenanted environments.
        <!--////Other possible solutions:
        <xref target="RFC7711">POSH</xref>.
        -->
        </t>

      </section>
      
   </section>


    <section title="Examples">

      <t>
   Consider an IMAP-accessible email server which supports both
   IMAP and IMAPS (IMAP-over-TLS) at the host
   "mail.example.net" servicing email addresses of the form
   "user@example.net".
   A certificate for this service needs to include
   DNS-IDs of "example.net" (because it is the domain portion of emails)
   and "mail.example.net" (this is what a user of this server enters manually, if not using <xref target="RFC6186"/>).
   It might also include CN-ID of "mail.example.net"
   for backward compatibility with deployed infrastructure.
      </t>
      
      <t>
   Consider the IMAP-accessible email server from the previous paragraph
   which is additionally discoverable via DNS SRV lookups
   in domain "example.net" (DNS SRV records "_imap._tcp.example.net"
   and "_imaps._tcp.example.net").  In addition to DNS-ID/CN-ID identity types specified above,
   a certificate for this service also needs to include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the IMAP port)
   and "_imaps.example.net" (when TLS is used on IMAPS port). See <xref target="RFC6186"/> for more details.
   (Note that unlike DNS SRV there is no "_tcp" component in SRV-IDs).
   If DNS SRV are DNSSEC protected, email clients that perform DNSSEC validation of SRV records
   would check for DNS-IDs that contain the target of SRV records, instead of SRV-IDs.
      </t>
      
      <t>
   Consider the IMAP-accessible email server from the first paragraph
   which is running on a host also known as "mycompany.example.com". <!--"vanity domain" case-->
   In addition to DNS-ID identity types specified above,
   a certificate for this service also needs to include
   DNS-ID of "mycompany.example.com" (this is what a user of this server enters manually, if not using <xref target="RFC6186"/>).
   It might also include CN-ID of "mycompany.example.com" instead of the CN-ID "mail.example.net"
   for backward compatibility with deployed infrastructure.
   (This is so, because a certificate can only include a single CN-ID)
      </t>
      
	
      <t>
   Consider an SMTP Submission server at the host
   "submit.example.net" servicing email addresses of the form
   "user@example.net" and discoverable via DNS SRV lookups
   in domain "example.net" (DNS SRV records "_submission._tcp.example.net").
   A certificate for this
   service needs to include SRV-IDs of "_submission.example.net"
   (see <xref target="RFC6186"/>) along with DNS-IDs of
   "example.net" and "submit.example.net".  It might also include CN-ID
   of "submit.example.net" for backward compatibility
   with deployed infrastructure.
      </t>

      <t>
   Consider a host "mail.example.net" servicing email addresses of the form
   "user@example.net" and discoverable via DNS SRV lookups in domain "example.net",
   which runs SMTP Submission, IMAPS and POP3S (POP3-over-TLS) and ManageSieve services.
   Each of the servers can use their own certificate specific to their service
   (see examples above). Alternatively they can all share a single certificate
   that would include SRV-IDs of "_submission.example.net",
   "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net"
   <!--////DNSSEC aware client will ignore SRV-IDs, if DNS SRV are DNSSEC protected.-->
   along with DNS-IDs of "example.net" and "mail.example.net".
   It might also include CN-ID of "mail.example.net"
   for backward compatibility with deployed infrastructure.
      </t>

   </section>

   <section title="Operational Considerations">

      <t><xref target="msp"/> covers operational considerations (in particular use of DNS SRV for autoconfiguration)
      related to generating TLS certificiates for email servers so that they can be successfully verified by email clients.
      Additionally, <xref target="msp-hosted"/> talks about operational considerations related
      to hosting multiple domains.
      </t>

   </section>
    
   <section title="IANA Considerations">
	
      <t>This document doesn't require any action from IANA.</t>
	
    </section>
    
    <section title="Security Considerations" anchor="seccons">

	    <t>The goal of this document is to improve interoperability and
      thus security of email clients wishing to access email servers
      over TLS protected email protocols, by specifying a consistent
      set of rules that email service providers, email client writers
      and Certification Authorities can use when creating server certificates.</t>

      <t>
      TLS Server Identity Check for Email relies on use of trustworthy DNS hostnames
      when constructing "reference identifiers" that are checked against an email server certificate.
      Such trustworthy names are either entered manually (for example if they are advertised on a Mail Service Provider's website),
      explicitly confirmed by the user (e.g. if they are a target of a DNS SRV lookup) or
      derived using a secure third party service (e.g. DNSSEC-protected SRV records
      which are verified by the client or trusted local resolver).
<!--///Actually, this is not true, unless PKIX is also subverted:
      TLS Server Identity Check doesn't protect from compromise of DNS information (such as DNS cache poisoning)
-->
      </t>

 <!--////
  <xref target="RFC6186"/>
 -->

    </section>
    
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.1939"?> <!-- POP3 -->
      <?rfc include="reference.RFC.2119"?> <!-- Keywords -->
      <?rfc include="reference.RFC.3207"?> <!-- SMTP STARTTLS extension -->
      <?rfc include="reference.RFC.3501"?> <!-- IMAP -->
      <?rfc include="reference.RFC.4985"?> <!-- PKIX-SRV -->
      <?rfc include="reference.RFC.5804"?> <!-- ManageSieve -->
      <?rfc include="reference.RFC.5280"?> <!-- PKIX -->
      <?rfc include="reference.RFC.6125"?> <!-- TLS Server Identity Check -->
      <?rfc include="reference.RFC.6186"?> <!-- Use of SRV Records for Locating Email Submission/Access Services -->
      <?rfc include="reference.RFC.6409"?> <!-- Submission protocol -->
      <?rfc include="reference.RFC.7672"?> <!-- SMTP Security via Opportunistic DANE TLS -->
      
    </references>

    <references title="Informative References">
	
      <?rfc include="reference.RFC.2595"?> <!-- STARTTLS/STLS in ACAP/IMAP/POP -->
      <?rfc include="reference.RFC.3986"?> <!-- URI -->
      <?rfc include="reference.RFC.4033"?> <!-- DNSSEC -->
      <?rfc include="reference.RFC.4034"?> <!-- DNSSEC -->
      <?rfc include="reference.RFC.4035"?> <!-- DNSSEC -->
      <?rfc include="reference.RFC.5234"?> <!-- ABNF -->
      <?rfc include="reference.RFC.6066"?> <!-- TLS SNI -->
      <?rfc include="reference.RFC.6698"?> <!-- DANE TLSA records -->
      <?rfc include="reference.RFC.7711"?> <!-- POSH -->

    </references>

    <section title="Acknowledgements">
	
      <!--
      <t>
      Thank you to Viktor Dukhovni, Harald Alvestrand and John Levine for comments on this document.
      </t>
      -->

      <t>The editor of this document copied lots of text from RFC 2595 and RFC 6125, RFC 7672,
      so the hard work of editors of these document is appreciated.</t>
	
    </section>

    <section title="Changes since draft-melnikov-uta-dnssec-email-tls-certs-00">

      <t>[[Note to RFC Editor: Please delete this section before publication]]</t>

      <t>TBD</t>

    </section>


  </back>
</rfc>
