<?xmlversion="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 --> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ ]> <?rfc toc="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?>version='1.0' encoding='utf-8'?> <rfcipr="trust200902"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-acme-tls-alpn-07"category="std">indexInclude="true" ipr="trust200902" number="8737" prepTime="2020-02-28T19:13:09" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn-07" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8737" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev="ACME-TLS-ALPN">ACMEabbrev="ACME-TLS-ALPN">Automated Certificate Management Environment (ACME) TLSALPNApplication‑Layer Protocol Negotiation (ALPN) Challenge Extension</title> <seriesInfo name="RFC" value="8737" stream="IETF"/> <author initials="R.B." surname="Shoemaker" fullname="Roland Bracewell Shoemaker"> <organizationabbrev="ISRG">Internetabbrev="ISRG" showOnFrontPage="true">Internet Security Research Group</organization> <address> <email>roland@letsencrypt.org</email> </address> </author> <dateyear="2019" month="October" day="01"/> <area>General</area>month="02" year="2020"/> <area>Security</area> <workgroup>ACME Working Group</workgroup><abstract> <t>This<keyword>acme</keyword> <keyword>pki</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1">This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8737" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t pn="section-boilerplate.2-1"> Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.3"> <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-with-application-layer-">TLS with Application-Layer Protocol Negotiation (TLS ALPN) Challenge</xref></t> </li> <li pn="section-toc.1-1.4"> <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-tls-1-protocol-definit">acme-tls/1 Protocol Definition</xref></t> </li> <li pn="section-toc.1-1.5"> <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-smi-security-for-pkix-certi">SMI Security for PKIX Certificate Extension OID</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-alpn-protocol-id">ALPN Protocol ID</xref></t> </li> <li pn="section-toc.1-1.6.2.3"> <t keepWithNext="true" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-validation-method">ACME Validation Method</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.8"> <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-design-rationale">Design Rationale</xref></t> </li> <li pn="section-toc.1-1.9"> <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t> </li> <li pn="section-toc.1-1.10"> <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="introduction"title="Introduction"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1">The Automatic Certificate Management Environment (ACME) <xreftarget="RFC8555"/>target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> specification describes methods for validating control of domain names via HTTP and DNS. Deployment experience has shown it is also useful to be able to validate domain control using the TLS layer alone. In particular, this allows hosting providers,CDNs,Content Distribution Networks (CDNs), and TLS-terminating load balancers to validate domain control without modifying the HTTP handling behavior of their backends.</t><t>This<t pn="section-1-2">This document specifies a new TLS-based challenge type, tls-alpn-01. This challenge requires negotiating a new application-layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension <xreftarget="RFC7301"/>.target="RFC7301" format="default" sectionFormat="of" derivedContent="RFC7301"/>. Because this protocol does not build on apreexistingpre-existing deployment base, the ability tofulfillcomplete tls-alpn-01 challengesis effectively opt-in. Arequires changes by serviceproviderproviders, making it explicitly an opt-in process. Because service providers must proactively deploy new code in order to implement tls-alpn-01,sowe can specify stronger controls in that code, resulting in a stronger validationmethod.</t>method. </t> </section> <section anchor="terminology"title="Terminology"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name> <t pn="section-2-1"> 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 <xreftarget="RFC2119"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xreftarget="RFC8174"/>target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="tls-with-application-layer-protocol-negotiation-tls-alpn-challenge"title="TLSnumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-tls-with-application-layer-">TLS withApplication LayerApplication-Layer Protocol Negotiation (TLS ALPN)Challenge"> <t>TheChallenge</name> <t pn="section-3-1">The TLS withApplication LayerApplication-Layer Protocol Negotiation (TLS ALPN) validation method proves control over a domain name by requiring the ACME client to configure a TLS server to respond to specific connection attempts using the ALPN extension with identifying information. The ACME server validates control of the domain name by connecting to a TLS server at one of the addresses resolved for the domain name and verifying that a certificate with specific content is presented.</t><t>The<t pn="section-3-2">The tls-alpn-01 ACME challenge object has the following format:</t><t><list style="hanging"> <t hangText='type<dl newline="false" spacing="normal" pn="section-3-3"> <dt pn="section-3-3.1">type (required,string):'>string):</dt> <dd pn="section-3-3.2"> The string“tls-alpn-01”</t> <t hangText='token"tls-alpn-01"</dd> <dt pn="section-3-3.3">token (required,string):'>string):</dt> <dd pn="section-3-3.4"> A random value that uniquely identifies the challenge. This valueMUST<bcp14>MUST</bcp14> have at least 128 bits of entropy. ItMUST NOT<bcp14>MUST NOT</bcp14> contain any characters outside the base64url alphabet as described in <xreftarget="RFC4648"/> Section 5.target="RFC4648" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/>. Trailing‘=’'=' padding charactersMUST<bcp14>MUST</bcp14> be stripped. See <xreftarget="RFC4086"/>target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for additional information on randomnessrequirements.</t> </list></t> <t>Therequirements.</dd> </dl> <t pn="section-3-4">The client prepares for validation by constructing a self-signed certificate thatMUST<bcp14>MUST</bcp14> contain an acmeIdentifier extension and a subjectAlternativeName extension <xreftarget="RFC5280"/>.target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>. The subjectAlternativeName extensionMUST<bcp14>MUST</bcp14> contain a single dNSName entry where the value is the domain name being validated. The acmeIdentifier extensionMUST<bcp14>MUST</bcp14> contain the SHA-256 digest <xreftarget="FIPS180-4"/>target="FIPS180-4" format="default" sectionFormat="of" derivedContent="FIPS180-4"/> of the key authorization <xreftarget="RFC8555"/>target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> for the challenge. The acmeIdentifier extensionMUST<bcp14>MUST</bcp14> be critical so that the certificateisn’tisn't inadvertently used by non-ACME software.</t><t>The<t pn="section-3-5">The acmeIdentifier extension is identified by the id-pe-acmeIdentifier object identifier (OID) in the id-pe arc <xreftarget="RFC5280"/>:</t> <figure><artwork><![CDATA[target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>:</t> <sourcecode type="asn.1" markers="false" pn="section-3-6"> id-pe-acmeIdentifier OBJECT IDENTIFIER ::= { id-pe 31 }]]></artwork></figure> <t>The</sourcecode> <t pn="section-3-7">The extension has the following ASN.1 <xreftarget="X.680"/>target="X.680" format="default" sectionFormat="of" derivedContent="X.680"/> format :</t><figure><artwork><![CDATA[<sourcecode type="asn.1" markers="false" pn="section-3-8"> Authorization ::= OCTET STRING (SIZE (32))]]></artwork></figure> <t>The</sourcecode> <t pn="section-3-9">The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER encoding <xreftarget="X.690"/>target="X.690" format="default" sectionFormat="of" derivedContent="X.690"/> of the Authorization structure, which contains the SHA-256 digest of the key authorization for the challenge.</t><t>Once<t pn="section-3-10">Once this certificate has beencreatedcreated, itMUST<bcp14>MUST</bcp14> be provisioned such that it is returned during a TLS handshake where the“acme-tls/1”"acme-tls/1" application-layer protocol has been negotiated and a Server Name Indication (SNI) extension <xreftarget="RFC6066"/>target="RFC6066" format="default" sectionFormat="of" derivedContent="RFC6066"/> has been provided containing the domain name being validated.</t><t>A<t pn="section-3-11">A client responds by POSTing an empty JSON object ({}) to the challenge URL to acknowledge that the challenge is ready to be validated by the server. The base64url encoding of the protected headers and payload is described in <xreftarget="RFC8555"/> Section 6.1.</t> <figure><artwork><![CDATA[target="RFC8555" sectionFormat="of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-6.1" derivedContent="RFC8555"/>.</t> <sourcecode markers="false" pn="section-3-12"> POST /acme/authz/1234/1 Host: example.com Content-Type: application/jose+json { "protected": base64url({ "alg": "ES256", "kid": "https://example.com/acme/acct/1", "nonce": "JHb54aT_KTXBWQOzGYkt9A", "url": "https://example.com/acme/authz/1234/1" }), "payload": base64url({}), "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"} ]]></artwork></figure> <t>On}</sourcecode> <t pn="section-3-13">On receiving this request from aclientclient, the server constructs and stores the key authorization from the challenge“token”"token" value and the current client account key.</t><t>The<t pn="section-3-14">The server then verifies theclient’sclient's control over the domain by verifying that the TLS server was configured as expected using the following steps:</t><t><list style="numbers"> <t>The<ol spacing="normal" type="1" start="1" pn="section-3-15"> <li pn="section-3-15.1" derivedCounter="1.">The ACME server computes the expected SHA-256 digest of the keyauthorization.</t> <t>Theauthorization.</li> <li pn="section-3-15.2" derivedCounter="2.">The ACME server resolves the domain name being validated and chooses one of the IP addresses returned for validation (the serverMAY<bcp14>MAY</bcp14> validate against multiple addresses if more than one isreturned).</t> <t>Thereturned).</li> <li pn="section-3-15.3" derivedCounter="3.">The ACME server initiates a TLS connection to the chosen IP address. This connectionMUST<bcp14>MUST</bcp14> use TCP port 443. The ACME serverMUST<bcp14>MUST</bcp14> provide an ALPN extension with the single protocol name“acme-tls/1”"acme-tls/1" and an SNI extension containing only the domain name being validated during the TLShandshake.</t> <t>Thehandshake.</li> <li pn="section-3-15.4" derivedCounter="4."> <t pn="section-3-15.4.1">The ACME server verifies that during the TLS handshake the application-layer protocol“acme-tls/1”"acme-tls/1" was successfully negotiated (and that the ALPN extension contained only the value“acme-tls/1”)"acme-tls/1") and that the certificate returned contains:<list style="symbols"> <t>a</t> <ul spacing="normal" bare="false" empty="false" pn="section-3-15.4.2"> <li pn="section-3-15.4.2.1">a subjectAltName extension containing the dNSName being validated and no otherentries</t> <t>aentries</li> <li pn="section-3-15.4.2.2">a critical acmeIdentifier extension containing the expected SHA-256 digest computed in step1</t> </list></t> </list></t> <t>The1</li> </ul> </li> </ol> <t pn="section-3-16">The comparison of dNSNamesMUST<bcp14>MUST</bcp14> be case insensitive <xreftarget="RFC4343"/>.target="RFC4343" format="default" sectionFormat="of" derivedContent="RFC4343"/>. Note that as ACMEdoesn’tdoesn't support Unicodeidentifiersidentifiers, all dNSNamesMUST<bcp14>MUST</bcp14> be encoded using the rules of <xreftarget="RFC3492"/> rules.</t> <t>Iftarget="RFC3492" format="default" sectionFormat="of" derivedContent="RFC3492"/>.</t> <t pn="section-3-17">If all of the above stepssucceedsucceed, then the validation issuccessful, otherwisesuccessful. Otherwise, it fails.</t> </section> <section anchor="acme-tls1-protocol-definition"title="acme-tls/1numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-acme-tls-1-protocol-definit">acme-tls/1 ProtocolDefinition"> <t>The “acme-tls/1”Definition</name> <t pn="section-4-1">The "acme-tls/1" protocolMUST<bcp14>MUST</bcp14> only be used for validating ACME tls-alpn-01 challenges. The protocol consists of a TLS handshake in which the required validation information is transmitted. The“acme-tls/1”"acme-tls/1" protocol does not carry applicationdata, oncedata. Once the handshake iscompletedcompleted, the clientMUST NOT<bcp14>MUST NOT</bcp14> exchange any further data with the server andMUST<bcp14>MUST</bcp14> immediately close the connection. While this protocol uses X.509 certificates, it does not use the authentication method described in <xreftarget="RFC5280"/> andtarget="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> and, assuchsuch, does not require a valid signature on the provided certificate nor require the TLS handshake to complete successfully. An ACME server may wish to use anoff the shelfoff-the-shelf TLS stack where it is not simple to allow these divergences in the protocol as defined. Because of this, an ACME serverMAY<bcp14>MAY</bcp14> choose to withhold authorization if either the certificate signature is invalid or the handshakedoesn’tdoesn't fully complete.</t><t>ACME<t pn="section-4-2">ACME servers that implement“acme-tls/1” MUST"acme-tls/1" <bcp14>MUST</bcp14> only negotiate TLS 1.2 <xreftarget="RFC5246"/>target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> or higher when connecting to clients for validation.</t> </section> <section anchor="security-considerations"title="Security Considerations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-5-1">The design of this challenge relies on some assumptions centered around howaan HTTPS server behaves during validation.</t><t>The<t pn="section-5-2">The first assumption is that whenaan HTTPS server is being used to serve content for multiple DNS names from a single IPaddressaddress, it properly segregates control of those names to the users that own them. This means that if User A registers Host A and User B registers HostBB, the HTTPS server should not allow a TLS request using an SNI value for Host A to be served by User B or a TLS connection with a server_name extension identifying Host B to be answered by User A. If the HTTPS server allows User B to serve thisrequestrequest, it allows them to illegitimately validate control of Host A to the ACME server.</t><t>The<t pn="section-5-3">The second assumption is that a server will not violate <xreftarget="RFC7301"/>target="RFC7301" format="default" sectionFormat="of" derivedContent="RFC7301"/> by blindly agreeing to use the“acme-tls/1”"acme-tls/1" protocol without actually understanding it.</t><t>To<t pn="section-5-4">To further mitigate the risk of users claiming domain names used by other users on the same infrastructure hosting providers, CDNs, and other service providersSHOULD NOT<bcp14>SHOULD NOT</bcp14> allow users to provide their own certificates for the TLS ALPN validation process. If providers wish to implement TLS ALPNvalidationvalidation, theySHOULD<bcp14>SHOULD</bcp14> only generate certificates used for validation themselves and not expose this functionality to users.</t><t>The<t pn="section-5-5">The extensions to the ACME protocol described in this document build upon the Security Considerations and threat model defined in <xreftarget="RFC8555"/> Section 10.1.</t>target="RFC8555" sectionFormat="of" section="10.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.1" derivedContent="RFC8555"/>.</t> </section> <section anchor="iana-considerations"title="IANA Considerations"> <t>[[RFC Editor: please replace I-D.ietf-acme-tls-alpn below by the RFC number.]]</t>numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <section anchor="smi-security-for-pkix-certificate-extension-oid"title="SMInumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-smi-security-for-pkix-certi">SMI Security for PKIX Certificate ExtensionOID"> <t>WithinOID</name> <t pn="section-6.1-1">Within theSMI-numbers"Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry, the“SMIfollowing entry has been added to the "SMI Security for PKIX CertificateExtension (1.3.6.1.5.5.7.1)” table is to be updated to add the following entry:</t> <texttable> <ttcol align='left'>Decimal</ttcol> <ttcol align='left'>Description</ttcol> <ttcol align='left'>References</ttcol> <c>31</c> <c>id-pe-acmeIdentifier</c> <c>I-D.ietf-acme-tls-alpn</c> </texttable>Extension" (1.3.6.1.5.5.7.1) table.</t> <table align="center" pn="table-1"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Decimal</th> <th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">References</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">31</td> <td align="left" colspan="1" rowspan="1">id-pe-acmeIdentifier</td> <td align="left" colspan="1" rowspan="1">RFC 8737</td> </tr> </tbody> </table> </section> <section anchor="alpn-protocol-id"title="ALPNnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-alpn-protocol-id">ALPN ProtocolID"> <t>WithinID</name> <t pn="section-6.2-1">Within theTransport"Transport Layer Security (TLS)ExtensionsExtensions" registry, the“Application-Layerfollowing entry has been added to the "TLS Application-Layer Protocol Negotiation (ALPN) ProtocolIDs” table is to be updated to add the following entry:</t> <texttable> <ttcol align='left'>Protocol</ttcol> <ttcol align='left'>Identification Sequence</ttcol> <ttcol align='left'>Reference</ttcol> <c>acme-tls/1</c> <c>0x61IDs" table.</t> <table align="center" pn="table-2"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Protocol</th> <th align="left" colspan="1" rowspan="1">Identification Sequence</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">acme-tls/1</td> <td align="left" colspan="1" rowspan="1">0x61 0x63 0x6d 0x65 0x2d 0x74 0x6c 0x73 0x2f 0x31(“acme-tls/1”)</c> <c>I-D.ietf-acme-tls-alpn</c> </texttable>("acme-tls/1")</td> <td align="left" colspan="1" rowspan="1">RFC 8737</td> </tr> </tbody> </table> </section> <section anchor="acme-validation-method"title="ACMEnumbered="true" toc="include" removeInRFC="false" pn="section-6.3"> <name slugifiedName="name-acme-validation-method">ACME ValidationMethod"> <t>The “ACME Validation Methods” registry is to be updated to includeMethod</name> <t pn="section-6.3-1">Within the "Automated Certificate Management Environment (ACME) Protocol" registry, the followingentry:</t> <texttable> <ttcol align='left'>Label</ttcol> <ttcol align='left'>Identifier Type</ttcol> <ttcol align='left'>ACME</ttcol> <ttcol align='left'>Reference</ttcol> <c>tls-alpn-01</c> <c>dns</c> <c>Y</c> <c>I-D.ietf-acme-tls-alpn</c> </texttable> </section> </section> <section anchor="acknowledgements" title="Acknowledgements"> <t>The author would likeentry has been added tothank all those whom have provided design insights and editorial review of this document, including Richard Barnes, Ryan Hurst, Adam Langley, Ryan Sleevi, Jacob Hoffman-Andrews, Daniel McCarney, Marcin Walas, Martin Thomson and especially Frans Rosén, who discovered the vulnerability intheTLS SNI method that necessitated the writing of this specification.</t>"ACME Validation Methods" registry.</t> <table align="center" pn="table-3"> <thead> <tr> <th align="left" colspan="1" rowspan="1">Label</th> <th align="left" colspan="1" rowspan="1">Identifier Type</th> <th align="left" colspan="1" rowspan="1">ACME</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">tls-alpn-01</td> <td align="left" colspan="1" rowspan="1">dns</td> <td align="left" colspan="1" rowspan="1">Y</td> <td align="left" colspan="1" rowspan="1">RFC 8737</td> </tr> </tbody> </table> </section> </section> </middle> <back> <referencestitle='Normative References'>pn="section-7"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf" quoteTitle="true" derivedAnchor="FIPS180-4"> <front> <title>Secure Hash Standard (SHS)</title> <author> <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization> </author> <date year="2015" month="August"/> </front> <seriesInfo name="FIPS PUB" value="180-4"/> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> </reference> <reference anchor="RFC2119"target='https://www.rfc-editor.org/info/rfc2119'>target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <authorinitials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <dateyear='1997' month='March' /> <abstract><t>Inyear="1997" month="March"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions forimprovements.</t></abstract>improvements.</t> </abstract> </front> <seriesInfoname='BCP' value='14'/>name="BCP" value="14"/> <seriesInfoname='RFC' value='2119'/>name="RFC" value="2119"/> <seriesInfoname='DOI' value='10.17487/RFC2119'/>name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3492"target='https://www.rfc-editor.org/info/rfc3492'>target="https://www.rfc-editor.org/info/rfc3492" quoteTitle="true" derivedAnchor="RFC3492"> <front> <title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title> <authorinitials='A.' surname='Costello' fullname='A. Costello'><organization /></author>initials="A." surname="Costello" fullname="A. Costello"> <organization showOnFrontPage="true"/> </author> <dateyear='2003' month='March' /> <abstract><t>Punycodeyear="2003" month="March"/> <abstract> <t>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA.[STANDARDS-TRACK]</t></abstract>[STANDARDS-TRACK]</t> </abstract> </front> <seriesInfoname='RFC' value='3492'/>name="RFC" value="3492"/> <seriesInfoname='DOI' value='10.17487/RFC3492'/>name="DOI" value="10.17487/RFC3492"/> </reference> <referenceanchor="RFC4343" target='https://www.rfc-editor.org/info/rfc4343'>anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086"> <front><title>Domain Name System (DNS) Case Insensitivity Clarification</title><title>Randomness Requirements for Security</title> <authorinitials='D.' surname='Eastlake 3rd' fullname='D.initials="D." surname="Eastlake 3rd" fullname="D. Eastlake3rd'><organization /></author>3rd"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Schiller" fullname="J. Schiller"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Crocker" fullname="S. Crocker"> <organization showOnFrontPage="true"/> </author> <dateyear='2006' month='January' /> <abstract><t>Domain Name System (DNS) namesyear="2005" month="June"/> <abstract> <t>Security systems are"case insensitive". This document explains exactly whatbuilt on strong cryptographic algorithms thatmeansfoil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, andprovides a clear specificationsimilar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce therules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='4343'/> <seriesInfo name='DOI' value='10.17487/RFC4343'/> </reference> <reference anchor="RFC4648" target='https://www.rfc-editor.org/info/rfc4648'> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author> <date year='2006' month='October' /> <abstract><t>This document describesenvironment that produced thecommonly used base 64, base 32,secret quantities andbase 16 encoding schemes. It also discussesto search theuse of line-feeds in encoded data, use of padding in encoded data, useresulting small set ofnon-alphabet characterspossibilities than to locate the quantities inencoded data, usethe whole ofdifferent encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='4648'/>the potential number space.</t> <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="106"/> <seriesInfo name="RFC" value="4086"/> <seriesInfo name="DOI" value="10.17487/RFC4086"/> </reference> <reference anchor="RFC4343" target="https://www.rfc-editor.org/info/rfc4343" quoteTitle="true" derivedAnchor="RFC4343"> <front> <title>Domain Name System (DNS) Case Insensitivity Clarification</title> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"> <organization showOnFrontPage="true"/> </author> <date year="2006" month="January"/> <abstract> <t>Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4343"/> <seriesInfo name="DOI" value="10.17487/RFC4343"/> </reference> <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648"> <front> <title>The Base16, Base32, and Base64 Data Encodings</title> <author initials="S." surname="Josefsson" fullname="S. Josefsson"> <organization showOnFrontPage="true"/> </author> <date year="2006" month="October"/> <abstract> <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4648"/> <seriesInfoname='DOI' value='10.17487/RFC4648'/>name="DOI" value="10.17487/RFC4648"/> </reference> <reference anchor="RFC5246"target='https://www.rfc-editor.org/info/rfc5246'>target="https://www.rfc-editor.org/info/rfc5246" quoteTitle="true" derivedAnchor="RFC5246"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title> <authorinitials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author> <author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>initials="T." surname="Dierks" fullname="T. Dierks"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Rescorla" fullname="E. Rescorla"> <organization showOnFrontPage="true"/> </author> <dateyear='2008' month='August' /> <abstract><t>Thisyear="2008" month="August"/> <abstract> <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.[STANDARDS-TRACK]</t></abstract>[STANDARDS-TRACK]</t> </abstract> </front> <seriesInfoname='RFC' value='5246'/>name="RFC" value="5246"/> <seriesInfoname='DOI' value='10.17487/RFC5246'/>name="DOI" value="10.17487/RFC5246"/> </reference> <reference anchor="RFC5280"target='https://www.rfc-editor.org/info/rfc5280'>target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280"> <front> <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title> <authorinitials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author> <author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author> <author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author> <author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author> <author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author> <author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>initials="D." surname="Cooper" fullname="D. Cooper"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Santesson" fullname="S. Santesson"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Farrell" fullname="S. Farrell"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Boeyen" fullname="S. Boeyen"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Housley" fullname="R. Housley"> <organization showOnFrontPage="true"/> </author> <author initials="W." surname="Polk" fullname="W. Polk"> <organization showOnFrontPage="true"/> </author> <dateyear='2008' month='May' /> <abstract><t>Thisyear="2008" month="May"/> <abstract> <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices.[STANDARDS-TRACK]</t></abstract>[STANDARDS-TRACK]</t> </abstract> </front> <seriesInfoname='RFC' value='5280'/>name="RFC" value="5280"/> <seriesInfoname='DOI' value='10.17487/RFC5280'/>name="DOI" value="10.17487/RFC5280"/> </reference> <reference anchor="RFC6066"target='https://www.rfc-editor.org/info/rfc6066'>target="https://www.rfc-editor.org/info/rfc6066" quoteTitle="true" derivedAnchor="RFC6066"> <front> <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title> <authorinitials='D.' surname='Eastlake 3rd' fullname='D.initials="D." surname="Eastlake 3rd" fullname="D. Eastlake3rd'><organization /></author>3rd"> <organization showOnFrontPage="true"/> </author> <dateyear='2011' month='January' /> <abstract><t>Thisyear="2011" month="January"/> <abstract> <t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246,"The"The Transport Layer Security (TLS) Protocol Version1.2".1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.[STANDARDS-TRACK]</t></abstract>[STANDARDS-TRACK]</t> </abstract> </front> <seriesInfoname='RFC' value='6066'/>name="RFC" value="6066"/> <seriesInfoname='DOI' value='10.17487/RFC6066'/>name="DOI" value="10.17487/RFC6066"/> </reference> <reference anchor="RFC7301"target='https://www.rfc-editor.org/info/rfc7301'>target="https://www.rfc-editor.org/info/rfc7301" quoteTitle="true" derivedAnchor="RFC7301"> <front> <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> <authorinitials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author> <author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author> <author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author> <author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>initials="S." surname="Friedl" fullname="S. Friedl"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Popov" fullname="A. Popov"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Langley" fullname="A. Langley"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Stephan" fullname="E. Stephan"> <organization showOnFrontPage="true"/> </author> <dateyear='2014' month='July' /> <abstract><t>Thisyear="2014" month="July"/> <abstract> <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLSconnection.</t></abstract> </front> <seriesInfo name='RFC' value='7301'/> <seriesInfo name='DOI' value='10.17487/RFC7301'/> </reference> <reference anchor="RFC8555" target='https://www.rfc-editor.org/info/rfc8555'> <front> <title>Automatic Certificate Management Environment (ACME)</title> <author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></author> <author initials='J.' surname='Hoffman-Andrews' fullname='J. Hoffman-Andrews'><organization /></author> <author initials='D.' surname='McCarney' fullname='D. McCarney'><organization /></author> <author initials='J.' surname='Kasten' fullname='J. Kasten'><organization /></author> <date year='2019' month='March' /> <abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>connection.</t> </abstract> </front> <seriesInfoname='RFC' value='8555'/>name="RFC" value="7301"/> <seriesInfoname='DOI' value='10.17487/RFC8555'/> </reference> <reference anchor="FIPS180-4" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf"> <front> <title>NIST FIPS 180-4, Secure Hash Standard</title> <author initials="National Institute of Standards and Technology, U.S." surname="Department of Commerce" fullname="NIST"> <organization></organization> </author> <date year="2012" month="March"/> </front> </reference> <reference anchor="X.690" target="https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf"> <front> <title>Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author initials="." surname="International Telecommunication Union" fullname="ITU-T"> <organization></organization> </author> <date year="2015"/> </front> </reference> <reference anchor="X.680" target="https://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf"> <front> <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author initials="." surname="International Telecommunication Union" fullname="ITU-T"> <organization></organization> </author> <date year="2015"/> </front>name="DOI" value="10.17487/RFC7301"/> </reference> <reference anchor="RFC8174"target='https://www.rfc-editor.org/info/rfc8174'>target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <authorinitials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <dateyear='2017' month='May' /> <abstract><t>RFCyear="2017" month="May"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined specialmeanings.</t></abstract>meanings.</t> </abstract> </front> <seriesInfoname='BCP' value='14'/>name="BCP" value="14"/> <seriesInfoname='RFC' value='8174'/>name="RFC" value="8174"/> <seriesInfoname='DOI' value='10.17487/RFC8174'/>name="DOI" value="10.17487/RFC8174"/> </reference> <referenceanchor="RFC4086" target='https://www.rfc-editor.org/info/rfc4086'>anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc8555" quoteTitle="true" derivedAnchor="RFC8555"> <front><title>Randomness Requirements for Security</title> <author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author><title>Automatic Certificate Management Environment (ACME)</title> <authorinitials='J.' surname='Schiller' fullname='J. Schiller'><organization /></author> <author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></author> <date year='2005' month='June' /> <abstract><t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t><t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can beinitials="R." surname="Barnes" fullname="R. Barnes"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Hoffman-Andrews" fullname="J. Hoffman-Andrews"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="McCarney" fullname="D. McCarney"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Kasten" fullname="J. Kasten"> <organization showOnFrontPage="true"/> </author> <date year="2019" month="March"/> <abstract> <t>Public Key Infrastructure using X.509 (PKIX) certificates are used forthis purpose. It provides suggestions to ameliorate the problem whenahardware solutionnumber of purposes, the most significant of which isnot available, and it gives examplesthe authentication ofhow large such quantities needdomain names. Thus, certification authorities (CAs) in the Web PKI are trusted tobeverify that an applicant forsome applications.a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This documentspecifiesdescribes a protocol that a CA and anInternet Best Current Practices forapplicant can use to automate theInternet Community, and requests discussionprocess of verification andsuggestionscertificate issuance. The protocol also provides facilities forimprovements.</t></abstract>other certificate management functions, such as certificate revocation.</t> </abstract> </front> <seriesInfo name="RFC" value="8555"/> <seriesInfo name="DOI" value="10.17487/RFC8555"/> </reference> <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-201508-I/en" quoteTitle="true" derivedAnchor="X.680"> <front> <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization showOnFrontPage="true">ITU-T</organization> </author> <date month="August" year="2015"/> </front> <seriesInfoname='BCP' value='106'/>name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ISO/IEC" value="8824-1:2015"/> </reference> <reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690-201508-I/en" quoteTitle="true" derivedAnchor="X.690"> <front> <title>Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author> <organization showOnFrontPage="true">ITU-T</organization> </author> <date month="August" year="2015"/> </front> <seriesInfoname='RFC' value='4086'/>name="ITU-T Recommendation" value="X.690"/> <seriesInfoname='DOI' value='10.17487/RFC4086'/>name="ISO/IEC" value="8825-1:2015"/> </reference> </references> <section anchor="design-rationale"title="Design Rationale"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-design-rationale">Design Rationale</name> <t pn="section-appendix.a-1">The TLS ALPN challenge exists to iterate on the TLS SNI challenge defined in the early ACME drafts. The TLS SNI challenge was convenient for service providers who were either operating largeTLS layerTLS-layer load balancing systems at which they wanted to perform validation or running servers fronting large numbers of DNS names from a single host as it allowed validation purely within the TLS layer. The value provided by the TLS SNI challenge was considered large enough that this document was written in order to provide a new challenge type that addressed the existing security concerns.</t><t>A<t pn="section-appendix.a-2">A security issue in the TLS SNI challenge was discovered by Frans Rosen, which allowed users of various service providers to illegitimately validate control of the DNS names of other users of the provider. When the TLS SNI challenge wasdesigneddesigned, it was assumed that a user would only be able to respond to TLS traffic via SNI for domain names they had registered with a service provider (i.e., if a user registered‘a.example’'a.example', they would only be able to respond to SNI requests for‘a.example’'a.example' and not for SNI requests for‘b.example’).'b.example'). It turns out that a number of large service providers do not honor this property. Because of this, users were able to respond to SNI requests for the names used by the TLS SNI challenge validation process. This meant that (1) if User A and User B had registered Host A and Host B, respectively, User A would be able to claim the constructed SNI challenge name for HostBB, and (2) when the validation connection wasmade thatmade, User A would be able to answer, thereby proving‘control’'control' of Host B. As the SNI name used was a subdomain of the domain name being validated, rather than the domain name itself, it was likely to not already be registered with the service provider for traffic routing, making it much easier for a hijack to occur.</t> </section> <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-acknowledgments">Acknowledgments</name> <t pn="section-appendix.b-1">The author would like to thank all those that provided design insights and editorial review of this document, including <contact fullname="Richard Barnes"/>, <contact fullname="Ryan Hurst"/>, <contact fullname="Adam Langley"/>, <contact fullname="Ryan Sleevi"/>, <contact fullname="Jacob Hoffman-Andrews"/>, <contact fullname="Daniel McCarney"/>, <contact fullname="Marcin Walas"/>, <contact fullname="Martin Thomson"/>, and especially <contact fullname="Frans Rosen"/>, who discovered the vulnerability in the TLS SNI method that necessitated the writing of this specification.</t> </section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c"> <name slugifiedName="name-authors-address">Author's Address</name> <author initials="R.B." surname="Shoemaker" fullname="Roland Bracewell Shoemaker"> <organization abbrev="ISRG" showOnFrontPage="true">Internet Security Research Group</organization> <address> <email>roland@letsencrypt.org</email> </address> </author> </section> </back><!-- ##markdown-source: H4sIAGG4k10AA9Va63LbuJL+z6fA6vyIXUeiLV9yUdWpWt9mojmxnLGUMzM7 NTUFkZCEMQXoEKQVTZJ9n32OfbHtblwISrKTs/trnSqHJoFGo69fN9Dr9ZJK VoUYsM7F1e0Nm7wbs4t370fsasGLQqi5YDcfK6GM1KqT8Om0FI8DhkN7MLSH Q5NcZ4ovgURe8lnVk6Ka9Xi2FL2qMD1erFTv+FWS8UrMdbkZMFPlSSJX5YBV ZW2qk+PjN8cnCS8FH7DvhRIlL5K1Lh/mpa5Xdi32E/wt1Zx9j++SxFRc5b/z QitYdSNMspID9mulsy4zuqxKMTPwtFniw29JwutqoctBwnoJgx+pzIDdp+wy ZeOFFkv+IEr6YHdxrwugzi5Lnom1KIqtQbqcD9hQVaJUomJjkdWlrDbsXhjB y2zhWMSRXlrD8f339AKoyGLASlrg3wtRGaGycrOqUiCaJEqXS17JRwGcsvvv rk76/Tfu8fTszYl7PDs9O/WPL89eu8fzk7OX4fH1sXt8efzSv311etx3j6/P z8/x8bvh+3H/9XHvbEDcOTsYDccT+sToW9duUbC33CzYGAXPy9zuz4uVNcLD 2e4FiXkEG9KKFyAxAwvUlWB6FsgYhpKeiGyhdKHnmy77kI5Tdi1WvKyWQlU4 +Eovl6LMBJHNwYwG7OS4f9I7PrVs83IuqgFbVNVqcHSUmTJLlTRVOtePR6t6 WsiMeDBHM7myv2hj9NSjx3SVz4DWz+nLN8ctWXSGamaVolXEJuv12MV4lPYZ 6E/naJhlXQjY7nglMjlzKyLzl9zIjN34Yfc4jB1c3twfdtkVV1rB2GLn+xV8 J9Fcw0bgfS3NQuQ7w65hWOdJVQwnH3otXVij9QqZiEJkINpaeXY/KPjdlvL5 jogNyHi9Xqegy1Sq6ohWOTJVnW/IYc0REO2/OgITn9d8LswRibV3fHL8qpHz 62fkXLXlPDUVeCJ42kZV/CMb6coOu1OCHZAWDvfIfUpyV27w/wshvY6ElPRg 69xtPUkmC2kYhNmafMLYzYIFcKbEmmUhVIMQWbUQ7KKuNEgTTOZKlJUVjGC3 XMFaROJGPcpSK3o+wAh7yFalhgCqCyDAKwYU9doQwRxIScUyrSqIXOyRFzK3 sqgNGiPkgdQyvJR5Xogk+QtKsdR5neEwZD+wBEr5dpY+fXLR6ssXv2mnhVyY rJRTEMFSgFJzy6lnDZjy3IIpOP5R34Y9Ss7eTibvrXeNbLAp9IaWFR9XopTg 04ItuGFmodeKyYqB8HlhNOxXzGoQkGZTAdopBD66RcW2nKxwUBuYUwu+ESWj jJWCdBgGOJnVBS+7MIYWIIEvNDk8auNR5qKEPHZ1PYLfFCgh44J1LqWymyw0 z8HSwYoyGPkcM2sJUqortoT4Mdt4xkgQC6Bc4JupWPBHCWIEmcFXWQLp7EGo 3KRfs0BkDDwO7K2xxWqzErC3AAH6KSMizYhS/LOWJRBRgAwqafdkCfLVysft nhVdMM+2XC+ige9o4Hs/cOSpgr0cIFA5bKAMmNa/uaT45QsgAZFxUK7VRFgp 18ibrti0lkXOYBaHj0J8tEEZjDBYDm6+S0zxqSwQD4AywFZmEvBDJINm9wat SsxmIsOMX2yYXgF0Uim7YEaUjxJs0NsAWwJMwr+4H2tXts6vcwGRC2AJjoRV 5XJVWI+K1kVcxNaCZVw55W0Ah4G7zWGSMxKDZMj5kWYX1GPqgjYqcedheBQA rPOl6PETsksK29bhH8SGAYwD1+zcfhhPOl37Pxvd0fP9zY8fhvc31/g8fnvx 7l148CPGb+8+vLtunpqZV3e3tzejazsZ3rKtV7cXv3Ssx3Tu3k+Gd6OLdx27 udiIAXE6V5YY80GzGDDB731wyXHO5dV71j+zoQgBGYQiazuv+6/O4I/1Qii7 llagGfsnGMIGbRgQIQkPjCDjK1lBFOmyEFkWohRWdmDI6KGxNbPnrNmj9MMG pluh/x8o7aiV7A/sNITSR4xgcThl041zYu+SBNazQpL5aZw6k3NEj5xYQ8u2 VgrGtdIgNHj0kR1HK0Epg/GqEstVZSJvp6pEBAemXYJ3qMoFNNlACIw0jhe3 oo+LJk4MSHVrN54FXFO3mQa/gODt5/E8hy0YIAj/6eIRjMUn35gk2gVMDjEX MyvLogRI24glUKHoKApBQQF/5anVbBxErJRDHNXTP4BnSlm4/kxjKsH1rEAG SYKxmB24eJt30Zfh++EgGZCk7J+sE63RgUkagv8Tsy5YCVvTSxRsLezGACP9 s8bo5LSC6QH5CYy6BGCnUCyAhCNQsIXgEOH6J6/ZVILSQcYCtbTaQK6smA8b JB4ULVcbpIrYCPMeJDYDa9JiGIhfntVlAU63WvAplGjbHk2ujKUTeO/Y2ds5 8FZCcYZiePG3F5CecwLa0SrExdQKCzw7h+JRCBcLzo5fvwRqaAE40YHHyCIx eViJKbAan/kwDBmnX+c0oHaABqKNZ2CytU1Yu85cmjSimPWMnCvMupFFkS6I 2UZcDMvxoVdLGbkRGijQqsmELgqHfR/FCK1XbKVLrCwxXZLNfG1KmwWGfgyA KR+N7TjQL0XL0urNGoU0u04pcLvef3O7+JPbaS2KpCCj9E7OX7JcQsqtYB+h 6AV9OV/GTGVrA/mnlXYMPL1bt8z4ayyAnYDBVVTcQeYlnRCRSFHSqBfg6orn ECHQ7cF1asRQoGsoDHs2fulZteaUJ55dFSQX3I4o4Goy761Eb2uOixayeXNw N7w+ZE5gNAdyY9bSOcSQ/ww/yV66d5c/3FxN2PD6ZjQZfje8uWeDwd8Y++Qo nvbZl5gGbafhfzd42QL70yeqjKwewJdYm5OLltpwwburyc2EjSf3w9H37GA8 /I8bdnB6cni4b231D7I6ZwZ7d9WSMKUhYgsq76b2Jx7fHDcG1ebKOi0kwS7Y u8wW3j7NPgN90iR3zTBJ7rBSIVAT2xWKciogdGeloBpQVsEoCVLiduC1qYEX skxb4gD+qUv8kNelDTGY/bA8MAv+ICJn7fju3lG/8xxUD5x4gI/4igLO2OZU CgVDlXukcjAeDQ93wg52sUC4gZrDxbkXpEcIz4WNJLnwIdZBD4Ne8v5uPKG9 KoZ4Y8N+GN+NvIscfPpyiDCgJXb24f4dYYPsQel1IfK5iNw7jCJ58nzjEGZg xLumBRU2lDQ5K5iUMwOUJHAC0xZADLMQim/FN1T5yX2JzUUtn9hepv205TG4 Y3aECjxCA/vzqH9yenbUT95C4TkA0XMsH9JML5MrC0Z6EwAPg1jNR39oI/76 h8HS/lPCWCew2Rk0mzn4RG2RDi/m8LpzMwYr73TtuweJQzu+VRKt6jjLsgps y42GYJgJHP/D2+n5GZ/8/vfJz5c//Xj35/e/PFRvLvwwWPN5otF2sSH05bBL zFtptll33zC9cnRdJPxjf/rhfv6DvjHF9Lqfnadperr6JR/fvpP6/NXyx9Ho rJO0Yxx4KJhBJuSjtVFpUz86+qwE9MQDVg4m0aR5q2xT6dIBqT1BAYm0Da9D sK3jEipSoO91WeI6bjmQr67hf6DoEotH5lC+WMAa0BvNeLFVBkTuBga9hXB9 be5orrlpCgEqsLDPQlbdoPsm7ptKgP6SpL+L4kGVq7pyjAUi3xhB0+Rkl6ID 71+FHSTIbKE1Iv6oDBi+b1UCLoBuYbeDSLtQmjZNGj7HNFBBfQ91NthqREvO 2FJTuOWKFowC9GGanO5uBeIghVjjAndUTYUYBuyriGffkWlGUp7ATsgEyt6V Lit2drZnLRrmwjDGzn21GW3agr6QEEi07eyB6UAxiPvR/CiuU1H9NeW4hOXt LqSsNDnbUwo21g22+tRUW+Q9ndpam0ALh2yagUhndVFs4nx3YF3QucWWoNxG Rd7s0/ptTP6QtUjEqT5YnIcUtrnda0H6LVy+nTQdIN9n8EozDWNKQusgskA8 YNsn0dLWKk85q/NoSl/o+KzvqiF4z0tpbDPf8djUYBlEamzX42JYevgy7PTs FOuTkfZ1ECiGdI+tPETbpl6RVX9Q0jbOAu/Ugd1diTJyiFR2GTyMgxRLRz4Q PoczmuobA1MIkDaIWZsQuY2qTrk+KMjYZLpWzmuJ24LcAJWooc5QYwZN/+Za zMjXfWe9ZYrBQGkDZFWwCyortjrkJJf9rUnrNIEUZiRpbF2+DQpBbxbU4vZ8 q6C1z6gIRggNVbBZyiqUcvu5D63XjJflJnZEPHbhIC8LfUXMiiGzKaiN16Su pn0gPsIWMUdi/2BWl2TaSC4KWK7XA8ZP0+RyKXJ0ZJBjVmhj12wCZsp+Wshi u3FcYwT/OT0/fhN7q+mibsPOakcMkxQaYdbqvW0Bu6YSsxHTWPQeiDnJg3pI 9CwAF2w8OCTpMHMUPpQuw8w9EVAHebaiW8ouVCuiLjlU8tIscAbuCjPWzHqD WYhiZsFABYjZ1RC23kC+DXWrCU9j/sc5QCAHly7neA5jfFkaZEvdnBnGzKZt T64n6ZCknaYg2dqkjSugkhe6yLcwFGRaIckUtqNrI0SsrpWVrCvDGjH50GIj v5cYFhwNJy7ZNK35ltU3rhryBomsn54E1Z9hBQRrL+QcWcU281az0lr7duOI oki4pHCFngx1hD0Qt+EDLA326WXYOp4pJKEdZjS2Mo2poUTCiSAl7JhjligB R0J1Aqqz52oB9dFpEkx3CbbFES47k6WpIqK2vgYh0da2iEnj8hMFMuwZ4/vQ LsUtBwx1PRq7sz4HsR0IaWAP2h/Y00qUIHIj5qWY77aG0WgsGYeeYGmvR2ze w6ulw09LwZXX8Ix9gHHYHxVziJk4BSsreIF+S98ut79dhsO4sGGz0HWRk4tY x7Bx1xcPNhs53GQRA8rArWRLTqJE9aZbFZuT28iQAh93q/6u2kgh7q57Ru3R pzJrUr8nfpGy4Wx3F+5M060f1Naqg2Q4a0aJ0gEW2N8c8tvSht2AliP1NBut 2uguVDOZpjC5Y108VCV4MofyfZS6QPLxiSBubFpIlcP6HOxDOB/zMXt/0vKH rDyrao7BAFwDlIx3XeiAokLudMg8kAXl3HZswdmkecCdWSvLCi6XdMQYn137 5qDFZHakC+8GNQeptuSh2/T8UbKlsX3SaFhz1OYMz5m9DnDfHg2jC8S5LfSn wgWyCAPA1IzKDTCSZimfMpqouG8uHaU5rihGzumKWCXay+8gHDt1aQSVdxbN 0gm/9ue8s1pltlPvzmtpq+lWZ9K0rKwBKHF+bp8r2tPieuVU80TwdaAeW3R4 Ki8Kn9ae6uT0j6mV8xc2vBhd7ETyX3+FGewml5UuB2yFByoYwVcFB/UOe9fp 7q088GRUsGtI4XRVL6fgQ7/9BstA1rgdNsyjaN//ffhz6/ZGc5x+N7xOkp/A /n3b/XbYs9SMi3blxp6Pd/4Vsgf99DTFFtY5/HuV9g87rKJ7F9K4UFSvbLmC CCLPt1oJdMgwSJLPgJkziCcFY/iImrNRIfx8ZvdiBiGNIEf88zn5POj5n+gx /nniNXyAlU/7YYm9DebPT2nnMymB3CFA/y0pTxBMUz1jj3iDWPFYN7rtsKOD f+3WRLS8+d8qINBAQfjtO8g7xlSAeP6bfyJ1bX1IWsp4UjPf/vOscqPy7DM7 /viyj79O8VeOv87h1wk+vTrDPzN8wq8nM/gFhnHQLvO/ZgoYgP7RhLdbqhRc Dbj/I6jLa36vxqTKitqdnO7T2jsOMSLIPLJa7AnDG1r1W5WxR5TuzbMyjkvU zyxXW/7JfnHMPS06dtH06unI1Z2lURnA1oS0CmkrHuy3PVA9byHgegEYko6p QwXlALME15ovXJdWUOCVEGFK8SjFOsBpnxW6TtZ0e1PisXLOLnmpsCq83wCS e1sDUuiyi5wvQeyIWDfuy7gQQLPLfuCZngL0mc2WXPUuFGDZNcy+5kqCkm6z KyQHk255mUGA+IkX3NBfgAIAqOqlcee9gu4bEEL5DiMIu9fmv/9L4fGUhtrL ZNjidTX0Y11gunWXmnzcgTyNyNPVqgSsAFFCipcV99X3GntE/igDux3xBT53 YRAvmKGCrq1I7921y+gyC8W/piahu1dkyLKyKEC3WWqGRumUOlAc0b5tBuE1 ddfk2J3n2tWPQklfW+zCJJQUQmBfOmIx4e7k4TXQ6MpfdEePutsbAP5Lw6jQ cX0TqJ65ch4JdLBfEsMYLNJrRa00X01CZaOi1XymBVE/Vf0gGMTa2cPtdpNm BXgRLy9FqcVvwIrJ1hjBBRxmeFJ4BE1gnGVPKF3PF76DGUMlHI52AnmqdYct tJa37rfSPRaL412nPHftRXclz/gMmGGDqFSGDv7CWwkFgdi24jb3kf1PI/8Q yp/eevE5/D0D2ZRS12aPlXxbMYO8NGqDFy18Hw4CiSb2m8Sz7At3JURa6VIJ JHJf/CBRF/F8b9DfY41uZCHpCpwEryThhVlcJroJ7MpiNNwFGLevZmGVqJxs XWA8kKlIu1gdOxaiOS946o7qXjhn+Bp7yI4rH23dEZPwSB/f7w6choGHdLUI 2+d0gcgLyLoSit3a7q5Sc030F1pRxWP7fuC21WZPQ8oqkSLFt2wE9dqu9fZr el9tFVoR1XYrIuo8bOkrak3YAp9ufa78ndSup2BVEmmDClTfC7UlJzb3W0xS NyG0JS5plfWeTnjcjgCLXfLc+fhTi9v2Q9fqBC9sOWd6EVoDlym7cNcrgCVi hARKHoFHI86S910CbJ+DgEC4aw5ytTNYVngLq+udDUFEQaWkbdzYGwBTseMi vtXcchIyAOd1JZgk8NEFaTzY3gFbYsMXyjrphnK2kH9gTxWW0xkEuDT5HyHt H13ONQAA --></rfc>