Diff: rfc9444.original.xml

	rfc9444.original.xml	rfc9444.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>	<!DOCTYPE rfc [
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.10 (Ruby 2.
	7.2) -->

	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">


	]>	]>

		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9444"
	<?rfc rfcedstyle="yes"?>	docName="draft-ietf-acme-subdomains-07" category="std" submissionType="IETF" con
	<?rfc strict="yes"?>	sensus="true" tocDepth="2" tocInclude="true" sortRefs="true" symRefs="true" vers
	<?rfc compact="no"?>	ion="3">
	<?rfc subcompact="no"?>	<!-- xml2rfc v2v3 conversion 3.17.1 -->
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>

	<rfc ipr="trust200902" docName="draft-ietf-acme-subdomains-07" category="std" co
	nsensus="yes" tocDepth="2" tocInclude="true" sortRefs="true" symRefs="true">
	<front>	<front>

	<title abbrev="ACME-SUBDOMAINS">Automated Certificate Management Environment	<title abbrev="ACME for Subdomains">Automated Certificate Management Environ
	(ACME) for Subdomains</title>	ment (ACME) for Subdomains</title>
		<seriesInfo name="RFC" value="9444"/>
	<author initials="O." surname="Friel" fullname="Owen Friel">	<author initials="O." surname="Friel" fullname="Owen Friel">
	<organization>Cisco</organization>	<organization>Cisco</organization>
	<address>	<address>
	<email>ofriel@cisco.com</email>	<email>ofriel@cisco.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="R." surname="Barnes" fullname="Richard Barnes">	<author initials="R." surname="Barnes" fullname="Richard Barnes">
	<organization>Cisco</organization>	<organization>Cisco</organization>
	<address>	<address>
	<email>rlb@ipv.sx</email>	<email>rlb@ipv.sx</email>

	skipping to change at line 48 ¶	skipping to change at line 37 ¶
	<address>	<address>
	<email>tim.hollebeek@digicert.com</email>	<email>tim.hollebeek@digicert.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="M." surname="Richardson" fullname="Michael Richardson">	<author initials="M." surname="Richardson" fullname="Michael Richardson">
	<organization>Sandelman Software Works</organization>	<organization>Sandelman Software Works</organization>
	<address>	<address>
	<email>mcr+ietf@sandelman.ca</email>	<email>mcr+ietf@sandelman.ca</email>
	</address>	</address>
	</author>	</author>

		<date year="2023" month="August"/>
	<date year="2023" month="March" day="01"/>

	<area>Security</area>	<area>Security</area>
	<workgroup>ACME Working Group</workgroup>	<workgroup>ACME Working Group</workgroup>

		<keyword>BRSKI</keyword>
		<keyword>BRSKI-Cloud</keyword>
		<keyword>ACME-Integrations</keyword>
	<abstract>	<abstract>

		<t>This document specifies how Automated Certificate Management Environmen
	<t>This document specifies how Automated Certificate Management Environment (ACM	t (ACME) can be used by a client to obtain a certificate for a subdomain identif
	E) can be used by a client to obtain a certificate for a subdomain identifier fr	ier from a certification authority. Additionally, this document specifies how a
	om a certification authority. This document specifies how a client can fulfill a	client can fulfill a challenge against an ancestor domain but may not need to fu
	challenge against an ancestor domain but may not need to fulfill a challenge ag	lfill a challenge against the explicit subdomain if certification authority poli
	ainst the explicit subdomain if certification authority policy allows issuance o	cy allows issuance of the subdomain certificate without explicit subdomain owner
	f the subdomain certificate without explicit subdomain ownership proof.</t>	ship proof.</t>

	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

		<section anchor="introduction">
	<section anchor="introduction"><name>Introduction</name>	<name>Introduction</name>
		<t>ACME <xref target="RFC8555"/> defines a protocol that a certification a
	<t>ACME <xref target="RFC8555"/> defines a protocol that a certification authori	uthority (CA) and an applicant can use to automate the process of domain name ow
	ty (CA) and an applicant can use to automate the process of domain name ownershi	nership validation and X.509v3 (PKIX) <xref target="RFC5280"/> certificate issua
	p validation and X.509v3 (PKIX) <xref target="RFC5280"/> certificate issuance. T	nce. The CA is the ACME server and the applicant is the ACME client, and the cli
	he CA is the ACME server and the applicant is the ACME client, and the client us	ent uses the ACME protocol to request certificate issuance from the server. This
	es the ACME protocol to request certificate issuance from the server. This docum	document outlines how ACME can be used to issue subdomain certificates without
	ent outlines how ACME can be used to issue subdomain certificates, without requi	requiring the ACME client to explicitly fulfill an ownership challenge against t
	ring the ACME client to explicitly fulfill an ownership challenge against the su	he subdomain identifiers -- the ACME client need only fulfill an ownership chall
	bdomain identifiers - the ACME client need only fulfill an ownership challenge a	enge against an ancestor domain identifier.</t>
	gainst an ancestor domain identifier.</t>	</section>
		<section anchor="terminology">
	</section>	<name>Terminology</name>
	<section anchor="terminology"><name>Terminology</name>	<t>
		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	be interpreted as
	nterpreted as	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	when, and only when, they appear in all capitals, as shown here.
	only when, they	</t>
	appear in all capitals, as shown here.</t>	<t>The following terms are defined in "DNS Terminology" <xref target="RFC8
		499"/> and are reproduced here:</t>
	<t>The following terms are defined in DNS Terminology <xref target="RFC8499"/> a	<dl newline="true">
	nd are reproduced here:</t>	<dt>Label:</dt>
		<dd>An ordered list of zero or more octets that makes up a
	<t><list style="symbols">
	<t>Label: An ordered list of zero or more octets that makes up a
	portion of a domain name. Using graph theory, a label identifies	portion of a domain name. Using graph theory, a label identifies

	one node in a portion of the graph of all possible domain names.</t>	one node in a portion of the graph of all possible domain names.</dd>
	<t>Domain Name: An ordered list of one or more labels.</t>	<dt>Domain Name:</dt>
	<t>Fully-Qualified Domain Name (FQDN): This is often just a clear way	<dd>An ordered list of one or more labels.</dd>
		<dt>Fully-Qualified Domain Name (FQDN):</dt>
		<dd>This is often just a clear way
	of saying the same thing as "domain name of a node", as outlined	of saying the same thing as "domain name of a node", as outlined
	above. However, the term is ambiguous. Strictly speaking, a	above. However, the term is ambiguous. Strictly speaking, a
	fully-qualified domain name would include every label, including	fully-qualified domain name would include every label, including
	the zero-length label of the root: such a name would be written	the zero-length label of the root: such a name would be written

	"www.example.net." (note the terminating dot). But, because every	<tt>www.example.net.</tt> (note the terminating dot). But, because every
	name eventually shares the common root, names are often written	name eventually shares the common root, names are often written

	relative to the root (such as "www.example.net") and are still	relative to the root (such as <tt>www.example.net</tt>) and are still
	called "fully qualified". This term first appeared in <xref target="RFC0819 "/>.	called "fully qualified". This term first appeared in <xref target="RFC0819 "/>.

	In this document, names are often written relative to the root.</t>	In this document, names are often written relative to the root.</dd>
	</list></t>	</dl>
		<t>The following definition for "subdomain" is taken from "DNS Terminology
	<t>The following definition for "subdomain" is taken from DNS Terminology <xref	" <xref target="RFC8499"/> and reproduced here; however, the definition is ambig
	target="RFC8499"/> and reproduced here, however the definition is ambiguous and	uous and is further clarified below:</t>
	is further clarified below:</t>	<dl newline="true">
		<dt>Subdomain:</dt>
	<t><list style="symbols">	<dd>"A domain is a subdomain of another domain if it is
	<t>Subdomain: "A domain is a subdomain of another domain if it is
	contained within that domain. This relationship can be tested by	contained within that domain. This relationship can be tested by
	seeing if the subdomain's name ends with the containing domain's	seeing if the subdomain's name ends with the containing domain's
	name." (Quoted from <xref section="3.1" sectionFormat="of" target="RFC1034" />.) For example, in the	name." (Quoted from <xref section="3.1" sectionFormat="of" target="RFC1034" />.) For example, in the

	host name "nnn.mmm.example.com", both "mmm.example.com" and	host name <tt>nnn.mmm.example.com</tt>, both <tt>mmm.example.com</tt> and
	"nnn.mmm.example.com" are subdomains of "example.com". Note that	<tt>nnn.mmm.example.com</tt> are subdomains of <tt>example.com</tt>. Note t
		hat
	the comparisons here are done on whole labels; that is,	the comparisons here are done on whole labels; that is,

	"ooo.example.com" is not a subdomain of "oo.example.com".</t>	<tt>ooo.example.com</tt> is not a subdomain of <tt>oo.example.com</tt>.</dd>
	</list></t>	</dl>
		<t>The definition is ambiguous as it appears to allow a subdomain to inclu
	<t>The definition is ambiguous as it appears to allow a subdomain to include the	de the given domain. That is, <tt>mmm.example.com</tt> ends with <tt>mmm.example
	given domain. That is, "mmm.example.com" ends with "mmm.example.com" and thus i	.com</tt> and thus is a subdomain of itself. This document interprets the first
	s a subdomain of itself. This document interprets the first sentence of the abov	sentence of the above definition as meaning "a domain is a subdomain of a differ
	e definition as meaning "A domain is a subdomain of a different domain if it is	ent domain if it is contained within that different domain". A domain cannot be
	contained within that different domain.". A domain cannot be a subdomain of itse	a subdomain of itself. For example, <tt>mmm.example.com</tt> is not a subdomain
	lf. For example, "mmm.example.com" is not a subdomain of "mmm.example.com".</t>	of <tt>mmm.example.com</tt>.</t>
		<t>The following additional terms are used in this document:</t>
	<t>The following additional terms are used in this document:</t>	<dl newline="true">
		<dt>Certification Authority (CA):</dt>
	<t><list style="symbols">	<dd>An organization that is responsible for the creation, issuance, revo
	<t>Certification Authority (CA): An organization that is responsible for the c	cation, and management of Certificates. The term applies equally to both root CA
	reation, issuance, revocation, and management of Certificates. The term applies	s and subordinate CAs. Refer to <xref target="RFC5280"/> for detailed informatio
	equally to both Root CAs and Subordinate CAs. Refer to <xref target="RFC5280"/>	n on Certification Authorities.</dd>
	for detailed information on Certification Authorities.</t>	<dt>CSR:</dt>
	<t>CSR: Certificate Signing Request as defined in <xref target="RFC2986"/></t>	<dd>Certificate Signing Request, as defined in <xref target="RFC2986"/>.
	<t>Ancestor Domain: a domain is an ancestor domain of a subdomain if it contai	</dd>
	ns that subdomain and has less labels than that subdomain. A domain cannot be an	<dt>Ancestor Domain:</dt>
	ancestor domain of itself. For example, for the host name "nnn.mmm.example.com"	<dd>A domain is an ancestor domain of a subdomain if it contains that su
	, both "mmm.example.com" and "example.com" are ancestor domains of "nnn.mmm.exam	bdomain and has less labels than that subdomain. A domain cannot be an ancestor
	ple.com". However, "nnn.mmm.example.com" is not an ancestor domain of "nnn.mmm.	domain of itself. For example, for the host name <tt>nnn.mmm.example.com</tt>, b
	example.com". Note that the comparisons here are done on whole labels; that is,	oth <tt>mmm.example.com</tt> and <tt>example.com</tt> are ancestor domains of <t
	"oo.example.com" is not an ancestor domain of "ooo.example.com".</t>	t>nnn.mmm.example.com</tt>. However, <tt>nnn.mmm.example.com</tt> is not an ance
	</list></t>	stor domain of <tt>nnn.mmm.example.com</tt>. Note that the comparisons here are
		done on whole labels; that is, <tt>oo.example.com</tt> is not an ancestor domai
	<t>ACME <xref target="RFC8555"/> defines the following object types which are us	n of <tt>ooo.example.com</tt>.</dd>
	ed in this document:</t>	</dl>
		<t><xref target="RFC8555"/> defines the following object types that are us
	<t><list style="symbols">	ed in this document:</t>
	<t>Order Object: An ACME order object represents a client's request for a cert	<dl newline="false">
	ificate and is used to track the progress of that order through to issuance.</t>	<dt>Order Object:</dt>
	<t>Authorization Object: An ACME authorization object represents a server's au	<dd>An ACME order object represents a client's request for a certificate
	thorization for an account to represent an identifier.</t>	and is used to track the progress of that order through to issuance.</dd>
	<t>Challenge Object: An ACME challenge object represents a server's offer to v	<dt>Authorization Object:</dt>
	alidate a client's possession of an identifier in a specific way.</t>	<dd>An ACME authorization object represents a server's authorization for
	</list></t>	an account to represent an identifier.</dd>
		<dt>Challenge Object:</dt>
	<t>ACME <xref target="RFC8555"/> Section 6.3 introduces the following term which	<dd>An ACME challenge object represents a server's offer to validate a c
	is used in this document:</t>	lient's possession of an identifier in a specific way.</dd>
		</dl>
	<t><list style="symbols">	<t>ACME <xref target="RFC8555" sectionFormat="comma" section="6.3"/> intro
	<t>POST-as-GET Request: When a client wishes to fetch a resource from the serv	duces the following term which is used in this document:</t>
	er, then it <bcp14>MUST</bcp14> send a POST request with a signed JWS body, wher	<dl newline="true">
	e the JWS body is specified in ACME <xref target="RFC8555"/> Section 6.2. ACME r	<dt>POST-as-GET Request:</dt>
	efers to these as "POST-as-GET" requests.</t>	<dd>When a client wishes to fetch a resource from the server, then it <b
	</list></t>	cp14>MUST</bcp14> send a POST request with a signed JSON Web Signature (JWS) bod
		y, where the JWS body is specified in ACME <xref target="RFC8555" sectionFormat=
	</section>	"comma" section="6.2"/>. ACME refers to these as "POST-as-GET" requests.</dd>
	<section anchor="acme-workflow-and-identifier-requirements"><name>ACME Workflow	</dl>
	and Identifier Requirements</name>	</section>
		<section anchor="acme-workflow-and-identifier-requirements">
	<t>A typical ACME <xref target="RFC8555"/> workflow for issuance of certificates	<name>ACME Workflow and Identifier Requirements</name>
	is as follows:</t>	<t>A typical ACME workflow for issuance of certificates is as follows:</t>
		<ol spacing="normal" type="1">
	<t><list style="numbers">	<li>Client POSTs a newOrder request that contains a set of identifier obj
	<t>client POSTs a newOrder request that contains a set of "identifiers"</t>	ects in the <tt>identifiers</tt> field of the ACME order object.</li>
	<t>server replies with an order object that contains a set of links to authori	<li>Server replies with an order object that contains a set of links to
	zation object(s) and a "finalize" URI</t>	authorization object(s) and a <tt>finalize</tt> URI.</li>
	<t>client sends POST-as-GET requests to retrieve the authorization object(s),	<li>Client sends POST-as-GET requests to retrieve the authorization obje
	with the downloaded authorization object(s) containing the "identifier" that the	ct(s), with the downloaded authorization object(s) containing the <tt>identifier
	client must prove that they control, and a set of links to associated challenge	</tt> that the client must prove that they control, and a set of links to associ
	s objects, one of which the client must fulfill</t>	ated challenges objects, one of which the client must fulfill.</li>
	<t>client proves control over the "identifier" in the authorization object by	<li>Client proves control over the <tt>identifier</tt> in the authorizat
	completing one of the specified challenges, for example, by publishing a DNS TXT	ion object by completing one of the specified challenges, for example, by publis
	record</t>	hing a DNS TXT record.</li>
	<t>client POSTs a CSR to the "finalize" API</t>	<li>Client POSTs a CSR to the <tt>finalize</tt> API.</li>
	<t>server replies with an updated order object that includes a "certificate" U	<li>Server replies with an updated order object that includes a <tt>cert
	RI</t>	ificate</tt> URI.</li>
	<t>client sends POST-as-GET request to the "certificate" URI to download the c	<li>Client sends a POST-as-GET request to the <tt>certificate</tt> URI t
	ertificate</t>	o download the certificate.</li>
	</list></t>	</ol>
		<t>ACME places the following restrictions on <tt>identifiers</tt>:</t>
	<t>ACME places the following restrictions on "identifiers":</t>	<ul spacing="normal">
		<li>
	<t><list style="symbols">	<xref section="7.1.3" sectionFormat="comma" target="RFC8555"/>: "The a
	<t><xref section="7.1.3" sectionFormat="comma" target="RFC8555"/>: The authori	uthorizations required are dictated by server policy; there may not be a 1:1 rel
	zations required are dictated by server policy; there may not be a 1:1 relations	ationship between the order identifiers and the authorizations required."</li>
	hip between the order identifiers and the authorizations required.</t>	<li>
	<t><xref section="7.1.4" sectionFormat="comma" target="RFC8555"/>: the only ty	<xref section="7.1.4" sectionFormat="comma" target="RFC8555"/>: The on
	pe of "identifier" defined by the ACME specification is an FQDN: "The only type	ly type of <tt>identifier</tt> defined by the ACME specification is an FQDN: "Th
	of identifier defined by this specification is a fully qualified domain name (ty	e only type of identifier defined by this specification is a fully qualified dom
	pe: "dns"). The domain name <bcp14>MUST</bcp14> be encoded in the form in which	ain name (type: "dns"). The domain name <bcp14>MUST</bcp14> be encoded in the fo
	it would appear in a certificate."</t>	rm in which it would appear in a certificate."</li>
	<t><xref section="7.4" sectionFormat="comma" target="RFC8555"/>: the "identifi	<li>
	er" in the CSR request must match the "identifier" in the newOrder request: "The	<xref section="7.4" sectionFormat="comma" target="RFC8555"/>: The <tt>
	CSR <bcp14>MUST</bcp14> indicate the exact same set of requested identifiers as	identifier</tt> in the CSR request must match the <tt>identifier</tt> in the new
	the initial newOrder request."</t>	Order request: "The CSR <bcp14>MUST</bcp14> indicate the exact same set of reque
	<t><xref section="8.3" sectionFormat="comma" target="RFC8555"/>: the "identifi	sted identifiers as the initial newOrder request."</li>
	er", or FQDN, in the authorization object must be used when fulfilling challenge	<li>
	s via HTTP: "Construct a URL by populating the URL template ... where the domain	<xref section="8.3" sectionFormat="comma" target="RFC8555"/>: The <tt>
	field is set to the domain name being verified"</t>	identifier</tt>, or FQDN, in the authorization object must be used when fulfilli
	<t><xref section="8.4" sectionFormat="comma" target="RFC8555"/>: the "identifi	ng challenges via HTTP: "Construct a URL by populating the URL template ... wher
	er", or FQDN, in the authorization object must be used when fulfilling challenge	e the <tt>domain</tt> field is set to the domain name being verified."</li>
	s via DNS: "The client constructs the validation domain name by prepending the l	<li>
	abel "_acme-challenge" to the domain name being validated."</t>	<xref section="8.4" sectionFormat="comma" target="RFC8555"/>: The <tt>
	</list></t>	identifier</tt>, or FQDN, in the authorization object must be used when fulfilli
		ng challenges via DNS: "The client constructs the validation domain name by prep
	<t>ACME does not mandate that the "identifier" in a newOrder request matches the	ending the label "_acme-challenge" to the domain name being validated."</li>
	"identifier" in authorization objects.</t>	</ul>
		<t>ACME does not mandate that the <tt>identifier</tt> in a newOrder reques
	<t>The base ACME <xref target="RFC8555"/> document only specifies the "dns" iden	t matches the <tt>identifier</tt> in authorization objects.</t>
	tifier type. Additional identifiers may be defined and registered in the IANA <x	<t>The ACME base document <xref target="RFC8555"/> only specifies the "dns
	ref target="ACME-Identifier-Types"/> registry. For example, <xref target="RFC873	" identifier type. Additional identifiers may be defined and registered in the I
	8"/> specifies the "ip" identifier type. This document is only relevant for the	ANA <xref target="ACME-Identifier-Types"/> registry. For example, <xref target="
	"dns" identifier type.</t>	RFC8738"/> specifies the "ip" identifier type. This document is only relevant fo
		r the "dns" identifier type.</t>
	<t>Note also that ACME supports multiple different validation methods that can b	<t>Note that ACME supports multiple different validation methods that can
	e used to fulfill challenges and prove ownership of identifiers. Validation meth	be used to fulfill challenges and prove ownership of identifiers. Validation met
	ods are registered in the IANA <xref target="ACME-Validation-Methods"/> registry	hods are registered in the IANA <xref target="ACME-Validation-Methods"/> registr
	. This document does not mandate use of any particular validation method or meth	y. This document does not mandate use of any particular validation method or met
	ods. ACME server policy dictates which validation methods are supported. See <xr	hods. ACME server policy dictates which validation methods are supported. See <x
	ef target="acme-server-policy-considerations"/> for more information on ACME ser	ref target="acme-server-policy-considerations"/> for more information on ACME se
	ver policy.</t>	rver policy.</t>
		</section>
	</section>	<section anchor="acme-issuance-of-subdomain-certificates">
	<section anchor="acme-issuance-of-subdomain-certificates"><name>ACME Issuance of	<name>ACME Issuance of Subdomain Certificates</name>
	Subdomain Certificates</name>	<t>As noted in the previous section, ACME <xref target="RFC8555"/> does no
		t mandate that the <tt>identifier</tt> in a newOrder request matches the <tt>ide
	<t>As noted in the previous section, ACME <xref target="RFC8555"/> does not mand	ntifier</tt> in authorization objects. This means that the ACME specification do
	ate that the "identifier" in a newOrder request matches the "identifier" in auth	es not preclude an ACME server processing newOrder requests and issuing certific
	orization objects. This means that the ACME specification does not preclude an A	ates for a subdomain without requiring a challenge to be fulfilled against that
	CME server processing newOrder requests and issuing certificates for a subdomain	explicit subdomain.</t>
	without requiring a challenge to be fulfilled against that explicit subdomain.<	<t>ACME server policy could allow issuance of certificates for a subdomain
	/t>	to a client where the client only has to fulfill an authorization challenge for
		an ancestor domain of that subdomain. For example, this allows for a flow where
	<t>ACME server policy could allow issuance of certificates for a subdomain to a	a client proves ownership of <tt>example.org</tt> and then successfully obtains
	client where the client only has to fulfill an authorization challenge for an an	a certificate for <tt>sub.example.org</tt>.</t>
	cestor domain of that subdomain. This allows a flow where a client proves owners	<t>ACME server policy is out of scope of this document; however, some comm
	hip of, for example, "example.org" and then successfully obtains a certificate f	entary is provided in <xref target="acme-server-policy-considerations"/>.</t>
	or "sub.example.org".</t>	<t>Clients need a mechanism to instruct the ACME server that they are requ
		esting authorization for all subdomains subordinate to the specified domain, as
	<t>ACME server policy is out of scope of this document, however, some commentary	opposed to just requesting authorization for an explicit domain identifier. Clie
	is provided in <xref target="acme-server-policy-considerations"/>.</t>	nts need a mechanism to do this in both newAuthz and newOrder requests. ACME ser
		vers need a mechanism to indicate to clients that authorization objects are vali
	<t>Clients need a mechanism to instruct the ACME server that they are requesting	d for all subdomains under the specified domain. These are described in this sec
	authorization for all subdomains subordinate to the specified domain, as oppose	tion.</t>
	d to just requesting authorization for an explicit domain identifier. Clients ne	<section anchor="authorization-object">
	ed a mechanism to do this in both newAuthz and newOrder requests. ACME servers n	<name>Authorization Object</name>
	eed a mechanism to indicate to clients that authorization objects are valid for	<t>ACME (<xref section="7.1.4" sectionFormat="comma" target="RFC8555"/>)
	all subdomains under the specified domain. These are described in this section.<	defines the authorization object. This document defines a new <tt>subdomainAuth
	/t>	Allowed</tt> field for the authorization object.
		When ACME server policy allows authorization for subdomains subordinate to a dom
	<section anchor="authorization-object"><name>Authorization Object</name>	ain, the server indicates this by including the new <tt>subdomainAuthAllowed</tt
		> field in the authorization object for that domain identifier:</t>
	<t>ACME (<xref section="7.1.4" sectionFormat="comma" target="RFC8555"/>) defines	<dl>
	the authorization object. This document defines a new "subdomainAuthAllowed" fi	<dt><tt>subdomainAuthAllowed</tt> (optional, boolean):</dt>
	eld for the authorization object. When ACME server policy allows authorization f	<dd>If present, this field
	or subdomains subordinate to a domain, the server indicates this by including th	<bcp14>MUST</bcp14> be true for authorizations where ACME server policy
	e new "subdomainAuthAllowed" field in the authorization object for that domain i
	dentifier:</t>

	<figure><artwork><![CDATA[
	subdomainAuthAllowed (optional, boolean): If present, this field
	MUST be true for authorizations where ACME server policy
	allows certificates to be issued for any subdomain subordinate	allows certificates to be issued for any subdomain subordinate

	to the domain specified in the 'identifier' field of the	to the domain specified in the <tt>identifier</tt> field of the
	authorization object.	authorization object.</dd>
	]]></artwork></figure>	</dl>
		<!--[rfced] Regarding the use of fixed-width font:
	<t>The following example shows an authorization object for the domain <spanx sty	where the spanx element was used in the provided XML file, now
	le="verb">example.org</spanx> where the authorization covers the subdomains subo	the <tt> element is present. Please review whether you would like to
	rdinate to <spanx style="verb">example.org</spanx>.</t>	use that element elsewhere for consistent usage. It yields
		fixed-width font in the PDF and HTML files.
	<figure><artwork><![CDATA[	Example of usage: ... for the domain <tt>example.org</tt>
	{	-->
	"status": "valid",	<t>The following example shows an authorization object for the domain <t
	"expires": "2023-09-01T14:09:07.99Z",	t>example.org</tt>, where the authorization covers the subdomains subordinate to
		<tt>example.org</tt>.</t>
	"identifier": {
	"type": "dns",
	"value": "example.org"
	},

	"challenges": [
	{
	"url": "https://example.com/acme/chall/prV_B7yEyA4",
	"type": "http-01",
	"status": "valid",
	"token": "DGyRejmCefe7v4NfDGDKfA",
	"validated": "2014-12-01T12:05:58.16Z"
	}
	],

	"subdomainAuthAllowed": true
	}
	]]></artwork></figure>

	<t>If the "subdomainAuthAllowed" field is not included, then the assumed default
	value is false.</t>

	<t>If ACME server policy allows issuance of certificates containing wildcard ide
	ntifiers under that authorization object, then the server <bcp14>SHOULD</bcp14>
	include the "wildcard" field with a value of true, as per <xref section="7.1.4"
	sectionFormat="comma" target="RFC8555"/>.</t>


	</section>	<sourcecode type="json"><![CDATA[
	<section anchor="pre-authorization"><name>Pre-Authorization</name>	{
		"status": "valid",
		"expires": "2023-09-01T14:09:07.99Z",


	<t>The basic ACME workflow has authorization objects created reactively in respo	"identifier": {
	nse to a certificate order. ACME also allows for pre-authorization, where client	"type": "dns",
	s obtain authorization for an identifier proactively, outside of the context of	"value": "example.org"
	a specific issuance. With the ACME pre-authorization flow, a client can pre-auth	},
	orize for a domain once, and then issue multiple newOrder requests for certifica
	tes with identifiers in the subdomains subordinate to that domain.</t>


	<t>ACME <xref section="7.4.1" sectionFormat="comma" target="RFC8555"/> defines t	"challenges": [
	he "identifier" object for newAuthz requests. This document defines a new "subdo	{
	mainAuthAllowed" field for the "identifier" object:</t>	"url": "https://example.com/acme/chall/prV_B7yEyA4",
		"type": "http-01",
		"status": "valid",
		"token": "DGyRejmCefe7v4NfDGDKfA",
		"validated": "2014-12-01T12:05:58.16Z"
		}
		],


	<figure><artwork><![CDATA[	"subdomainAuthAllowed": true
	subdomainAuthAllowed (optional, boolean): An ACME client sets	}
		]]></sourcecode>
		<t>If the <tt>subdomainAuthAllowed</tt> field is not included, then the
		assumed default value is false.</t>
		<t>If ACME server policy allows issuance of certificates containing wild
		card identifiers under that authorization object, then the server <bcp14>SHOULD<
		/bcp14> include the <tt>wildcard</tt> field with a value of true, as per <xref s
		ection="7.1.4" sectionFormat="comma" target="RFC8555"/>.</t>
		</section>
		<section anchor="pre-authorization">
		<name>Pre-authorization</name>
		<t>The basic ACME workflow has authorization objects created reactively
		in response to a certificate order. ACME also allows for pre-authorization, wher
		e clients obtain authorization for an identifier proactively, outside of the con
		text of a specific issuance. With the ACME pre-authorization flow, a client can
		pre-authorize for a domain once and then issue multiple newOrder requests for ce
		rtificates with identifiers in the subdomains subordinate to that domain.</t>
		<t>ACME (<xref section="7.4.1" sectionFormat="comma" target="RFC8555"/>)
		defines the <tt>identifier</tt> object for newAuthz requests. This document def
		ines a new <tt>subdomainAuthAllowed</tt> field for the <tt>identifier</tt> objec
		t:</t>
		<dl>
		<dt><tt>subdomainAuthAllowed</tt> (optional, boolean):</dt>
		<dd>An ACME client sets
	this flag to indicate to the server that it is requesting an	this flag to indicate to the server that it is requesting an
	authorization for the subdomains subordinate to the specified	authorization for the subdomains subordinate to the specified

	domain identifier value	domain identifier value.</dd>
	]]></artwork></figure>	</dl>
		<t>Clients include the new <tt>subdomainAuthAllowed</tt> field in the <t
	<t>Clients include the new "subdomainAuthAllowed" field in the "identifier" obje	t>identifier</tt> object of newAuthz requests to indicate that they are requesti
	ct of newAuthz requests to indicate that they are requesting a subdomain authori	ng a subdomain authorization. In the following example of a newAuthz payload, th
	zation. In the following example newAuthz payload, the client is requesting pre-	e client is requesting pre-authorization for the subdomains subordinate to <tt>e
	authorization for the subdomains subordinate to <spanx style="verb">example.org<	xample.org</tt>.</t>
	/spanx>.</t>	<sourcecode type="json"><![CDATA[
		"payload": base64url({
	<figure><artwork><![CDATA[	"identifier": {
	"payload": base64url({	"type": "dns",
	"identifier": {	"value": "example.org",
	"type": "dns",	"subdomainAuthAllowed": true
	"value": "example.org",	}
	"subdomainAuthAllowed": true	})
	}	]]></sourcecode>
	})	<t>If the server is willing to allow a single authorization for the subd
	]]></artwork></figure>	omains and there is not an existing authorization object for the identifier, the
		n it will create an authorization object and include the <tt>subdomainAuthAllowe
	<t>If the server is willing to allow a single authorization for the subdomains,	d</tt> flag with a value of true.</t>
	and there is not an existing authorization object for the identifier, then it wi	<t>If the server policy does not allow creation of subdomain authorizati
	ll create an authorization object and include the "subdomainAuthAllowed" flag wi	ons subordinate to that domain, the server can create an authorization object fo
	th value of true.</t>	r the indicated identifier and <bcp14>MAY</bcp14> include the <tt>subdomainAuthA
		llowed</tt> flag with a value of false. If the server creates an authorization o
	<t>If the server policy does not allow creation of subdomain authorizations subo	bject and does not include the <tt>subdomainAuthAllowed</tt> flag, then the assu
	rdinate to that domain, the server can create an authorization object for the in	med value is false.</t>
	dicated identifier, and <bcp14>MAY</bcp14> include the "subdomainAuthAllowed" fl	<t>In both scenarios, handling of the pre-authorization follows the proc
	ag with value of false. If the server creates an authorization object and does n	ess documented in ACME <xref section="7.4.1" sectionFormat="comma" target="RFC85
	ot include the "subdomainAuthAllowed" flag, then the assumed value is false.</t>	55"/>.</t>
		</section>
	<t>In both scenarios, handling of the pre-authorization follows the process docu	<section anchor="new-orders">
	mented in ACME <xref section="7.4.1" sectionFormat="comma" target="RFC8555"/>.</	<name>New Orders</name>
	t>	<t>Clients need a mechanism to optionally indicate to servers whether or
		not they are authorized to fulfill challenges against an ancestor domain for a
	</section>	given identifier. For example, if a client places an order for an identifier <tt
	<section anchor="new-orders"><name>New Orders</name>	>foo.bar.example.org</tt> and is authorized to fulfill a challenge against the a
		ncestor domains <tt>bar.example.org</tt> or <tt>example.org</tt>, then the clien
	<t>Clients need a mechanism to optionally indicate to servers whether or not the	t needs a mechanism to indicate control over the ancestor domains to the ACME se
	y are authorized to fulfill challenges against an ancestor domain for a given id	rver.</t>
	entifier. For example, if a client places an order for an identifier <spanx styl	<t>In order to accomplish this, this document defines a new <tt>ancestor
	e="verb">foo.bar.example.org</spanx>, and is authorized to fulfill a challenge a	Domain</tt> field for the identifier that is included in order objects.</t>
	gainst the ancestor domains <spanx style="verb">bar.example.org</spanx> or <span	<dl>
	x style="verb">example.org</spanx>, then the client needs a mechanism to indicat	<dt><tt>ancestorDomain</tt> (optional, string):</dt>
	e control over the ancestor domains to the ACME server.</t>	<dd>This is an ancestor domain of
		the requested identifier. The client <bcp14>MUST</bcp14> be able to fulfill
	<t>In order to accomplish this, this document defines a new "ancestorDomain" fie	a challenge against the ancestor domain.</dd>
	ld for the identifier that is included in order objects.</t>	</dl>
		<t>This field specifies an ancestor domain of the identifier that the cl
	<figure><artwork><![CDATA[	ient has DNS control over and is capable of fulfilling challenges against. Based
	ancestorDomain (optional, string): This is an ancestor domain of	on server policy, the server can choose to issue a challenge against any ancest
	the requested identifier. The client MUST be able to fulfill	or domain of the identifier up to and including the specified <tt>ancestorDomain
	a challenge against the ancestor domain.	</tt> and create a corresponding authorization object against the chosen identif
	]]></artwork></figure>	ier.</t>
		<t>In the following example of a newOrder payload, the client requests a
	<t>This field specifies an ancestor domain of the identifier that the client has	certificate for identifier <tt>foo.bar.example.org</tt> and indicates that it c
	DNS control over, and is capable of fulfilling challenges against. Based on ser	an fulfill a challenge against the ancestor domain <tt>bar.example.org</tt>. The
	ver policy, the server can choose to issue a challenge against any ancestor doma	server can then choose to issue a challenge against either <tt>foo.bar.example.
	in of the identifier up to and including the specified "ancestorDomain", and cre	org</tt> or <tt>bar.example.org</tt> identifiers.</t>
	ate a corresponding authorization object against the chosen identifier.</t>	<sourcecode type="json"><![CDATA[

	<t>In the following example newOrder payload, the client requests a certificate
	for identifier <spanx style="verb">foo.bar.example.org</spanx> and indicates tha
	t it can fulfill a challenge against the ancestor domain <spanx style="verb">bar
	.example.org</spanx>. The server can then choose to issue a challenge against ei
	ther <spanx style="verb">foo.bar.example.org</spanx> or <spanx style="verb">bar.
	example.org</spanx> identifiers.</t>

	<figure><artwork><![CDATA[
	"payload": base64url({	"payload": base64url({
	"identifiers": [	"identifiers": [
	{ "type": "dns",	{ "type": "dns",
	"value": "foo.bar.example.org",	"value": "foo.bar.example.org",
	"ancestorDomain": "bar.example.org" }	"ancestorDomain": "bar.example.org" }
	],	],
	"notBefore": "2023-09-01T00:04:00+04:00",	"notBefore": "2023-09-01T00:04:00+04:00",
	"notAfter": "2023-09-08T00:04:00+04:00"	"notAfter": "2023-09-08T00:04:00+04:00"
	})	})

	]]></artwork></figure>	]]></sourcecode>
		<t>In the following example of a newOrder payload, the client requests a
	<t>In the following example newOrder payload, the client requests a certificate	certificate for identifier <tt>foo.bar.example.org</tt> and indicates that it c
	for identifier <spanx style="verb">foo.bar.example.org</spanx> and indicates tha	an fulfill a challenge against the ancestor domain <tt>example.org</tt>. The ser
	t it can fulfill a challenge against the ancestor domain <spanx style="verb">exa	ver can then choose to issue a challenge against any one of <tt>foo.bar.example.
	mple.org</spanx>. The server can then choose to issue a challenge against any on	org</tt>, <tt>bar.example.org</tt>, or <tt>example.org</tt> identifiers.</t>
	e of <spanx style="verb">foo.bar.example.org</spanx>, <spanx style="verb">bar.ex	<sourcecode type="json"><![CDATA[
	ample.org</spanx> or <spanx style="verb">example.org</spanx> identifiers.</t>

	<figure><artwork><![CDATA[
	"payload": base64url({	"payload": base64url({
	"identifiers": [	"identifiers": [
	{ "type": "dns",	{ "type": "dns",
	"value": "foo.bar.example.org",	"value": "foo.bar.example.org",
	"ancestorDomain": "example.org" }	"ancestorDomain": "example.org" }
	],	],
	"notBefore": "2023-09-01T00:04:00+04:00",	"notBefore": "2023-09-01T00:04:00+04:00",
	"notAfter": "2023-09-08T00:04:00+04:00"	"notAfter": "2023-09-08T00:04:00+04:00"
	})	})

	]]></artwork></figure>	]]></sourcecode>
		<t>If the client is unable to fulfill authorizations against an ancestor
	<t>If the client is unable to fulfill authorizations against an ancestor domain,	domain, the client should not include the <tt>ancestorDomain</tt> field.</t>
	the client should not include the "ancestorDomain" field.</t>	<t>Server newOrder handling generally follows the process documented in
		ACME (<xref section="7.4" sectionFormat="of" target="RFC8555"/>). If the server
	<t>Server newOrder handling generally follows the process documented in ACME, <x	is willing to allow subdomain authorizations for the domain specified in <tt>anc
	ref section="7.4" sectionFormat="of" target="RFC8555"/>. If the server is willin	estorDomain</tt>, then it creates an authorization object against that ancestor
	g to allow subdomain authorizations for the domain specified in "ancestorDomain"	domain and includes the <tt>subdomainAuthAllowed</tt> flag with a value of true.
	, then it creates an authorization object against that ancestor domain and inclu	</t>
	des the "subdomainAuthAllowed" flag with a value of true.</t>	<t>If the server policy does not allow creation of subdomain authorizati
		ons against that ancestor domain, then it can create an authorization object for
	<t>If the server policy does not allow creation of subdomain authorizations agai	the indicated identifier value and <bcp14>SHOULD NOT</bcp14> include the <tt>su
	nst that ancestor domain, then it can create an authorization object for the ind	bdomainAuthAllowed</tt> flag. As the client requested a subdomain authorization
	icated identifier value, and <bcp14>SHOULD NOT</bcp14> include the "subdomainAut	for the ancestor domain and not for the indicated identifier, there is no need f
	hAllowed" flag. As the client requested a subdomain authorization for the ancest	or the server to include the <tt>subdomainAuthAllowed</tt> flag in the authoriza
	or domain, and not for the indicated identifier, there is no need for the server	tion object for the indicated identifier.</t>
	to include the "subdomainAuthAllowed" flag in the authorization object for the	</section>
	indicated identifier.</t>	<section anchor="directory-object-metadata">
		<name>Directory Object Metadata</name>
	</section>	<t>This document defines a new <tt>subdomainAuthAllowed</tt> ACME direct
	<section anchor="directory-object-metadata"><name>Directory Object Metadata</nam	ory metadata field. An ACME server can advertise support for authorization of su
	e>	bdomains by including the <tt>subdomainAuthAllowed</tt> boolean flag in its "ACM
		E Directory Metadata Fields" registry:</t>
	<t>This document defines a new "subdomainAuthAllowed" ACME directory metadata fi	<dl>
	eld. An ACME server can advertise support for authorization of subdomains by inc	<dt><tt>subdomainAuthAllowed</tt> (optional, bool):</dt>
	luding the "subdomainAuthAllowed" boolean flag in its "ACME Directory Metadata F	<dd>Indicates if an ACME
	ields" registry:</t>	server supports authorization of subdomains.</dd>
		</dl>
	<figure><artwork><![CDATA[	<t>If not specified, then the assumed default value is false. If an ACME
	subdomainAuthAllowed (optional, bool): Indicates if an ACME	server supports authorization of subdomains, it can indicate this by including
	server supports authorization of subdomains.	this field with a value of "true".</t>
	]]></artwork></figure>	</section>
		</section>
	<t>If not specified, then the assumed default value is false. If an ACME server	<section anchor="illustrative-call-flow">
	supports authorization of subdomains, it can indicate this by including this fie	<name>Illustrative Call Flow</name>
	ld with a value of "true".</t>	<t>The call flow illustrated here uses the ACME pre-authorization flow usi
		ng DNS-based proof of ownership.</t>
	</section>	<artwork><![CDATA[
	</section>
	<section anchor="illustrative-call-flow"><name>Illustrative Call Flow</name>

	<t>The call flow illustrated here uses the ACME pre-authorization flow using DNS
	-based proof of ownership.</t>

	<figure><artwork><![CDATA[
	+--------+ +------+ +-----+	+--------+ +------+ +-----+
	\| Client \| \| ACME \| \| DNS \|	\| Client \| \| ACME \| \| DNS \|
	+--------+ +------+ +-----+	+--------+ +------+ +-----+
	\| \| \|	\| \| \|

	STEP 1: Pre-Authorization of ancestor domain	Step 1: Pre-authorization of ancestor domain.
	\| \| \|	\| \| \|
	\| POST /newAuthz \| \|	\| POST /newAuthz \| \|
	\| "example.org" \| \|	\| "example.org" \| \|
	\|--------------------------->\| \|	\|--------------------------->\| \|
	\| \| \|	\| \| \|
	\| 201 authorizations \| \|	\| 201 authorizations \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|
	\| Publish DNS TXT \| \|	\| Publish DNS TXT \| \|
	\| "example.org" \| \|	\| "example.org" \| \|

	skipping to change at line 345 ¶	skipping to change at line 307 ¶
	\|--------------------------->\| \|	\|--------------------------->\| \|
	\| \| Verify \|	\| \| Verify \|
	\| \|---------->\|	\| \|---------->\|
	\| 200 status=valid \| \|	\| 200 status=valid \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|
	\| Delete DNS TXT \| \|	\| Delete DNS TXT \| \|
	\| "example.org" \| \|	\| "example.org" \| \|
	\|--------------------------------------->\|	\|--------------------------------------->\|
	\| \| \|	\| \| \|

	STEP 2: Place order for sub1.example.org	Step 2: Place order for sub1.example.org.
	\| \| \|	\| \| \|
	\| POST /newOrder \| \|	\| POST /newOrder \| \|
	\| "sub1.example.org" \| \|	\| "sub1.example.org" \| \|
	\|--------------------------->\| \|	\|--------------------------->\| \|
	\| \| \|	\| \| \|
	\| 201 status=ready \| \|	\| 201 status=ready \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|
	\| POST /finalize \| \|	\| POST /finalize \| \|
	\| CSR SAN "sub1.example.org" \| \|	\| CSR SAN "sub1.example.org" \| \|

	skipping to change at line 368 ¶	skipping to change at line 330 ¶
	\| 200 OK status=valid \| \|	\| 200 OK status=valid \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|
	\| POST /certificate \| \|	\| POST /certificate \| \|
	\|--------------------------->\| \|	\|--------------------------->\| \|
	\| \| \|	\| \| \|
	\| 200 OK \| \|	\| 200 OK \| \|
	\| PEM SAN "sub1.example.org" \| \|	\| PEM SAN "sub1.example.org" \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|

	STEP 3: Place order for sub2.example.org	Step 3: Place order for sub2.example.org.
	\| \| \|	\| \| \|
	\| POST /newOrder \| \|	\| POST /newOrder \| \|
	\| "sub2.example.org" \| \|	\| "sub2.example.org" \| \|
	\|--------------------------->\| \|	\|--------------------------->\| \|
	\| \| \|	\| \| \|
	\| 201 status=ready \| \|	\| 201 status=ready \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|
	\| POST /finalize \| \|	\| POST /finalize \| \|
	\| CSR SAN "sub2.example.org" \| \|	\| CSR SAN "sub2.example.org" \| \|

	skipping to change at line 390 ¶	skipping to change at line 352 ¶
	\| \| \|	\| \| \|
	\| 200 OK status=valid \| \|	\| 200 OK status=valid \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|
	\| \| \|	\| \| \|
	\| POST /certificate \| \|	\| POST /certificate \| \|
	\|--------------------------->\| \|	\|--------------------------->\| \|
	\| \| \|	\| \| \|
	\| 200 OK \| \|	\| 200 OK \| \|
	\| PEM SAN "sub2.example.org" \| \|	\| PEM SAN "sub2.example.org" \| \|
	\|<---------------------------\| \|	\|<---------------------------\| \|

	]]></artwork></figure>	]]></artwork>

	<t><list style="symbols">
	<t>STEP 1: Pre-authorization of ancestor domain <vspace blankLines='1'/>
	The client sends a newAuthz request for the ancestor domain including the "subdo
	mainAuthAllowed" flag in the identifier object.</t>
	</list></t>

	<figure><artwork><![CDATA[
	POST /acme/new-authz HTTP/1.1
	Host: example.com
	Content-Type: application/jose+json

	{
	"protected": base64url({
	"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
	"url": "https://example.com/acme/new-authz"
	}),
	"payload": base64url({
	"identifier": {
	"type": "dns",
	"value": "example.org",
	"subdomainAuthAllowed": true
	}
	}),
	"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
	}
	]]></artwork></figure>

	<t>The server creates and returns an authorization object for the identifier inc
	luding the "subdomainAuthAllowed" flag. The object is initially in "pending" sta
	te.</t>

	<figure><artwork><![CDATA[
	{
	"status": "pending",
	"expires": "2023-09-01T14:09:07.99Z",

	"identifier": {
	"type": "dns",
	"value": "example.org"
	},

	"challenges": [
	{
	"url": "https://example.com/acme/chall/prV_B7yEyA4",
	"type": "dns-01",
	"status": "pending",
	"token": "DGyRejmCefe7v4NfDGDKfA",
	"validated": "2023-08-01T12:05:58.16Z"
	}
	],

	"subdomainAuthAllowed": true
	}
	]]></artwork></figure>

	<t>The example illustrates the client completing a DNS challenge by publishing a
	DNS TXT record. The client then posts to the challenge resource to inform the s
	erver that it can validate the challenge.</t>

	<t>Once the server validates the challenge by checking the DNS TXT record, the s
	erver will transition the authorization object and associated challenge object s
	tatus to "valid".</t>

	<t>The call flow above illustrates the ACME server replying to the client's chal
	lenge with status of "valid" after the ACME server has validated the DNS challen
	ge. However, the validation flow may take some time. If this is the case, the AC
	ME server may reply to the client's challenge immediately with a status of "proc
	essing", and the client will then need to poll the authorization resource to see
	when it is finalized. Refer to ACME <xref section="7.5.1" sectionFormat="comma"
	target="RFC8555"/> for more details.</t>

	<t><list style="symbols">
	<t>STEP 2: The client places a newOrder for <spanx style="verb">sub1.example.o
	rg</spanx> <vspace blankLines='1'/>
	The client sends a newOrder request to the server and includes the subdomain ide
	ntifier. Note that the identifier is a subdomain of the ancestor domain that has
	been pre-authorized in step 1. The client does not need to include the "subdoma
	inAuthAllowed" field in the "identifier" object as it has already pre-authorized
	the ancestor domain.</t>
	</list></t>

	<figure><artwork><![CDATA[
	POST /acme/new-order HTTP/1.1
	Host: example.com
	Content-Type: application/jose+json

	{
	"protected": base64url({
	"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	"nonce": "5XJ1L3lEkMG7tR6pA00clA",
	"url": "https://example.com/acme/new-order"
	}),
	"payload": base64url({
	"identifiers": [
	{ "type": "dns", "value": "sub1.example.org" }
	],
	"notBefore": "2023-09-01T00:04:00+04:00",
	"notAfter": "2023-09-08T00:04:00+04:00"
	}),
	"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
	}
	]]></artwork></figure>

	<t>As an authorization object already exists for the ancestor domain, the server
	replies with an order object with a status of "ready" that includes a link to t
	he existing "valid" authorization object.</t>

	<figure><artwork><![CDATA[
	HTTP/1.1 201 Created
	Replay-Nonce: MYAuvOpaoIiywTezizk5vw
	Link: <https://example.com/acme/directory>;rel="index"
	Location: https://example.com/acme/order/TOlocE8rfgo

	{
	"status": "ready",
	"expires": "2023-09-01T14:09:07.99Z",

	"notBefore": "2023-09-01T00:00:00Z",
	"notAfter": "2023-09-08T00:00:00Z",

	"identifiers": [
	{ "type": "dns", "value": "sub1.example.org" }
	],

	"authorizations": [
	"https://example.com/acme/authz/PAniVnsZcis"
	],

	"finalize": "https://example.com/acme/order/TOlocrfgo/finalize"
	}
	]]></artwork></figure>

	<t>The client can proceed to finalize the order by posting a CSR to the "finaliz
	e" resource. The client can then download the certificate for <spanx style="verb
	">sub1.example.org</spanx>.</t>

	<t><list style="symbols">
	<t>STEP 3: The client places a newOrder for <spanx style="verb">sub2.example.o
	rg</spanx> <vspace blankLines='1'/>
	The client sends a newOrder request to the server and includes the subdomain ide
	ntifier. Note that the identifier is a subdomain of the ancestor domain that has
	been pre-authorized in step 1. The client does not need to include the "subdoma
	inAuthAllowed" field in the "identifier" object as it has already pre-authorized
	the ancestor domain.</t>
	</list></t>

	<figure><artwork><![CDATA[
	POST /acme/new-order HTTP/1.1
	Host: example.com
	Content-Type: application/jose+json

	{
	"protected": base64url({
	"alg": "ES256",
	"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	"nonce": "5XJ1L3lEkMG7tR6pA00clA",
	"url": "https://example.com/acme/new-order"
	}),
	"payload": base64url({
	"identifiers": [
	{ "type": "dns", "value": "sub2.example.org" }
	],
	"notBefore": "2023-09-01T00:04:00+04:00",
	"notAfter": "2023-09-08T00:04:00+04:00"
	}),
	"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
	}
	]]></artwork></figure>

	<t>As an authorization object already exists for the ancestor domain, the server
	replies with an order object with a status of "ready" that includes a link to t
	he existing "valid" authorization object.</t>

	<figure><artwork><![CDATA[
	HTTP/1.1 201 Created
	Replay-Nonce: MYAuvOpaoIiywTezizk5vw
	Link: <https://example.com/acme/directory>;rel="index"
	Location: https://example.com/acme/order/TOlocE8rfgo

	{
	"status": "ready",
	"expires": "2023-09-01T14:09:07.99Z",

	"notBefore": "2023-09-01T00:00:00Z",
	"notAfter": "2023-09-08T00:00:00Z",

	"identifiers": [
	{ "type": "dns", "value": "sub2.example.org" }
	],

	"authorizations": [
	"https://example.com/acme/authz/PAniVnsZcis"
	],

	"finalize": "https://example.com/acme/order/ROni7rdde/finalize"
	}
	]]></artwork></figure>

	<t>The client can proceed to finalize the order by posting a CSR to the "finaliz
	e" resource. The client can then download the certificate for <spanx style="verb
	">sub2.example.org</spanx>.</t>

	</section>
	<section anchor="iana-considerations"><name>IANA Considerations</name>

	<section anchor="authorization-object-fields-registry"><name>Authorization Objec
	t Fields Registry</name>

	<t>The following field is added to the "ACME Authorization Object Fields" regist
	ry defined in ACME <xref target="RFC8555"/>.</t>

	<figure><artwork><![CDATA[
	+----------------------+------------+--------------+-----------+
	\| Field Name \| Field Type \| Configurable \| Reference \|
	+----------------------+------------+--------------+-----------+
	\| subdomainAuthAllowed \| boolean \| false \| RFC XXXX \|
	+----------------------+------------+--------------+-----------+
	]]></artwork></figure>

	</section>
	<section anchor="directory-object-metadata-fields-registry"><name>Directory Obje
	ct Metadata Fields Registry</name>

	<t>The following field is added to the "ACME Directory Metadata Fields" registry
	defined in ACME <xref target="RFC8555"/>.</t>

	<figure><artwork><![CDATA[
	+----------------------+------------+-----------+
	\| Field Name \| Field Type \| Reference \|
	+----------------------+------------+-----------+
	\| subdomainAuthAllowed \| boolean \| RFC XXXX \|
	+----------------------+------------+-----------+
	]]></artwork></figure>


	</section>	<ul>
	</section>	<li>
	<section anchor="security-considerations"><name>Security Considerations</name>	<t>Step 1: Pre-authorization of ancestor domain.</t>
		<t>
		The client sends a newAuthz request for the ancestor domain and includes the <tt
		>subdomainAuthAllowed</tt> flag in the identifier object.</t>


	<t>This document specifies enhancements to ACME <xref target="RFC8555"/> that op	<sourcecode type="http-message"><![CDATA[
	timize the protocol flows for issuance of certificates for subdomains. The under	POST /acme/new-authz HTTP/1.1
	lying goal of ACME for Subdomains remains the same as that of ACME: managing cer	Host: example.com
	tificates that attest to identifier/key bindings for these subdomains. Thus, ACM	Content-Type: application/jose+json
	E for Subdomains has the same two security goals as ACME:</t>


	<t><list style="numbers">	{
	<t>Only an entity that controls an identifier can get an authorization for tha	"protected": base64url({
	t identifier</t>	"alg": "ES256",
	<t>Once authorized, an account key's authorizations cannot be improperly used	"kid": "https://example.com/acme/acct/evOfKhNU60wg",
	by another account</t>	"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
	</list></t>	"url": "https://example.com/acme/new-authz"
		}),
		"payload": base64url({
		"identifier": {
		"type": "dns",
		"value": "example.org",
		"subdomainAuthAllowed": true
		}
		}),
		"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
		}
		]]></sourcecode>


	<t>ACME for Subdomains makes no changes to:</t>	<t>The server creates and returns an authorization object for the identifi
		er that includes the <tt>subdomainAuthAllowed</tt> flag. The object is initially
		in "pending" state.</t>
		<sourcecode type="json"><![CDATA[
		{
		"status": "pending",
		"expires": "2023-09-01T14:09:07.99Z",


	<t><list style="symbols">	"identifier": {
	<t>account or account key management</t>	"type": "dns",
	<t>ACME channel establishment, security mechanisms or threat model</t>	"value": "example.org"
	<t>Validation channel establishment, security mechanisms or threat model</t>	},
	</list></t>


	<t>Therefore, all Security Considerations in ACME in the following areas are equ	"challenges": [
	ally applicable to ACME for Subdomains:</t>	{
		"url": "https://example.com/acme/chall/prV_B7yEyA4",
		"type": "dns-01",
		"status": "pending",
		"token": "DGyRejmCefe7v4NfDGDKfA",
		"validated": "2023-08-01T12:05:58.16Z"
		}
		],


	<t><list style="symbols">	"subdomainAuthAllowed": true
	<t>Threat Model</t>	}
	<t>Integrity of Authorizations</t>	]]></sourcecode>
	<t>Denial-of-Service Considerations</t>	<t>The example illustrates the client completing a DNS challenge by publis
	<t>Server-Side Request Forgery</t>	hing a DNS TXT record. The client then posts to the challenge resource to inform
	<t>CA Policy Considerations</t>	the server that it can validate the challenge.</t>
	</list></t>	<t>Once the server validates the challenge by checking the DNS TXT record,
		the server will transition the authorization object and associated challenge ob
		ject status to "valid".</t>
		<t>The call flow above illustrates the ACME server replying to the client'
		s challenge with status of "valid" after the ACME server has validated the DNS c
		hallenge. However, the validation flow may take some time. If this is the case,
		the ACME server may reply to the client's challenge immediately with a status of
		"processing" and the client will then need to poll the authorization resource t
		o see when it is finalized. Refer to <xref section="7.5.1" sectionFormat="of" ta
		rget="RFC8555"/> for more details.</t>
		</li>


	<t>The only exception is that in order to satisfy goal (1) above, this draft ass	<li>
	umes that control over a domain may imply control over a subdomain, and therefor	<t>Step 2: The client places a newOrder for <tt>sub1.example.org</tt>.</t>
	e authorization for certificate issuance for the former may imply authorization	<t>
	for certificate issuance for the latter. In many ecosystems, this is a safe ass	The client sends a newOrder request to the server and includes the subdomain
	umption, especially because control over the domain can often be leveraged to su	identifier. Note that the identifier is a subdomain of the ancestor domain that
	ccessfully demonstrate control over subdomains anyway, for example by temporaril	has been pre-authorized in Step 1. The client does not need to include the <tt>
	y modifying DNS for the subdomain to point to a server the ancestor domain owner	subdomainAuthAllowed</tt> field in the <tt>identifier</tt> object, as it has alr
	controls, rendering the distinction moot. For example, the CA/Browser Forum Ba	eady pre-authorized the ancestor domain.</t>
	seline Requirements may consider control of an ancestor domain sufficient for is
	suance of certificates for subdomains, but only if specific processes and proced
	ures are used for validating ownership of the ancestor domain.</t>


	<t>In ecosystems where control of an ancestor domain may not imply control over	<sourcecode type="http-message"><![CDATA[
	subdomains or authorization for issuance of certificates for subdomains, a more	POST /acme/new-order HTTP/1.1
	complicated threat analysis and server policy might be needed.</t>	Host: example.com
		Content-Type: application/jose+json


	<t>Some additional comments on ACME server policy are given later in this sectio	{
	n.</t>	"protected": base64url({
		"alg": "ES256",
		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
		"nonce": "5XJ1L3lEkMG7tR6pA00clA",
		"url": "https://example.com/acme/new-order"
		}),
		"payload": base64url({
		"identifiers": [
		{ "type": "dns", "value": "sub1.example.org" }
		],
		"notBefore": "2023-09-01T00:04:00+04:00",
		"notAfter": "2023-09-08T00:04:00+04:00"
		}),
		"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
		}
		]]></sourcecode>
		<t>As an authorization object already exists for the ancestor domain, the
		server replies with an order object with a status of "ready" that includes a lin
		k to the existing "valid" authorization object.</t>
		<sourcecode type="http-message"><![CDATA[
		HTTP/1.1 201 Created
		Replay-Nonce: MYAuvOpaoIiywTezizk5vw
		Link: <https://example.com/acme/directory>;rel="index"
		Location: https://example.com/acme/order/TOlocE8rfgo


	<section anchor="client-account-security"><name>Client Account Security</name>	{
		"status": "ready",
		"expires": "2023-09-01T14:09:07.99Z",


	<t>There may be scenarios were a client wishes to deactivate an authorization ob	"notBefore": "2023-09-01T00:00:00Z",
	ject for an ancestor domain, or deactivate its account completely. For example,	"notAfter": "2023-09-08T00:00:00Z",
	a client may want to do this if an account key is compromised, or if a authoriza
	tion object covering domains subordinate to an ancestor domain is no longer need
	ed. The client can deactivate an authorization using the mechanism specified in
	<xref section="7.5.2" sectionFormat="comma" target="RFC8555"/> and can deactivat
	e an account using the mechanism specified in <xref section="7.3.6" sectionForma
	t="comma" target="RFC8555"/>.</t>


	</section>	"identifiers": [
	<section anchor="subdomain-determination"><name>Subdomain Determination</name>	{ "type": "dns", "value": "sub1.example.org" }
		],


	<t>The <xref target="RFC8499"/> definition of a subdomain is reproduced in <xref	"authorizations": [
	target="terminology"/>. When comparing domains to determine if one is a subdoma	"https://example.com/acme/authz/PAniVnsZcis"
	in of the other, it is important to compare entire labels, and not rely on a str	],
	ing prefix match. Relying on string prefix matches may yield incorrect results.<
	/t>


	</section>	"finalize": "https://example.com/acme/order/TOlocrfgo/finalize"
	<section anchor="acme-server-policy-considerations"><name>ACME Server Policy Con	}
	siderations</name>	]]></sourcecode>
		<t>The client can proceed to finalize the order by posting a CSR to the <t
		t>finalize</tt> resource. The client can then download the certificate for <tt>s
		ub1.example.org</tt>.</t>
		</li>


	<t>The ACME for Subdomains and the ACME specifications do not mandate any specif	<li>
	ic ACME server or CA policies, or any specific use cases for issuance of certifi	<t>Step 3: The client places a newOrder for <tt>sub2.example.org</tt>. </t>
	cates. For example, an ACME server could be used:</t>	<t>
		The client sends a newOrder request to the server and includes the subdomain
		identifier. Note that the identifier is a subdomain of the ancestor domain that
		has been pre-authorized in Step 1. The client does not need to include the <tt>
		subdomainAuthAllowed</tt> field in the <tt>identifier</tt> object, as it has alr
		eady pre-authorized the ancestor domain.</t>


	<t><list style="symbols">	<sourcecode type="http-message"><![CDATA[
	<t>to issue Web PKI certificates where the ACME server must comply with CA/Bro	POST /acme/new-order HTTP/1.1
	wser Forum <xref target="CAB"></xref> Baseline Requirements.</t>	Host: example.com
	<t>as a Private CA for issuance of certificates within an organization. The or	Content-Type: application/jose+json
	ganization could enforce whatever policies they desire on the ACME server.</t>
	<t>for issuance of IoT device certificates. There are currently no IoT device
	certificate policies that are generally enforced across the industry. Organizati
	ons issuing IoT device certificates can enforce whatever policies they desire on
	the ACME server.</t>
	</list></t>


	<t>ACME server policy could specify whether:</t>	{
		"protected": base64url({
		"alg": "ES256",
		"kid": "https://example.com/acme/acct/evOfKhNU60wg",
		"nonce": "5XJ1L3lEkMG7tR6pA00clA",
		"url": "https://example.com/acme/new-order"
		}),
		"payload": base64url({
		"identifiers": [
		{ "type": "dns", "value": "sub2.example.org" }
		],
		"notBefore": "2023-09-01T00:04:00+04:00",
		"notAfter": "2023-09-08T00:04:00+04:00"
		}),
		"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
		}
		]]></sourcecode>
		<t>As an authorization object already exists for the ancestor domain, the
		server replies with an order object with a status of "ready" that includes a lin
		k to the existing "valid" authorization object.</t>
		<sourcecode type="http-message"><![CDATA[
		HTTP/1.1 201 Created
		Replay-Nonce: MYAuvOpaoIiywTezizk5vw
		Link: <https://example.com/acme/directory>;rel="index"
		Location: https://example.com/acme/order/TOlocE8rfgo


	<t><list style="symbols">	{
	<t>issuance of subdomain certificates is allowed based on proof of ownership o	"status": "ready",
	f an ancestor domain</t>	"expires": "2023-09-01T14:09:07.99Z",
	<t>issuance of subdomain certificates is allowed, but only for a specific set
	of ancestor domains</t>
	<t>DNS based proof of ownership, or HTTP based proof of ownership, or both, ar
	e allowed</t>
	</list></t>


	<t>The CA policy considerations listed in <xref section="10.5" sectionFormat="co	"notBefore": "2023-09-01T00:00:00Z",
	mma" target="RFC8555"/> are equally applicable here. These include, but are not	"notAfter": "2023-09-08T00:00:00Z",
	limited to:</t>


	<t><list style="symbols">	"identifiers": [
	<t>Is the claimed identifier syntactically valid?</t>	{ "type": "dns", "value": "sub2.example.org" }
	<t>For domain names:</t>	],
	<t>Is the name on the Public Suffix List?</t>
	<t>Is the name a high-value name?</t>
	<t>Is the key in the CSR sufficiently strong?</t>
	</list></t>


	<t>Refer to <xref section="10.5" sectionFormat="comma" target="RFC8555"/> for mo	"authorizations": [
	re CA policy considerations.</t>	"https://example.com/acme/authz/PAniVnsZcis"
		],


	<t>ACME server policy specification is explicitly out of scope of this document.	"finalize": "https://example.com/acme/order/ROni7rdde/finalize"
	</t>	}
		]]></sourcecode>
		<t>The client can proceed to finalize the order by posting a CSR to the <t
		t>finalize</tt> resource. The client can then download the certificate for <tt>s
		ub2.example.org</tt>.</t>


	</section>	</li>
	</section>	</ul>
		</section>
		<section anchor="iana-considerations">
		<name>IANA Considerations</name>
		<section anchor="authorization-object-fields-registry">
		<name>Authorization Object Fields Registry</name>
		<t>The following field has been added to the "ACME Authorization Object
		Fields" registry defined in ACME <xref target="RFC8555"/>.</t>
		<table anchor="iana1">
		<name/>
		<thead>
		<tr>
		<th>Field Name</th>
		<th>Field Type</th>
		<th>Configurable</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>subdomainAuthAllowed</td>
		<td>boolean</td>
		<td>false</td>
		<td>RFC 9444</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="directory-object-metadata-fields-registry">
		<name>Directory Object Metadata Fields Registry</name>
		<t>The following field has been added to the "ACME Directory Metadata Fi
		elds" registry defined in <xref target="RFC8555"/>.</t>
		<table anchor="iana2">
		<name/>
		<thead>
		<tr>
		<th>Field Name</th>
		<th>Field Type</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>subdomainAuthAllowed</td>
		<td>boolean</td>
		<td>RFC 9444</td>
		</tr>
		</tbody>
		</table>
		</section>
		</section>
		<section anchor="security-considerations">
		<name>Security Considerations</name>
		<t>This document specifies enhancements to ACME <xref target="RFC8555"/> t
		hat optimize the protocol flows for issuance of certificates for subdomains. The
		underlying goal of ACME for Subdomains remains the same as that of ACME: managi
		ng certificates that attest to identifier/key bindings for these subdomains. Thu
		s, ACME for Subdomains has the same two security goals as ACME:</t>
		<ol spacing="normal" type="(%d)"><li>Only an entity that controls an ident
		ifier can get an authorization for that identifier.</li>
		<li>Once authorized, an account key's authorizations cannot be improperl
		y used by another account.</li>
		</ol>
		<t>ACME for Subdomains makes no changes to:</t>
		<ul spacing="normal">
		<li>account or account key management</li>
		<li>ACME channel establishment, security mechanisms, or threat model</li
		>
		<li>validation channel establishment, security mechanisms, or threat mod
		el</li>
		</ul>
		<t>Therefore, all Security Considerations in ACME in the following areas a
		re equally applicable to ACME for Subdomains:</t>
		<ul spacing="normal">
		<li>Threat Model</li>
		<li>Integrity of Authorizations</li>
		<li>Denial-of-Service Considerations</li>
		<li>Server-Side Request Forgery</li>
		<li>CA Policy Considerations</li>
		</ul>
		<t>The only exception is that in order to satisfy goal (1) above, this doc
		ument assumes that control over a domain may imply control over a subdomain; the
		refore, authorization for certificate issuance for the former may imply authoriz
		ation for certificate issuance for the latter.
		In many ecosystems, this is a safe assumption, especially because control over t
		he domain can often be leveraged to successfully demonstrate control over subdom
		ains anyway, for example, by temporarily modifying DNS for the subdomain to poin
		t to a server the ancestor domain owner controls, rendering the distinction moot
		. For example, the CA/Browser Forum Baseline Requirements may consider control
		of an ancestor domain sufficient for issuance of certificates for subdomains, bu
		t only if specific processes and procedures are used for validating ownership of
		the ancestor domain.</t>
		<t>In ecosystems where control of an ancestor domain may not imply control
		over subdomains or authorization for issuance of certificates for subdomains, a
		more complicated threat analysis and server policy might be needed.</t>
		<t>Some additional comments on ACME server policy are given later in this
		section.</t>
		<section anchor="client-account-security">
		<name>Client Account Security</name>
		<t>There may be scenarios were a client wishes to deactivate an authoriz
		ation object for an ancestor domain or deactivate its account completely. For ex
		ample, a client may want to do this if an account key is compromised or if an au
		thorization object covering domains subordinate to an ancestor domain is no long
		er needed. The client can deactivate an authorization using the mechanism specif
		ied in <xref section="7.5.2" sectionFormat="comma" target="RFC8555"/> and can de
		activate an account using the mechanism specified in <xref section="7.3.6" secti
		onFormat="comma" target="RFC8555"/>.</t>
		</section>
		<section anchor="subdomain-determination">
		<name>Subdomain Determination</name>
		<t>The <xref target="RFC8499"/> definition of a subdomain is reproduced
		in <xref target="terminology"/>. When comparing domains to determine if one is a
		subdomain of the other, it is important to compare entire labels and not rely o
		n a string prefix match. Relying on string prefix matches may yield incorrect re
		sults.</t>
		</section>
		<section anchor="acme-server-policy-considerations">
		<name>ACME Server Policy Considerations</name>
		<t>The ACME for Subdomains and the ACME specifications do not mandate an
		y specific ACME server or CA policies, or any specific use cases for issuance of
		certificates. For example, an ACME server could be used:</t>
		<ul spacing="normal">
		<li>to issue Web PKI certificates where the ACME server must comply wi
		th CA/Browser Forum Baseline Requirements <xref target="CAB"/>.</li>
		<li>as a Private CA for issuance of certificates within an organizatio
		n. The organization could enforce whatever policies they desire on the ACME serv
		er.</li>
		<li>for issuance of Internet of Things (IoT) device certificates. Ther
		e are currently no IoT device certificate policies that are generally enforced a
		cross the industry. Organizations issuing IoT device certificates can enforce wh
		atever policies they desire on the ACME server.</li>
		</ul>
		<t>ACME server policy could specify whether:</t>
		<ul spacing="normal">
		<li>issuance of subdomain certificates is allowed based on proof of ow
		nership of an ancestor domain.</li>
		<li>issuance of subdomain certificates is allowed, but only for a spec
		ific set of ancestor domains.</li>
		<li>DNS-based or HTTP-based proof of ownership, or both, are allowed.<
		/li>
		</ul>
		<t>The CA policy considerations listed in <xref section="10.5" sectionFo
		rmat="comma" target="RFC8555"/> are equally applicable here. These include, but
		are not limited to:</t>


		<ul spacing="normal">
		<li>Is the claimed identifier syntactically valid?</li>
		<li><t>For domain names:</t>
		<ul>
		<li>Is the name on the Public Suffix List?</li>
		<li>Is the name a high-value name?</li>
		</ul>
		</li>
		<li>Is the key in the CSR sufficiently strong?</li>
		</ul>
		<t>Refer to <xref section="10.5" sectionFormat="comma" target="RFC8555"/
		> for more CA policy considerations.</t>
		<t>ACME server policy specification is explicitly out of scope of this d
		ocument.</t>
		</section>
		</section>
	</middle>	</middle>


	<back>	<back>

		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		555.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		499.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<reference anchor="CAB" target="https://cabforum.org/baseline-requiremen
		ts-documents/">
		<front>
		<title>Baseline Requirements for the Issuance and
		Management of Publicly-Trusted Certificates</title>
		<author>
		<organization>CA/Browser Forum</organization>
		</author>
		</front>
		</reference>


	<references title='Normative References'>	<reference anchor="ACME-Identifier-Types" target="https://www.iana.org/a
		ssignments/acme/">
	<reference anchor='RFC8555' target='https://www.rfc-editor.org/info/rfc8555'>	<front>
	<front>	<title>ACME Identifier Types</title>
	<title>Automatic Certificate Management Environment (ACME)</title>	<author>
	<author fullname='R. Barnes' initials='R.' surname='Barnes'><organization/></aut	<organization>IANA</organization>
	hor>	</author>
	<author fullname='J. Hoffman-Andrews' initials='J.' surname='Hoffman-Andrews'><o	</front>
	rganization/></author>	</reference>
	<author fullname='D. McCarney' initials='D.' surname='McCarney'><organization/><	<reference anchor="ACME-Validation-Methods" target="https://www.iana.org
	/author>	/assignments/acme/">
	<author fullname='J. Kasten' initials='J.' surname='Kasten'><organization/></aut	<front>
	hor>	<title>ACME Validation Methods</title>
	<date month='March' year='2019'/>	<author>
	<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used	<organization>IANA</organization>
	for a number of purposes, the most significant of which is the authentication of	</author>
	domain names. Thus, certification authorities (CAs) in the Web PKI are trusted	</front>
	to verify that an applicant for a certificate legitimately represents the domai	</reference>
	n name(s) in the certificate. As of this writing, this verification is done thr	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	ough a collection of ad hoc mechanisms. This document describes a protocol that	280.xml"/>
	a CA and an applicant can use to automate the process of verification and certi	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
	ficate issuance. The protocol also provides facilities for other certificate ma	819.xml"/>
	nagement functions, such as certificate revocation.</t></abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
	</front>	034.xml"/>
	<seriesInfo name='RFC' value='8555'/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<seriesInfo name='DOI' value='10.17487/RFC8555'/>	986.xml"/>
	</reference>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		738.xml"/>
	<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>	</references>
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>
	<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a
	uthor>
	<date month='March' year='1997'/>
	<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 Comm
	unity, and requests discussion and suggestions for improvements.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='2119'/>
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>
	</reference>

	<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
	r>
	<date month='May' year='2017'/>
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
	pecifications. This document aims to reduce the ambiguity by clarifying that on
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
	tract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='8174'/>
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>
	</reference>

	<reference anchor='RFC8499' target='https://www.rfc-editor.org/info/rfc8499'>
	<front>
	<title>DNS Terminology</title>
	<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
	uthor>
	<author fullname='A. Sullivan' initials='A.' surname='Sullivan'><organization/><
	/author>
	<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'><organization/><
	/author>
	<date month='January' year='2019'/>
	<abstract><t>The Domain Name System (DNS) is defined in literally dozens of diff
	erent RFCs. The terminology used by implementers and developers of DNS protocol
	s, and by operators of DNS systems, has sometimes changed in the decades since t
	he DNS was first defined. This document gives current definitions for many of t
	he terms used in the DNS in a single document.</t><t>This document obsoletes RFC
	7719 and updates RFC 2308.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='219'/>
	<seriesInfo name='RFC' value='8499'/>
	<seriesInfo name='DOI' value='10.17487/RFC8499'/>
	</reference>

	</references>

	<references title='Informative References'>

	<reference anchor="CAB" target="https://cabforum.org/baseline-requirements-docum
	ents/">
	<front>
	<title>Baseline Requirements for the Issuance and Management of Publicly-Tru
	sted Certificates</title>
	<author >
	<organization>CA/Browser Forum</organization>
	</author>
	<date year="n.d."/>
	</front>
	</reference>
	<reference anchor="ACME-Identifier-Types" target="https://www.iana.org/assignmen
	ts/acme/acme.xhtml#acme-identifier-types">
	<front>
	<title>ACME Identifier Types</title>
	<author >
	<organization>IANA</organization>
	</author>
	<date year="n.d."/>
	</front>
	</reference>
	<reference anchor="ACME-Validation-Methods" target="https://www.iana.org/assignm
	ents/acme/acme.xhtml#acme-validation-methods">
	<front>
	<title>ACME Validation Methods</title>
	<author >
	<organization>IANA</organization>
	</author>
	<date year="n.d."/>
	</front>
	</reference>

	<reference anchor='RFC5280' target='https://www.rfc-editor.org/info/rfc5280'>
	<front>
	<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revo
	cation List (CRL) Profile</title>
	<author fullname='D. Cooper' initials='D.' surname='Cooper'><organization/></aut
	hor>
	<author fullname='S. Santesson' initials='S.' surname='Santesson'><organization/
	></author>
	<author fullname='S. Farrell' initials='S.' surname='Farrell'><organization/></a
	uthor>
	<author fullname='S. Boeyen' initials='S.' surname='Boeyen'><organization/></aut
	hor>
	<author fullname='R. Housley' initials='R.' surname='Housley'><organization/></a
	uthor>
	<author fullname='W. Polk' initials='W.' surname='Polk'><organization/></author>
	<date month='May' year='2008'/>
	<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
	nd model is provided as an introduction. The X.509 v3 certificate format is des
	cribed 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 extensi
	ons is specified. The X.509 v2 CRL format is described in detail along with sta
	ndard and Internet-specific extensions. An algorithm for X.509 certification pa
	th validation is described. An ASN.1 module and examples are provided in the ap
	pendices. [STANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='5280'/>
	<seriesInfo name='DOI' value='10.17487/RFC5280'/>
	</reference>

	<reference anchor='RFC0819' target='https://www.rfc-editor.org/info/rfc819'>
	<front>
	<title>The Domain Naming Convention for Internet User Applications</title>
	<author fullname='Z. Su' initials='Z.' surname='Su'><organization/></author>
	<author fullname='J. Postel' initials='J.' surname='Postel'><organization/></aut
	hor>
	<date month='August' year='1982'/>
	<abstract><t>This RFC is an attempt to clarify the generalization of the Domain
	Naming Convention, the Internet Naming Convention, and to explore the implicatio
	ns of its adoption for Internet name service and user applications.</t></abstrac
	t>
	</front>
	<seriesInfo name='RFC' value='819'/>
	<seriesInfo name='DOI' value='10.17487/RFC0819'/>
	</reference>

	<reference anchor='RFC1034' target='https://www.rfc-editor.org/info/rfc1034'>
	<front>
	<title>Domain names - concepts and facilities</title>
	<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organizat
	ion/></author>
	<date month='November' year='1987'/>
	<abstract><t>This RFC is the revised basic definition of The Domain Name System.
	It obsoletes RFC-882. This memo describes the domain style names and their us
	ed for host address look up and electronic mail forwarding. It discusses the cl
	ients and servers in the domain name system and the protocol used between them.<
	/t></abstract>
	</front>
	<seriesInfo name='STD' value='13'/>
	<seriesInfo name='RFC' value='1034'/>
	<seriesInfo name='DOI' value='10.17487/RFC1034'/>
	</reference>

	<reference anchor='RFC2986' target='https://www.rfc-editor.org/info/rfc2986'>
	<front>
	<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
	<author fullname='M. Nystrom' initials='M.' surname='Nystrom'><organization/></a
	uthor>
	<author fullname='B. Kaliski' initials='B.' surname='Kaliski'><organization/></a
	uthor>
	<date month='November' year='2000'/>
	<abstract><t>This memo represents a republication of PKCS #10 v1.7 from RSA Labo
	ratories' Public-Key Cryptography Standards (PKCS) series, and change control is
	retained within the PKCS process. The body of this document, except for the se
	curity considerations section, is taken directly from the PKCS #9 v2.0 or the PK
	CS #10 v1.7 document. This memo provides information for the Internet community
	.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='2986'/>
	<seriesInfo name='DOI' value='10.17487/RFC2986'/>
	</reference>

	<reference anchor='RFC8738' target='https://www.rfc-editor.org/info/rfc8738'>
	<front>
	<title>Automated Certificate Management Environment (ACME) IP Identifier Validat
	ion Extension</title>
	<author fullname='R.B. Shoemaker' initials='R.B.' surname='Shoemaker'><organizat
	ion/></author>
	<date month='February' year='2020'/>
	<abstract><t>This document specifies identifiers and challenges required to enab
	le the Automated Certificate Management Environment (ACME) to issue certificates
	for IP addresses.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8738'/>
	<seriesInfo name='DOI' value='10.17487/RFC8738'/>
	</reference>

	</references>	</references>


	</back>	</back>


	<!-- ##markdown-source:
	H4sIAAAAAAAAA+0963rbNpb/9RRY9UeTjcTYjnPTXDqKnTSexrFrO73NN9+E
	IiGJCUVqCMqK0mSeZZ9ln2zPBQBBEpSdpJ22O803F4sEgYODc8fBwXA47CXL
	YiTKYqXKvZ2dhzt7PVWGWfyPMM0zORIbqXplUqbwZ3+8KvNFWMpYHMiiTKZJ
	BD/EcZiFM7mQWSkeZ5dJkWf0943xwfHjm2KaF+J8NYnhwyRT/fZo4WRSyMuR
	wObD8xePDk+Ox0fPz3thIcOROJfRqkjKTW894ybi27x4nWQz8WWRr5Y9gGAk
	VBn3ojxTMlMrNRKfA8yf9+I8ysIFgB0X4bQcJrKcDsNoIYfKQjPcuQ/fxdDb
	SKzg9YPeMhn1hCimkYxVucFJc2cCxiiSqKx+l3lU+xHLZTmHJ3vUeLMo5FQ5
	X+dFWX8S5YtlSB1mObVYTZqP4Ddi0vkoydIks0D1wlU5zwuAeIivoN1JIJ4U
	iUyhqRA8+5O1zJyHeQFzPUhUlNNPCXhIRyKfYoO/RPg8gGGrHs8C8SgsMiCC
	qsuzJJqHRey+8HdbpJO/JMvLQL2pOrwIxNM8TeVEytdOnxfJovGcujxMZgnS
	mttrmSyCuWn6lxhaRNCiDvZxYKBUeeYMc4wPZdp8SWOdA9XLdBFm4jyflmug
	P6I15Y69iIpbSEl/UaZxEIW9XpIBmQNnJJcS6edg/GhEX9kFEhWSxrcfFfla
	yUI8yYvVgt5pBnsUKokLLM7kP1dJQTyliIPKuRRHSq3CLJIChnaZLp+K09Uk
	TaJ0M7xAxqrzJ8NfhsVMAmnNy3KpRrdvR+FkisMHANTtiR53WDjjDoGBVvTX
	7R50Qex5FMNv6FcWw4vNUqrOWR6Nn4/dmRHnVl8L+toL2Hq9DhKYHAEWKpXM
	MgYCeZf+J3gzLxfpZ8TLSQVQSV0aSL8J0ySGBcmz4bEE8OIPhLX6XujvfwJo
	LyugFrrT3nA4FOEEpAtwfq93MU+UMIgXaikjnJwS83wtPkb6RkDNEylWCr6a
	bEQoojTB12Uu8kkJMhAfOb0hrYXCSkhR4VdMi3xRa424YXSCfA7ENtDtuAjP
	dJVOkzTFh/MQ2DibAUnPUB6XQNoCSVyVAIcGYbIqxSLciCwvRSZhHgD7ti6Q
	VeSbJfBDUrozmXaBLpY5NAbkpCnwpUgMmwFfYV9VFy6i1gl8DZB5RsrXmSzU
	PFmKZZHn04DXeJHEcSp7vd5n4igrizxeRQhGr0fk9uOP/3X25ODB3bt3378X
	sZwCMyqYHXQAqiVPAZCw7Ea+uHEwvkliAfG3RIhCjWxYeURYqGmHZgS9AooV
	TlCDjMLRgbuiU+r0u+DuzsPLO+LG6VdH390EWL8AWO/uPdgBWF2cGMwhLUgQ
	dPCAxqMZgsC7BCrC/vBZBaXbiKlkYFtpqoFJOI0qpOQCBRZQixcMplhaQhq7
	SaKwfCnhmZiLhne4BTrHjjrWXw0sBbDMRIukMQ3swpBHuqlo1qUQP/n6+E+B
	bmsOQOyQZ9fv3MNe1QgB0uaFLBZJlqf5bIPSSIrXciPWOahK0T9+cX7RH/D/
	i+cn9PfZ469fHJ09PsS/z5+Onz2zf/R0i/OnJy+eHVZ/VV8enBwfP35+yB/D
	U1F71Osfj7/vMy30T04vjk6ej5/1Qb0DGtxlRD0NmIZ1S7JSFstCoogMVS+W
	KiqSCfyAbx4dnP7v/+zua0bb2919CMSruW73/j78WM9lxqMRRvknYHzTA1qV
	YYG9AD6BSJZJGaZAAaESCmgnE3NZSMDef/8NMfP3kfjjJFru7v9ZP8AJ1x4a
	nNUeEs7aT1ofMxI9jzzDWGzWnjcwXYd3/H3tt8G785DJYpqjtCSqB4pRtAos
	twjdh8/PXVIymN5/iGgnQQXtC7kkOQifIAZHICjFs3Aiwc4aAx0XMTyMRZoo
	snHeygKUViEWOXyaR6UsFYvFRfgamHi1FKHW6kswtlF2wUehK+ECIV4oBHlW
	hMs5rm1ebGAZRYqDVpygjHUAlliWx5JW3u0V+ZD7wCGAJpY5qP5JKt3RFAp+
	ccgPnpP16ZkVjmEmRWDwZ09WKVhzX69AEANAsduNuPHk68PnN0eCxVmCcrwE
	G//VSpGKSJFW1+HGTGIqVLgx4klhB8A/8BOot18T/4gtnG6fKFtLx1h3E07y
	S0Tg03wtQZYSZ9DSIwDhYpLMVvlKQYNz8pOAgcACCNFRG9h1mdKk/mkn5Y6+
	zlcpUk6UrgDhOMSG8THQD6En3Q2OjMQwRNlWzvXq6WUBjYsO4Sqa42yqnkE8
	rEFVAqJ0L3003eSbcLFMZZDJMuiLG2BiSDuxJAMNCHiK8/ImzOvRCvTSREYh
	alSCT3dEg8CDrISJ4bzBsdDqCh04oBiEacA0QXTP61UHp5ApuQ8oysw8xA2e
	h2oB279pmUiVIPd1JxHKe5CWhGhhEd0PNK3Qek2TAgmFZBozKyv0nQcoEwPd
	1VFDzHbC74U8aAoJEg0J8Q+amH2r4fqk/4GDM1bXVwqOhtAYoPbG5aCxnWFc
	sqQP4cF0VUCrAngkLJgEgXLyNQkeG6PAOIdVjqpmDSOLAI1gF5VVmaAJYxYg
	z9Coho7ROiBVBQKK25pFYHzlGatotjjAoCjJQtf9KCkRa0nDAv1caWrLQB3j
	CJrKaFCmVW7mkCbQtbjx9SrH/gnDP/54Lsn0FHeCXZwSLv7uzh3QgcFN9EmF
	JrQB61qpO5vnQDY0fD/LsmCxWFiKBDoHoTEBzIh+8zni3rCc7zsmYhuSQYD6
	7ntA23Nmy7B0BADFSooEHHhFdMAKiKQpkOY8T404/QOvQaIGBoo8z+sQwKKg
	c9FY6X6jmeEMouxOQlNID8xcigxv5IBa12hYajFHegRYJ7MkcqFh9eCxWnQv
	jqGzlfIQbFKCbz9t2r7WVGJBxTJBwRvpeD4k892pwuwWMiRK28ojIk6mU1iU
	rGzySReHNNoHsOx2AOARXB5gk46p1WjWg52O9W22awmtMI5p3mHqGDnkHDSN
	UJIgBzXnbFxzzrTunwHy3vJ7TZUgDtQSiJisBxPpiQpJjQbWlxlAu8s80k9x
	uRe1AJAb72H3i2Q9eVkgteU/WTehnYxceoba5WDMghEkH1glqO7QaYPPz+QU
	5Wle9/QQuFjC4qWEAB3wQoMo65h6om2gg/OzUS1mcZ7MiIjOtPcGdOXYjjzq
	3sMH996/x8/HxmM51PI5dEmv7dEQBdYcfyA9TXfaZKzeIgLmMH6KDjFLDGyS
	Ndr5ydE7tpcqzcp+ghCti0WixcboLDx9/QaV3eYXwoZFvDPq6tPK5Y+VyC0Z
	ux2OluQOtkVPyhov55NXoPUEBQkBmgTtqq3cfIKGujihz4h7aSQy301naIpI
	RTFaE+D6XNmQBIfS3MCEtkJMeAFDfq9NQGZW6IgM4YaHKedFvprNTSiCQivE
	EMxfWpA0QQxrb32gcjgEQK03JYAB8VGUrzh6Yb/C57VAATC1DS40AajCDlsH
	z6dayuhok3SRiA4VIMR4cbVAJHljOr4YoafjJQNj5NwL7qC2Y5uxSRUkJJka
	zMJ4ieH05PxiGKrhl48vjNAaiW/nMqsim+tEzSWp/KksyfuAOeeroh2HIt8p
	Q6FE0QFADFjyNISlHVLzMEmQkwDSX789B7kQg6u6JsbCrswzhNvEWgn4bZjY
	C/h1gQJeaYMd3Bn0MJwp9g0cikJCdtdtSqYMQOsE8t2dClgGZDAg9tQDxtr0
	gHTmBlndsBqJdKVXSAHudwODYAQQCSiTa+ZNgyziGCvfkcJIJfad2Fm/14O5
	6xAkkCMpRUZyVufpjs7AFX6tdCC1xV03lHbHwPMCNZomb2VfvDg76vXuWOgV
	mW8uHRkcM6OB1ywveWk7hhhUFn+cr7M0D2OMc3XA4zgF+IWDjL4jshm2BUYO
	QAZdVtJ8Qx0UeTrQM2vhQak8Smg3wvK70uODYCexP9Ws1RxKByt7vX2LHhpd
	mUFFbhy6GtzsjvgF3GRDCiiV5LPr4YnnLHNUcLI+tsoZvl3iBpriuAj7oN/h
	CkVAG73e3RYNgkVj3F1nycensOT3OulstYwJX2160/4A9tx3uEET0f2ricgC
	0/waXxhq4XWoGmipuUzDtmAE2UVxHPRTUX/XmIlEYsXbAyth7ge7wZ3370dk
	gNaWSekwueSgRQxdh+zxGmzxJgzaBijizIYPGf27o9261zyR5VpKpgbGphsn
	t1sMfgCCbdDvI/TULcaA0VpoiJK+tVQB9GpzQ2uj0HqEmcAo3Uj0L5qdOZqs
	1lUlyJ1uRCOUU4uZ3cAuYYg4U/2bbPW7r0m7TDBaEOWx0WzkZCzwb632Sh0g
	c4LcLpEE/W50WWT5uBRZxFAncT14C1oW+Jo3pbrGHPZC80iymI0o3t4LgXUo
	lqnlkv4KZ+lSApM1ua+gk5pjdM/tAZNxE9gBhmpxXQdbZRFN1+wj4T6CkXjI
	WY60vExC8fTi4hTmegAUWharCL3UF2fPSCTly1XKIUgcCZ+WEgQWIiEIAscW
	0IsOIKZkYCJOtEBw6WFCMSXgNQ4Kds/du64/w9xBzuplNrvDBgu8bs42ZG0e
	gBuQrSALDW44Atz/B22y20H6W5CgTc4YSYA4OM4lux7gV8eh69c0qdVjgRBp
	axnaau7BktKhBsy78FhK1Q5lxnF0vZNO3SOzuzIEZQCYdVWowmUAFKOTamOG
	46ezBBilqAQC5j8AAN4ED4CGPyg2DY+WvfQH9+88gDYNGJOlB8RGAErx7ECu
	y0vcBjYesn+CvR45m2Gqcl4ZFrurJe7KwDxXaZkscf/FBpIc4tG5Ftq2q+/x
	mo1ThzQRS2wNVVupNbmtAjc9xPTOO1rbkNvOSamht46gFkHivgP5QkD+Icjn
	CKRD0Z4m7SZx70Ft511nOWjVa5xgD5o4IEuYBQYBuSBhApw5Rz0Nuachcisg
	pWD9qiNEtJHViA61oaj8iiPHEbAh+Hr6Um9MiKhwCtx/mWC0VbHIGnh56N/K
	z7x4GBxV1Uge08CCBXPgGHDYwA/nZqCQaoJltjHUimSp6zU103bauQlupgzv
	lmvKR7FgUw9CX0KLca/rdBSx1UDh7U5vrgkXOg7WYbb6Sz8geYCxODfBp4nw
	ahYmXNGOEzVDd7Q2OrsHLCqEmAcPG+6Hy+8NH8EG3/JiZuLtoNzUKsLlYiuN
	M6qUJ6UK97sCtwc/ThPadqUt2yhfahemtgk3N2E8lS+kSRANC/oUJ5HEJoZ6
	DYYFIA5o/oozSUIgYMBvlqgF71Jok6SZw1M5iSzziDqJyNrxJFhDZ3NHOaFm
	rZwr/4wb8eYzSB8toGlbe/sYWUW07aQWsW2Kcc4IxjQzDLwCy2Fw7S0tcIv/
	avK0C2fGTM01bWl54BUbhD+SwD5krbJYe8FNHJGtr3SE1c1yYS+CpSLK2M+8
	sUJNeze2OEE3a2FUH/AtfWWT1gBvzgYvAjBG3gOTU5uoRtX7u6Wwmoc5DAO3
	1r+bvkJLU1X0zS6RYmyBNWkTDIwnsh38beYvTy30ECI4zf/61796vo6FuJEv
	2XrDDYA8BTWC+R1HU6EDpwOGlcbHbUjj2gF/akFY93VZvLWRiN9qPNbktM6f
	wnw3TYpgZVRi20Er9lA3q2vRR3z+eTXpzzXKOBbTs/m3jTUnzDQ237S0pAwr
	1dYDNXxbWF46Mvalo2EaOiQn/q1trbdop9ZVwIsH8P/Iu8B9BUbUSvXBfyH+
	7evdZVATywTWDF/s7ezdGe48HO7sXuzuj3YejnbuBw8f/gBNdVvHshiZjuEx
	Grx97dYP7FMYZkWPXTXCb9/bHisrFlr+zXxru4YWqyLFTkz+srObwinL1MPt
	ZfHNPx7d3zzejPcrEBzQ8HOYV+1dB0b4u/y1zPDV4ZebM/lqcSCn8v7l/vPp
	4ZeHX03HtbbWN2Mc7u4Pd/cIh3ujnbujuw+C3Xs/9E379/zH3y0GvIxLB06I
	/N4zqR1xbHA7m7OhpmNzsY7aEzUBnyxQGMtpCI6HoKWh/BLwT9BXge67BVin
	seSEbNdJGkd4xMJ15ow+6NAmDoB6XJ0X6GYb9E3PZpZ6p4GngGwKiCIVvIQO
	tigI1i6nhRzWNIz1a5OIUWCj/mjY+ZUg7XZL9EzDCBOJUpTIZl9cy3HXoKKI
	n9bF5BBqxKIsAHk5rI1i9kyMMjZZ7z4rwnE6wZYywAzQJkO7yUSUcZ3km1Lv
	M5t9qCr5+VsTptfZyg2IyAAd1FPi3UYmCd/Ys7T7bw1Ozkm2/m7bR8CPa2RF
	K+zSkRbT28yyKmnJbq354n/BbmO/teYsOSLa2lWVKfXJ1oNnrG061qti7Zal
	ia+XlDrFyjYNZ02TzmEuDtzrFI7KOs1EW8sZiK9pCGMH7eMXxKEsvYxF6zL2
	da0W3woBIbcWqD7zToPfzaRw5xxwAqFPoduhluEGtyUGrg9Yx6aHd65EZYfe
	BtWgxwNtgHG3e/ugCm9UWtevjLvUcZdCrinE7arIUV/vb9bUkjFUkXc5cOom
	ksHvtGnRtNFiRUYhnaQK+SbxeVENY6pCRbVVvaYgGUnqTmOMwhOusumgR2Qs
	kko1rRM0528CViZkwhgwuVHkJfuJb5tAq7kCKHqvmJPFieaFuIYdOok3/v4j
	Z83mgqjPmuHptnhxSIuSa47rsV3aNot2gVUks7BIcqAgcGtjIj+t+HzsyKpX
	J7HQqSIj02vpCF3ag82I5yC8SI2p7REJI8LJQqiksnHIQdMjwWMEFJFjBZbV
	rJ0R3+7jMayLOUnTjSrU82SnTiiJt1NtXkHbtng5zfNgEhZuQOjlwGQH+YHt
	OujWygB72ewYsfGyPpIlBucYkeqMZLT25FtjagXmmLxMTzqLKaeUIhg/UXNS
	rYN6VKup/E3/hzpBvK723Z0BnUJpTHSkN3dzXWnxX+/QtQRwkzub3RzZoxTe
	gCKbBNK7ycjbrhqRxi0PMZmzWj2yCK63gNYVNt6+s7XSFexs48RZWzS7MZ/B
	XUVLa1G4JFBRFnl36TSkAZ1MxoNRddncFqbzPGeTne1U/xHPzTXmsVoS4ViN
	Yg+w2GhDk054Vkacw4QLdiHiTn3nrgNArmQjyW2bCcNWt8+EqaL1rTDwVUJA
	z7eKT7GJedWhWQ8dteUAE6qzViQFrrNgMiGp6ocYpUvrobtVxix4beOrFrgQ
	4sdO+8u1wDyQNZo2aAW+aba3xhhFE8x3oEceSVg62Qjo7OyMdvZHOzu36H/7
	tQ/G05KMyKr9g2b7htn3W6azn4bGUCjopK0O9Xi1YvtNkN2vheSmDa9rlTWU
	VtOk7raRalSp5rQv2DJOvUodVumcicVSurU5ZzKTBZl61zMyB87BJjAukZLs
	bnDTxvZ5Vp2+RCPEXAt3t3WQ8ZeuNOPdPdcmUzmOlLqeTxH+fL7UNkid+X6a
	K8XgswqvjjNf178JxFh5RCM5EB3zqjahmjOirb/8Ks/P8azZVbEuuA4P5dd2
	Cq/eT/IDwb7TYVJAw7zY6M09LFcSxmEZNouJXCvExrlQtsuF7kuzq42XOSI+
	jC9R+yibM9Lej6qRl2fHrQMWHaazSEpA1/Vp+GrOZrLiCQKo+jad5gNCgWD+
	H1ldmExtRgZKTD1Rm2i0ZV6BlaxIPVZMXH/fAIVUIxvkOuMODPs54br2vqb1
	J5rioo/yok8JOUdpusJCNHSa9wB3o58Awjikj0eLOXUiMa30CdxWdQ5fvBsa
	IRzgiQwn5EpQaRQ6AG9yLrTK7t0a6n+3RPvfLfcV/7jVe6f3+MU7zxfvGKx3
	+gf6Qu8+Ygz+ess/9+W7nji/eHwqdkftHRLO4arJnA/unJ7QgZHbNpp6VfOG
	5XFF82H3vz/7ev9A2Pd2dptqZkvzP26B5icA5pRz/23a/xXNfzJE1pH6KURQ
	2dMfDcyHr+o3mEi8uW5zz1T3dnYEbxr/iXNgtsL+MxPBoUwliE4PDfyqiYDE
	zB6IGYw6OhFHUA+7rl/yiSKGbfMrkdIctb+t+U9KjO3mKGI0dYFZGm+2N/+5
	RQwh0pwUurI5nno4Hz/3IfSXQOSOOPnKy6m/FCLdeMe25v8ezFwb9sfHH7Cq
	Px8iSWbc8cqMvV9EZuz9LjM8zT9BZuz9LjNEE5G/fZlx9apeH5HkaQ1rXkrL
	xWx6KTiGs9nFh1HDVupIV2Tlek6/GxFxwkMmUdSkc/CaUsYijE+wv6WzdLd3
	g11s8DTHM4ROeiM+PMDMrayko00jU4ISp3v7Va7krVdYDthN8sRKkzCs7Iof
	h+kMg66Pz/fu3nMCsq+TeGuOZRhF5W15eTL9av78xb2d9awWzAWs4derr5fn
	r9Kzyf7l198cvPrm+/Fm8+Jbt+VVmZwWLzb0a3JUf82JMAZGLH0AwoOj4Nnq
	/PDofPLtlw8Wx7PH958GQfD15psXz+492Lyd3vkhXC9V38nu1HTaSqjAFEPo
	Mrs6nbhWbeKaVMubH7oj2pWmU6eczdjXxxX7JBPltnxi0/I/K6M4xmrsXQnF
	DZTwhx+fUoxIfPBTpxRrojNbd1WUrBaZdmoUcJ2BynXfXoWglmdAEcVlrtP0
	ePvadGOrjlAEmg57e7IWMV5o667UOqAyZ/jfE8xRdj41zVVjQKy8MJfRa8Mi
	dbhrKQKURAZIyVSia2B1hL2p5oSnwoR5z6SBU9TJ5hbqeqySK5g118KNsGKR
	ho3eCKrW6XPljEkRUz0iBkx5RBHinlurP8y3sORm8VFht15A0zl9SfDieV0s
	hsjHu8pkYdLDODuFAASRPWgNix/SVLbMI1ksZIwIxeq2usBMNavq4GG/VX+Z
	1w2JzhTgXub8pLF8LvEpKfkAOCfJGkM2duqLdSeH3aXUYnuglOuOcTUxE/Jw
	+MHkXFXbiPjly6af9XKLCdMoKVNL9W1tx/nqMzfLYbkqpFUhz2ce0ZdIPhMs
	bVHLCKe9RlXKpdityQG7nWeW5TpbTldlA3MJQ0rXT9kLasDiTVvqMMzYu/x/
	ZZjd/e6vu8/upI9fH395vzy7txzv7ETp+AMNM8LLRxtmV2QrOKq9HWr4BVIO
	vDbd03s/fFd++erih82L7FR+lYFNt3483r94nT6K53fk/t39mWvTjbdspWsy
	peRm1b2x63D01hJQbdlI/eu6SU6tHiyGZESFzay26sF70M2wieEICjkc8AEY
	fH4GgIWb4XMktpE4/n68ujxZhvlRsllfyLfJ29d3L9fY7hkMPRJ/7KQxu4X7
	5z8UMv1TP8li+Ybw+UxXkazusGh9TNi4fXGS5tHjB8V0ltd4rzLLGC0fY6du
	Izj8zw+21y2UZhq2bN+6qfoRzFHZfvVNKrffLVIEna7bp+Ms+SZTP0SJ6jd7
	tSWjtokJZxVwDWwkyOUKRxfwMSLQ4Tpx2MSNkDiZvKmmjDm34a9gZfR3TcvY
	RK6uQlId2rbS1neuqa33ftfWv2vr/2xtvfe7tv5dW/+urT+EOX5F2vrsJEvu
	F3Esfwvaeq+prT/jalUHtTIxnVVEdModMAFn3DULONhT9GEc64LHCD75/Fv6
	q1L43JrgrQJPQc9K1Fv+DY9bnT/qP2/Zjt4xCHzLSvXPPEZ1hxtteTZNZquC
	8qXfcTCDqua/+zkg8iYwvrO5kdSG0gerTwBH4jv4J35KiLammn4KKVwjl/O6
	hPDBs6wQfc219y32p416nfX1LehHjAr8bW5TbfF41+V9MpujZuaLKKuInVNo
	jeuVL8tkYeSXvZ9tassybC0Q5qTQkiCjOhcclJ3lId3sQ8PWb5IF6tCnD+f6
	WqNQn2TR7Ud8RUKrVhrnsZel9hwqRXQbrzqbJLTVYA0TJRvwrdTAC848dEAp
	1xj/1LjGSVAtUoKKSlqfYKkzPI8NQ5cbYYtOF3mqGqdFUZ7PZNm2p2ypoaox
	VbmmuH3lAAzcmu4ww2bZd+VcaJAsYO2WiPzqxkh9343uQZeDaMydb+DKcgw2
	07nBMqcawWbYvHAhcK6uoGr2umZ8lslUwKKEtAfC5c4sDu3RVCVo2miDiUUe
	yxS7cKoxfkpHF5jOjHbOgEpxdTCLlUJJ89gW3ljMNb3MfRvaN9InazyoIzRd
	MBTHZjpH4F7NaGQk5dpi0ZViMkvCdJhPh3h4JoHVbnIzuN1c+O0cy5aYWzae
	gJrHa6uweP9YnPKJkLYg0OWK5ZtILk0dYm1LVyd6FbRXU6ZtcWP3Ju+0mIO9
	eOGyznZXNeLmQ8S2tgnuWgDNpZvme8tyThkDXBgPC/hvftReBW5/6d0RHucD
	v09RThQBXYe1wDNqMsrVBnz7hTnEzNGCcKqz+5dcc0aSBCUSMFeGtY5RV9eJ
	6Au1gAFT3BoC3iAdWastGMsFFcdtnch2DlYAgOtwUytcSKWl5WKZF2GRQDdA
	6cl0o1Px22UjeGsn4dsfwmrTsB3/oLR9K7PwehqU2mYPMCb3ijdzFngfmKgf
	mMc2zYuQO24/xrUzhQurmU99p6HVagoLSVbwByidAd0wSzSfTKt6Pno/rKoH
	G8l4VUjnEiDsxmzgYZEEt1isP+oCVFQRkClMtHVKpg66h0vcO7OaB24+aPoh
	77HxEf1I71uSRAI5nW5UwiionyRbJLM56QwMZlFR9XPcsnSuTDK3l/srwBIa
	uawCVrQu/NUL9bmOsVYe9jJ4FtWmvLEtWSHWtaqe1ZUcMZeWuup0mu9sI916
	ZL/GM0hGlem9fJk2SyNbABC+dcjcZEtNThsKmW/FQs27SBTqa1w7LCjhBZNq
	11VXvbVLHnpueCXVnOagmQuzXE2PcRuC+OgOUnRVIKJ2CtJfJuxusKev7PMM
	oKf/kV3fCe6R4Y8kUhUNPpT22kZTiKx2e6BzkVnziijlXitIw5bVHYR4fpSK
	UuobjhzkE2lxU4mLhkeY/fFjsqIGei88QYFcasLgXiXZgvYS0OoYYoHb9Tld
	eUPFKjC+O03ecI1i3EtnSxlLM7TfS5afGx1FppoIdCGPWqV8u4suw6yP4W4x
	Cnx2n0kTaBc6RmeiVn6ZCkoa2eqKA+gRrBESCgnezGGKT5q2pDtDJbc7Ek0O
	bJxTNFeAotwmk8seRv9WTsTpV0eNkmm2cGQtxwIr0RLT6/yJlgb728H40d/9
	eow2Q9A6FKcFswHMequY1vfjhfV743SWmXuTHM9OYq5PhCkX8LWVs7okO9oP
	CqlLJ93US7UMW4Ac5RfwBdmWdSxf2Ju9QBJjnfUU9VNHexeEkC9qrk51a3hj
	kAVFrsxFDfGKa6GfOBNUtuZ1B1gkYD5h/p3VrZkIN6awEFGOiyb/1eDCVJtG
	D8rUTWmfd/Rr/A8ewjFfdLVtwzn6aoxmuR5yIcD46zqHSSyIEe/tLbBY1IDL
	KzEgLCYML1dGm15DvPC4W6bv7gQYTOjwneh+bV3zWEf0edrYHqVMmiwSslvY
	7zwyOXdhsqgfM1ebrERFFNEQZL19gV+Q+HDuiUDHTAh4rrviG5KZeOi8YARy
	cIpy9hnM6wtP41DMwUQa8jlbfPKFAxmp/eqelMpwxfsewMTLZtDauYaxE2E2
	Q6oL737ybl0049xTv7UCedD7P1ZGop0yiAAA


	</rfc>	</rfc>

End of changes. 58 change blocks.
	1170 lines changed or deleted	769 lines changed or added
This html diff was produced by rfcdiff 1.48.