<?xmlversion="1.0" encoding="US-ASCII"?> <!-- this is version 5 of this xml2rfc template -->version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc2119 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY rfc4648 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.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">nbsp " "> <!ENTITYrfc8446 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml">zwsp "​"> <!ENTITYrfc8446 SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.9460.xml">nbhy "‑"> <!ENTITYI-D.ietf-tls-esni SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-esni"> <!ENTITY I-D.ietf-tls-svcb-ech SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-svcb-ech">wj "⁠"> ]><?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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-farrell-tls-pemesni-13" number="9934" ipr="trust200902">obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" consensus="true"> <front> <title abbrev="PEMfile formatFile Format forECH">PEM file formatECH">Privacy-Enhanced Mail (PEM) File Format forECH</title>Encrypted ClientHello (ECH)</title> <seriesInfo name="RFC" value="9934"/> <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 month="February" year="2026"/> <area>Security Area</area><workgroup>Internet Engineering Task Force (IETF)</workgroup><keyword>TLS</keyword> <keyword>ESNI</keyword> <abstract> <t> Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, which can be built using different TLS libraries. This document specifies a standard file formatto use,for this purpose, similar to how RFC 7468 defines otherPEMPrivacy-Enhanced Mail (PEM) file formats. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Encrypted ClientHello (ECH) <xreftarget="I-D.ietf-tls-esni"/>target="RFC9849" format="default"/> for TLS1.3 <xreftarget="RFC8446"/>target="RFC8446" format="default"/> 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 <xreftarget="RFC9460"/>target="RFC9460" format="default"/> 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 and configs, just as was done with <xreftarget="RFC7468"/>.target="RFC7468" format="default"/>. </t> </section> <sectiontitle="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectiontitle="ECHConfig file">numbered="true" toc="default"> <name>ECHConfig File</name> <t>A PEM ECH file contains zero or one private key and one encoded ECHConfigList.</t> <t>The public and private keysMUST<bcp14>MUST</bcp14> both be PEM encoded <xreftarget="RFC7468"/>.target="RFC7468" format="default"/>. The file contains the concatenation of the PEM encoding of the private key (if present) followed by the PEM encoding of the public key(s) as an ECHConfigList. When a private key is present, the ECHConfigListMUST<bcp14>MUST</bcp14> contain an ECHConfig that matches the private key. The private keyMUST<bcp14>MUST</bcp14> be encoded as a PKCS#8 PrivateKey <xreftarget="RFC7468"/>.target="RFC7468" format="default"/>. The public key(s)MUST<bcp14>MUST</bcp14> be thebase64 encodedbase64-encoded form (seeSection 4 of<xreftarget="RFC4648"/>) formtarget="RFC4648" section="4"/>) of an ECHConfigList value that can be published in the DNS using an HTTPS RR as described in <xreftarget="I-D.ietf-tls-svcb-ech"/>.target="RFC9848" format="default"/>. The string "ECHCONFIG"MUST<bcp14>MUST</bcp14> be used in the PEM file delimiter for the public key.</t> <t>Any content after the PEM encoded ECHConfigListSHOULD<bcp14>SHOULD</bcp14> be ignored.</t> <t><xreftarget="sample"/>target="sample" format="default"/> shows an example ECHConfig PEM File</t> <figureanchor="sample" title="Exampleanchor="sample"> <name>Example ECHConfig PEMfile" > <artwork><![CDATA[File</name> <artwork name="" type="" align="left" alt=""><![CDATA[ -----BEGIN PRIVATE KEY----- MC4CAQAwBQYDK2VuBCIEICjd4yGRdsoP9gU7YT7My8DHx1Tjme8GYDXrOMCi8v1V -----END PRIVATE KEY----- -----BEGIN ECHCONFIG----- AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRCwAEAAEA AQALZXhhbXBsZS5jb20AAA== -----ENDECHCONFIG----- ]]></artwork>ECHCONFIG-----]]></artwork> </figure> <t> If the above ECHConfigList were published in the DNS for foo.example.com, then one could access that as shown in <xreftarget="dig"/>.target="dig" format="default"/>. </t> <figureanchor="dig" title="Useanchor="dig"> <name>Use ofdigDig togetGet the ECHConfigList fromDNS" > <artwork><![CDATA[DNS</name> <artwork name="" type="" align="left" alt=""><![CDATA[ $ dig +short HTTPS foo.example.com 1 . ech=AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRwAEAAEAAQALZXhhbXBsZS5jb20AAA== ]]></artwork>wAEAAEAAQALZXhhbXBsZS5jb20AAA==]]></artwork> </figure> <t> TLS servers using this file format might configure multiple file names as part of their overall configuration, if, for example, only the ECHConfigList values from a subset of those files are to be used as the value for retry_configs in the ECH fallback scenario. </t> <t> The ECHConfigList in a PEM file might contain more than one ECHConfig if, for example, those ECHConfig values contain different extensions or different public_name values. Consistent with <xreftarget="I-D.ietf-tls-esni"/>,target="RFC9849" format="default"/>, the ECHConfig values within an ECHConfigList appear in decreasing order of preference. If the ECHConfigList value is to be used as the retry_configs value, then that might contain different public keys. (Nonetheless, when a private key is present, thatMUST<bcp14>MUST</bcp14> match the public key from one of the ECHConfig values.) </t> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>Storing cryptographic keys in files leaves them vulnerable should anyone get read access to the filesystem on which they are stored. The same protection mechanisms that would be used for a server'sPEM encodedPEM-encoded HTTPS certificate private key should be used for the PEM ECH configuration. </t> <t> The security considerations of <xreftarget="I-D.ietf-tls-svcb-ech"/>target="RFC9848" format="default"/> apply when retrieving an ECHConfigList from the DNS. </t> <t> For clarity, only the ECHConfigList is to be published in the DNS - the private key from an ECH PEM fileMUST NOT<bcp14>MUST NOT</bcp14> be published in the DNS. </t> </section> <sectiontitle="Acknowledgements"> <t>Thanks to Daniel McCarney, Jim Reid and Peter Yee for comments.</t> </section> <section title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentcontainshas no IANAconsiderations.</t>actions.</t> </section> </middle> <back><references title="Normative References"> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.4648'?> <?rfc include='reference.RFC.7468'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.8446'?> &I-D.ietf-tls-esni; </references> <references title="Informative References"> <?rfc include='reference.RFC.9460'?> &I-D.ietf-tls-svcb-ech; </references><references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7468.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <!--<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>[I-D.ietf-tls-esni] -> [RFC9849] in AUTH48 as of 02/17/26 --><section title="Changes"> <t>From -12 to -13: <list style="symbols"> <t>Changes resulting from IESG review.</t> </list> </t> <t>From -11 to -12: <list style="symbols"> <t>Changes resulting from IETF last call reviews.</t> </list> </t> <t>From -10 to -11: <list style="symbols"> <t>Change to standards track<reference anchor="RFC9849" target="https://www.rfc-editor.org/info/rfc9849"> <front> <title>TLS Encrypted Client Hello</title> <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> </author> <author initials="K." surname="Oku" fullname="Kazuho Oku"> <organization>Fastly</organization> </author> <author initials="N." surname="Sullivan" fullname="Nick Sullivan"> <organization>Cryptography Consulting LLC</organization> </author> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> </author> <date month='February' year='2026'/> </front> <seriesInfo name="RFC" value="9849"/> <seriesInfo name="DOI" value="10.17487/RFC9849"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> <!-- [I-D.ietf-tls-svcb-ech] RFC-to-be 9848 in AUTH48-DONE asagreed with shepherd/AD.</t> </list> </t> <t>From -09 to -10: <list style="symbols"> <t>Tweaks to fit being AD sponsored.</t> </list> </t> <t>From -08 to -09: <list style="symbols"> <t>Minor clarificationofencoding based on current OpenSSL ECH feature branch code.</t> </list> </t> <t>From -07 to -08: <list style="symbols"> <t>Processed some github comments</t> </list> </t> <t>From -06 to -07: <list style="symbols"> <t>Refresh due to expiry.</t> </list> </t> <t>From -05 to -06: <list style="symbols"> <t>Refresh due to expiry.</t> </list> </t> <t>From -04 to -05: <list style="symbols"> <t>Refresh due to expiry.</t> </list> </t> <t>From -03 to -04: <list style="symbols"> <t>Refresh due to expiry.</t> </list> </t> <t>From -02 to -03: <list style="symbols"> <t>Refresh due02/17/2026 --> <reference anchor="RFC9848" target="https://www.rfc-editor.org/info/rfc9848"> <front> <title> Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings </title> <author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz"> <organization>Meta Platforms, Inc.</organization> </author> <author fullname="Mike Bishop" initials="M." surname="Bishop"> <organization>Akamai Technologies</organization> </author> <author fullname="Erik Nygren" initials="E." surname="Nygren"> <organization>Akamai Technologies</organization> </author> <date month="February" year="2026"/> </front> <seriesInfo name="RFC" value="9848"/> </reference> </references> </references> <section numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thanks toexpiry<contact fullname="Daniel McCarney"/>, <contact fullname="Jim Reid"/>, andnot possible ISE destination</t> </list> </t> <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><contact fullname="Peter Yee"/> for comments.</t> </section> </back> </rfc>