rfc8737xml2.original.xml   rfc8737.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 --> nsus="true" docName="draft-ietf-acme-tls-alpn-07" indexInclude="true" ipr="trust
200902" number="8737" prepTime="2020-02-28T19:13:09" scripts="Common,Latin" sort
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ Refs="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=
<?rfc toc="yes"?> "prev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8737" rel="alternate"/>
<?rfc symrefs="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<rfc ipr="trust200902" docName="draft-ietf-acme-tls-alpn-07" category="std">
<front> <front>
<title abbrev="ACME-TLS-ALPN">ACME TLS ALPN Challenge Extension</title> <title abbrev="ACME-TLS-ALPN">Automated Certificate Management Environment (
ACME) TLS Application‑Layer Protocol Negotiation (ALPN) Challenge Extension</tit
le>
<seriesInfo name="RFC" value="8737" stream="IETF"/>
<author initials="R.B." surname="Shoemaker" fullname="Roland Bracewell Shoem aker"> <author initials="R.B." surname="Shoemaker" fullname="Roland Bracewell Shoem aker">
<organization abbrev="ISRG">Internet Security Research Group</organization > <organization abbrev="ISRG" showOnFrontPage="true">Internet Security Resea rch Group</organization>
<address> <address>
<email>roland@letsencrypt.org</email> <email>roland@letsencrypt.org</email>
</address> </address>
</author> </author>
<date month="02" year="2020"/>
<date year="2019" month="October" day="01"/> <area>Security</area>
<area>General</area>
<workgroup>ACME Working Group</workgroup> <workgroup>ACME Working Group</workgroup>
<keyword>acme</keyword>
<abstract> <keyword>pki</keyword>
<abstract pn="section-abstract">
<t>This document specifies a new challenge for the Automated Certificate Managem <t pn="section-abstract-1">This document specifies a new challenge for the
ent Environment (ACME) protocol that allows for domain control validation using Automated Certificate Management Environment (ACME) protocol that allows for do
TLS.</t> main control validation using TLS.</t>
</abstract> </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="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.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 derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</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 derivedCon
tent="" 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 derivedCon
tent="" format="title" sectionFormat="of" target="name-tls-with-application-laye
r-">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 derivedCon
tent="" format="title" sectionFormat="of" target="name-acme-tls-1-protocol-defin
it">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 derivedCon
tent="" 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 derivedCon
tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derive
dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
f 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 derive
dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
f 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 derive
dContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-acme-validati
on-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 derivedCon
tent="" format="title" sectionFormat="of" target="name-normative-references">Nor
mative 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 derivedC
ontent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknow
ledgments</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-address">Autho
r's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">The Automatic Certificate Management Environment (ACME
) <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC
8555"/> 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, Content Distribution Networks (CDNs), and TLS-terminating
load balancers to validate domain control without modifying the HTTP handl
ing behavior of their backends.</t>
<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 <xref target="RFC7301" format="default" sectionFormat="of" deriv
edContent="RFC7301"/>.
<section anchor="introduction" title="Introduction"> Because this protocol does not build on a pre-existing deployment base, the
ability to complete tls-alpn-01 challenges requires changes by service
<t>The Automatic Certificate Management Environment (ACME) <xref target="RFC8555 providers, making it explicitly an opt-in process. Because service providers mus
"/> specification describes methods for validating control of domain names via H t
TTP and DNS. Deployment experience has shown it is also useful to be able to val proactively deploy new code in order to implement tls-alpn-01, we can specify
idate domain control using the TLS layer alone. In particular, this allows hosti stronger controls in that code, resulting in a stronger validation method.
ng providers, CDNs, and TLS-terminating load balancers to validate domain contro </t>
l without modifying the HTTP handling behavior of their backends.</t> </section>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
<t>This document specifies a new TLS-based challenge type, tls-alpn-01. This cha se" pn="section-2">
llenge requires negotiating a new application-layer protocol using the TLS Appli <name slugifiedName="name-terminology">Terminology</name>
cation-Layer Protocol Negotiation (ALPN) Extension <xref target="RFC7301"/>. Bec <t pn="section-2-1">
ause this protocol does not build on a preexisting deployment base, the ability The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
to fulfill tls-alpn-01 challenges is effectively opt-in. A service provider must IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
proactively deploy new code in order to implement tls-alpn-01, so we can specif D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
y stronger controls in that code, resulting in a stronger validation method.</t> OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
<section anchor="terminology" title="Terminology"> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, mat="of" derivedContent="RFC8174"/>
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this d when, and only when, they appear in all capitals, as shown here.
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x </t>
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show </section>
n here.</t> <section anchor="tls-with-application-layer-protocol-negotiation-tls-alpn-ch
allenge" numbered="true" toc="include" removeInRFC="false" pn="section-3">
</section> <name slugifiedName="name-tls-with-application-layer-">TLS with Applicatio
<section anchor="tls-with-application-layer-protocol-negotiation-tls-alpn-challe n-Layer Protocol Negotiation (TLS ALPN) Challenge</name>
nge" title="TLS with Application Layer Protocol Negotiation (TLS ALPN) Challenge <t pn="section-3-1">The TLS with Application-Layer Protocol Negotiation (T
"> LS ALPN) validation method proves control over a domain name by requiring the AC
ME client to configure a TLS server to respond to specific connection attempts u
<t>The TLS with Application Layer Protocol Negotiation (TLS ALPN) validation met sing the ALPN extension with identifying information. The ACME server validates
hod proves control over a domain name by requiring the ACME client to configure control of the domain name by connecting to a TLS server at one of the addresses
a TLS server to respond to specific connection attempts using the ALPN extension resolved for the domain name and verifying that a certificate with specific con
with identifying information. The ACME server validates control of the domain n tent is presented.</t>
ame by connecting to a TLS server at one of the addresses resolved for the domai <t pn="section-3-2">The tls-alpn-01 ACME challenge object has the followin
n name and verifying that a certificate with specific content is presented.</t> g format:</t>
<dl newline="false" spacing="normal" pn="section-3-3">
<t>The tls-alpn-01 ACME challenge object has the following format:</t> <dt pn="section-3-3.1">type (required, string):</dt>
<dd pn="section-3-3.2">
<t><list style="hanging"> The string "tls-alpn-01"</dd>
<t hangText='type (required, string):'> <dt pn="section-3-3.3">token (required, string):</dt>
The string “tls-alpn-01”</t> <dd pn="section-3-3.4">
<t hangText='token (required, string):'> A random value that uniquely identifies the challenge. This value
A random value that uniquely identifies the challenge. This value MUST have at <bcp14>MUST</bcp14> have at least 128 bits of entropy. It <bcp14>MUST NOT
least 128 bits of entropy. It MUST NOT contain any characters outside the base6 </bcp14> contain any characters outside the base64url alphabet as
4url alphabet as described in <xref target="RFC4648"/> Section 5. Trailing ‘=’ p described in <xref target="RFC4648" sectionFormat="of" section="5" format
adding characters MUST be stripped. See <xref target="RFC4086"/> for additional ="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedCon
information on randomness requirements.</t> tent="RFC4648"/>. Trailing '=' padding characters <bcp14>MUST</bcp14> be strippe
</list></t> d. See <xref target="RFC4086" format="default" sectionFormat="of" derivedContent
="RFC4086"/> for additional information on randomness requirements.</dd>
<t>The client prepares for validation by constructing a self-signed certificate </dl>
that MUST contain an acmeIdentifier extension and a subjectAlternativeName exten <t pn="section-3-4">The client prepares for validation by constructing a s
sion <xref target="RFC5280"/>. The subjectAlternativeName extension MUST contain elf-signed certificate that <bcp14>MUST</bcp14> contain an acmeIdentifier extens
a single dNSName entry where the value is the domain name being validated. The ion and a subjectAlternativeName extension <xref target="RFC5280" format="defaul
acmeIdentifier extension MUST contain the SHA-256 digest <xref target="FIPS180-4 t" sectionFormat="of" derivedContent="RFC5280"/>. The subjectAlternativeName ext
"/> of the key authorization <xref target="RFC8555"/> for the challenge. The acm ension <bcp14>MUST</bcp14> contain a single dNSName entry where the value is the
eIdentifier extension MUST be critical so that the certificate isn’t inadvertent domain name being validated. The acmeIdentifier extension <bcp14>MUST</bcp14> c
ly used by non-ACME software.</t> ontain the SHA-256 digest <xref target="FIPS180-4" format="default" sectionForma
t="of" derivedContent="FIPS180-4"/> of the key authorization <xref target="RFC85
<t>The acmeIdentifier extension is identified by the id-pe-acmeIdentifier object 55" format="default" sectionFormat="of" derivedContent="RFC8555"/> for the chall
identifier (OID) in the id-pe arc <xref target="RFC5280"/>:</t> enge. The acmeIdentifier extension <bcp14>MUST</bcp14> be critical so that the c
ertificate isn't inadvertently used by non-ACME software.</t>
<figure><artwork><![CDATA[ <t pn="section-3-5">The acmeIdentifier extension is identified by the id-p
e-acmeIdentifier object identifier (OID) in the id-pe arc <xref 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 } id-pe-acmeIdentifier OBJECT IDENTIFIER ::= { id-pe 31 }
]]></artwork></figure> </sourcecode>
<t pn="section-3-7">The extension has the following ASN.1 <xref target="X.
<t>The extension has the following ASN.1 <xref target="X.680"/> format :</t> 680" format="default" sectionFormat="of" derivedContent="X.680"/> format :</t>
<sourcecode type="asn.1" markers="false" pn="section-3-8">
<figure><artwork><![CDATA[
Authorization ::= OCTET STRING (SIZE (32)) Authorization ::= OCTET STRING (SIZE (32))
]]></artwork></figure> </sourcecode>
<t pn="section-3-9">The extnValue of the id-pe-acmeIdentifier extension is
<t>The extnValue of the id-pe-acmeIdentifier extension is the ASN.1 DER encoding the ASN.1 DER encoding <xref target="X.690" format="default" sectionFormat="of"
<xref target="X.690"/> of the Authorization structure, which contains the SHA-2 derivedContent="X.690"/> of the Authorization structure, which contains the SHA
56 digest of the key authorization for the challenge.</t> -256 digest of the key authorization for the challenge.</t>
<t pn="section-3-10">Once this certificate has been created, it <bcp14>MUS
<t>Once this certificate has been created it MUST be provisioned such that it is T</bcp14> be provisioned such that it is returned during a TLS handshake where t
returned during a TLS handshake where the “acme-tls/1” application-layer protoc he "acme-tls/1" application-layer protocol has been negotiated and a Server Name
ol has been negotiated and a Server Name Indication (SNI) extension <xref target Indication (SNI) extension <xref target="RFC6066" format="default" sectionForma
="RFC6066"/> has been provided containing the domain name being validated.</t> t="of" derivedContent="RFC6066"/> has been provided containing the domain name b
eing validated.</t>
<t>A client responds by POSTing an empty JSON object ({}) to the challenge URL t <t pn="section-3-11">A client responds by POSTing an empty JSON object ({}
o acknowledge that the challenge is ready to be validated by the server. The bas ) to the
e64url encoding of the protected headers and payload is described in <xref targe challenge URL to acknowledge that the challenge is ready to be validated
t="RFC8555"/> Section 6.1.</t> by the server. The base64url encoding of the protected headers and
payload is described in <xref target="RFC8555" sectionFormat="of" section=
<figure><artwork><![CDATA[ "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 POST /acme/authz/1234/1
Host: example.com Host: example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/1", "kid": "https://example.com/acme/acct/1",
"nonce": "JHb54aT_KTXBWQOzGYkt9A", "nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/authz/1234/1" "url": "https://example.com/acme/authz/1234/1"
}), }),
"payload": base64url({}), "payload": base64url({}),
"signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4" "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
} }</sourcecode>
]]></artwork></figure> <t pn="section-3-13">On receiving this request from a client, the server c
onstructs and stores the key authorization from the challenge "token" value and
<t>On receiving this request from a client the server constructs and stores the the current client account key.</t>
key authorization from the challenge “token” value and the current client accoun <t pn="section-3-14">The server then verifies the client's control over th
t key.</t> e domain by verifying that the TLS server was configured as expected using the f
ollowing steps:</t>
<t>The server then verifies the client’s control over the domain by verifying th <ol spacing="normal" type="1" start="1" pn="section-3-15">
at the TLS server was configured as expected using the following steps:</t> <li pn="section-3-15.1" derivedCounter="1.">The ACME server computes the
expected SHA-256 digest of the key authorization.</li>
<t><list style="numbers"> <li pn="section-3-15.2" derivedCounter="2.">The ACME server resolves the
<t>The ACME server computes the expected SHA-256 digest of the key authorizati domain name being validated and chooses one of the IP addresses returned for va
on.</t> lidation (the server <bcp14>MAY</bcp14> validate against multiple addresses if m
<t>The ACME server resolves the domain name being validated and chooses one of ore than one is returned).</li>
the IP addresses returned for validation (the server MAY validate against multi <li pn="section-3-15.3" derivedCounter="3.">The ACME server initiates a
ple addresses if more than one is returned).</t> TLS connection to the chosen IP address. This connection <bcp14>MUST</bcp14> use
<t>The ACME server initiates a TLS connection to the chosen IP address. This c TCP port 443. The ACME server <bcp14>MUST</bcp14> provide an ALPN extension wit
onnection MUST use TCP port 443. The ACME server MUST provide an ALPN extension h the single protocol name "acme-tls/1" and an SNI extension containing only the
with the single protocol name “acme-tls/1” and an SNI extension containing only domain name being validated during the TLS handshake.</li>
the domain name being validated during the TLS handshake.</t> <li pn="section-3-15.4" derivedCounter="4.">
<t>The ACME server verifies that during the TLS handshake the application-laye <t pn="section-3-15.4.1">The ACME server verifies that during the TLS
r protocol “acme-tls/1” was successfully negotiated (and that the ALPN extension handshake the application-layer protocol "acme-tls/1" was successfully negotiate
contained only the value “acme-tls/1”) and that the certificate returned contai d (and that the ALPN extension contained only the value "acme-tls/1") and that t
ns: he certificate returned contains:
<list style="symbols"> </t>
<t>a subjectAltName extension containing the dNSName being validated and n <ul spacing="normal" bare="false" empty="false" pn="section-3-15.4.2">
o other entries</t> <li pn="section-3-15.4.2.1">a subjectAltName extension containing th
<t>a critical acmeIdentifier extension containing the expected SHA-256 dig e dNSName being validated and no other entries</li>
est computed in step 1</t> <li pn="section-3-15.4.2.2">a critical acmeIdentifier extension cont
</list></t> aining the expected SHA-256 digest computed in step 1</li>
</list></t> </ul>
</li>
<t>The comparison of dNSNames MUST be case insensitive <xref target="RFC4343"/>. </ol>
Note that as ACME doesn’t support Unicode identifiers all dNSNames MUST be enco <t pn="section-3-16">The comparison of dNSNames <bcp14>MUST</bcp14> be cas
ded using <xref target="RFC3492"/> rules.</t> e insensitive
<xref target="RFC4343" format="default" sectionFormat="of" derivedContent=
<t>If all of the above steps succeed then the validation is successful, otherwis "RFC4343"/>. Note that as ACME doesn't
e it fails.</t> support Unicode identifiers, all dNSNames <bcp14>MUST</bcp14> be encoded
using the rules of <xref target="RFC3492" format="default" sectionFormat="
</section> of" derivedContent="RFC3492"/>.</t>
<section anchor="acme-tls1-protocol-definition" title="acme-tls/1 Protocol Defin <t pn="section-3-17">If all of the above steps succeed, then the validatio
ition"> n is
successful. Otherwise, it fails.</t>
<t>The “acme-tls/1” protocol MUST only be used for validating ACME tls-alpn-01 c </section>
hallenges. The protocol consists of a TLS handshake in which the required valida <section anchor="acme-tls1-protocol-definition" numbered="true" toc="include
tion information is transmitted. The “acme-tls/1” protocol does not carry applic " removeInRFC="false" pn="section-4">
ation data, once the handshake is completed the client MUST NOT exchange any fur <name slugifiedName="name-acme-tls-1-protocol-definit">acme-tls/1 Protocol
ther data with the server and MUST immediately close the connection. While this Definition</name>
protocol uses X.509 certificates, it does not use the authentication method desc <t pn="section-4-1">The "acme-tls/1" protocol <bcp14>MUST</bcp14> only be
ribed in <xref target="RFC5280"/> and as such does not require a valid signature used for
on the provided certificate nor require the TLS handshake to complete successfu validating ACME tls-alpn-01 challenges. The protocol consists of a TLS
lly. An ACME server may wish to use an off the shelf TLS stack where it is not s handshake in which the required validation information is
imple to allow these divergences in the protocol as defined. Because of this, an transmitted. The "acme-tls/1" protocol does not carry application data.
ACME server MAY choose to withhold authorization if either the certificate sign Once the handshake is completed, the client <bcp14>MUST NOT</bcp14>
ature is invalid or the handshake doesn’t fully complete.</t> exchange any further data with the server and <bcp14>MUST</bcp14>
immediately close the connection. While this protocol uses X.509
<t>ACME servers that implement “acme-tls/1” MUST only negotiate TLS 1.2 <xref ta certificates, it does not use the authentication method described in
rget="RFC5246"/> or higher when connecting to clients for validation.</t> <xref target="RFC5280" format="default" sectionFormat="of" derivedContent=
"RFC5280"/> and, as such, does not require a
</section> valid signature on the provided certificate nor require the TLS
<section anchor="security-considerations" title="Security Considerations"> handshake to complete successfully. An ACME server may wish to use an
off-the-shelf TLS stack where it is not simple to allow these
<t>The design of this challenge relies on some assumptions centered around how a divergences in the protocol as defined. Because of this, an ACME server
HTTPS server behaves during validation.</t> <bcp14>MAY</bcp14> choose to withhold authorization if either the
certificate signature is invalid or the handshake doesn't fully
<t>The first assumption is that when a HTTPS server is being used to serve conte complete.</t>
nt for multiple DNS names from a single IP address it properly segregates contro <t pn="section-4-2">ACME servers that implement "acme-tls/1" <bcp14>MUST</
l of those names to the users that own them. This means that if User A registers bcp14> only negotiate TLS 1.2 <xref target="RFC5246" format="default" sectionFor
Host A and User B registers Host B the HTTPS server should not allow a TLS requ mat="of" derivedContent="RFC5246"/> or higher when connecting to clients for val
est using an SNI value for Host A to be served by User B or a TLS connection wit idation.</t>
h a server_name extension identifying Host B to be answered by User A. If the HT </section>
TPS server allows User B to serve this request it allows them to illegitimately <section anchor="security-considerations" numbered="true" toc="include" remo
validate control of Host A to the ACME server.</t> veInRFC="false" pn="section-5">
<name slugifiedName="name-security-considerations">Security Considerations
<t>The second assumption is that a server will not violate <xref target="RFC7301 </name>
"/> by blindly agreeing to use the “acme-tls/1” protocol without actually unders <t pn="section-5-1">The design of this challenge relies on some assumption
tanding it.</t> s centered around how an HTTPS server behaves during validation.</t>
<t pn="section-5-2">The first assumption is that when an HTTPS server is b
<t>To further mitigate the risk of users claiming domain names used by other use eing used to
rs on the same infrastructure hosting providers, CDNs, and other service provide serve content for multiple DNS names from a single IP address, it
rs SHOULD NOT allow users to provide their own certificates for the TLS ALPN val properly segregates control of those names to the users that own
idation process. If providers wish to implement TLS ALPN validation they SHOULD them. This means that if User A registers Host A and User B registers
only generate certificates used for validation themselves and not expose this fu Host B, the HTTPS server should not allow a TLS request using an SNI
nctionality to users.</t> 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
<t>The extensions to the ACME protocol described in this document build upon the the HTTPS server allows User B to serve this request, it allows them to
Security Considerations and threat model defined in <xref target="RFC8555"/> Se illegitimately validate control of Host A to the ACME server.</t>
ction 10.1.</t> <t pn="section-5-3">The second assumption is that a server will not violat
e <xref target="RFC7301" format="default" sectionFormat="of" derivedContent="RFC
</section> 7301"/> by blindly agreeing to use the "acme-tls/1" protocol without actually un
<section anchor="iana-considerations" title="IANA Considerations"> derstanding it.</t>
<t pn="section-5-4">To further mitigate the risk of users claiming domain
<t>[[RFC Editor: please replace I-D.ietf-acme-tls-alpn below by the RFC number.] names used by other users on the same infrastructure hosting providers, CDNs, an
]</t> d other service providers <bcp14>SHOULD NOT</bcp14> allow users to provide their
own certificates for the TLS ALPN validation process. If providers wish to impl
<section anchor="smi-security-for-pkix-certificate-extension-oid" title="SMI Sec ement TLS ALPN validation, they <bcp14>SHOULD</bcp14> only generate certificates
urity for PKIX Certificate Extension OID"> used for validation themselves and not expose this functionality to users.</t>
<t pn="section-5-5">The extensions to the ACME protocol described in this
<t>Within the SMI-numbers registry, the “SMI Security for PKIX Certificate Exten document build
sion (1.3.6.1.5.5.7.1)” table is to be updated to add the following entry:</t> upon the Security Considerations and threat model defined in <xref target=
"RFC8555" sectionFormat="of" section="10.1" format="default" derivedLink="https:
<texttable> //rfc-editor.org/rfc/rfc8555#section-10.1" derivedContent="RFC8555"/>.</t>
<ttcol align='left'>Decimal</ttcol> </section>
<ttcol align='left'>Description</ttcol> <section anchor="iana-considerations" numbered="true" toc="include" removeIn
<ttcol align='left'>References</ttcol> RFC="false" pn="section-6">
<c>31</c> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<c>id-pe-acmeIdentifier</c> <section anchor="smi-security-for-pkix-certificate-extension-oid" numbered
<c>I-D.ietf-acme-tls-alpn</c> ="true" toc="include" removeInRFC="false" pn="section-6.1">
</texttable> <name slugifiedName="name-smi-security-for-pkix-certi">SMI Security for
PKIX Certificate Extension OID</name>
</section> <t pn="section-6.1-1">Within the "Structure of Management Information (S
<section anchor="alpn-protocol-id" title="ALPN Protocol ID"> MI) Numbers (MIB
Module Registrations)" registry, the following entry has been added to
<t>Within the Transport Layer Security (TLS) Extensions registry, the “Applicati the "SMI Security for PKIX
on-Layer Protocol Negotiation (ALPN) Protocol IDs” table is to be updated to add Certificate Extension" (1.3.6.1.5.5.7.1) table.</t>
the following entry:</t> <table align="center" pn="table-1">
<thead>
<texttable> <tr>
<ttcol align='left'>Protocol</ttcol> <th align="left" colspan="1" rowspan="1">Decimal</th>
<ttcol align='left'>Identification Sequence</ttcol> <th align="left" colspan="1" rowspan="1">Description</th>
<ttcol align='left'>Reference</ttcol> <th align="left" colspan="1" rowspan="1">References</th>
<c>acme-tls/1</c> </tr>
<c>0x61 0x63 0x6d 0x65 0x2d 0x74 0x6c 0x73 0x2f 0x31 (“acme-tls/1”)</c> </thead>
<c>I-D.ietf-acme-tls-alpn</c> <tbody>
</texttable> <tr>
<td align="left" colspan="1" rowspan="1">31</td>
</section> <td align="left" colspan="1" rowspan="1">id-pe-acmeIdentifier</td>
<section anchor="acme-validation-method" title="ACME Validation Method"> <td align="left" colspan="1" rowspan="1">RFC 8737</td>
</tr>
<t>The “ACME Validation Methods” registry is to be updated to include the follow </tbody>
ing entry:</t> </table>
</section>
<texttable> <section anchor="alpn-protocol-id" numbered="true" toc="include" removeInR
<ttcol align='left'>Label</ttcol> FC="false" pn="section-6.2">
<ttcol align='left'>Identifier Type</ttcol> <name slugifiedName="name-alpn-protocol-id">ALPN Protocol ID</name>
<ttcol align='left'>ACME</ttcol> <t pn="section-6.2-1">Within the "Transport Layer Security (TLS) Extensi
<ttcol align='left'>Reference</ttcol> ons" registry,
<c>tls-alpn-01</c> the following entry has been added to the "TLS Application-Layer Protocol
<c>dns</c> Negotiation (ALPN) Protocol IDs" table.</t>
<c>Y</c> <table align="center" pn="table-2">
<c>I-D.ietf-acme-tls-alpn</c> <thead>
</texttable> <tr>
<th align="left" colspan="1" rowspan="1">Protocol</th>
</section> <th align="left" colspan="1" rowspan="1">Identification Sequence</
</section> th>
<section anchor="acknowledgements" title="Acknowledgements"> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
<t>The author would like to thank all those whom have provided design insights a </thead>
nd editorial review of this document, including Richard Barnes, Ryan Hurst, Adam <tbody>
Langley, Ryan Sleevi, Jacob Hoffman-Andrews, Daniel McCarney, Marcin Walas, Mar <tr>
tin Thomson and especially Frans Rosén, who discovered the vulnerability in the <td align="left" colspan="1" rowspan="1">acme-tls/1</td>
TLS SNI method that necessitated the writing of this specification.</t> <td align="left" colspan="1" rowspan="1">0x61 0x63 0x6d 0x65 0x2d
0x74 0x6c 0x73 0x2f 0x31 ("acme-tls/1")</td>
</section> <td align="left" colspan="1" rowspan="1">RFC 8737</td>
</tr>
</tbody>
</table>
</section>
<section anchor="acme-validation-method" numbered="true" toc="include" rem
oveInRFC="false" pn="section-6.3">
<name slugifiedName="name-acme-validation-method">ACME Validation Method
</name>
<t pn="section-6.3-1">Within the "Automated Certificate Management Envir
onment (ACME)
Protocol" registry, the following entry has been added to the "ACME Valid
ation 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> </middle>
<back> <back>
<references pn="section-7">
<references title='Normative References'> <name slugifiedName="name-normative-references">Normative References</name
>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <reference anchor="FIPS180-4" target="https://nvlpubs.nist.gov/nistpubs/FI
<front> PS/NIST.FIPS.180-4.pdf" quoteTitle="true" derivedAnchor="FIPS180-4">
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <front>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <title>Secure Hash Standard (SHS)</title>
author> <author>
<date year='1997' month='March' /> <organization showOnFrontPage="true">National Institute of Standards
<abstract><t>In many standards track documents several words are used to signify and Technology (NIST)</organization>
the requirements in the specification. These words are often capitalized. This </author>
document defines these words as they should be interpreted in IETF documents. <date year="2015" month="August"/>
This document specifies an Internet Best Current Practices for the Internet Comm </front>
unity, and requests discussion and suggestions for improvements.</t></abstract> <seriesInfo name="FIPS PUB" value="180-4"/>
</front> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
<seriesInfo name='BCP' value='14'/> </reference>
<seriesInfo name='RFC' value='2119'/> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211
<seriesInfo name='DOI' value='10.17487/RFC2119'/> 9" quoteTitle="true" derivedAnchor="RFC2119">
</reference> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title
<reference anchor="RFC3492" target='https://www.rfc-editor.org/info/rfc3492'> >
<front> <author initials="S." surname="Bradner" fullname="S. Bradner">
<title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain N <organization showOnFrontPage="true"/>
ames in Applications (IDNA)</title> </author>
<author initials='A.' surname='Costello' fullname='A. Costello'><organization /> <date year="1997" month="March"/>
</author> <abstract>
<date year='2003' month='March' /> <t>In many standards track documents several words are used to signi
<abstract><t>Punycode is a simple and efficient transfer encoding syntax designe fy the requirements in the specification. These words are often capitalized. Th
d for use with Internationalized Domain Names in Applications (IDNA). It unique is document defines these words as they should be interpreted in IETF documents.
ly and reversibly transforms a Unicode string into an ASCII string. ASCII chara This document specifies an Internet Best Current Practices for the Internet Co
cters in the Unicode string are represented literally, and non-ASCII characters mmunity, and requests discussion and suggestions for improvements.</t>
are represented by ASCII characters that are allowed in host name labels (letter </abstract>
s, digits, and hyphens). This document defines a general algorithm called Bootst </front>
ring that allows a string of basic code points to uniquely represent any string <seriesInfo name="BCP" value="14"/>
of code points drawn from a larger set. Punycode is an instance of Bootstring t <seriesInfo name="RFC" value="2119"/>
hat uses particular parameter values specified by this document, appropriate for <seriesInfo name="DOI" value="10.17487/RFC2119"/>
IDNA. [STANDARDS-TRACK]</t></abstract> </reference>
</front> <reference anchor="RFC3492" target="https://www.rfc-editor.org/info/rfc349
<seriesInfo name='RFC' value='3492'/> 2" quoteTitle="true" derivedAnchor="RFC3492">
<seriesInfo name='DOI' value='10.17487/RFC3492'/> <front>
</reference> <title>Punycode: A Bootstring encoding of Unicode for Internationalize
d Domain Names in Applications (IDNA)</title>
<reference anchor="RFC4343" target='https://www.rfc-editor.org/info/rfc4343'> <author initials="A." surname="Costello" fullname="A. Costello">
<front> <organization showOnFrontPage="true"/>
<title>Domain Name System (DNS) Case Insensitivity Clarification</title> </author>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz <date year="2003" month="March"/>
ation /></author> <abstract>
<date year='2006' month='January' /> <t>Punycode is a simple and efficient transfer encoding syntax desig
<abstract><t>Domain Name System (DNS) names are &quot;case insensitive&quot;. T ned for use with Internationalized Domain Names in Applications (IDNA). It uniq
his document explains exactly what that means and provides a clear specification uely and reversibly transforms a Unicode string into an ASCII string. ASCII cha
of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARD racters in the Unicode string are represented literally, and non-ASCII character
S-TRACK]</t></abstract> s are represented by ASCII characters that are allowed in host name labels (lett
</front> ers, digits, and hyphens). This document defines a general algorithm called Boot
<seriesInfo name='RFC' value='4343'/> string that allows a string of basic code points to uniquely represent any strin
<seriesInfo name='DOI' value='10.17487/RFC4343'/> g of code points drawn from a larger set. Punycode is an instance of Bootstring
</reference> that uses particular parameter values specified by this document, appropriate f
or IDNA. [STANDARDS-TRACK]</t>
<reference anchor="RFC4648" target='https://www.rfc-editor.org/info/rfc4648'> </abstract>
<front> </front>
<title>The Base16, Base32, and Base64 Data Encodings</title> <seriesInfo name="RFC" value="3492"/>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization <seriesInfo name="DOI" value="10.17487/RFC3492"/>
/></author> </reference>
<date year='2006' month='October' /> <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc408
<abstract><t>This document describes the commonly used base 64, base 32, and bas 6" quoteTitle="true" derivedAnchor="RFC4086">
e 16 encoding schemes. It also discusses the use of line-feeds in encoded data, <front>
use of padding in encoded data, use of non-alphabet characters in encoded data, <title>Randomness Requirements for Security</title>
use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd
]</t></abstract> ">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='RFC' value='4648'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC4648'/> <author initials="J." surname="Schiller" fullname="J. Schiller">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC5246" target='https://www.rfc-editor.org/info/rfc5246'> <author initials="S." surname="Crocker" fullname="S. Crocker">
<front> <organization showOnFrontPage="true"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title> </author>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></au <date year="2005" month="June"/>
thor> <abstract>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /> <t>Security systems are built on strong cryptographic algorithms tha
</author> t foil pattern analysis attempts. However, the security of these systems is dep
<date year='2008' month='August' /> endent on generating secret quantities for passwords, cryptographic keys, and si
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security milar quantities. The use of pseudo-random processes to generate secret quantit
(TLS) protocol. The TLS protocol provides communications security over the Int ies can result in pseudo-security. A sophisticated attacker may find it easier t
ernet. The protocol allows client/server applications to communicate in a way t o reproduce the environment that produced the secret quantities and to search th
hat is designed to prevent eavesdropping, tampering, or message forgery. [STAND e resulting small set of possibilities than to locate the quantities in the whol
ARDS-TRACK]</t></abstract> e of the potential number space.</t>
</front> <t>Choosing random quantities to foil a resourceful and motivated ad
<seriesInfo name='RFC' value='5246'/> versary is surprisingly difficult. This document points out many pitfalls in us
<seriesInfo name='DOI' value='10.17487/RFC5246'/> ing poor entropy sources or traditional pseudo-random number generation techniqu
</reference> es for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
<reference anchor="RFC5280" target='https://www.rfc-editor.org/info/rfc5280'> or this purpose. It provides suggestions to ameliorate the problem when a hardwa
<front> re solution is not available, and it gives examples of how large such quantities
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo need to be for some applications. This document specifies an Internet Best Cur
cation List (CRL) Profile</title> rent Practices for the Internet Community, and requests discussion and suggestio
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></au ns for improvements.</t>
thor> </abstract>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization </front>
/></author> <seriesInfo name="BCP" value="106"/>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></ <seriesInfo name="RFC" value="4086"/>
author> <seriesInfo name="DOI" value="10.17487/RFC4086"/>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></au </reference>
thor> <reference anchor="RFC4343" target="https://www.rfc-editor.org/info/rfc434
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></ 3" quoteTitle="true" derivedAnchor="RFC4343">
author> <front>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author <title>Domain Name System (DNS) Case Insensitivity Clarification</titl
> e>
<date year='2008' month='May' /> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificat ">
e revocation list (CRL) for use in the Internet. An overview of this approach a <organization showOnFrontPage="true"/>
nd model is provided as an introduction. The X.509 v3 certificate format is des </author>
cribed in detail, with additional information regarding the format and semantics <date year="2006" month="January"/>
of Internet name forms. Standard certificate extensions are described and two <abstract>
Internet-specific extensions are defined. A set of required certificate extensi <t>Domain Name System (DNS) names are "case insensitive". This docu
ons is specified. The X.509 v2 CRL format is described in detail along with sta ment explains exactly what that means and provides a clear specification of the
ndard and Internet-specific extensions. An algorithm for X.509 certification pa rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]
th validation is described. An ASN.1 module and examples are provided in the ap </t>
pendices. [STANDARDS-TRACK]</t></abstract> </abstract>
</front> </front>
<seriesInfo name='RFC' value='5280'/> <seriesInfo name="RFC" value="4343"/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/> <seriesInfo name="DOI" value="10.17487/RFC4343"/>
</reference> </reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc464
<reference anchor="RFC6066" target='https://www.rfc-editor.org/info/rfc6066'> 8" quoteTitle="true" derivedAnchor="RFC4648">
<front> <front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title> <title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz <author initials="S." surname="Josefsson" fullname="S. Josefsson">
ation /></author> <organization showOnFrontPage="true"/>
<date year='2011' month='January' /> </author>
<abstract><t>This document provides specifications for existing TLS extensions. <date year="2006" month="October"/>
It is a companion document for RFC 5246, &quot;The Transport Layer Security (TL <abstract>
S) Protocol Version 1.2&quot;. The extensions specified are server_name, max_fr <t>This document describes the commonly used base 64, base 32, and b
agment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and stat ase 16 encoding schemes. It also discusses the use of line-feeds in encoded dat
us_request. [STANDARDS-TRACK]</t></abstract> a, use of padding in encoded data, use of non-alphabet characters in encoded dat
</front> a, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
<seriesInfo name='RFC' value='6066'/> CK]</t>
<seriesInfo name='DOI' value='10.17487/RFC6066'/> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="4648"/>
<reference anchor="RFC7301" target='https://www.rfc-editor.org/info/rfc7301'> <seriesInfo name="DOI" value="10.17487/RFC4648"/>
<front> </reference>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Ext <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc524
ension</title> 6" quoteTitle="true" derivedAnchor="RFC5246">
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></au <front>
thor> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></auth <author initials="T." surname="Dierks" fullname="T. Dierks">
or> <organization showOnFrontPage="true"/>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></ </author>
author> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></ <organization showOnFrontPage="true"/>
author> </author>
<date year='2014' month='July' /> <date year="2008" month="August"/>
<abstract><t>This document describes a Transport Layer Security (TLS) extension <abstract>
for application-layer protocol negotiation within the TLS handshake. For instanc <t>This document specifies Version 1.2 of the Transport Layer Securi
es in which multiple application protocols are supported on the same TCP or UDP ty (TLS) protocol. The TLS protocol provides communications security over the I
port, this extension allows the application layer to negotiate which protocol wi nternet. The protocol allows client/server applications to communicate in a way
ll be used within the TLS connection.</t></abstract> that is designed to prevent eavesdropping, tampering, or message forgery. [STA
</front> NDARDS-TRACK]</t>
<seriesInfo name='RFC' value='7301'/> </abstract>
<seriesInfo name='DOI' value='10.17487/RFC7301'/> </front>
</reference> <seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
<reference anchor="RFC8555" target='https://www.rfc-editor.org/info/rfc8555'> </reference>
<front> <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc528
<title>Automatic Certificate Management Environment (ACME)</title> 0" quoteTitle="true" derivedAnchor="RFC5280">
<author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></au <front>
thor> <title>Internet X.509 Public Key Infrastructure Certificate and Certif
<author initials='J.' surname='Hoffman-Andrews' fullname='J. Hoffman-Andrews'><o icate Revocation List (CRL) Profile</title>
rganization /></author> <author initials="D." surname="Cooper" fullname="D. Cooper">
<author initials='D.' surname='McCarney' fullname='D. McCarney'><organization /> <organization showOnFrontPage="true"/>
</author> </author>
<author initials='J.' surname='Kasten' fullname='J. Kasten'><organization /></au <author initials="S." surname="Santesson" fullname="S. Santesson">
thor> <organization showOnFrontPage="true"/>
<date year='2019' month='March' /> </author>
<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used <author initials="S." surname="Farrell" fullname="S. Farrell">
for a number of purposes, the most significant of which is the authentication of <organization showOnFrontPage="true"/>
domain names. Thus, certification authorities (CAs) in the Web PKI are trusted </author>
to verify that an applicant for a certificate legitimately represents the domai <author initials="S." surname="Boeyen" fullname="S. Boeyen">
n name(s) in the certificate. As of this writing, this verification is done thr <organization showOnFrontPage="true"/>
ough a collection of ad hoc mechanisms. This document describes a protocol that </author>
a CA and an applicant can use to automate the process of verification and certi <author initials="R." surname="Housley" fullname="R. Housley">
ficate issuance. The protocol also provides facilities for other certificate ma <organization showOnFrontPage="true"/>
nagement functions, such as certificate revocation.</t></abstract> </author>
</front> <author initials="W." surname="Polk" fullname="W. Polk">
<seriesInfo name='RFC' value='8555'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC8555'/> </author>
</reference> <date year="2008" month="May"/>
<abstract>
<reference anchor="FIPS180-4" target="http://csrc.nist.gov/publications/fips/fip <t>This memo profiles the X.509 v3 certificate and X.509 v2 certific
s180-4/fips-180-4.pdf"> ate revocation list (CRL) for use in the Internet. An overview of this approach
<front> and model is provided as an introduction. The X.509 v3 certificate format is d
<title>NIST FIPS 180-4, Secure Hash Standard</title> escribed in detail, with additional information regarding the format and semanti
<author initials="National Institute of Standards and Technology, U.S." surn cs of Internet name forms. Standard certificate extensions are described and tw
ame="Department of Commerce" fullname="NIST"> o Internet-specific extensions are defined. A set of required certificate exten
<organization></organization> sions is specified. The X.509 v2 CRL format is described in detail along with s
</author> tandard and Internet-specific extensions. An algorithm for X.509 certification
<date year="2012" month="March"/> path validation is described. An ASN.1 module and examples are provided in the
</front> appendices. [STANDARDS-TRACK]</t>
</reference> </abstract>
<reference anchor="X.690" target="https://www.itu.int/ITU-T/studygroups/com17/la </front>
nguages/X.690-0207.pdf"> <seriesInfo name="RFC" value="5280"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC5280"/>
<title>Information Technology -- ASN.1 encoding rules: Specification of Basi </reference>
c Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encodin <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc606
g Rules (DER)</title> 6" quoteTitle="true" derivedAnchor="RFC6066">
<author initials="." surname="International Telecommunication Union" fullnam <front>
e="ITU-T"> <title>Transport Layer Security (TLS) Extensions: Extension Definition
<organization></organization> s</title>
</author> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd
<date year="2015"/> ">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="X.680" target="https://www.itu.int/ITU-T/studygroups/com17/la <date year="2011" month="January"/>
nguages/X.680-0207.pdf"> <abstract>
<front> <t>This document provides specifications for existing TLS extensions
<title>Information technology -- Abstract Syntax Notation One (ASN.1): Speci . It is a companion document for RFC 5246, "The Transport Layer Security (TLS)
fication of basic notation</title> Protocol Version 1.2". The extensions specified are server_name, max_fragment_l
<author initials="." surname="International Telecommunication Union" fullnam ength, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_reque
e="ITU-T"> st. [STANDARDS-TRACK]</t>
<organization></organization> </abstract>
</author> </front>
<date year="2015"/> <seriesInfo name="RFC" value="6066"/>
</front> <seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference> </reference>
<reference anchor="RFC7301" target="https://www.rfc-editor.org/info/rfc730
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'> 1" quoteTitle="true" derivedAnchor="RFC7301">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <title>Transport Layer Security (TLS) Application-Layer Protocol Negot
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth iation Extension</title>
or> <author initials="S." surname="Friedl" fullname="S. Friedl">
<date year='2017' month='May' /> <organization showOnFrontPage="true"/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s </author>
pecifications. This document aims to reduce the ambiguity by clarifying that on <author initials="A." surname="Popov" fullname="A. Popov">
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs <organization showOnFrontPage="true"/>
tract> </author>
</front> <author initials="A." surname="Langley" fullname="A. Langley">
<seriesInfo name='BCP' value='14'/> <organization showOnFrontPage="true"/>
<seriesInfo name='RFC' value='8174'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC8174'/> <author initials="E." surname="Stephan" fullname="E. Stephan">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC4086" target='https://www.rfc-editor.org/info/rfc4086'> <date year="2014" month="July"/>
<front> <abstract>
<title>Randomness Requirements for Security</title> <t>This document describes a Transport Layer Security (TLS) extensio
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz n for application-layer protocol negotiation within the TLS handshake. For insta
ation /></author> nces in which multiple application protocols are supported on the same TCP or UD
<author initials='J.' surname='Schiller' fullname='J. Schiller'><organization /> P port, this extension allows the application layer to negotiate which protocol
</author> will be used within the TLS connection.</t>
<author initials='S.' surname='Crocker' fullname='S. Crocker'><organization /></ </abstract>
author> </front>
<date year='2005' month='June' /> <seriesInfo name="RFC" value="7301"/>
<abstract><t>Security systems are built on strong cryptographic algorithms that <seriesInfo name="DOI" value="10.17487/RFC7301"/>
foil pattern analysis attempts. However, the security of these systems is depen </reference>
dent on generating secret quantities for passwords, cryptographic keys, and simi <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc817
lar quantities. The use of pseudo-random processes to generate secret quantitie 4" quoteTitle="true" derivedAnchor="RFC8174">
s can result in pseudo-security. A sophisticated attacker may find it easier to <front>
reproduce the environment that produced the secret quantities and to search the <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
resulting small set of possibilities than to locate the quantities in the whole e>
of the potential number space.</t><t>Choosing random quantities to foil a resour <author initials="B." surname="Leiba" fullname="B. Leiba">
ceful and motivated adversary is surprisingly difficult. This document points o <organization showOnFrontPage="true"/>
ut many pitfalls in using poor entropy sources or traditional pseudo-random numb </author>
er generation techniques for generating such quantities. It recommends the use <date year="2017" month="May"/>
of truly random hardware techniques and shows that the existing hardware on many <abstract>
systems can be used for this purpose. It provides suggestions to ameliorate the <t>RFC 2119 specifies common key words that may be used in protocol
problem when a hardware solution is not available, and it gives examples of how specifications. This document aims to reduce the ambiguity by clarifying that
large such quantities need to be for some applications. This document specifie only UPPERCASE usage of the key words have the defined special meanings.</t>
s an Internet Best Current Practices for the Internet Community, and requests di </abstract>
scussion and suggestions for improvements.</t></abstract> </front>
</front> <seriesInfo name="BCP" value="14"/>
<seriesInfo name='BCP' value='106'/> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name='RFC' value='4086'/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/> </reference>
</reference> <reference anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc855
5" quoteTitle="true" derivedAnchor="RFC8555">
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author initials="R." surname="Barnes" fullname="R. Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hoffman-Andrews" fullname="J. Hoffman-A
ndrews">
<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 use
d 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 trust
ed to verify that an applicant for a certificate legitimately represents the dom
ain name(s) in the certificate. As of this writing, this verification is done t
hrough a collection of ad hoc mechanisms. This document describes a protocol th
at a CA and an applicant can use to automate the process of verification and cer
tificate issuance. The protocol also provides facilities for 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-2015
08-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>
<seriesInfo 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-2015
08-I/en" quoteTitle="true" derivedAnchor="X.690">
<front>
<title>Information Technology -- ASN.1 encoding rules: Specification o
f Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished E
ncoding Rules (DER)</title>
<author>
<organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="August" year="2015"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2015"/>
</reference>
</references> </references>
<section anchor="design-rationale" numbered="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 t
he TLS SNI challenge
defined in the early ACME drafts. The TLS SNI challenge was
convenient for service providers who were either operating large
TLS-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 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 was designed, 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', they would only be able to respond to SNI
requests for 'a.example' and not for SNI requests for '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.
<section anchor="design-rationale" title="Design Rationale"> 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
<t>The TLS ALPN challenge exists to iterate on the TLS SNI challenge defined in for Host B, and (2) when the validation connection was made, User A would be
the early ACME drafts. The TLS SNI challenge was convenient for service provider able to answer, thereby proving 'control' of Host B.
s who were either operating large TLS layer load balancing systems at which they
wanted to perform validation or running servers fronting large numbers of DNS n
ames from a single host as it allowed validation purely within the TLS layer. Th
e 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 security issue in the TLS SNI challenge was discovered by Frans Rosen, whic
h 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 was
designed 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’ they would only be able to respond to SNI requests
for ‘a.example’ and not for SNI requests for ‘b.example’). It turns out that a
number of large service providers do not honor this property. Because of this, u
sers were able to respond to SNI requests for the names used by the TLS SNI chal
lenge validation process. This meant that if User A and User B had registered Ho
st A and Host B, respectively, User A would be able to claim the constructed SNI
challenge name for Host B and when the validation connection was made that User
A would be able to answer, proving ‘control’ of Host B. As the SNI name used wa
s a subdomain of the domain name being validated, rather than the domain name it
self, it was likely to not already be registered with the service provider for t
raffic routing, making it much easier for a hijack to occur.</t>
</section>
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 Sho
emaker">
<organization abbrev="ISRG" showOnFrontPage="true">Internet Security Res
earch Group</organization>
<address>
<email>roland@letsencrypt.org</email>
</address>
</author>
</section>
</back> </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> </rfc>
 End of changes. 18 change blocks. 
693 lines changed or deleted 848 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/