<?xml version="1.0" encoding="US-ASCII"?>
<!-- this is version 5 of this xml2rfc template -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc7468 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.7468.xml">
<!ENTITY rfc8174 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc8446 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY I-D.ietf-tls-esni SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni">
<!ENTITY I-D.ietf-dnsop-svcb-https SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-svcb-https">

]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="exp" docName="draft-farrell-tls-pemesni-02" ipr="trust200902" >
  <front>
    <title abbrev="PEM file format for ECH">PEM file format for ECH</title>

    <author fullname="Stephen Farrell" initials="S." surname="Farrell">
      <organization>Trinity College Dublin</organization>

      <address>
        <postal>
          <street/>

          <city>Dublin</city>

          <region/>

          <code>2</code>

          <country>Ireland</country>
        </postal>

        <phone>+353-1-896-2354</phone>

        <email>stephen.farrell@cs.tcd.ie</email>
      </address>
    </author>

    <date year="2021"/>

    <area>Security Area</area>

    <workgroup>TLS</workgroup>

    <keyword>TLS</keyword>

    <keyword>ESNI</keyword>

    <abstract>
        <t>Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, some of which
            can be built with different TLS libraries, so there is a benefit and
            little cost in documenting a file format to use for these, similar to
            how RFC7468 defines other PEM file formats.
            </t> 
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

        <t>Encrypted ClientHello (ECH)
            <xref target="I-D.ietf-tls-esni"/> for TLS1.3 <xref target="RFC8446"/>
            defines a confidentiality mechanism for server names and other ClientHello 
            content in TLS.
            That requires publication of an ECHConfigList data structure in an HTTPS or SVCB RR
            <xref target="I-D.ietf-dnsop-svcb-https"/> in the DNS.
            An ECHConfigList can contain one or more ECHConfig values.
            An ECHConfig structure contains the public component of a key pair
            that will typically be periodically (re-)generated by some key manager
            for a TLS server.
            TLS servers then need to be configured to use these key pairs, 
            and given that various TLS servers can be built with different
            TLS libraries, there is a benefit in having a standard format for
            ECH key pairs, just as was done with <xref target="RFC7468"/>. 
        </t>

        <t>[[This idea could: a) wither on the vine, b) be published
            as it's own RFC, or c) end up as a PR for <xref target="I-D.ietf-tls-esni"/>.
            There is no absolute need for this to be in the RFC that
            defines ECHO, so (b) seems feasible if there's enough
            interest, hence this draft.
            The source for this is in https://github.com/sftcd/pemesni/ 
            PRs are welcome there too.]]
        </t>

      </section>

      <section title="Terminology">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>

      <section title="ECHConfig file">

              <t>The public and private keys MUST both
                  be PEM encoded. The file contains the catenation of the PEM encoding
              of the private key followed by the PEM encoding of the public key as
              an ECHConfigList containing exactly one ECHConfig. 
                  The private key MUST be encoded as a PKCS#8 PrivateKey. The public
                  key MUST be the base64 encoded form of an ECHConfigList value that 
                  can also be published in the DNS. The string "ECHCONFIG" MUST be used in the PEM
                  file delimiter for the public key.</t>

              <t>There MUST only be one key pair in each file even if a server publishes
                  multiple public keys in the DNS in one ECHConfigList structure.</t>

              <t><xref target="sample"/> shows an example ECHConfig PEM File</t>

            <figure anchor="sample" title="Example ECHConfig PEM file" >
            <artwork><![CDATA[
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEICjd4yGRdsoP9gU7YT7My8DHx1Tjme8GYDXrOMCi8v1V
-----END PRIVATE KEY-----
-----BEGIN ECHCONFIG-----
AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRCwAEAAEA
AQALZXhhbXBsZS5jb20AAA==
-----END ECHCONFIG-----
            ]]></artwork>
            </figure>

      </section>



    <section title="Security Considerations">
        <t>Storing cryptographic keys in files leaves them vulnerable should
            anyone get shell access to the TLS server machine.
            So: Don't let that happen:-)</t>

    </section>

    <section title="Acknowledgements">
        <t>TBD, as needed</t>
    </section>

    <section title="IANA Considerations">
        <t>There are none so this section can be deleted later.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.7468'?>
      <?rfc include='reference.RFC.8174'?>
      <?rfc include='reference.RFC.8446'?>
      &I-D.ietf-tls-esni;
      &I-D.ietf-dnsop-svcb-https;

    </references>

    <!--
    <references title="Informative References">
    </references>

    <section title="Change Log ">
      <t>[[RFC editor: please remove this before publication.]]</t>

      <t>From -00 to -01:
          <list style="symbols">
              <t>Re-structured a bit after re-reading rfc8615</t>
          </list>
      </t>
    </section>
    -->

    <section title="Changes">

      <t>From -01 to -02:
          <list style="symbols">
            <t>ECHO -> ECH</t>
          </list>
      </t>

      <t>From -00 to -01:
          <list style="symbols">
            <t>ESNI -> ECHO</t>
          </list>
      </t>

    </section>

  </back>
</rfc>
