test9115.prepped.xml		test9115.plain.prepped.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse nsus="true" docName="draft-ietf-acme-star-delegation-09" indexInclude="true" ipr ="trust200902" number="9115" prepTime="2021-06-11T11:25:00" scripts="Common,Lati n" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude= "true" xml:lang="en">		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse nsus="true" docName="draft-ietf-acme-star-delegation-09" indexInclude="true" ipr ="trust200902" number="9115" prepTime="2021-09-20T12:02:22" scripts="Common,Lati n" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude= "true" xml:lang="en">
	<link href="https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation-0 9" rel="prev"/>		<link href="https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation-0 9" rel="prev"/>
	<link href="https://dx.doi.org/10.17487/rfc9115" rel="alternate"/>		<link href="https://dx.doi.org/10.17487/rfc9115" rel="alternate"/>
	<link href="urn:issn:2070-1721" rel="alternate"/>		<link href="urn:issn:2070-1721" rel="alternate"/>
	<front>		<front>
	<title abbrev="ACME Delegation">An Automatic Certificate Management Environm ent (ACME) Profile for Generating Delegated Certificates</title>		<title abbrev="ACME Delegation">An Automatic Certificate Management Environm ent (ACME) Profile for Generating Delegated Certificates</title>
	<seriesInfo name="RFC" value="9115" stream="IETF"/>		<seriesInfo name="RFC" value="9115" stream="IETF"/>
	<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">		<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
	<organization showOnFrontPage="true">Intuit</organization>		<organization showOnFrontPage="true">Intuit</organization>
	<address>		<address>
	<email>yaronf.ietf@gmail.com</email>		<email>yaronf.ietf@gmail.com</email>
	skipping to change at line 55 ¶		skipping to change at line 55 ¶
	terminating TLS sessions on behalf of a content provider (the holder of a domain		terminating TLS sessions on behalf of a content provider (the holder of a domain
	name). The presented mechanism allows the holder of the identifier to retain		name). The presented mechanism allows the holder of the identifier to retain
	control over the delegation and revoke it at any time. Importantly, this		control over the delegation and revoke it at any time. Importantly, this
	mechanism does not require any modification to the deployed TLS		mechanism does not require any modification to the deployed TLS
	clients and servers.</t>		clients and servers.</t>
	</abstract>		</abstract>
	<boilerplate>		<boilerplate>
	<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc= "exclude" pn="section-boilerplate.1">		<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc= "exclude" pn="section-boilerplate.1">
	<name slugifiedName="name-status-of-this-memo">Status of This Memo</name >		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name >
	<t indent="0" pn="section-boilerplate.1-1">		<t indent="0" pn="section-boilerplate.1-1">
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	</t>		</t>
	<t indent="0" pn="section-boilerplate.1-2">		<t indent="0" pn="section-boilerplate.1-2">
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by		received public review and has been approved for publication by
	the Internet Engineering Steering Group (IESG). Further		the Internet Engineering Steering Group (IESG). Further
	information on Internet Standards is available in Section 2 of		information on Internet Standards is available in Section 2 of
	RFC 7841.		RFC 7841.
	</t>		</t>
	<t indent="0" pn="section-boilerplate.1-3">		<t indent="0" pn="section-boilerplate.1-3">
	Information about the current status of this document, any		Information about the current status of this document, any
	errata, and how to provide feedback on it may be obtained at		errata, and how to provide feedback on it may be obtained at
	<eref target="http://www.rfc-editor.org/info/rfc9115" brackets="none"/>.		<eref target="https://www.rfc-editor.org/info/rfc9115" brackets="non
			e"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl ude" pn="section-boilerplate.2">		<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl ude" pn="section-boilerplate.2">
	<name slugifiedName="name-copyright-notice">Copyright Notice</name>		<name slugifiedName="name-copyright-notice">Copyright Notice</name>
	<t indent="0" pn="section-boilerplate.2-1">		<t indent="0" pn="section-boilerplate.2-1">
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	</t>		</t>
	<t indent="0" pn="section-boilerplate.2-2">		<t indent="0" pn="section-boilerplate.2-2">
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	skipping to change at line 121 ¶		skipping to change at line 121 ¶
	<li pn="section-toc.1-1.2.2.2">		<li pn="section-toc.1-1.2.2.2">
	<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent= "2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-overview">Overview</xr ef></t>		<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent= "2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-overview">Overview</xr ef></t>
	</li>		</li>
	<li pn="section-toc.1-1.2.2.3">		<li pn="section-toc.1-1.2.2.3">
	<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent= "2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-delegated-identity-pro file">Delegated Identity Profile</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent= "2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-delegated-identity-pro file">Delegated Identity Profile</xref></t>
	<ul bare="true" empty="true" indent="2" spacing="compact" pn="se ction-toc.1-1.2.2.3.2">		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se ction-toc.1-1.2.2.3.2">
	<li pn="section-toc.1-1.2.2.3.2.1">		<li pn="section-toc.1-1.2.2.3.2.1">
	<t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derived Content="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-delegation -configuration">Delegation Configuration</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derived Content="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-delegation -configuration">Delegation Configuration</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.2.2.3.2.2">		<li pn="section-toc.1-1.2.2.3.2.2">
	<t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derived Content="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fr">Order Object Transmitted from NDC to IdO and to ACME Server ( for STAR)</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derived Content="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fr">Order Object Transmitted from NDC to IdO and to ACME Server ( STAR)</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.2.2.3.2.3">		<li pn="section-toc.1-1.2.2.3.2.3">
	<t indent="0" pn="section-toc.1-1.2.2.3.2.3.1"><xref derived Content="2.3.3" format="counter" sectionFormat="of" target="section-2.3.3"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fro">Order Object Transmitted from NDC to IdO and to ACME Server (for Non-STAR)</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.2.3.1"><xref derived Content="2.3.3" format="counter" sectionFormat="of" target="section-2.3.3"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fro">Order Object Transmitted from NDC to IdO and to ACME Server (Non-STAR)</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.2.2.3.2.4">		<li pn="section-toc.1-1.2.2.3.2.4">
	<t indent="0" pn="section-toc.1-1.2.2.3.2.4.1"><xref derived Content="2.3.4" format="counter" sectionFormat="of" target="section-2.3.4"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-capability -discovery">Capability Discovery</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.2.4.1"><xref derived Content="2.3.4" format="counter" sectionFormat="of" target="section-2.3.4"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-capability -discovery">Capability Discovery</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.2.2.3.2.5">		<li pn="section-toc.1-1.2.2.3.2.5">
	<t indent="0" pn="section-toc.1-1.2.2.3.2.5.1"><xref derived Content="2.3.5" format="counter" sectionFormat="of" target="section-2.3.5"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-negotiatin g-an-unauthentica">Negotiating an Unauthenticated GET</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.2.5.1"><xref derived Content="2.3.5" format="counter" sectionFormat="of" target="section-2.3.5"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-negotiatin g-an-unauthentica">Negotiating an Unauthenticated GET</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.2.2.3.2.6">		<li pn="section-toc.1-1.2.2.3.2.6">
	<t indent="0" pn="section-toc.1-1.2.2.3.2.6.1"><xref derived Content="2.3.6" format="counter" sectionFormat="of" target="section-2.3.6"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-terminatin g-the-delegation">Terminating the Delegation</xref></t>		<t indent="0" pn="section-toc.1-1.2.2.3.2.6.1"><xref derived Content="2.3.6" format="counter" sectionFormat="of" target="section-2.3.6"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-terminatin g-the-delegation">Terminating the Delegation</xref></t>
	</li>		</li>
	skipping to change at line 230 ¶		skipping to change at line 230 ¶
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	<li pn="section-toc.1-1.9">		<li pn="section-toc.1-1.9">
	<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendi x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d erivedContent="" format="title" sectionFormat="of" target="name-csr-template-cdd l">CSR Template: CDDL</xref></t>		<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendi x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d erivedContent="" format="title" sectionFormat="of" target="name-csr-template-cdd l">CSR Template: CDDL</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.10">		<li pn="section-toc.1-1.10">
	<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-template-js on-schema">CSR Template: JSON Schema</xref></t>		<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-template-js on-schema">CSR Template: JSON Schema</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.11">		<li pn="section-toc.1-1.11">
	<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form at="none" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedConten t="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledg ements</xref></t>		<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent=" " format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme nts</xref></t>
	</li>		</li>
	<li pn="section-toc.1-1.12">		<li pn="section-toc.1-1.12">
	<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent=" " format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add resses</xref></t>		<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent=" " format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add resses</xref></t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	</toc>		</toc>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa lse" pn="section-1">		<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl ude" pn="section-1">
	<name slugifiedName="name-introduction">Introduction</name>		<name slugifiedName="name-introduction">Introduction</name>
	<t indent="0" pn="section-1-1">This document is related to <xref target="R FC8739" format="default" sectionFormat="of" derivedContent="RFC8739"/>, in that some important use cases require both documents to be implemented. To avoid dupl ication,		<t indent="0" pn="section-1-1">This document is related to <xref target="R FC8739" format="default" sectionFormat="of" derivedContent="RFC8739"/>, in that some important use cases require both documents to be implemented. To avoid dupl ication,
	we give here a bare-bones description of the motivation for this solution. For		we give here a bare-bones description of the motivation for this solution. For
	more details, please refer to the introductory sections		more details, please refer to the introductory sections
	of <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t>		of <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t>
	<t indent="0" pn="section-1-2">An Identifier Owner (IdO) has agreements		<t indent="0" pn="section-1-2">An Identifier Owner (IdO) has agreements
	in place with one or more Name Delegation Consumer (NDC) to use and attest its		in place with one or more Name Delegation Consumer (NDC) to use and attest its
	identity.</t>		identity.</t>
	<t indent="0" pn="section-1-3">In the primary use case, the IdO is a conte nt provider, and we consider a Content Delivery Network (CDN) provider contracte d to		<t indent="0" pn="section-1-3">In the primary use case, the IdO is a conte nt provider, and we consider a Content Delivery Network (CDN) provider contracte d to
	serve the content over HTTPS. The CDN terminates the HTTPS connection at		serve the content over HTTPS. The CDN terminates the HTTPS connection at
	skipping to change at line 280 ¶		skipping to change at line 280 ¶
	case of long-lived certificates, the IdO uses the <tt>revokeCert</tt> URL expose d by the		case of long-lived certificates, the IdO uses the <tt>revokeCert</tt> URL expose d by the
	CA and waits for the explicit revocation based on the Certificate Revocation		CA and waits for the explicit revocation based on the Certificate Revocation
	List (CRL) and Online Certificate Status Protocol (OCSP) to propagate to the		List (CRL) and Online Certificate Status Protocol (OCSP) to propagate to the
	relying parties.</t>		relying parties.</t>
	<t indent="0" pn="section-1-6">In case the delegated identity is a domain name, this document also provides a		<t indent="0" pn="section-1-6">In case the delegated identity is a domain name, this document also provides a
	way for the NDC to inform the IdO about the CNAME mappings that need to be		way for the NDC to inform the IdO about the CNAME mappings that need to be
	installed in the IdO's DNS zone to enable the aliasing of the delegated name,		installed in the IdO's DNS zone to enable the aliasing of the delegated name,
	thus allowing the complete name delegation workflow to be handled using a		thus allowing the complete name delegation workflow to be handled using a
	single interface.</t>		single interface.</t>
	<t indent="0" pn="section-1-7">We note that other standardization efforts address the problem of certificate delegation for TLS connections, specifically <xref target="I-D.ietf-tls-subcerts" format="default" sectionFormat="of" derived Content="TLS-SUBCERTS"/> and <xref target="I-D.mglt-lurk-tls13" format="default" sectionFormat="of" derivedContent="MGLT-LURK-TLS13"/>. The former extends the T LS certificate chain with a customer-owned signing certificate; the latter separ ates the server's private key into a dedicated, more-secure component. Compared to these other approaches, the current document does not require changes to the TLS network stack of the client or the server, nor does it introduce additional latency to the TLS connection.</t>		<t indent="0" pn="section-1-7">We note that other standardization efforts address the problem of certificate delegation for TLS connections, specifically <xref target="I-D.ietf-tls-subcerts" format="default" sectionFormat="of" derived Content="TLS-SUBCERTS"/> and <xref target="I-D.mglt-lurk-tls13" format="default" sectionFormat="of" derivedContent="MGLT-LURK-TLS13"/>. The former extends the T LS certificate chain with a customer-owned signing certificate; the latter separ ates the server's private key into a dedicated, more-secure component. Compared to these other approaches, the current document does not require changes to the TLS network stack of the client or the server, nor does it introduce additional latency to the TLS connection.</t>
	<section anchor="terminology" numbered="true" toc="include" removeInRFC="f alse" pn="section-1.1">		<section anchor="terminology" numbered="true" removeInRFC="false" toc="inc lude" pn="section-1.1">
	<name slugifiedName="name-terminology">Terminology</name>		<name slugifiedName="name-terminology">Terminology</name>
	<dl indent="8" newline="false" spacing="normal" pn="section-1.1-1">		<dl indent="8" newline="false" spacing="normal" pn="section-1.1-1">
	<dt pn="section-1.1-1.1">IdO</dt>		<dt pn="section-1.1-1.1">IdO</dt>
	<dd pn="section-1.1-1.2">		<dd pn="section-1.1-1.2">
	<t indent="0" pn="section-1.1-1.2.1">Identifier Owner, the holder (c urrent owner) of an identifier (e.g., a domain		<t indent="0" pn="section-1.1-1.2.1">Identifier Owner, the holder (c urrent owner) of an identifier (e.g., a domain
	name) that needs to be delegated. Depending on the context, the term IdO may		name) that needs to be delegated. Depending on the context, the term IdO may
	also be used to designate the (profiled) ACME server deployed by the Identifier		also be used to designate the (profiled) ACME server deployed by the Identifier
	Owner or the ACME client used by the Identifier Owner to interact with the CA.</ t>		Owner or the ACME client used by the Identifier Owner to interact with the CA.</ t>
	</dd>		</dd>
	<dt pn="section-1.1-1.3">NDC</dt>		<dt pn="section-1.1-1.3">NDC</dt>
	skipping to change at line 328 ¶		skipping to change at line 328 ¶
	<dt pn="section-1.1-1.13">CSR</dt>		<dt pn="section-1.1-1.13">CSR</dt>
	<dd pn="section-1.1-1.14">		<dd pn="section-1.1-1.14">
	<t indent="0" pn="section-1.1-1.14.1">Certificate Signing Request, s pecifically a PKCS#10 <xref target="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/> Certificate Signing Request, as supported by ACME.</ t>		<t indent="0" pn="section-1.1-1.14.1">Certificate Signing Request, s pecifically a PKCS#10 <xref target="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/> Certificate Signing Request, as supported by ACME.</ t>
	</dd>		</dd>
	<dt pn="section-1.1-1.15">FQDN</dt>		<dt pn="section-1.1-1.15">FQDN</dt>
	<dd pn="section-1.1-1.16">		<dd pn="section-1.1-1.16">
	<t indent="0" pn="section-1.1-1.16.1">Fully Qualified Domain Name.</ t>		<t indent="0" pn="section-1.1-1.16.1">Fully Qualified Domain Name.</ t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="conventions-used-in-this-document" numbered="true" toc="i nclude" removeInRFC="false" pn="section-1.2">		<section anchor="conventions-used-in-this-document" numbered="true" remove InRFC="false" toc="include" pn="section-1.2">
	<name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>		<name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
	<t indent="0" pn="section-1.2-1">		<t indent="0" pn="section-1.2-1">
	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED </bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</b cp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT R ECOMMENDED</bcp14>",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED </bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</b cp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT R ECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
	described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" d erivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat= "of" derivedContent="RFC8174"/> when, and only when, they		described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" d erivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat= "of" derivedContent="RFC8174"/> when, and only when, they
	appear in all capitals, as shown here.</t>		appear in all capitals, as shown here.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-protocol-flow" numbered="true" toc="include" removeInRF C="false" pn="section-2">		<section anchor="sec-protocol-flow" numbered="true" removeInRFC="false" toc= "include" pn="section-2">
	<name slugifiedName="name-protocol-flow">Protocol Flow</name>		<name slugifiedName="name-protocol-flow">Protocol Flow</name>
	<t indent="0" pn="section-2-1">This section presents the protocol flow. F or completeness, we include the ACME		<t indent="0" pn="section-2-1">This section presents the protocol flow. F or completeness, we include the ACME
	profile proposed in this document as well as the ACME STAR protocol described		profile proposed in this document as well as the ACME STAR protocol described
	in <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t>		in <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t>
	<section anchor="proto-preconditions" numbered="true" toc="include" remove InRFC="false" pn="section-2.1">		<section anchor="proto-preconditions" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
	<name slugifiedName="name-preconditions">Preconditions</name>		<name slugifiedName="name-preconditions">Preconditions</name>
	<t indent="0" pn="section-2.1-1">The protocol assumes the following prec onditions are met:</t>		<t indent="0" pn="section-2.1-1">The protocol assumes the following prec onditions are met:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2 .1-2">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2 .1-2">
	<li pn="section-2.1-2.1">The IdO exposes an ACME server interface to t he NDC(s) comprising the account		<li pn="section-2.1-2.1">The IdO exposes an ACME server interface to t he NDC(s) comprising the account
	management interface.</li>		management interface.</li>
	<li pn="section-2.1-2.2">The NDC has registered an ACME account with t he IdO.</li>		<li pn="section-2.1-2.2">The NDC has registered an ACME account with t he IdO.</li>
	<li pn="section-2.1-2.3">The NDC and IdO have agreed on a "CSR templat e" to use, including at a minimum:		<li pn="section-2.1-2.3">The NDC and IdO have agreed on a "CSR templat e" to use, including at a minimum:
	subject name (e.g., <tt>abc.ido.example</tt>), requested algorithms and key		subject name (e.g., <tt>abc.ido.example</tt>), requested algorithms and key
	length, key usage, and extensions. The NDC will use		length, key usage, and extensions. The NDC will use
	this template for every CSR created under the same delegation.</li>		this template for every CSR created under the same delegation.</li>
	<li pn="section-2.1-2.4">The IdO has registered an ACME account with t he Certification Authority (CA).</li>		<li pn="section-2.1-2.4">The IdO has registered an ACME account with t he Certification Authority (CA).</li>
	</ul>		</ul>
	<t indent="0" pn="section-2.1-3">Note that even if the IdO implements th e ACME server role, it is not acting as		<t indent="0" pn="section-2.1-3">Note that even if the IdO implements th e ACME server role, it is not acting as
	a CA; in fact, from the point of view of the certificate issuance process, the		a CA; in fact, from the point of view of the certificate issuance process, the
	IdO only works as a "policing" forwarder of the NDC's key pair and is		IdO only works as a "policing" forwarder of the NDC's key pair and is
	responsible for completing the identity verification process towards the CA.</t>		responsible for completing the identity verification process towards the CA.</t>
	</section>		</section>
	<section anchor="overview" numbered="true" toc="include" removeInRFC="fals e" pn="section-2.2">		<section anchor="overview" numbered="true" removeInRFC="false" toc="includ e" pn="section-2.2">
	<name slugifiedName="name-overview">Overview</name>		<name slugifiedName="name-overview">Overview</name>
	<t indent="0" pn="section-2.2-1">For clarity, the protocol overview pres ented here covers the main use case of this protocol,		<t indent="0" pn="section-2.2-1">For clarity, the protocol overview pres ented here covers the main use case of this protocol,
	namely delegation of STAR certificates. Protocol behavior for non-STAR certifica tes is similar,		namely delegation of STAR certificates. Protocol behavior for non-STAR certifica tes is similar,
	and the detailed differences are listed in the following sections.</t>		and the detailed differences are listed in the following sections.</t>
	<t indent="0" pn="section-2.2-2">The interaction between the NDC and the IdO is governed by the profiled ACME		<t indent="0" pn="section-2.2-2">The interaction between the NDC and the IdO is governed by the profiled ACME
	workflow detailed in <xref target="sec-profile" format="default" sectionFormat=" of" derivedContent="Section 2.3"/>. The interaction between the IdO and the		workflow detailed in <xref target="sec-profile" format="default" sectionFormat=" of" derivedContent="Section 2.3"/>. The interaction between the IdO and the
	CA is ruled by ACME <xref target="RFC8555" format="default" sectionFormat="of" d erivedContent="RFC8555"/>, ACME STAR <xref target="RFC8739" format="default" sec tionFormat="of" derivedContent="RFC8739"/>, and any other ACME extension that		CA is ruled by ACME <xref target="RFC8555" format="default" sectionFormat="of" d erivedContent="RFC8555"/>, ACME STAR <xref target="RFC8739" format="default" sec tionFormat="of" derivedContent="RFC8739"/>, and any other ACME extension that
	applies (e.g., <xref target="I-D.ietf-acme-authority-token-tnauthlist" format="d efault" sectionFormat="of" derivedContent="TOKEN-TNAUTHLIST"/> for Secure Teleph one Identity Revisited (STIR)).</t>		applies (e.g., <xref target="I-D.ietf-acme-authority-token-tnauthlist" format="d efault" sectionFormat="of" derivedContent="TOKEN-TNAUTHLIST"/> for Secure Teleph one Identity Revisited (STIR)).</t>
	<t indent="0" pn="section-2.2-3">The outline of the combined protocol fo r STAR certificates is as follows (<xref target="fig-endtoend" format="default" sectionFormat="of" derivedContent="Figure 1"/>):</t>		<t indent="0" pn="section-2.2-3">The outline of the combined protocol fo r STAR certificates is as follows (<xref target="fig-endtoend" format="default" sectionFormat="of" derivedContent="Figure 1"/>):</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2 .2-4">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2 .2-4">
	<li pn="section-2.2-4.1">NDC sends an Order1 for the delegated identif ier to IdO.</li>		<li pn="section-2.2-4.1">NDC sends an Order1 for the delegated identif ier to IdO.</li>
	<li pn="section-2.2-4.2">IdO creates an Order1 resource in state <tt>r eady</tt> with a <tt>finalize</tt> URL.</li>		<li pn="section-2.2-4.2">IdO creates an Order1 resource in state <tt>r eady</tt> with a <tt>finalize</tt> URL.</li>
	<li pn="section-2.2-4.3">NDC immediately sends a <tt>finalize</tt> req uest (which includes the CSR) to the IdO.</li>		<li pn="section-2.2-4.3">NDC immediately sends a <tt>finalize</tt> req uest (which includes the CSR) to the IdO.</li>
	<li pn="section-2.2-4.4">IdO verifies the CSR according to the agreed upon CSR template.</li>		<li pn="section-2.2-4.4">IdO verifies the CSR according to the agreed upon CSR template.</li>
	<li pn="section-2.2-4.5">If the CSR verification fails, Order1 is move d to an <tt>invalid</tt> state and		<li pn="section-2.2-4.5">If the CSR verification fails, Order1 is move d to an <tt>invalid</tt> state and
	everything stops.</li>		everything stops.</li>
	<li pn="section-2.2-4.6">If the CSR verification is successful, IdO mo ves Order1 to state		<li pn="section-2.2-4.6">If the CSR verification is successful, IdO mo ves Order1 to state
	<tt>processing</tt> and sends a new Order2 (using its own account) for the deleg ated		<tt>processing</tt> and sends a new Order2 (using its own account) for the deleg ated
	identifier to the CA.</li>		identifier to the CA.</li>
	<li pn="section-2.2-4.7">If the ACME STAR protocol fails, Order2 moves to <tt>invalid</tt>, and the same state		<li pn="section-2.2-4.7">If the ACME STAR protocol fails, Order2 moves to <tt>invalid</tt>, and the same state
	is reflected in Order1 (i.e., the NDC Order).</li>		is reflected in Order1 (i.e., the NDC Order).</li>
	<li pn="section-2.2-4.8">If the ACME STAR run is successful (i.e., Ord er2 is <tt>valid</tt>), IdO copies the		<li pn="section-2.2-4.8">If the ACME STAR run is successful (i.e., Ord er2 is <tt>valid</tt>), IdO copies the
	<tt>star-certificate</tt> URL from Order2 to Order1 and updates the Order1 state to		<tt>star-certificate</tt> URL from Order2 to Order1 and updates the Order1 state to
	<tt>valid</tt>.</li>		<tt>valid</tt>.</li>
	</ul>		</ul>
	<t indent="0" pn="section-2.2-5">The NDC can now download, install, and use the short-term certificate bearing the name delegated by the IdO. The STAR c ertificate can be used until it expires, at which time the NDC is guaranteed to find a new certificate it can download, install, and use. This continues with su bsequent certificates until either Order1 expires or the IdO decides to cancel t he automatic renewal process with the CA.</t>		<t indent="0" pn="section-2.2-5">The NDC can now download, install, and use the short-term certificate bearing the name delegated by the IdO. The STAR c ertificate can be used until it expires, at which time the NDC is guaranteed to find a new certificate it can download, install, and use. This continues with su bsequent certificates until either Order1 expires or the IdO decides to cancel t he automatic renewal process with the CA.</t>
	<t indent="0" pn="section-2.2-6">Note that the interactive identifier au thorization phase described in <xref target="RFC8555" format="default" sectionFo rmat="of" derivedContent="RFC8555" section="7.5" derivedLink="https://rfc-editor .org/rfc/rfc8555#section-7.5"/> is suppressed on the NDC-IdO side because the de legated		<t indent="0" pn="section-2.2-6">Note that the interactive identifier au thorization phase described in <xref target="RFC8555" section="7.5" format="defa ult" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section- 7.5" derivedContent="RFC8555"/> is suppressed on the NDC-IdO side because the de legated
	identity contained in the CSR presented to the IdO is validated against the		identity contained in the CSR presented to the IdO is validated against the
	configured CSR template (<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" derivedContent="Section 4.1"/>). Therefore, the NDC		configured CSR template (<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" derivedContent="Section 4.1"/>). Therefore, the NDC
	sends the <tt>finalize</tt> request, including the CSR, to the IdO immediately a fter		sends the <tt>finalize</tt> request, including the CSR, to the IdO immediately a fter
	Order1 has been acknowledged. The IdO <bcp14>SHALL</bcp14> buffer a (valid) CSR until the		Order1 has been acknowledged. The IdO <bcp14>SHALL</bcp14> buffer a (valid) CSR until the
	Validation phase completes successfully.</t>		Validation phase completes successfully.</t>
	<t indent="0" pn="section-2.2-7">Also note that the successful negotiati on of the unauthenticated GET (<xref target="RFC8739" format="default" sectionFo rmat="of" derivedContent="RFC8739" section="3.4" derivedLink="https://rfc-editor .org/rfc/rfc8739#section-3.4"/>) is required in order to allow the NDC to access the		<t indent="0" pn="section-2.2-7">Also note that the successful negotiati on of the unauthenticated GET (<xref target="RFC8739" section="3.4" format="defa ult" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section- 3.4" derivedContent="RFC8739"/>) is required in order to allow the NDC to access the
	<tt>star-certificate</tt> URL on the CA.</t>		<tt>star-certificate</tt> URL on the CA.</t>
	<figure anchor="fig-endtoend" align="left" suppress-title="false" pn="fi gure-1">		<figure anchor="fig-endtoend" align="left" suppress-title="false" pn="fi gure-1">
	<name slugifiedName="name-end-to-end-star-delegation-">End-to-End STAR Delegation Flow</name>		<name slugifiedName="name-end-to-end-star-delegation-">End-to-End STAR Delegation Flow</name>
	<artset pn="section-2.2-8.1">		<artset pn="section-2.2-8.1">
	<artwork type="svg" name="" align="left" alt="" pn="section-2.2-8.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 720.0 841.0">		<artwork type="svg" name="" alt="" align="left" pn="section-2.2-8.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 720.0 841.0">
	<g transform="translate(8,16)">		<g transform="translate(8,16)">
	<path d="M 16,16 L 56,16" fill="none" stroke="black"/>		<path d="M 16,16 L 56,16" fill="none" stroke="black"/>
	<path d="M 176,16 L 288,16" fill="none" stroke="black"/>		<path d="M 176,16 L 288,16" fill="none" stroke="black"/>
	<path d="M 408,16 L 448,16" fill="none" stroke="black"/>		<path d="M 408,16 L 448,16" fill="none" stroke="black"/>
	<path d="M 0,48 L 72,48" fill="none" stroke="black"/>		<path d="M 0,48 L 72,48" fill="none" stroke="black"/>
	<path d="M 160,48 L 232,48" fill="none" stroke="black"/>		<path d="M 160,48 L 232,48" fill="none" stroke="black"/>
	<path d="M 232,48 L 304,48" fill="none" stroke="black"/>		<path d="M 232,48 L 304,48" fill="none" stroke="black"/>
	<path d="M 392,48 L 464,48" fill="none" stroke="black"/>		<path d="M 392,48 L 464,48" fill="none" stroke="black"/>
	<path d="M 0,80 L 32,80" fill="none" stroke="black"/>		<path d="M 0,80 L 32,80" fill="none" stroke="black"/>
	<path d="M 32,80 L 72,80" fill="none" stroke="black"/>		<path d="M 32,80 L 72,80" fill="none" stroke="black"/>
	skipping to change at line 904 ¶		skipping to change at line 904 ¶
	<text text-anchor="middle" font-family="monospace" x="424" y=" 580" fill="black" font-size="1em">&gt;</text>		<text text-anchor="middle" font-family="monospace" x="424" y=" 580" fill="black" font-size="1em">&gt;</text>
	<text text-anchor="middle" font-family="monospace" x="232" y=" 644" fill="black" font-size="1em">c</text>		<text text-anchor="middle" font-family="monospace" x="232" y=" 644" fill="black" font-size="1em">c</text>
	<text text-anchor="middle" font-family="monospace" x="240" y=" 740" fill="black" font-size="1em">]</text>		<text text-anchor="middle" font-family="monospace" x="240" y=" 740" fill="black" font-size="1em">]</text>
	<text text-anchor="middle" font-family="monospace" x="232" y=" 756" fill="black" font-size="1em">E</text>		<text text-anchor="middle" font-family="monospace" x="232" y=" 756" fill="black" font-size="1em">E</text>
	<text text-anchor="middle" font-family="monospace" x="208" y=" 68" fill="black" font-size="1em">e</text>		<text text-anchor="middle" font-family="monospace" x="208" y=" 68" fill="black" font-size="1em">e</text>
	<text text-anchor="middle" font-family="monospace" x="232" y=" 788" fill="black" font-size="1em">c</text>		<text text-anchor="middle" font-family="monospace" x="232" y=" 788" fill="black" font-size="1em">c</text>
	<text text-anchor="middle" font-family="monospace" x="336" y=" 756" fill="black" font-size="1em">f</text>		<text text-anchor="middle" font-family="monospace" x="336" y=" 756" fill="black" font-size="1em">f</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" name="" align="left" alt="" pn="section-2. 2-8.1.2">		<artwork type="ascii-art" name="" alt="" align="left" pn="section-2. 2-8.1.2">
	.------. .---------------. .------.		.------. .---------------. .------.
	| NDC | | IdO | | ACME |		| NDC | | IdO | | ACME |
	+--------+ +--------+--------+ +--------+		+--------+ +--------+--------+ +--------+
	| Client | | Server | Client | | Server |		| Client | | Server | Client | | Server |
	'---+----' '----+---+---+----' '----+---'		'---+----' '----+---+---+----' '----+---'
	| | | |		| | | |
	| Order1 | | |		| Order1 | | |
	| Signature | | |		| Signature | | |
	o-------------------&gt;| | |		o-------------------&gt;| | |
	| | | |		| | | |
	skipping to change at line 960 ¶		skipping to change at line 960 ¶
	| [...] |		| [...] |
	| (unauthenticated) GET STAR certificate |		| (unauthenticated) GET STAR certificate |
	o------------------------------------------------&gt;|		o------------------------------------------------&gt;|
	| Certificate #n |		| Certificate #n |
	|&lt;------------------------------------------------o		|&lt;------------------------------------------------o
	</artwork>		</artwork>
	</artset>		</artset>
	</figure>		</figure>
	</section>		</section>
	<section anchor="sec-profile" numbered="true" toc="include" removeInRFC="f alse" pn="section-2.3">		<section anchor="sec-profile" numbered="true" removeInRFC="false" toc="inc lude" pn="section-2.3">
	<name slugifiedName="name-delegated-identity-profile">Delegated Identity Profile</name>		<name slugifiedName="name-delegated-identity-profile">Delegated Identity Profile</name>
	<t indent="0" pn="section-2.3-1">This section defines a profile of the A CME protocol to be used between the NDC		<t indent="0" pn="section-2.3-1">This section defines a profile of the A CME protocol to be used between the NDC
	and IdO.</t>		and IdO.</t>
	<section anchor="sec-profile-dele-config" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.1">		<section anchor="sec-profile-dele-config" numbered="true" removeInRFC="f alse" toc="include" pn="section-2.3.1">
	<name slugifiedName="name-delegation-configuration">Delegation Configu ration</name>		<name slugifiedName="name-delegation-configuration">Delegation Configu ration</name>
	<t indent="0" pn="section-2.3.1-1">The IdO must be preconfigured to re cognize one or more NDCs and present them with		<t indent="0" pn="section-2.3.1-1">The IdO must be preconfigured to re cognize one or more NDCs and present them with
	details about certificate delegations that apply to each one.</t>		details about certificate delegations that apply to each one.</t>
	<section anchor="account-object-extensions" numbered="true" toc="exclu de" removeInRFC="false" pn="section-2.3.1.1">		<section anchor="account-object-extensions" numbered="true" removeInRF C="false" toc="exclude" pn="section-2.3.1.1">
	<name slugifiedName="name-account-object-extensions">Account Object Extensions</name>		<name slugifiedName="name-account-object-extensions">Account Object Extensions</name>
	<t indent="0" pn="section-2.3.1.1-1">An NDC identifies itself to the IdO as an ACME account. The IdO can delegate		<t indent="0" pn="section-2.3.1.1-1">An NDC identifies itself to the IdO as an ACME account. The IdO can delegate
	multiple names to an NDC, and these configurations are described through		multiple names to an NDC, and these configurations are described through
	<tt>delegation</tt> objects associated with the NDC's account object on the IdO. </t>		<tt>delegation</tt> objects associated with the NDC's account object on the IdO. </t>
	<t indent="0" pn="section-2.3.1.1-2">As shown in <xref target="fig-a ccount-object" format="default" sectionFormat="of" derivedContent="Figure 2"/>, the ACME account resource on the IdO is		<t indent="0" pn="section-2.3.1.1-2">As shown in <xref target="fig-a ccount-object" format="default" sectionFormat="of" derivedContent="Figure 2"/>, the ACME account resource on the IdO is
	extended with a new <tt>delegations</tt> attribute:</t>		extended with a new <tt>delegations</tt> attribute:</t>
	<dl newline="false" spacing="normal" pn="section-2.3.1.1-3" indent=" 3">		<dl indent="3" newline="false" spacing="normal" pn="section-2.3.1.1- 3">
	<dt pn="section-2.3.1.1-3.1">delegations (required, string):</dt>		<dt pn="section-2.3.1.1-3.1">delegations (required, string):</dt>
	<dd pn="section-2.3.1.1-3.2">A URL from which a list of delegation s		<dd pn="section-2.3.1.1-3.2">A URL from which a list of delegation s
	configured for this account (<xref target="sec-delegation-objects" format="defau lt" sectionFormat="of" derivedContent="Section 2.3.1.3"/>) can be fetched via a		configured for this account (<xref target="sec-delegation-objects" format="defau lt" sectionFormat="of" derivedContent="Section 2.3.1.3"/>) can be fetched via a
	POST-as-GET request.</dd>		POST-as-GET request.</dd>
	</dl>		</dl>
	<figure anchor="fig-account-object" align="left" suppress-title="fal se" pn="figure-2">		<figure anchor="fig-account-object" align="left" suppress-title="fal se" pn="figure-2">
	<name slugifiedName="name-example-account-object-with">Example Acc ount Object with Delegations</name>		<name slugifiedName="name-example-account-object-with">Example Acc ount Object with Delegations</name>
	<artwork name="" type="" align="left" alt="" pn="section-2.3.1.1-4 .1">		<artwork name="" type="" alt="" align="left" pn="section-2.3.1.1-4 .1">
	{		{
	"status": "valid",		"status": "valid",
	"contact": [		"contact": [
	"mailto:delegation-admin@ido.example"		"mailto:delegation-admin@ido.example"
	],		],
	"termsOfServiceAgreed": true,		"termsOfServiceAgreed": true,
	"orders": "https://example.com/acme/orders/saHpfB",		"orders": "https://example.com/acme/orders/saHpfB",
	"delegations": "https://acme.ido.example/acme/delegations/adFqoz"		"delegations": "https://acme.ido.example/acme/delegations/adFqoz"
	}		}
	</artwork>		</artwork>
	</figure>		</figure>
	</section>		</section>
	<section anchor="delegation-lists" numbered="true" toc="exclude" remov eInRFC="false" pn="section-2.3.1.2">		<section anchor="delegation-lists" numbered="true" removeInRFC="false" toc="exclude" pn="section-2.3.1.2">
	<name slugifiedName="name-delegation-lists">Delegation Lists</name>		<name slugifiedName="name-delegation-lists">Delegation Lists</name>
	<t indent="0" pn="section-2.3.1.2-1">Each account object includes a <tt>delegations</tt> URL from which a list of		<t indent="0" pn="section-2.3.1.2-1">Each account object includes a <tt>delegations</tt> URL from which a list of
	delegation configurations created by the IdO can be fetched via a POST-as-GET		delegation configurations created by the IdO can be fetched via a POST-as-GET
	request. The result of the request <bcp14>MUST</bcp14> be a JSON object whose < tt>delegations</tt>		request. The result of the request <bcp14>MUST</bcp14> be a JSON object whose < tt>delegations</tt>
	field is an array of URLs, each identifying a delegation configuration made		field is an array of URLs, each identifying a delegation configuration made
	available to the NDC account (<xref target="sec-delegation-objects" format="defa ult" sectionFormat="of" derivedContent="Section 2.3.1.3"/>). The server <bcp14> MAY</bcp14>		available to the NDC account (<xref target="sec-delegation-objects" format="defa ult" sectionFormat="of" derivedContent="Section 2.3.1.3"/>). The server <bcp14> MAY</bcp14>
	return an incomplete list, along with a <tt>Link</tt> header field with a <tt>ne xt</tt> link		return an incomplete list, along with a <tt>Link</tt> header field with a <tt>ne xt</tt> link
	relation indicating where further entries can be acquired.</t>		relation indicating where further entries can be acquired.</t>
	<sourcecode name="" type="json" pn="section-2.3.1.2-2" markers="fals e">		<sourcecode name="" type="json" markers="false" pn="section-2.3.1.2- 2">
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Link: &lt;https://acme.ido.example/acme/directory&gt;;rel="index"		Link: &lt;https://acme.ido.example/acme/directory&gt;;rel="index"
	Link: &lt;https://acme.ido.example/acme/delegations/adFqoz?/		Link: &lt;https://acme.ido.example/acme/delegations/adFqoz?/
	cursor=2&gt;;rel="next"		cursor=2&gt;;rel="next"
	{		{
	"delegations": [		"delegations": [
	"https://acme.ido.example/acme/delegation/ogfr8EcolOT",		"https://acme.ido.example/acme/delegation/ogfr8EcolOT",
	"https://acme.ido.example/acme/delegation/wSi5Lbb61E4",		"https://acme.ido.example/acme/delegation/wSi5Lbb61E4",
	/* more URLs not shown for example brevity */		/* more URLs not shown for example brevity */
	"https://acme.ido.example/acme/delegation/gm0wfLYHBen"		"https://acme.ido.example/acme/delegation/gm0wfLYHBen"
	]		]
	}		}
	</sourcecode>		</sourcecode>
	<t indent="0" pn="section-2.3.1.2-3">Note that in the figure above, https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a line break		<t indent="0" pn="section-2.3.1.2-3">Note that in the figure above, https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a line break
	for the sake of presentation.</t>		for the sake of presentation.</t>
	</section>		</section>
	<section anchor="sec-delegation-objects" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.1.3">		<section anchor="sec-delegation-objects" numbered="true" removeInRFC=" false" toc="exclude" pn="section-2.3.1.3">
	<name slugifiedName="name-delegation-objects">Delegation Objects</na me>		<name slugifiedName="name-delegation-objects">Delegation Objects</na me>
	<t indent="0" pn="section-2.3.1.3-1">This profile extends the ACME r esource model with a new read-only <tt>delegation</tt>		<t indent="0" pn="section-2.3.1.3-1">This profile extends the ACME r esource model with a new read-only <tt>delegation</tt>
	object that represents a delegation configuration that applies to a given NDC.</ t>		object that represents a delegation configuration that applies to a given NDC.</ t>
	<t indent="0" pn="section-2.3.1.3-2">A <tt>delegation</tt> object co ntains the CSR template (see <xref target="sec-csr-template" format="default" se ctionFormat="of" derivedContent="Section 4"/>) that		<t indent="0" pn="section-2.3.1.3-2">A <tt>delegation</tt> object co ntains the CSR template (see <xref target="sec-csr-template" format="default" se ctionFormat="of" derivedContent="Section 4"/>) that
	applies to that delegation and, optionally, any related CNAME mapping for the		applies to that delegation and, optionally, any related CNAME mapping for the
	delegated identifiers. Its structure is as follows:</t>		delegated identifiers. Its structure is as follows:</t>
	<dl spacing="normal" newline="false" indent="3" pn="section-2.3.1.3- 3">		<dl indent="3" newline="false" spacing="normal" pn="section-2.3.1.3- 3">
	<dt pn="section-2.3.1.3-3.1">csr-template (required, object):</dt>		<dt pn="section-2.3.1.3-3.1">csr-template (required, object):</dt>
	<dd pn="section-2.3.1.3-3.2">CSR template, as defined in		<dd pn="section-2.3.1.3-3.2">CSR template, as defined in
	<xref target="sec-csr-template" format="default" sectionFormat="of" derivedConte nt="Section 4"/>.</dd>		<xref target="sec-csr-template" format="default" sectionFormat="of" derivedConte nt="Section 4"/>.</dd>
	<dt pn="section-2.3.1.3-3.3">cname-map (optional, object):</dt>		<dt pn="section-2.3.1.3-3.3">cname-map (optional, object):</dt>
	<dd pn="section-2.3.1.3-3.4">A map of FQDN pairs. In each pair, t he name is		<dd pn="section-2.3.1.3-3.4">A map of FQDN pairs. In each pair, t he name is
	the delegated identifier; the value is the corresponding NDC name that is		the delegated identifier; the value is the corresponding NDC name that is
	aliased in the IdO's zone file to redirect the resolvers to the delegated		aliased in the IdO's zone file to redirect the resolvers to the delegated
	entity. Both names and values <bcp14>MUST</bcp14> be FQDNs with a terminating ' .'.		entity. Both names and values <bcp14>MUST</bcp14> be FQDNs with a terminating ' .'.
	This field is only meaningful for identifiers of type <tt>dns</tt>.</dd>		This field is only meaningful for identifiers of type <tt>dns</tt>.</dd>
	</dl>		</dl>
	<t indent="0" pn="section-2.3.1.3-4">An example <tt>delegation</tt> object in JSON format is shown in		<t indent="0" pn="section-2.3.1.3-4">An example <tt>delegation</tt> object in JSON format is shown in
	<xref target="fig-configuration-object" format="default" sectionFormat="of" deri vedContent="Figure 3"/>.</t>		<xref target="fig-configuration-object" format="default" sectionFormat="of" deri vedContent="Figure 3"/>.</t>
	<figure anchor="fig-configuration-object" align="left" suppress-titl e="false" pn="figure-3">		<figure anchor="fig-configuration-object" align="left" suppress-titl e="false" pn="figure-3">
	<name slugifiedName="name-example-delegation-configur">Example Del egation Configuration Object</name>		<name slugifiedName="name-example-delegation-configur">Example Del egation Configuration Object</name>
	<sourcecode name="" type="json" pn="section-2.3.1.3-5.1" markers=" false">		<sourcecode name="" type="json" markers="false" pn="section-2.3.1. 3-5.1">
	{		{
	"csr-template": {		"csr-template": {
	"keyTypes": [		"keyTypes": [
	{		{
	"PublicKeyType": "id-ecPublicKey",		"PublicKeyType": "id-ecPublicKey",
	"namedCurve": "secp256r1",		"namedCurve": "secp256r1",
	"SignatureType": "ecdsa-with-SHA256"		"SignatureType": "ecdsa-with-SHA256"
	}		}
	],		],
	"subject": {		"subject": {
	skipping to change at line 1093 ¶		skipping to change at line 1093 ¶
	order object on the NDC-IdO side (see Figures <xref target="fig-star-ndc-neworde r" format="counter" sectionFormat="of" derivedContent="4"/>		order object on the NDC-IdO side (see Figures <xref target="fig-star-ndc-neworde r" format="counter" sectionFormat="of" derivedContent="4"/>
	and <xref target="fig-non-star-ndc-neworder" format="counter" sectionFormat="of" derivedContent="7"/>). The		and <xref target="fig-non-star-ndc-neworder" format="counter" sectionFormat="of" derivedContent="7"/>). The
	value of this attribute is the URL pointing to the delegation configuration		value of this attribute is the URL pointing to the delegation configuration
	object that is to be used for this certificate request. If the <tt>delegation</ tt>		object that is to be used for this certificate request. If the <tt>delegation</ tt>
	attribute in the order object contains a URL that does not correspond to a		attribute in the order object contains a URL that does not correspond to a
	configuration available to the requesting ACME account, the IdO <bcp14>MUST</bcp 14> return an error		configuration available to the requesting ACME account, the IdO <bcp14>MUST</bcp 14> return an error
	response with status code 403 (Forbidden), providing a problem document		response with status code 403 (Forbidden), providing a problem document
	<xref target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC78 07"/> with type <tt>urn:ietf:params:acme:error:unknownDelegation</tt>.</t>		<xref target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC78 07"/> with type <tt>urn:ietf:params:acme:error:unknownDelegation</tt>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-profile-star-order-journey" numbered="true" toc="in clude" removeInRFC="false" pn="section-2.3.2">		<section anchor="sec-profile-star-order-journey" numbered="true" removeI nRFC="false" toc="include" pn="section-2.3.2">
	<name slugifiedName="name-order-object-transmitted-fr">Order Object Tr ansmitted from NDC to IdO and to ACME Server (STAR)</name>		<name slugifiedName="name-order-object-transmitted-fr">Order Object Tr ansmitted from NDC to IdO and to ACME Server (STAR)</name>
	<t indent="0" pn="section-2.3.2-1">If the delegation is for a STAR cer tificate, the request object created by the		<t indent="0" pn="section-2.3.2-1">If the delegation is for a STAR cer tificate, the request object created by the
	NDC:</t>		NDC:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.2-2">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.2-2">
	<li pn="section-2.3.2-2.1">		<li pn="section-2.3.2-2.1">
	<bcp14>MUST</bcp14> have a <tt>delegation</tt> attribute indicatin g the preconfigured delegation		<bcp14>MUST</bcp14> have a <tt>delegation</tt> attribute indicatin g the preconfigured delegation
	that applies to this Order;</li>		that applies to this Order;</li>
	<li pn="section-2.3.2-2.2">		<li pn="section-2.3.2-2.2">
	<bcp14>MUST</bcp14> have entries in the <tt>identifiers</tt> field for each delegated name		<bcp14>MUST</bcp14> have entries in the <tt>identifiers</tt> field for each delegated name
	present in the configuration;</li>		present in the configuration;</li>
	<li pn="section-2.3.2-2.3">		<li pn="section-2.3.2-2.3">
	<bcp14>MUST NOT</bcp14> contain the <tt>notBefore</tt> and <tt>not After</tt> fields; and</li>		<bcp14>MUST NOT</bcp14> contain the <tt>notBefore</tt> and <tt>not After</tt> fields; and</li>
	<li pn="section-2.3.2-2.4">		<li pn="section-2.3.2-2.4">
	<bcp14>MUST</bcp14> contain an <tt>auto-renewal</tt> object and, i nside it, the fields		<bcp14>MUST</bcp14> contain an <tt>auto-renewal</tt> object and, i nside it, the fields
	listed in <xref target="RFC8739" format="default" sectionFormat="of" derivedCont ent="RFC8739" section="3.1.1" derivedLink="https://rfc-editor.org/rfc/rfc8739#se ction-3.1.1"/>. In particular, the		listed in <xref target="RFC8739" section="3.1.1" format="default" sectionFormat= "of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.1.1" derivedConte nt="RFC8739"/>. In particular, the
	<tt>allow-certificate-get</tt> attribute <bcp14>MUST</bcp14> be present and set to true.</li>		<tt>allow-certificate-get</tt> attribute <bcp14>MUST</bcp14> be present and set to true.</li>
	</ul>		</ul>
	<figure anchor="fig-star-ndc-neworder" align="left" suppress-title="fa lse" pn="figure-4">		<figure anchor="fig-star-ndc-neworder" align="left" suppress-title="fa lse" pn="figure-4">
	<name slugifiedName="name-new-star-order-from-ndc">New STAR Order fr om NDC</name>		<name slugifiedName="name-new-star-order-from-ndc">New STAR Order fr om NDC</name>
	<sourcecode name="" type="json" pn="section-2.3.2-3.1" markers="fals e">		<sourcecode name="" type="json" markers="false" pn="section-2.3.2-3. 1">
	POST /acme/new-order HTTP/1.1		POST /acme/new-order HTTP/1.1
	Host: acme.ido.example		Host: acme.ido.example
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",		"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
	"nonce": "Alc00Ap6Rt7GMkEl3L1JX5",		"nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
	"url": "https://acme.ido.example/acme/new-order"		"url": "https://acme.ido.example/acme/new-order"
	skipping to change at line 1145 ¶		skipping to change at line 1145 ¶
	"allow-certificate-get": true		"allow-certificate-get": true
	},		},
	"delegation":		"delegation":
	"https://acme.ido.example/acme/delegation/gm0wfLYHBen"		"https://acme.ido.example/acme/delegation/gm0wfLYHBen"
	}),		}),
	"signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"		"signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
	}		}
	</sourcecode>		</sourcecode>
	</figure>		</figure>
	<t indent="0" pn="section-2.3.2-4">The order object that is created on the IdO:</t>		<t indent="0" pn="section-2.3.2-4">The order object that is created on the IdO:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.2-5">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.2-5">
	<li pn="section-2.3.2-5.1">		<li pn="section-2.3.2-5.1">
	<bcp14>MUST</bcp14> start in the <tt>ready</tt> state;</li>		<bcp14>MUST</bcp14> start in the <tt>ready</tt> state;</li>
	<li pn="section-2.3.2-5.2">		<li pn="section-2.3.2-5.2">
	<bcp14>MUST</bcp14> contain an <tt>authorizations</tt> array with zero elements;</li>		<bcp14>MUST</bcp14> contain an <tt>authorizations</tt> array with zero elements;</li>
	<li pn="section-2.3.2-5.3">		<li pn="section-2.3.2-5.3">
	<bcp14>MUST</bcp14> contain the indicated <tt>delegation</tt> conf iguration;</li>		<bcp14>MUST</bcp14> contain the indicated <tt>delegation</tt> conf iguration;</li>
	<li pn="section-2.3.2-5.4">		<li pn="section-2.3.2-5.4">
	<bcp14>MUST</bcp14> contain the indicated <tt>auto-renewal</tt> se ttings; and</li>		<bcp14>MUST</bcp14> contain the indicated <tt>auto-renewal</tt> se ttings; and</li>
	<li pn="section-2.3.2-5.5">		<li pn="section-2.3.2-5.5">
	<bcp14>MUST NOT</bcp14> contain the <tt>notBefore</tt> and <tt>not After</tt> fields.</li>		<bcp14>MUST NOT</bcp14> contain the <tt>notBefore</tt> and <tt>not After</tt> fields.</li>
	</ul>		</ul>
	<figure anchor="fig-star-ido-order-resource-created" align="left" supp ress-title="false" pn="figure-5">		<figure anchor="fig-star-ido-order-resource-created" align="left" supp ress-title="false" pn="figure-5">
	<name slugifiedName="name-star-order-resource-created">STAR Order Re source Created on IdO</name>		<name slugifiedName="name-star-order-resource-created">STAR Order Re source Created on IdO</name>
	<sourcecode name="" type="json" pn="section-2.3.2-6.1" markers="fals e">		<sourcecode name="" type="json" markers="false" pn="section-2.3.2-6. 1">
	{		{
	"status": "ready",		"status": "ready",
	"expires": "2021-05-01T00:00:00Z",		"expires": "2021-05-01T00:00:00Z",
	"identifiers": [		"identifiers": [
	{		{
	"type": "dns",		"type": "dns",
	"value": "abc.ido.example"		"value": "abc.ido.example"
	}		}
	],		],
	skipping to change at line 1192 ¶		skipping to change at line 1192 ¶
	"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize"		"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize"
	}		}
	</sourcecode>		</sourcecode>
	</figure>		</figure>
	<t indent="0" pn="section-2.3.2-7">The Order is then finalized by the NDC supplying the CSR containing the		<t indent="0" pn="section-2.3.2-7">The Order is then finalized by the NDC supplying the CSR containing the
	delegated identifiers. The IdO checks the provided CSR against the template		delegated identifiers. The IdO checks the provided CSR against the template
	contained in the <tt>delegation</tt> object that applies to this request, as des cribed in		contained in the <tt>delegation</tt> object that applies to this request, as des cribed in
	<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" deriv edContent="Section 4.1"/>. If the CSR fails validation for any of the		<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" deriv edContent="Section 4.1"/>. If the CSR fails validation for any of the
	identifiers, the IdO <bcp14>MUST</bcp14> return an error response with status co de 403		identifiers, the IdO <bcp14>MUST</bcp14> return an error response with status co de 403
	(Forbidden) and an appropriate type, e.g., <tt>rejectedIdentifier</tt> or <tt>ba dCSR</tt>.		(Forbidden) and an appropriate type, e.g., <tt>rejectedIdentifier</tt> or <tt>ba dCSR</tt>.
	The error response <bcp14>SHOULD</bcp14> contain subproblems (<xref target="RFC8 555" format="default" sectionFormat="of" derivedContent="RFC8555" section="6.7.1 " derivedLink="https://rfc-editor.org/rfc/rfc8555#section-6.7.1"/>)		The error response <bcp14>SHOULD</bcp14> contain subproblems (<xref target="RFC8 555" section="6.7.1" format="default" sectionFormat="of" derivedLink="https://rf c-editor.org/rfc/rfc8555#section-6.7.1" derivedContent="RFC8555"/>)
	for each failed identifier. If the CSR is successfully validated, the order		for each failed identifier. If the CSR is successfully validated, the order
	object status moves to <tt>processing</tt> and the twin ACME protocol instance i s		object status moves to <tt>processing</tt> and the twin ACME protocol instance i s
	initiated on the IdO-CA side.</t>		initiated on the IdO-CA side.</t>
	<t indent="0" pn="section-2.3.2-8">The request object created by the I dO:</t>		<t indent="0" pn="section-2.3.2-8">The request object created by the I dO:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.2-9">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.2-9">
	<li pn="section-2.3.2-9.1">		<li pn="section-2.3.2-9.1">
	<bcp14>MUST</bcp14> copy the identifiers sent by the NDC;</li>		<bcp14>MUST</bcp14> copy the identifiers sent by the NDC;</li>
	<li pn="section-2.3.2-9.2">		<li pn="section-2.3.2-9.2">
	<bcp14>MUST</bcp14> strip the <tt>delegation</tt> attribute; and</ li>		<bcp14>MUST</bcp14> strip the <tt>delegation</tt> attribute; and</ li>
	<li pn="section-2.3.2-9.3">		<li pn="section-2.3.2-9.3">
	<bcp14>MUST</bcp14> carry a copy of the <tt>auto-renewal</tt> obje ct sent by the NDC.</li>		<bcp14>MUST</bcp14> carry a copy of the <tt>auto-renewal</tt> obje ct sent by the NDC.</li>
	</ul>		</ul>
	<t indent="0" pn="section-2.3.2-10">When the identifiers' authorizatio n has been successfully completed and the		<t indent="0" pn="section-2.3.2-10">When the identifiers' authorizatio n has been successfully completed and the
	certificate has been issued by the CA, the IdO:</t>		certificate has been issued by the CA, the IdO:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.2-11">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.2-11">
	<li pn="section-2.3.2-11.1">		<li pn="section-2.3.2-11.1">
	<bcp14>MUST</bcp14> move its Order resource status to <tt>valid</t t> and</li>		<bcp14>MUST</bcp14> move its Order resource status to <tt>valid</t t> and</li>
	<li pn="section-2.3.2-11.2">		<li pn="section-2.3.2-11.2">
	<bcp14>MUST</bcp14> copy the <tt>star-certificate</tt> field from the STAR Order returned by the CA		<bcp14>MUST</bcp14> copy the <tt>star-certificate</tt> field from the STAR Order returned by the CA
	into its Order resource. When dereferenced, the <tt>star-certificate</tt> URL		into its Order resource. When dereferenced, the <tt>star-certificate</tt> URL
	includes (via the <tt>Cert-Not-Before</tt> and <tt>Cert-Not-After</tt> HTTP head er fields) the renewal timers		includes (via the <tt>Cert-Not-Before</tt> and <tt>Cert-Not-After</tt> HTTP head er fields) the renewal timers
	needed by the NDC to inform its certificate reload logic.</li>		needed by the NDC to inform its certificate reload logic.</li>
	</ul>		</ul>
	<figure anchor="fig-star-ido-order-resource-updated" align="left" supp ress-title="false" pn="figure-6">		<figure anchor="fig-star-ido-order-resource-updated" align="left" supp ress-title="false" pn="figure-6">
	<name slugifiedName="name-star-order-resource-updated">STAR Order Re source Updated on IdO</name>		<name slugifiedName="name-star-order-resource-updated">STAR Order Re source Updated on IdO</name>
	<sourcecode name="" type="json" pn="section-2.3.2-12.1" markers="fal se">		<sourcecode name="" type="json" markers="false" pn="section-2.3.2-12 .1">
	{		{
	"status": "valid",		"status": "valid",
	"expires": "2021-05-01T00:00:00Z",		"expires": "2021-05-01T00:00:00Z",
	"identifiers": [		"identifiers": [
	{		{
	"type": "dns",		"type": "dns",
	"value": "abc.ido.example"		"value": "abc.ido.example"
	}		}
	],		],
	skipping to change at line 1253 ¶		skipping to change at line 1253 ¶
	"star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"		"star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"
	}		}
	</sourcecode>		</sourcecode>
	</figure>		</figure>
	<t indent="0" pn="section-2.3.2-13">This delegation protocol is predic ated on the NDC being able to fetch		<t indent="0" pn="section-2.3.2-13">This delegation protocol is predic ated on the NDC being able to fetch
	certificates periodically using an unauthenticated HTTP GET, since, in general,		certificates periodically using an unauthenticated HTTP GET, since, in general,
	the NDC does not possess an account on the CA; as a consequence, it cannot issue the		the NDC does not possess an account on the CA; as a consequence, it cannot issue the
	standard POST-as-GET ACME request. Therefore, before forwarding the Order		standard POST-as-GET ACME request. Therefore, before forwarding the Order
	request to the CA, the IdO <bcp14>SHOULD</bcp14> ensure that the selected CA sup ports		request to the CA, the IdO <bcp14>SHOULD</bcp14> ensure that the selected CA sup ports
	unauthenticated GET by inspecting the relevant settings in the CA's		unauthenticated GET by inspecting the relevant settings in the CA's
	directory object, as per <xref target="RFC8739" format="default" sectionFormat=" of" derivedContent="RFC8739" section="3.4" derivedLink="https://rfc-editor.org/r fc/rfc8739#section-3.4"/>. If the CA does not		directory object, as per <xref target="RFC8739" section="3.4" format="default" s ectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.4" d erivedContent="RFC8739"/>. If the CA does not
	support unauthenticated GET of STAR certificates, the IdO <bcp14>MUST NOT</bcp14 > forward		support unauthenticated GET of STAR certificates, the IdO <bcp14>MUST NOT</bcp14 > forward
	the Order request. Instead, it <bcp14>MUST</bcp14> move the Order status to <tt >invalid</tt> and set		the Order request. Instead, it <bcp14>MUST</bcp14> move the Order status to <tt >invalid</tt> and set
	the <tt>allow-certificate-get</tt> in the <tt>auto-renewal</tt> object to <tt>fa lse</tt>. The same		the <tt>allow-certificate-get</tt> in the <tt>auto-renewal</tt> object to <tt>fa lse</tt>. The same
	occurs in case the Order request is forwarded and the CA does not reflect the		occurs in case the Order request is forwarded and the CA does not reflect the
	<tt>allow-certificate-get</tt> setting in its Order resource. The combination o f		<tt>allow-certificate-get</tt> setting in its Order resource. The combination o f
	<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at		<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at
	the IdO provides an unambiguous (asynchronous) signal to the NDC about the		the IdO provides an unambiguous (asynchronous) signal to the NDC about the
	failure reason.</t>		failure reason.</t>
	<section anchor="sec-cname-installation" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.2.1">		<section anchor="sec-cname-installation" numbered="true" removeInRFC=" false" toc="exclude" pn="section-2.3.2.1">
	<name slugifiedName="name-cname-installation">CNAME Installation</na me>		<name slugifiedName="name-cname-installation">CNAME Installation</na me>
	<t indent="0" pn="section-2.3.2.1-1">If one of the objects in the <t t>identifiers</tt> list is of type <tt>dns</tt>, the IdO can add the		<t indent="0" pn="section-2.3.2.1-1">If one of the objects in the <t t>identifiers</tt> list is of type <tt>dns</tt>, the IdO can add the
	CNAME records specified in the <tt>delegation</tt> object to its zone, for examp le:</t>		CNAME records specified in the <tt>delegation</tt> object to its zone, for examp le:</t>
	<artwork name="" type="" align="left" alt="" pn="section-2.3.2.1-2">		<artwork name="" type="" alt="" align="left" pn="section-2.3.2.1-2">
	abc.ido.example. CNAME abc.ndc.example.		abc.ido.example. CNAME abc.ndc.example.
	</artwork>		</artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-profile-non-star-order-journey" numbered="true" toc ="include" removeInRFC="false" pn="section-2.3.3">		<section anchor="sec-profile-non-star-order-journey" numbered="true" rem oveInRFC="false" toc="include" pn="section-2.3.3">
	<name slugifiedName="name-order-object-transmitted-fro">Order Object T ransmitted from NDC to IdO and to ACME Server (Non-STAR)</name>		<name slugifiedName="name-order-object-transmitted-fro">Order Object T ransmitted from NDC to IdO and to ACME Server (Non-STAR)</name>
	<t indent="0" pn="section-2.3.3-1">If the delegation is for a non-STAR certificate, the request object created by		<t indent="0" pn="section-2.3.3-1">If the delegation is for a non-STAR certificate, the request object created by
	the NDC:</t>		the NDC:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.3-2">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.3-2">
	<li pn="section-2.3.3-2.1">		<li pn="section-2.3.3-2.1">
	<bcp14>MUST</bcp14> have a <tt>delegation</tt> attribute indicatin g the preconfigured delegation		<bcp14>MUST</bcp14> have a <tt>delegation</tt> attribute indicatin g the preconfigured delegation
	that applies to this Order;</li>		that applies to this Order;</li>
	<li pn="section-2.3.3-2.2">		<li pn="section-2.3.3-2.2">
	<bcp14>MUST</bcp14> have entries in the <tt>identifiers</tt> field for each delegated name		<bcp14>MUST</bcp14> have entries in the <tt>identifiers</tt> field for each delegated name
	present in the configuration; and</li>		present in the configuration; and</li>
	<li pn="section-2.3.3-2.3">		<li pn="section-2.3.3-2.3">
	<bcp14>MUST</bcp14> have the <tt>allow-certificate-get</tt> attrib ute set to true.</li>		<bcp14>MUST</bcp14> have the <tt>allow-certificate-get</tt> attrib ute set to true.</li>
	</ul>		</ul>
	<figure anchor="fig-non-star-ndc-neworder" align="left" suppress-title ="false" pn="figure-7">		<figure anchor="fig-non-star-ndc-neworder" align="left" suppress-title ="false" pn="figure-7">
	<name slugifiedName="name-new-non-star-order-from-ndc">New Non-STAR Order from NDC</name>		<name slugifiedName="name-new-non-star-order-from-ndc">New Non-STAR Order from NDC</name>
	<sourcecode name="" type="json" pn="section-2.3.3-3.1" markers="fals e">		<sourcecode name="" type="json" markers="false" pn="section-2.3.3-3. 1">
	POST /acme/new-order HTTP/1.1		POST /acme/new-order HTTP/1.1
	Host: acme.ido.example		Host: acme.ido.example
	Content-Type: application/jose+json		Content-Type: application/jose+json
	{		{
	"protected": base64url({		"protected": base64url({
	"alg": "ES256",		"alg": "ES256",
	"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",		"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
	"nonce": "IYBkoQfaCS80UcCn9qH8Gt",		"nonce": "IYBkoQfaCS80UcCn9qH8Gt",
	"url": "https://acme.ido.example/acme/new-order"		"url": "https://acme.ido.example/acme/new-order"
	skipping to change at line 1315 ¶		skipping to change at line 1315 ¶
	],		],
	"delegation":		"delegation":
	"https://acme.ido.example/acme/delegation/gm0wfLYHBen",		"https://acme.ido.example/acme/delegation/gm0wfLYHBen",
	"allow-certificate-get": true		"allow-certificate-get": true
	}),		}),
	"signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H"		"signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H"
	}		}
	</sourcecode>		</sourcecode>
	</figure>		</figure>
	<t indent="0" pn="section-2.3.3-4">The order object that is created on the IdO:</t>		<t indent="0" pn="section-2.3.3-4">The order object that is created on the IdO:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.3-5">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.3-5">
	<li pn="section-2.3.3-5.1">		<li pn="section-2.3.3-5.1">
	<bcp14>MUST</bcp14> start in the <tt>ready</tt> state;</li>		<bcp14>MUST</bcp14> start in the <tt>ready</tt> state;</li>
	<li pn="section-2.3.3-5.2">		<li pn="section-2.3.3-5.2">
	<bcp14>MUST</bcp14> contain an <tt>authorizations</tt> array with zero elements;</li>		<bcp14>MUST</bcp14> contain an <tt>authorizations</tt> array with zero elements;</li>
	<li pn="section-2.3.3-5.3">		<li pn="section-2.3.3-5.3">
	<bcp14>MUST</bcp14> contain the indicated <tt>delegation</tt> conf iguration; and</li>		<bcp14>MUST</bcp14> contain the indicated <tt>delegation</tt> conf iguration; and</li>
	<li pn="section-2.3.3-5.4">		<li pn="section-2.3.3-5.4">
	<bcp14>MUST</bcp14> contain the indicated <tt>allow-certificate-ge t</tt> setting.</li>		<bcp14>MUST</bcp14> contain the indicated <tt>allow-certificate-ge t</tt> setting.</li>
	</ul>		</ul>
	<figure anchor="fig-non-star-ido-order-resource-created" align="left" suppress-title="false" pn="figure-8">		<figure anchor="fig-non-star-ido-order-resource-created" align="left" suppress-title="false" pn="figure-8">
	<name slugifiedName="name-non-star-order-resource-cre">Non-STAR Orde r Resource Created on IdO</name>		<name slugifiedName="name-non-star-order-resource-cre">Non-STAR Orde r Resource Created on IdO</name>
	<sourcecode name="" type="json" pn="section-2.3.3-6.1" markers="fals e">		<sourcecode name="" type="json" markers="false" pn="section-2.3.3-6. 1">
	{		{
	"status": "ready",		"status": "ready",
	"expires": "2021-05-01T00:00:00Z",		"expires": "2021-05-01T00:00:00Z",
	"identifiers": [		"identifiers": [
	{		{
	"type": "dns",		"type": "dns",
	"value": "abc.ido.example"		"value": "abc.ido.example"
	}		}
	],		],
	skipping to change at line 1355 ¶		skipping to change at line 1355 ¶
	"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize"		"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize"
	}		}
	</sourcecode>		</sourcecode>
	</figure>		</figure>
	<t indent="0" pn="section-2.3.3-7">The Order finalization by the NDC a nd the subsequent validation of the CSR by		<t indent="0" pn="section-2.3.3-7">The Order finalization by the NDC a nd the subsequent validation of the CSR by
	the IdO proceed in the same way as for the STAR case. If the CSR is		the IdO proceed in the same way as for the STAR case. If the CSR is
	successfully validated, the order object status moves to <tt>processing</tt> and the		successfully validated, the order object status moves to <tt>processing</tt> and the
	twin ACME protocol instance is initiated on the IdO-CA side.</t>		twin ACME protocol instance is initiated on the IdO-CA side.</t>
	<t indent="0" pn="section-2.3.3-8">The request object created by the I dO:</t>		<t indent="0" pn="section-2.3.3-8">The request object created by the I dO:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.3-9">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.3-9">
	<li pn="section-2.3.3-9.1">		<li pn="section-2.3.3-9.1">
	<bcp14>MUST</bcp14> copy the identifiers sent by the NDC;</li>		<bcp14>MUST</bcp14> copy the identifiers sent by the NDC;</li>
	<li pn="section-2.3.3-9.2">		<li pn="section-2.3.3-9.2">
	<bcp14>MUST</bcp14> strip the <tt>delegation</tt> attribute; and</ li>		<bcp14>MUST</bcp14> strip the <tt>delegation</tt> attribute; and</ li>
	<li pn="section-2.3.3-9.3">		<li pn="section-2.3.3-9.3">
	<bcp14>MUST</bcp14> copy the <tt>allow-certificate-get</tt> attrib ute.</li>		<bcp14>MUST</bcp14> copy the <tt>allow-certificate-get</tt> attrib ute.</li>
	</ul>		</ul>
	<t indent="0" pn="section-2.3.3-10">When the identifiers' authorizatio n has been successfully completed and the		<t indent="0" pn="section-2.3.3-10">When the identifiers' authorizatio n has been successfully completed and the
	certificate has been issued by the CA, the IdO:</t>		certificate has been issued by the CA, the IdO:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -2.3.3-11">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -2.3.3-11">
	<li pn="section-2.3.3-11.1">		<li pn="section-2.3.3-11.1">
	<bcp14>MUST</bcp14> move its Order resource status to <tt>valid</t t> and</li>		<bcp14>MUST</bcp14> move its Order resource status to <tt>valid</t t> and</li>
	<li pn="section-2.3.3-11.2">		<li pn="section-2.3.3-11.2">
	<bcp14>MUST</bcp14> copy the <tt>certificate</tt> field from the O rder returned by the CA into its		<bcp14>MUST</bcp14> copy the <tt>certificate</tt> field from the O rder returned by the CA into its
	Order resource, as well as <tt>notBefore</tt> and <tt>notAfter</tt> if these fie lds exist.</li>		Order resource, as well as <tt>notBefore</tt> and <tt>notAfter</tt> if these fie lds exist.</li>
	</ul>		</ul>
	<figure anchor="fig-non-star-ido-order-resource-updated" align="left" suppress-title="false" pn="figure-9">		<figure anchor="fig-non-star-ido-order-resource-updated" align="left" suppress-title="false" pn="figure-9">
	<name slugifiedName="name-non-star-order-resource-upd">Non-STAR Orde r Resource Updated on IdO</name>		<name slugifiedName="name-non-star-order-resource-upd">Non-STAR Orde r Resource Updated on IdO</name>
	<sourcecode name="" type="json" pn="section-2.3.3-12.1" markers="fal se">		<sourcecode name="" type="json" markers="false" pn="section-2.3.3-12 .1">
	{		{
	"status": "valid",		"status": "valid",
	"expires": "2021-05-01T00:00:00Z",		"expires": "2021-05-01T00:00:00Z",
	"identifiers": [		"identifiers": [
	{		{
	"type": "dns",		"type": "dns",
	"value": "abc.ido.example"		"value": "abc.ido.example"
	}		}
	],		],
	skipping to change at line 1412 ¶		skipping to change at line 1412 ¶
	selected CA supports unauthenticated GET by inspecting the relevant settings		selected CA supports unauthenticated GET by inspecting the relevant settings
	in the CA's directory object, as per <xref target="sec-nego-allow-cert-get" form at="default" sectionFormat="of" derivedContent="Section 2.3.5"/>. If the CA		in the CA's directory object, as per <xref target="sec-nego-allow-cert-get" form at="default" sectionFormat="of" derivedContent="Section 2.3.5"/>. If the CA
	does not support unauthenticated GET of certificate resources, the IdO <bcp14>MU ST NOT</bcp14> forward the Order request. Instead, it <bcp14>MUST</bcp14> move the Order status to		does not support unauthenticated GET of certificate resources, the IdO <bcp14>MU ST NOT</bcp14> forward the Order request. Instead, it <bcp14>MUST</bcp14> move the Order status to
	<tt>invalid</tt> and set the <tt>allow-certificate-get</tt> attribute to <tt>fal se</tt>. The same		<tt>invalid</tt> and set the <tt>allow-certificate-get</tt> attribute to <tt>fal se</tt>. The same
	occurs in case the Order request is forwarded and the CA does not reflect the		occurs in case the Order request is forwarded and the CA does not reflect the
	<tt>allow-certificate-get</tt> setting in its Order resource. The combination o f		<tt>allow-certificate-get</tt> setting in its Order resource. The combination o f
	<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at		<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at
	the IdO provides an unambiguous (asynchronous) signal to the NDC about the		the IdO provides an unambiguous (asynchronous) signal to the NDC about the
	failure reason.</t>		failure reason.</t>
	</section>		</section>
	<section anchor="capability-discovery" numbered="true" toc="include" rem oveInRFC="false" pn="section-2.3.4">		<section anchor="capability-discovery" numbered="true" removeInRFC="fals e" toc="include" pn="section-2.3.4">
	<name slugifiedName="name-capability-discovery">Capability Discovery</ name>		<name slugifiedName="name-capability-discovery">Capability Discovery</ name>
	<t indent="0" pn="section-2.3.4-1">In order to help a client discover support for this profile, the directory		<t indent="0" pn="section-2.3.4-1">In order to help a client discover support for this profile, the directory
	object of an ACME server (typically, one deployed by the IdO) contains the		object of an ACME server (typically, one deployed by the IdO) contains the
	following attribute in the <tt>meta</tt> field:</t>		following attribute in the <tt>meta</tt> field:</t>
	<dl spacing="compact" newline="false" indent="3" pn="section-2.3.4-2">		<dl spacing="compact" indent="3" newline="false" pn="section-2.3.4-2">
	<dt pn="section-2.3.4-2.1">delegation-enabled (optional, boolean):</ dt>		<dt pn="section-2.3.4-2.1">delegation-enabled (optional, boolean):</ dt>
	<dd pn="section-2.3.4-2.2">Boolean flag indicating support for		<dd pn="section-2.3.4-2.2">Boolean flag indicating support for
	the profile specified in this memo. An ACME server that supports this		the profile specified in this memo. An ACME server that supports this
	delegation profile <bcp14>MUST</bcp14> include this key and <bcp14>MUST</bcp14> set it to true.</dd>		delegation profile <bcp14>MUST</bcp14> include this key and <bcp14>MUST</bcp14> set it to true.</dd>
	</dl>		</dl>
	<t indent="0" pn="section-2.3.4-3">The IdO <bcp14>MUST</bcp14> declare its support for delegation using <tt>delegation-enabled</tt>		<t indent="0" pn="section-2.3.4-3">The IdO <bcp14>MUST</bcp14> declare its support for delegation using <tt>delegation-enabled</tt>
	regardless of whether it supports delegation of STAR certificates, non-STAR		regardless of whether it supports delegation of STAR certificates, non-STAR
	certificates, or both.</t>		certificates, or both.</t>
	<t indent="0" pn="section-2.3.4-4">In order to help a client discover support for certificate fetching using		<t indent="0" pn="section-2.3.4-4">In order to help a client discover support for certificate fetching using
	unauthenticated HTTP GET, the directory object of an ACME server (typically,		unauthenticated HTTP GET, the directory object of an ACME server (typically,
	one deployed by the CA) contains the following attribute in the <tt>meta</tt> fi eld:</t>		one deployed by the CA) contains the following attribute in the <tt>meta</tt> fi eld:</t>
	<dl spacing="compact" newline="false" indent="3" pn="section-2.3.4-5">		<dl spacing="compact" indent="3" newline="false" pn="section-2.3.4-5">
	<dt pn="section-2.3.4-5.1">allow-certificate-get (optional, boolean) :</dt>		<dt pn="section-2.3.4-5.1">allow-certificate-get (optional, boolean) :</dt>
	<dd pn="section-2.3.4-5.2">See <xref target="sec-nego-allow-cert-get " format="default" sectionFormat="of" derivedContent="Section 2.3.5"/>.</dd>		<dd pn="section-2.3.4-5.2">See <xref target="sec-nego-allow-cert-get " format="default" sectionFormat="of" derivedContent="Section 2.3.5"/>.</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="sec-nego-allow-cert-get" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.5">		<section anchor="sec-nego-allow-cert-get" numbered="true" removeInRFC="f alse" toc="include" pn="section-2.3.5">
	<name slugifiedName="name-negotiating-an-unauthentica">Negotiating an Unauthenticated GET</name>		<name slugifiedName="name-negotiating-an-unauthentica">Negotiating an Unauthenticated GET</name>
	<t indent="0" pn="section-2.3.5-1">In order to enable the name delegat ion of non-STAR certificates, this document		<t indent="0" pn="section-2.3.5-1">In order to enable the name delegat ion of non-STAR certificates, this document
	defines a mechanism that allows a server to advertise support for accessing		defines a mechanism that allows a server to advertise support for accessing
	certificate resources via unauthenticated GET (in addition to		certificate resources via unauthenticated GET (in addition to
	POST-as-GET) and a client to enable this service with per-Order granularity.</t>		POST-as-GET) and a client to enable this service with per-Order granularity.</t>
	<t indent="0" pn="section-2.3.5-2">It is worth pointing out that the p rotocol elements described in this section		<t indent="0" pn="section-2.3.5-2">It is worth pointing out that the p rotocol elements described in this section
	have the same names and semantics as those introduced in		have the same names and semantics as those introduced in
	<xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RFC87 39" section="3.4" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.4"/> for the STAR use case (except, of course, they apply to the		<xref target="RFC8739" section="3.4" format="default" sectionFormat="of" derived Link="https://rfc-editor.org/rfc/rfc8739#section-3.4" derivedContent="RFC8739"/> for the STAR use case (except, of course, they apply to the
	certificate resource rather than the star-certificate resource). However, they		certificate resource rather than the star-certificate resource). However, they
	differ in terms of their position in the directory meta and order objects;		differ in terms of their position in the directory meta and order objects;
	rather than being wrapped in an <tt>auto-renewal</tt> subobject, they are locate d at the		rather than being wrapped in an <tt>auto-renewal</tt> subobject, they are locate d at the
	top level.</t>		top level.</t>
	<t anchor="capability-metadata" indent="0" pn="section-2.3.5-3">A serv er states its availability to grant unauthenticated access to a client's		<t anchor="capability-metadata" indent="0" pn="section-2.3.5-3">A serv er states its availability to grant unauthenticated access to a client's
	Order certificate by setting the <tt>allow-certificate-get</tt> attribute to <tt >true</tt> in		Order certificate by setting the <tt>allow-certificate-get</tt> attribute to <tt >true</tt> in
	the <tt>meta</tt> field inside the directory object:</t>		the <tt>meta</tt> field inside the directory object:</t>
	<dl spacing="compact" newline="false" indent="3" pn="section-2.3.5-4">		<dl spacing="compact" indent="3" newline="false" pn="section-2.3.5-4">
	<dt pn="section-2.3.5-4.1">allow-certificate-get (optional, boolean) :</dt>		<dt pn="section-2.3.5-4.1">allow-certificate-get (optional, boolean) :</dt>
	<dd pn="section-2.3.5-4.2">If this field is present and set		<dd pn="section-2.3.5-4.2">If this field is present and set
	to <tt>true</tt>, the server allows GET (and HEAD) requests to certificate URLs. </dd>		to <tt>true</tt>, the server allows GET (and HEAD) requests to certificate URLs. </dd>
	</dl>		</dl>
	<t indent="0" pn="section-2.3.5-5">A client states its desire to acces s the issued certificate via unauthenticated		<t indent="0" pn="section-2.3.5-5">A client states its desire to acces s the issued certificate via unauthenticated
	GET by adding an <tt>allow-certificate-get</tt> attribute to the payload of its		GET by adding an <tt>allow-certificate-get</tt> attribute to the payload of its
	newOrder request and setting it to <tt>true</tt>.</t>		newOrder request and setting it to <tt>true</tt>.</t>
	<dl spacing="compact" newline="false" indent="3" pn="section-2.3.5-6">		<dl spacing="compact" indent="3" newline="false" pn="section-2.3.5-6">
	<dt pn="section-2.3.5-6.1">allow-certificate-get (optional, boolean) :</dt>		<dt pn="section-2.3.5-6.1">allow-certificate-get (optional, boolean) :</dt>
	<dd pn="section-2.3.5-6.2">If this field is present and set		<dd pn="section-2.3.5-6.2">If this field is present and set
	to <tt>true</tt>, the client requests the server to allow unauthenticated GET (a nd		to <tt>true</tt>, the client requests the server to allow unauthenticated GET (a nd
	HEAD) to the certificate associated with this Order.</dd>		HEAD) to the certificate associated with this Order.</dd>
	</dl>		</dl>
	<t indent="0" pn="section-2.3.5-7">If the server accepts the request, it <bcp14>MUST</bcp14> reflect the attribute setting in the		<t indent="0" pn="section-2.3.5-7">If the server accepts the request, it <bcp14>MUST</bcp14> reflect the attribute setting in the
	resulting order object.</t>		resulting order object.</t>
	<t indent="0" pn="section-2.3.5-8">Note that even when the use of unau thenticated GET has been agreed upon, the		<t indent="0" pn="section-2.3.5-8">Note that even when the use of unau thenticated GET has been agreed upon, the
	server <bcp14>MUST</bcp14> also allow POST-as-GET requests to the certificate re source.</t>		server <bcp14>MUST</bcp14> also allow POST-as-GET requests to the certificate re source.</t>
	</section>		</section>
	<section anchor="terminating-the-delegation" numbered="true" toc="includ e" removeInRFC="false" pn="section-2.3.6">		<section anchor="terminating-the-delegation" numbered="true" removeInRFC ="false" toc="include" pn="section-2.3.6">
	<name slugifiedName="name-terminating-the-delegation">Terminating the Delegation</name>		<name slugifiedName="name-terminating-the-delegation">Terminating the Delegation</name>
	<t indent="0" pn="section-2.3.6-1">Identity delegation is terminated d ifferently depending on whether or not this is a STAR certificate.</t>		<t indent="0" pn="section-2.3.6-1">Identity delegation is terminated d ifferently depending on whether or not this is a STAR certificate.</t>
	<section anchor="by-cancellation-star" numbered="true" toc="exclude" r emoveInRFC="false" pn="section-2.3.6.1">		<section anchor="by-cancellation-star" numbered="true" removeInRFC="fa lse" toc="exclude" pn="section-2.3.6.1">
	<name slugifiedName="name-by-cancellation-star">By Cancellation (STA R)</name>		<name slugifiedName="name-by-cancellation-star">By Cancellation (STA R)</name>
	<t indent="0" pn="section-2.3.6.1-1">The IdO can terminate the deleg ation of a STAR certificate by requesting its		<t indent="0" pn="section-2.3.6.1-1">The IdO can terminate the deleg ation of a STAR certificate by requesting its
	cancellation (see <xref target="RFC8739" format="default" sectionFormat="of" der ivedContent="RFC8739" section="3.1.2" derivedLink="https://rfc-editor.org/rfc/rf c8739#section-3.1.2"/>).</t>		cancellation (see <xref target="RFC8739" section="3.1.2" format="default" sectio nFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.1.2" deri vedContent="RFC8739"/>).</t>
	<t indent="0" pn="section-2.3.6.1-2">Cancellation of the ACME STAR c ertificate is a		<t indent="0" pn="section-2.3.6.1-2">Cancellation of the ACME STAR c ertificate is a
	prerogative of the IdO. The NDC does not own the relevant account key on the		prerogative of the IdO. The NDC does not own the relevant account key on the
	CA; therefore, it can't issue a cancellation request for the STAR certificate.		CA; therefore, it can't issue a cancellation request for the STAR certificate.
	Potentially, since it holds the STAR certificate's private key, it could request the		Potentially, since it holds the STAR certificate's private key, it could request the
	revocation of a single STAR certificate. However, STAR explicitly disables the		revocation of a single STAR certificate. However, STAR explicitly disables the
	revokeCert interface.</t>		revokeCert interface.</t>
	<t indent="0" pn="section-2.3.6.1-3">Shortly after the automatic ren ewal process is stopped by the IdO, the last		<t indent="0" pn="section-2.3.6.1-3">Shortly after the automatic ren ewal process is stopped by the IdO, the last
	issued STAR certificate expires and the delegation terminates.</t>		issued STAR certificate expires and the delegation terminates.</t>
	</section>		</section>
	<section anchor="by-revocation-non-star" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.6.2">		<section anchor="by-revocation-non-star" numbered="true" removeInRFC=" false" toc="exclude" pn="section-2.3.6.2">
	<name slugifiedName="name-by-revocation-non-star">By Revocation (Non -STAR)</name>		<name slugifiedName="name-by-revocation-non-star">By Revocation (Non -STAR)</name>
	<t indent="0" pn="section-2.3.6.2-1">The IdO can terminate the deleg ation of a non-STAR certificate by requesting it		<t indent="0" pn="section-2.3.6.2-1">The IdO can terminate the deleg ation of a non-STAR certificate by requesting it
	to be revoked using the <tt>revokeCert</tt> URL exposed by the CA.</t>		to be revoked using the <tt>revokeCert</tt> URL exposed by the CA.</t>
	<t indent="0" pn="section-2.3.6.2-2">According to <xref target="RFC8 555" format="default" sectionFormat="of" derivedContent="RFC8555" section="7.6" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.6"/>, the revocation e ndpoint can be used		<t indent="0" pn="section-2.3.6.2-2">According to <xref target="RFC8 555" section="7.6" format="default" sectionFormat="of" derivedLink="https://rfc- editor.org/rfc/rfc8555#section-7.6" derivedContent="RFC8555"/>, the revocation e ndpoint can be used
	with either the account key pair or the certificate key pair. In other words, an		with either the account key pair or the certificate key pair. In other words, an
	NDC that learns the <tt>revokeCert</tt> URL of the CA (which is publicly availab le via		NDC that learns the <tt>revokeCert</tt> URL of the CA (which is publicly availab le via
	the CA's directory object) would be able to revoke the certificate using the		the CA's directory object) would be able to revoke the certificate using the
	associated private key. However, given the trust relationship between the NDC an d		associated private key. However, given the trust relationship between the NDC an d
	IdO expected by the delegation trust model (<xref target="sec-trust-model" forma t="default" sectionFormat="of" derivedContent="Section 7.1"/>), as well as		IdO expected by the delegation trust model (<xref target="sec-trust-model" forma t="default" sectionFormat="of" derivedContent="Section 7.1"/>), as well as
	the lack of incentives for the NDC to prematurely terminate the delegation,		the lack of incentives for the NDC to prematurely terminate the delegation,
	this does not represent a significant security risk.</t>		this does not represent a significant security risk.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="proxy-behavior" numbered="true" toc="include" removeInRFC ="false" pn="section-2.4">		<section anchor="proxy-behavior" numbered="true" removeInRFC="false" toc=" include" pn="section-2.4">
	<name slugifiedName="name-proxy-behavior">Proxy Behavior</name>		<name slugifiedName="name-proxy-behavior">Proxy Behavior</name>
	<t indent="0" pn="section-2.4-1">There are cases where the ACME Delegati on flow should be proxied, such as the		<t indent="0" pn="section-2.4-1">There are cases where the ACME Delegati on flow should be proxied, such as the
	use case described in <xref target="sec-cdni-dele" format="default" sectionForma t="of" derivedContent="Section 5.1.2"/>. This section describes the behavior of		use case described in <xref target="sec-cdni-dele" format="default" sectionForma t="of" derivedContent="Section 5.1.2"/>. This section describes the behavior of
	such proxies.</t>		such proxies.</t>
	<t indent="0" pn="section-2.4-2">An entity implementing the IdO server r ole -- an "ACME Delegation server" --		<t indent="0" pn="section-2.4-2">An entity implementing the IdO server r ole -- an "ACME Delegation server" --
	may behave, on a per-identity case, either as a proxy into another ACME Delegati on		may behave, on a per-identity case, either as a proxy into another ACME Delegati on
	server or as an IdO and obtain a certificate directly.		server or as an IdO and obtain a certificate directly.
	The determining factor is whether it can successfully be authorized by		The determining factor is whether it can successfully be authorized by
	the next-hop ACME server for the identity associated with the certificate reques t.</t>		the next-hop ACME server for the identity associated with the certificate reques t.</t>
	<t indent="0" pn="section-2.4-3">The identities supported by each server and the disposition for each of them		<t indent="0" pn="section-2.4-3">The identities supported by each server and the disposition for each of them
	skipping to change at line 1563 ¶		skipping to change at line 1563 ¶
	<dd pn="section-2.4-5.10">		<dd pn="section-2.4-5.10">
	<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.10.1">		<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.10.1">
	<li pn="section-2.4-5.10.1.1">The <tt>Location</tt> header, <tt>Li nk</tt> relations, and the <tt>finalize</tt> URLs are rewritten as for Get Order .</li>		<li pn="section-2.4-5.10.1.1">The <tt>Location</tt> header, <tt>Li nk</tt> relations, and the <tt>finalize</tt> URLs are rewritten as for Get Order .</li>
	</ul>		</ul>
	</dd>		</dd>
	</dl>		</dl>
	<t indent="0" pn="section-2.4-6">We note that all the above messages are authenticated; therefore, each proxy		<t indent="0" pn="section-2.4-6">We note that all the above messages are authenticated; therefore, each proxy
	must be able to authenticate any subordinate server.</t>		must be able to authenticate any subordinate server.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-ca-behavior" numbered="true" toc="include" removeInRFC= "false" pn="section-3">		<section anchor="sec-ca-behavior" numbered="true" removeInRFC="false" toc="i nclude" pn="section-3">
	<name slugifiedName="name-ca-behavior">CA Behavior</name>		<name slugifiedName="name-ca-behavior">CA Behavior</name>
	<t indent="0" pn="section-3-1">Although most of this document, and in part icular <xref target="sec-protocol-flow" format="default" sectionFormat="of" deri vedContent="Section 2"/>, is focused on the protocol between the NDC and IdO, th e protocol does affect the ACME server running in the CA. A CA that wishes to su pport certificate delegation <bcp14>MUST</bcp14> also support unauthenticated ce rtificate fetching, which it declares using <tt>allow-certificate-get</tt> (<xre f target="capability-metadata" format="default" sectionFormat="of" derivedConten t="Section 2.3.5, Paragraph 3"/>).</t>		<t indent="0" pn="section-3-1">Although most of this document, and in part icular <xref target="sec-protocol-flow" format="default" sectionFormat="of" deri vedContent="Section 2"/>, is focused on the protocol between the NDC and IdO, th e protocol does affect the ACME server running in the CA. A CA that wishes to su pport certificate delegation <bcp14>MUST</bcp14> also support unauthenticated ce rtificate fetching, which it declares using <tt>allow-certificate-get</tt> (<xre f target="capability-metadata" format="default" sectionFormat="of" derivedConten t="Section 2.3.5, Paragraph 3"/>).</t>
	</section>		</section>
	<section anchor="sec-csr-template" numbered="true" toc="include" removeInRFC ="false" pn="section-4">		<section anchor="sec-csr-template" numbered="true" removeInRFC="false" toc=" include" pn="section-4">
	<name slugifiedName="name-csr-template">CSR Template</name>		<name slugifiedName="name-csr-template">CSR Template</name>
	<t indent="0" pn="section-4-1">The CSR template is used to express and con strain the shape of the CSR that the		<t indent="0" pn="section-4-1">The CSR template is used to express and con strain the shape of the CSR that the
	NDC uses to request the certificate. The CSR is used for every certificate		NDC uses to request the certificate. The CSR is used for every certificate
	created under the same delegation. Its validation by the IdO is a critical		created under the same delegation. Its validation by the IdO is a critical
	element in the security of the whole delegation mechanism.</t>		element in the security of the whole delegation mechanism.</t>
	<t indent="0" pn="section-4-2">Instead of defining every possible CSR attr ibute, this document takes a		<t indent="0" pn="section-4-2">Instead of defining every possible CSR attr ibute, this document takes a
	minimalist approach by declaring only the minimum attribute set and deferring		minimalist approach by declaring only the minimum attribute set and deferring
	the registration of further, more-specific attributes to future documents.</t>		the registration of further, more-specific attributes to future documents.</t>
	<section anchor="sec-csr-template-syntax" numbered="true" toc="include" re moveInRFC="false" pn="section-4.1">		<section anchor="sec-csr-template-syntax" numbered="true" removeInRFC="fal se" toc="include" pn="section-4.1">
	<name slugifiedName="name-template-syntax">Template Syntax</name>		<name slugifiedName="name-template-syntax">Template Syntax</name>
	<t indent="0" pn="section-4.1-1">The template is a JSON document. Each f ield (with the exception of <tt>keyTypes</tt>, see below) denotes one of the fol lowing:</t>		<t indent="0" pn="section-4.1-1">The template is a JSON document. Each f ield (with the exception of <tt>keyTypes</tt>, see below) denotes one of the fol lowing:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4 .1-2">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4 .1-2">
	<li pn="section-4.1-2.1">A mandatory field where the template specifie s the literal value of that		<li pn="section-4.1-2.1">A mandatory field where the template specifie s the literal value of that
	field. This is denoted by a literal string, such as <tt>abc.ido.example</tt>.</l i>		field. This is denoted by a literal string, such as <tt>abc.ido.example</tt>.</l i>
	<li pn="section-4.1-2.2">A mandatory field where the content of the fi eld is defined by the client.		<li pn="section-4.1-2.2">A mandatory field where the content of the fi eld is defined by the client.
	This is denoted by <tt>**</tt>.</li>		This is denoted by <tt>**</tt>.</li>
	<li pn="section-4.1-2.3">An optional field where the client decides wh ether the field is included in		<li pn="section-4.1-2.3">An optional field where the client decides wh ether the field is included in
	the CSR and, if so, what its value is. This is denoted by <tt>*</tt>.</li>		the CSR and, if so, what its value is. This is denoted by <tt>*</tt>.</li>
	</ul>		</ul>
	<t indent="0" pn="section-4.1-3">The NDC <bcp14>MUST NOT</bcp14> include any fields in the CSR, including any extensions, unless they are specified in t he		<t indent="0" pn="section-4.1-3">The NDC <bcp14>MUST NOT</bcp14> include any fields in the CSR, including any extensions, unless they are specified in t he
	template.</t>		template.</t>
	<t indent="0" pn="section-4.1-4">The structure of the template object is defined by the Concise Data Definition Language (CDDL) <xref target="RFC8610" f ormat="default" sectionFormat="of" derivedContent="RFC8610"/> document in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" derivedCon tent="Appendix A"/>.		<t indent="0" pn="section-4.1-4">The structure of the template object is defined by the Concise Data Definition Language (CDDL) <xref target="RFC8610" f ormat="default" sectionFormat="of" derivedContent="RFC8610"/> document in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" derivedCon tent="Appendix A"/>.
	An alternative, nonnormative JSON Schema syntax is given in <xref target="csr-te mplate-schema" format="default" sectionFormat="of" derivedContent="Appendix B"/> .		An alternative, nonnormative JSON Schema syntax is given in <xref target="csr-te mplate-schema" format="default" sectionFormat="of" derivedContent="Appendix B"/> .
	While the CSR template must follow the syntax defined here, neither the IdO nor		While the CSR template must follow the syntax defined here, neither the IdO nor
	the NDC are expected to validate it at runtime.</t>		the NDC are expected to validate it at runtime.</t>
	<t indent="0" pn="section-4.1-5">The <tt>subject</tt> field and its subf ields are mapped into the <tt>subject</tt> field of the CSR, as per <xref target ="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280" section= "4.1.2.6" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.1.2.6"/>. Ot her extension fields of the CSR template are mapped into the CSR according to th e table in <xref target="csr-template-registry" format="default" sectionFormat=" of" derivedContent="Section 6.5"/>.</t>		<t indent="0" pn="section-4.1-5">The <tt>subject</tt> field and its subf ields are mapped into the <tt>subject</tt> field of the CSR, as per <xref target ="RFC5280" section="4.1.2.6" format="default" sectionFormat="of" derivedLink="ht tps://rfc-editor.org/rfc/rfc5280#section-4.1.2.6" derivedContent="RFC5280"/>. Ot her extension fields of the CSR template are mapped into the CSR according to th e table in <xref target="csr-template-registry" format="default" sectionFormat=" of" derivedContent="Section 6.5"/>.</t>
	<t indent="0" pn="section-4.1-6">The <tt>subjectAltName</tt> field is cu rrently defined for the following identifiers:		<t indent="0" pn="section-4.1-6">The <tt>subjectAltName</tt> field is cu rrently defined for the following identifiers:
	DNS names, email addresses, and URIs. New identifier types may be added in the		DNS names, email addresses, and URIs. New identifier types may be added in the
	future by documents that extend this specification. Each new identifier type		future by documents that extend this specification. Each new identifier type
	<bcp14>SHALL</bcp14> have an associated identifier validation challenge that the CA can		<bcp14>SHALL</bcp14> have an associated identifier validation challenge that the CA can
	use to obtain proof of the requester's control over it.</t>		use to obtain proof of the requester's control over it.</t>
	<t indent="0" pn="section-4.1-7">The <tt>keyTypes</tt> property is not c opied into the CSR. Instead, this property constrains the <tt>SubjectPublicKeyIn fo</tt> field of the CSR, which <bcp14>MUST</bcp14> have the type/size defined b y one of the array members of the <tt>keyTypes</tt> property.</t>		<t indent="0" pn="section-4.1-7">The <tt>keyTypes</tt> property is not c opied into the CSR. Instead, this property constrains the <tt>SubjectPublicKeyIn fo</tt> field of the CSR, which <bcp14>MUST</bcp14> have the type/size defined b y one of the array members of the <tt>keyTypes</tt> property.</t>
	<t indent="0" pn="section-4.1-8">When the IdO receives the CSR, it <bcp1 4>MUST</bcp14> verify that the CSR is consistent		<t indent="0" pn="section-4.1-8">When the IdO receives the CSR, it <bcp1 4>MUST</bcp14> verify that the CSR is consistent
	with the template contained in the <tt>delegation</tt> object referenced in the Order. The IdO <bcp14>MAY</bcp14> enforce additional		with the template contained in the <tt>delegation</tt> object referenced in the Order. The IdO <bcp14>MAY</bcp14> enforce additional
	constraints, e.g., by restricting field lengths. In this regard, note that a		constraints, e.g., by restricting field lengths. In this regard, note that a
	<tt>subjectAltName</tt> of type <tt>DNS</tt> can be specified using the wildcard notation,		<tt>subjectAltName</tt> of type <tt>DNS</tt> can be specified using the wildcard notation,
	meaning that the NDC can be required (<tt>**</tt>) or offered the possibility (< tt>*</tt>) to		meaning that the NDC can be required (<tt>**</tt>) or offered the possibility (< tt>*</tt>) to
	define the delegated domain name by itself. If this is the case, the IdO <bcp14 >MUST</bcp14>		define the delegated domain name by itself. If this is the case, the IdO <bcp14 >MUST</bcp14>
	apply application-specific checks on top of the control rules already provided		apply application-specific checks on top of the control rules already provided
	by the CSR template to ensure the requested domain name is legitimate according		by the CSR template to ensure the requested domain name is legitimate according
	to its local policy.</t>		to its local policy.</t>
	</section>		</section>
	<section anchor="example" numbered="true" toc="include" removeInRFC="false " pn="section-4.2">		<section anchor="example" numbered="true" removeInRFC="false" toc="include " pn="section-4.2">
	<name slugifiedName="name-example">Example</name>		<name slugifiedName="name-example">Example</name>
	<t indent="0" pn="section-4.2-1">The CSR template in <xref target="fig-c sr-template" format="default" sectionFormat="of" derivedContent="Figure 10"/> re presents one possible CSR template		<t indent="0" pn="section-4.2-1">The CSR template in <xref target="fig-c sr-template" format="default" sectionFormat="of" derivedContent="Figure 10"/> re presents one possible CSR template
	governing the delegation exchanges provided in the rest of this document.</t>		governing the delegation exchanges provided in the rest of this document.</t>
	<figure anchor="fig-csr-template" align="left" suppress-title="false" pn ="figure-10">		<figure anchor="fig-csr-template" align="left" suppress-title="false" pn ="figure-10">
	<name slugifiedName="name-example-csr-template">Example CSR Template</ name>		<name slugifiedName="name-example-csr-template">Example CSR Template</ name>
	<sourcecode name="" type="json" pn="section-4.2-2.1" markers="false">		<sourcecode name="" type="json" markers="false" pn="section-4.2-2.1">
	{		{
	"keyTypes": [		"keyTypes": [
	{		{
	"PublicKeyType": "rsaEncryption",		"PublicKeyType": "rsaEncryption",
	"PublicKeyLength": 2048,		"PublicKeyLength": 2048,
	"SignatureType": "sha256WithRSAEncryption"		"SignatureType": "sha256WithRSAEncryption"
	},		},
	{		{
	"PublicKeyType": "id-ecPublicKey",		"PublicKeyType": "id-ecPublicKey",
	"namedCurve": "secp256r1",		"namedCurve": "secp256r1",
	skipping to change at line 1654 ¶		skipping to change at line 1654 ¶
	"extendedKeyUsage": [		"extendedKeyUsage": [
	"serverAuth",		"serverAuth",
	"clientAuth"		"clientAuth"
	]		]
	}		}
	}		}
	</sourcecode>		</sourcecode>
	</figure>		</figure>
	</section>		</section>
	</section>		</section>
	<section anchor="further-use-cases" numbered="true" toc="include" removeInRF C="false" pn="section-5">		<section anchor="further-use-cases" numbered="true" removeInRFC="false" toc= "include" pn="section-5">
	<name slugifiedName="name-further-use-cases">Further Use Cases</name>		<name slugifiedName="name-further-use-cases">Further Use Cases</name>
	<t indent="0" pn="section-5-1">This nonnormative section describes additio nal use cases implementing the STAR certificate		<t indent="0" pn="section-5-1">This nonnormative section describes additio nal use cases implementing the STAR certificate
	delegation in nontrivial ways.</t>		delegation in nontrivial ways.</t>
	<section anchor="cdn-interconnection-cdni" numbered="true" toc="include" r emoveInRFC="false" pn="section-5.1">		<section anchor="cdn-interconnection-cdni" numbered="true" removeInRFC="fa lse" toc="include" pn="section-5.1">
	<name slugifiedName="name-cdn-interconnection-cdni">CDN Interconnection (CDNI)</name>		<name slugifiedName="name-cdn-interconnection-cdni">CDN Interconnection (CDNI)</name>
	<t indent="0" pn="section-5.1-1"><xref target="I-D.ietf-cdni-interfaces- https-delegation" format="default" sectionFormat="of" derivedContent="HTTPS-DELE GATION"/> discusses several solutions		<t indent="0" pn="section-5.1-1"><xref target="I-D.ietf-cdni-interfaces- https-delegation" format="default" sectionFormat="of" derivedContent="HTTPS-DELE GATION"/> discusses several solutions
	addressing different delegation requirements for the CDN Interconnection (CDNI)		addressing different delegation requirements for the CDN Interconnection (CDNI)
	environment. This section discusses two of the stated requirements in the		environment. This section discusses two of the stated requirements in the
	context of the STAR delegation workflow.</t>		context of the STAR delegation workflow.</t>
	<t indent="0" pn="section-5.1-2">This section uses specific CDNI termino logy, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in <xref targe t="RFC7336" format="default" sectionFormat="of" derivedContent="RFC7336"/>.</t>		<t indent="0" pn="section-5.1-2">This section uses specific CDNI termino logy, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in <xref targe t="RFC7336" format="default" sectionFormat="of" derivedContent="RFC7336"/>.</t>
	<section anchor="multiple-parallel-delegates" numbered="true" toc="inclu de" removeInRFC="false" pn="section-5.1.1">		<section anchor="multiple-parallel-delegates" numbered="true" removeInRF C="false" toc="include" pn="section-5.1.1">
	<name slugifiedName="name-multiple-parallel-delegates">Multiple Parall el Delegates</name>		<name slugifiedName="name-multiple-parallel-delegates">Multiple Parall el Delegates</name>
	<t indent="0" pn="section-5.1.1-1">In some cases, the content owner (I dO) would like to delegate authority over a		<t indent="0" pn="section-5.1.1-1">In some cases, the content owner (I dO) would like to delegate authority over a
	website to multiple NDCs (CDNs). This could happen if the IdO has agreements		website to multiple NDCs (CDNs). This could happen if the IdO has agreements
	in place with different regional CDNs for different geographical regions or if		in place with different regional CDNs for different geographical regions or if
	a "backup" CDN is used to handle overflow traffic by temporarily altering some		a "backup" CDN is used to handle overflow traffic by temporarily altering some
	of the CNAME mappings in place. The STAR delegation flow enables this use case		of the CNAME mappings in place. The STAR delegation flow enables this use case
	naturally, since each CDN can authenticate separately to the IdO (via its own		naturally, since each CDN can authenticate separately to the IdO (via its own
	separate account) specifying its CSR, and the IdO is free to allow or deny each		separate account) specifying its CSR, and the IdO is free to allow or deny each
	certificate request according to its own policy.</t>		certificate request according to its own policy.</t>
	</section>		</section>
	<section anchor="sec-cdni-dele" numbered="true" toc="include" removeInRF C="false" pn="section-5.1.2">		<section anchor="sec-cdni-dele" numbered="true" removeInRFC="false" toc= "include" pn="section-5.1.2">
	<name slugifiedName="name-chained-delegation">Chained Delegation</name >		<name slugifiedName="name-chained-delegation">Chained Delegation</name >
	<t indent="0" pn="section-5.1.2-1">In other cases, a content owner (Id O) delegates some domains to a large CDN		<t indent="0" pn="section-5.1.2-1">In other cases, a content owner (Id O) delegates some domains to a large CDN
	(uCDN), which in turn delegates to a smaller regional CDN (dCDN). The IdO has a		(uCDN), which in turn delegates to a smaller regional CDN (dCDN). The IdO has a
	contractual relationship with uCDN, and uCDN has a similar relationship with		contractual relationship with uCDN, and uCDN has a similar relationship with
	dCDN. However, IdO may not even know about dCDN.</t>		dCDN. However, IdO may not even know about dCDN.</t>
	<t indent="0" pn="section-5.1.2-2">If needed, the STAR protocol can be chained to support this use case: uCDN		<t indent="0" pn="section-5.1.2-2">If needed, the STAR protocol can be chained to support this use case: uCDN
	could forward requests from dCDN to IdO and forward responses back to dCDN.		could forward requests from dCDN to IdO and forward responses back to dCDN.
	Whether such proxying is allowed is governed by policy and contracts between		Whether such proxying is allowed is governed by policy and contracts between
	the parties.</t>		the parties.</t>
	<t indent="0" pn="section-5.1.2-3">A mechanism is necessary at the int erface between uCDN and dCDN, by which the		<t indent="0" pn="section-5.1.2-3">A mechanism is necessary at the int erface between uCDN and dCDN, by which the
	uCDN can advertise:</t>		uCDN can advertise:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section -5.1.2-4">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section -5.1.2-4">
	<li pn="section-5.1.2-4.1">the names that the dCDN is allowed to use and</li>		<li pn="section-5.1.2-4.1">the names that the dCDN is allowed to use and</li>
	<li pn="section-5.1.2-4.2">the policy for creating the key material (allowed algorithms, minimum key		<li pn="section-5.1.2-4.2">the policy for creating the key material (allowed algorithms, minimum key
	lengths, key usage, etc.) that the dCDN needs to satisfy.</li>		lengths, key usage, etc.) that the dCDN needs to satisfy.</li>
	</ul>		</ul>
	<t indent="0" pn="section-5.1.2-5">Note that such mechanism is provide d by the CSR template.</t>		<t indent="0" pn="section-5.1.2-5">Note that such mechanism is provide d by the CSR template.</t>
	<section anchor="two-level-delegation-in-cdni" numbered="true" toc="ex clude" removeInRFC="false" pn="section-5.1.2.1">		<section anchor="two-level-delegation-in-cdni" numbered="true" removeI nRFC="false" toc="exclude" pn="section-5.1.2.1">
	<name slugifiedName="name-two-level-delegation-in-cdn">Two-Level Del egation in CDNI</name>		<name slugifiedName="name-two-level-delegation-in-cdn">Two-Level Del egation in CDNI</name>
	<t indent="0" pn="section-5.1.2.1-1">A User Agent (UA), e.g., a brow ser or set-top box, wants to fetch the video resource at		<t indent="0" pn="section-5.1.2.1-1">A User Agent (UA), e.g., a brow ser or set-top box, wants to fetch the video resource at
	the following URI: <tt>https://video.cp.example/movie</tt>.		the following URI: <tt>https://video.cp.example/movie</tt>.
	Redirection between the		Redirection between the
	content provider (CP) and upstream and downstream CDNs is arranged as a		content provider (CP) and upstream and downstream CDNs is arranged as a
	CNAME-based aliasing chain, as illustrated in <xref target="fig-cdni-dns-redirec tion" format="default" sectionFormat="of" derivedContent="Figure 11"/>.</t>		CNAME-based aliasing chain, as illustrated in <xref target="fig-cdni-dns-redirec tion" format="default" sectionFormat="of" derivedContent="Figure 11"/>.</t>
	<figure anchor="fig-cdni-dns-redirection" align="left" suppress-titl e="false" pn="figure-11">		<figure anchor="fig-cdni-dns-redirection" align="left" suppress-titl e="false" pn="figure-11">
	<name slugifiedName="name-dns-redirection">DNS Redirection</name>		<name slugifiedName="name-dns-redirection">DNS Redirection</name>
	<artset pn="section-5.1.2.1-2.1">		<artset pn="section-5.1.2.1-2.1">
	<artwork type="svg" name="" align="left" alt="" pn="section-5.1. 2.1-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox="0 0 780.0 489.0">		<artwork type="svg" name="" alt="" align="left" pn="section-5.1. 2.1-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox="0 0 780.0 489.0">
	<g transform="translate(8,16)">		<g transform="translate(8,16)">
	<path d="M 400,16 L 488,16" fill="none" stroke="black"/>		<path d="M 400,16 L 488,16" fill="none" stroke="black"/>
	<path d="M 400,32 L 448,32" fill="none" stroke="black"/>		<path d="M 400,32 L 448,32" fill="none" stroke="black"/>
	<path d="M 120,48 L 392,48" fill="none" stroke="black"/>		<path d="M 120,48 L 392,48" fill="none" stroke="black"/>
	<path d="M 152,80 L 400,80" fill="none" stroke="black"/>		<path d="M 152,80 L 400,80" fill="none" stroke="black"/>
	<path d="M 400,96 L 448,96" fill="none" stroke="black"/>		<path d="M 400,96 L 448,96" fill="none" stroke="black"/>
	<path d="M 400,112 L 488,112" fill="none" stroke="black"/>		<path d="M 400,112 L 488,112" fill="none" stroke="black"/>
	<path d="M 16,160 L 96,160" fill="none" stroke="black"/>		<path d="M 16,160 L 96,160" fill="none" stroke="black"/>
	<path d="M 112,160 L 128,160" fill="none" stroke="black"/>		<path d="M 112,160 L 128,160" fill="none" stroke="black"/>
	<path d="M 144,160 L 152,160" fill="none" stroke="black"/>		<path d="M 144,160 L 152,160" fill="none" stroke="black"/>
	skipping to change at line 1987 ¶		skipping to change at line 1987 ¶
	<text text-anchor="middle" font-family="monospace" x="64" y="212" fill="black" font-size="1em">L</text>		<text text-anchor="middle" font-family="monospace" x="64" y="212" fill="black" font-size="1em">L</text>
	<text text-anchor="middle" font-family="monospace" x="192" y="244" fill="black" font-size="1em">N</text>		<text text-anchor="middle" font-family="monospace" x="192" y="244" fill="black" font-size="1em">N</text>
	<text text-anchor="middle" font-family="monospace" x="216" y="244" fill="black" font-size="1em">E</text>		<text text-anchor="middle" font-family="monospace" x="216" y="244" fill="black" font-size="1em">E</text>
	<text text-anchor="middle" font-family="monospace" x="272" y="244" fill="black" font-size="1em">.</text>		<text text-anchor="middle" font-family="monospace" x="272" y="244" fill="black" font-size="1em">.</text>
	<text text-anchor="middle" font-family="monospace" x="328" y="244" fill="black" font-size="1em">x</text>		<text text-anchor="middle" font-family="monospace" x="328" y="244" fill="black" font-size="1em">x</text>
	<text text-anchor="middle" font-family="monospace" x="240" y="180" fill="black" font-size="1em">.</text>		<text text-anchor="middle" font-family="monospace" x="240" y="180" fill="black" font-size="1em">.</text>
	<text text-anchor="middle" font-family="monospace" x="296" y="180" fill="black" font-size="1em">x</text>		<text text-anchor="middle" font-family="monospace" x="296" y="180" fill="black" font-size="1em">x</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" name="" align="left" alt="" pn="sectio n-5.1.2.1-2.1.2">		<artwork type="ascii-art" name="" alt="" align="left" pn="sectio n-5.1.2.1-2.1.2">
	.------------.		.------------.
	video.cp.example ? | .-----. |		video.cp.example ? | .-----. |
	.----------------------------------&gt;| | |		.----------------------------------&gt;| | |
	| (a) | | DNS | CP |		| (a) | | DNS | CP |
	| .-------------------------------+ | |		| .-------------------------------+ | |
	| | CNAME video.ucdn.example | '-----' |		| | CNAME video.ucdn.example | '-----' |
	| | '------------'		| | '------------'
	| |		| |
	| |		| |
	.-----------|---v--. .------------.		.-----------|---v--. .------------.
	skipping to change at line 2034 ¶		skipping to change at line 2034 ¶
	original URI -- in the example, <tt>video.cp.example</tt>. So, in order to		original URI -- in the example, <tt>video.cp.example</tt>. So, in order to
	successfully complete the handshake, the landing dCDN node has to be configured		successfully complete the handshake, the landing dCDN node has to be configured
	with a certificate whose <tt>subjectAltName</tt> field matches <tt>video.cp.exam ple</tt>, i.e., a		with a certificate whose <tt>subjectAltName</tt> field matches <tt>video.cp.exam ple</tt>, i.e., a
	content provider's name.</t>		content provider's name.</t>
	<t indent="0" pn="section-5.1.2.1-4"><xref target="fig-cdni-flow" fo rmat="default" sectionFormat="of" derivedContent="Figure 12"/> illustrates the c ascaded delegation flow that allows dCDN to		<t indent="0" pn="section-5.1.2.1-4"><xref target="fig-cdni-flow" fo rmat="default" sectionFormat="of" derivedContent="Figure 12"/> illustrates the c ascaded delegation flow that allows dCDN to
	obtain a STAR certificate that bears a name belonging to the content provider		obtain a STAR certificate that bears a name belonging to the content provider
	with a private key that is only known to the dCDN.</t>		with a private key that is only known to the dCDN.</t>
	<figure anchor="fig-cdni-flow" align="left" suppress-title="false" p n="figure-12">		<figure anchor="fig-cdni-flow" align="left" suppress-title="false" p n="figure-12">
	<name slugifiedName="name-two-level-delegation-in-cdni">Two-Level Delegation in CDNI</name>		<name slugifiedName="name-two-level-delegation-in-cdni">Two-Level Delegation in CDNI</name>
	<artset pn="section-5.1.2.1-5.1">		<artset pn="section-5.1.2.1-5.1">
	<artwork type="svg" name="" align="left" alt="" pn="section-5.1. 2.1-5.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox="0 0 696.0 553.0">		<artwork type="svg" name="" alt="" align="left" pn="section-5.1. 2.1-5.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox="0 0 696.0 553.0">
	<g transform="translate(8,16)">		<g transform="translate(8,16)">
	<path d="M 96,16 L 248,16" fill="none" stroke="black"/>		<path d="M 96,16 L 248,16" fill="none" stroke="black"/>
	<path d="M 136,32 L 192,32" fill="none" stroke="black"/>		<path d="M 136,32 L 192,32" fill="none" stroke="black"/>
	<path d="M 192,32 L 248,32" fill="none" stroke="black"/>		<path d="M 192,32 L 248,32" fill="none" stroke="black"/>
	<path d="M 256,48 L 360,48" fill="none" stroke="black"/>		<path d="M 256,48 L 360,48" fill="none" stroke="black"/>
	<path d="M 248,80 L 288,80" fill="none" stroke="black"/>		<path d="M 248,80 L 288,80" fill="none" stroke="black"/>
	<path d="M 136,96 L 168,96" fill="none" stroke="black"/>		<path d="M 136,96 L 168,96" fill="none" stroke="black"/>
	<path d="M 168,96 L 192,96" fill="none" stroke="black"/>		<path d="M 168,96 L 192,96" fill="none" stroke="black"/>
	<path d="M 192,96 L 248,96" fill="none" stroke="black"/>		<path d="M 192,96 L 248,96" fill="none" stroke="black"/>
	<path d="M 96,112 L 160,112" fill="none" stroke="black"/>		<path d="M 96,112 L 160,112" fill="none" stroke="black"/>
	skipping to change at line 2274 ¶		skipping to change at line 2274 ¶
	<text text-anchor="middle" font-family="monospace" x="224" y="484" fill="black" font-size="1em">H</text>		<text text-anchor="middle" font-family="monospace" x="224" y="484" fill="black" font-size="1em">H</text>
	<text text-anchor="middle" font-family="monospace" x="160" y="68" fill="black" font-size="1em">e</text>		<text text-anchor="middle" font-family="monospace" x="160" y="68" fill="black" font-size="1em">e</text>
	<text text-anchor="middle" font-family="monospace" x="224" y="68" fill="black" font-size="1em">A</text>		<text text-anchor="middle" font-family="monospace" x="224" y="68" fill="black" font-size="1em">A</text>
	<text text-anchor="middle" font-family="monospace" x="376" y="100" fill="black" font-size="1em">6</text>		<text text-anchor="middle" font-family="monospace" x="376" y="100" fill="black" font-size="1em">6</text>
	<text text-anchor="middle" font-family="monospace" x="392" y="180" fill="black" font-size="1em">A</text>		<text text-anchor="middle" font-family="monospace" x="392" y="180" fill="black" font-size="1em">A</text>
	<text text-anchor="middle" font-family="monospace" x="376" y="420" fill="black" font-size="1em">9</text>		<text text-anchor="middle" font-family="monospace" x="376" y="420" fill="black" font-size="1em">9</text>
	<text text-anchor="middle" font-family="monospace" x="184" y="500" fill="black" font-size="1em">i</text>		<text text-anchor="middle" font-family="monospace" x="184" y="500" fill="black" font-size="1em">i</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" name="" align="left" alt="" pn="sectio n-5.1.2.1-5.1.2">		<artwork type="ascii-art" name="" alt="" align="left" pn="sectio n-5.1.2.1-5.1.2">
	.--------------------.		.--------------------.
	| .------.------. |		| .------.------. |
	| | STAR | ACME |&lt;-------------.		| | STAR | ACME |&lt;-------------.
	| CP | dele | STAR | | |		| CP | dele | STAR | | |
	| | srv | cli +-----. |		| | srv | cli +-----. |
	| '---+--'------' | | 6		| '---+--'------' | | 6
	'---------|------^---' 5 |		'---------|------^---' 5 |
	| | | .--|-------.		| | | .--|-------.
	| | | | .-+----. |		| | | | .-+----. |
	7 | '----&gt;| ACME | |		7 | '----&gt;| ACME | |
	skipping to change at line 2312 ¶		skipping to change at line 2312 ¶
	| .-+----.----+-.------. | | |		| .-+----.----+-.------. | | |
	| | | STAR | +------------' |		| | | STAR | +------------' |
	| dCDN | CDNI | dele | HTTP | | |		| dCDN | CDNI | dele | HTTP | | |
	| | | cli | |&lt;--------------'		| | | cli | |&lt;--------------'
	| '------'------'------' |		| '------'------'------' |
	'---------------------------'		'---------------------------'
	</artwork>		</artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t indent="0" pn="section-5.1.2.1-6">uCDN is configured to delegate to dCDN, and CP is configured to delegate to uCDN, both as defined in <xref targ et="sec-profile-dele-config" format="default" sectionFormat="of" derivedContent= "Section 2.3.1"/>.</t>		<t indent="0" pn="section-5.1.2.1-6">uCDN is configured to delegate to dCDN, and CP is configured to delegate to uCDN, both as defined in <xref targ et="sec-profile-dele-config" format="default" sectionFormat="of" derivedContent= "Section 2.3.1"/>.</t>
	<ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio		<ol indent="adaptive" spacing="normal" start="1" type="1" pn="sectio
	n-5.1.2.1-7">		n-5.1.2.1-7">
	<li pn="section-5.1.2.1-7.1" derivedCounter="1.">dCDN requests CDNI		<li derivedCounter="1." pn="section-5.1.2.1-7.1">dCDN requests CDNI
	path metadata to uCDN.</li>		path metadata to uCDN.</li>
	<li pn="section-5.1.2.1-7.2" derivedCounter="2.">uCDN replies with		<li derivedCounter="2." pn="section-5.1.2.1-7.2">uCDN replies with
	, among other CDNI metadata, the STAR delegation		, among other CDNI metadata, the STAR delegation
	configuration, which includes the delegated content provider's name.</li>		configuration, which includes the delegated content provider's name.</li>
	<li pn="section-5.1.2.1-7.3" derivedCounter="3.">dCDN creates a ke y pair and the CSR with the delegated name. It then places		<li derivedCounter="3." pn="section-5.1.2.1-7.3">dCDN creates a ke y pair and the CSR with the delegated name. It then places
	an order for the delegated name to uCDN.</li>		an order for the delegated name to uCDN.</li>
	<li pn="section-5.1.2.1-7.4" derivedCounter="4.">uCDN forwards the		<li derivedCounter="4." pn="section-5.1.2.1-7.4">uCDN forwards the
	received order to the content provider (CP).</li>		received order to the content provider (CP).</li>
	<li pn="section-5.1.2.1-7.5" derivedCounter="5.">CP creates an ord		<li derivedCounter="5." pn="section-5.1.2.1-7.5">CP creates an ord
	er for a STAR certificate and sends it to the CA. The		er for a STAR certificate and sends it to the CA. The
	order also requests unauthenticated access to the certificate resource.</li>		order also requests unauthenticated access to the certificate resource.</li>
	<li pn="section-5.1.2.1-7.6" derivedCounter="6.">After all authori zations complete successfully, the STAR certificate is		<li derivedCounter="6." pn="section-5.1.2.1-7.6">After all authori zations complete successfully, the STAR certificate is
	issued.</li>		issued.</li>
	<li pn="section-5.1.2.1-7.7" derivedCounter="7.">CP notifies uCDN that the STAR certificate is available at the order's		<li derivedCounter="7." pn="section-5.1.2.1-7.7">CP notifies uCDN that the STAR certificate is available at the order's
	<tt>star-certificate</tt> URL.</li>		<tt>star-certificate</tt> URL.</li>
	<li pn="section-5.1.2.1-7.8" derivedCounter="8.">uCDN forwards the information to dCDN. At this point, the ACME signaling is		<li derivedCounter="8." pn="section-5.1.2.1-7.8">uCDN forwards the information to dCDN. At this point, the ACME signaling is
	complete.</li>		complete.</li>
	<li pn="section-5.1.2.1-7.9" derivedCounter="9.">dCDN requests the		<li derivedCounter="9." pn="section-5.1.2.1-7.9">dCDN requests the
	STAR certificate using unauthenticated GET from the CA.</li>		STAR certificate using unauthenticated GET from the CA.</li>
	<li pn="section-5.1.2.1-7.10" derivedCounter="10.">The CA returns		<li derivedCounter="10." pn="section-5.1.2.1-7.10">The CA returns
	the certificate. Now dCDN is fully configured to handle		the certificate. Now dCDN is fully configured to handle
	HTTPS traffic in lieu of the content provider.</li>		HTTPS traffic in lieu of the content provider.</li>
	</ol>		</ol>
	<t indent="0" pn="section-5.1.2.1-8">Note that 9 and 10 repeat until the delegation expires or is terminated.</t>		<t indent="0" pn="section-5.1.2.1-8">Note that 9 and 10 repeat until the delegation expires or is terminated.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="secure-telephone-identity-revisited-stir" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">		<section anchor="secure-telephone-identity-revisited-stir" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
	<name slugifiedName="name-secure-telephone-identity-r">Secure Telephone Identity Revisited (STIR)</name>		<name slugifiedName="name-secure-telephone-identity-r">Secure Telephone Identity Revisited (STIR)</name>
	<t indent="0" pn="section-5.2-1">As a second use case, we consider the d elegation of credentials in the STIR		<t indent="0" pn="section-5.2-1">As a second use case, we consider the d elegation of credentials in the STIR
	ecosystem <xref target="RFC9060" format="default" sectionFormat="of" derivedCon tent="RFC9060"/>.</t>		ecosystem <xref target="RFC9060" format="default" sectionFormat="of" derivedCon tent="RFC9060"/>.</t>
	<t indent="0" pn="section-5.2-2">This section uses STIR terminology. The term Personal Assertion Token (PASSporT) is defined in <xref target="RFC8225" f ormat="default" sectionFormat="of" derivedContent="RFC8225"/>, and "TNAuthList" is defined in <xref target="RFC8226" format="default" sectionFormat="of" derived Content="RFC8226"/>.</t>		<t indent="0" pn="section-5.2-2">This section uses STIR terminology. The term Personal Assertion Token (PASSporT) is defined in <xref target="RFC8225" f ormat="default" sectionFormat="of" derivedContent="RFC8225"/>, and "TNAuthList" is defined in <xref target="RFC8226" format="default" sectionFormat="of" derived Content="RFC8226"/>.</t>
	<t indent="0" pn="section-5.2-3">In the STIR delegated mode, a service p rovider SP2 -- the NDC -- needs to sign		<t indent="0" pn="section-5.2-3">In the STIR delegated mode, a service p rovider SP2 -- the NDC -- needs to sign
	PASSporTs <xref target="RFC8225" format="default" sectionFormat="of" derivedCont ent="RFC8225"/> for telephone numbers (e.g., TN=+123) belonging to		PASSporTs <xref target="RFC8225" format="default" sectionFormat="of" derivedCont ent="RFC8225"/> for telephone numbers (e.g., TN=+123) belonging to
	another service provider, SP1 -- the IdO. In order to do that, SP2 needs a STIR		another service provider, SP1 -- the IdO. In order to do that, SP2 needs a STIR
	certificate and a private key that includes TN=+123 in the TNAuthList		certificate and a private key that includes TN=+123 in the TNAuthList
	<xref target="RFC8226" format="default" sectionFormat="of" derivedContent="RFC82 26"/> certificate extension.</t>		<xref target="RFC8226" format="default" sectionFormat="of" derivedContent="RFC82 26"/> certificate extension.</t>
	<t indent="0" pn="section-5.2-4">In detail (<xref target="fig-stir-flow" format="default" sectionFormat="of" derivedContent="Figure 13"/>):</t>		<t indent="0" pn="section-5.2-4">In detail (<xref target="fig-stir-flow" format="default" sectionFormat="of" derivedContent="Figure 13"/>):</t>
	<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.		<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-5.
	2-5">		2-5">
	<li pn="section-5.2-5.1" derivedCounter="1.">SP1 and SP2 agree on the c		<li derivedCounter="1." pn="section-5.2-5.1">SP1 and SP2 agree on the c
	onfiguration of the delegation -- in particular,		onfiguration of the delegation -- in particular,
	the CSR template that applies.</li>		the CSR template that applies.</li>
	<li pn="section-5.2-5.2" derivedCounter="2.">SP2 generates a private/p ublic key pair and sends a CSR to SP1, requesting		<li derivedCounter="2." pn="section-5.2-5.2">SP2 generates a private/p ublic key pair and sends a CSR to SP1, requesting
	creation of a certificate with an SP1 name, an SP2 public key, and a TNAuthList		creation of a certificate with an SP1 name, an SP2 public key, and a TNAuthList
	extension with the list of TNs that SP1 delegates to SP2. (Note that the		extension with the list of TNs that SP1 delegates to SP2. (Note that the
	CSR sent by SP2 to SP1 needs to be validated against the CSR template		CSR sent by SP2 to SP1 needs to be validated against the CSR template
	agreed upon in step 1.).</li>		agreed upon in step 1.).</li>
	<li pn="section-5.2-5.3" derivedCounter="3.">SP1 sends an order for th e CSR to the CA. The order also requests		<li derivedCounter="3." pn="section-5.2-5.3">SP1 sends an order for th e CSR to the CA. The order also requests
	unauthenticated access to the certificate resource.</li>		unauthenticated access to the certificate resource.</li>
	<li pn="section-5.2-5.4" derivedCounter="4.">Subsequently, after the r equired TNAuthList authorizations are successfully		<li derivedCounter="4." pn="section-5.2-5.4">Subsequently, after the r equired TNAuthList authorizations are successfully
	completed, the CA moves the order to a "valid" state; at the same		completed, the CA moves the order to a "valid" state; at the same
	time, the star-certificate endpoint is populated.</li>		time, the star-certificate endpoint is populated.</li>
	<li pn="section-5.2-5.5" derivedCounter="5.">The contents of the order are forwarded from SP1 to SP2 by means of the paired		<li derivedCounter="5." pn="section-5.2-5.5">The contents of the order are forwarded from SP1 to SP2 by means of the paired
	"delegation" order.</li>		"delegation" order.</li>
	<li pn="section-5.2-5.6" derivedCounter="6.">SP2 dereferences the <tt> star-certificate</tt> URL in the order to fetch the rolling		<li derivedCounter="6." pn="section-5.2-5.6">SP2 dereferences the <tt> star-certificate</tt> URL in the order to fetch the rolling
	STAR certificate bearing the delegated identifiers.</li>		STAR certificate bearing the delegated identifiers.</li>
	<li pn="section-5.2-5.7" derivedCounter="7.">The STAR certificate is r eturned to SP2.</li>		<li derivedCounter="7." pn="section-5.2-5.7">The STAR certificate is r eturned to SP2.</li>
	</ol>		</ol>
	<figure anchor="fig-stir-flow" align="left" suppress-title="false" pn="f igure-13">		<figure anchor="fig-stir-flow" align="left" suppress-title="false" pn="f igure-13">
	<name slugifiedName="name-delegation-in-stir">Delegation in STIR</name >		<name slugifiedName="name-delegation-in-stir">Delegation in STIR</name >
	<artset pn="section-5.2-6.1">		<artset pn="section-5.2-6.1">
	<artwork type="svg" name="" align="left" alt="" pn="section-5.2-6.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 612.0 377.0">		<artwork type="svg" name="" alt="" align="left" pn="section-5.2-6.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 612.0 377.0">
	<g transform="translate(8,16)">		<g transform="translate(8,16)">
	<path d="M 56,16 L 200,16" fill="none" stroke="black"/>		<path d="M 56,16 L 200,16" fill="none" stroke="black"/>
	<path d="M 88,32 L 144,32" fill="none" stroke="black"/>		<path d="M 88,32 L 144,32" fill="none" stroke="black"/>
	<path d="M 144,32 L 200,32" fill="none" stroke="black"/>		<path d="M 144,32 L 200,32" fill="none" stroke="black"/>
	<path d="M 208,48 L 320,48" fill="none" stroke="black"/>		<path d="M 208,48 L 320,48" fill="none" stroke="black"/>
	<path d="M 16,64 L 32,64" fill="none" stroke="black"/>		<path d="M 16,64 L 32,64" fill="none" stroke="black"/>
	<path d="M 200,80 L 240,80" fill="none" stroke="black"/>		<path d="M 200,80 L 240,80" fill="none" stroke="black"/>
	<path d="M 88,96 L 128,96" fill="none" stroke="black"/>		<path d="M 88,96 L 128,96" fill="none" stroke="black"/>
	<path d="M 128,96 L 144,96" fill="none" stroke="black"/>		<path d="M 128,96 L 144,96" fill="none" stroke="black"/>
	<path d="M 144,96 L 200,96" fill="none" stroke="black"/>		<path d="M 144,96 L 200,96" fill="none" stroke="black"/>
	skipping to change at line 2543 ¶		skipping to change at line 2543 ¶
	<text text-anchor="middle" font-family="monospace" x="128" y=" 308" fill="black" font-size="1em">e</text>		<text text-anchor="middle" font-family="monospace" x="128" y=" 308" fill="black" font-size="1em">e</text>
	<text text-anchor="middle" font-family="monospace" x="112" y=" 52" fill="black" font-size="1em">T</text>		<text text-anchor="middle" font-family="monospace" x="112" y=" 52" fill="black" font-size="1em">T</text>
	<text text-anchor="middle" font-family="monospace" x="120" y=" 292" fill="black" font-size="1em">A</text>		<text text-anchor="middle" font-family="monospace" x="120" y=" 292" fill="black" font-size="1em">A</text>
	<text text-anchor="middle" font-family="monospace" x="176" y=" 68" fill="black" font-size="1em">l</text>		<text text-anchor="middle" font-family="monospace" x="176" y=" 68" fill="black" font-size="1em">l</text>
	<text text-anchor="middle" font-family="monospace" x="104" y=" 292" fill="black" font-size="1em">S</text>		<text text-anchor="middle" font-family="monospace" x="104" y=" 292" fill="black" font-size="1em">S</text>
	<text text-anchor="middle" font-family="monospace" x="112" y=" 292" fill="black" font-size="1em">T</text>		<text text-anchor="middle" font-family="monospace" x="112" y=" 292" fill="black" font-size="1em">T</text>
	<text text-anchor="middle" font-family="monospace" x="72" y="3 08" fill="black" font-size="1em">2</text>		<text text-anchor="middle" font-family="monospace" x="72" y="3 08" fill="black" font-size="1em">2</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" name="" align="left" alt="" pn="section-5. 2-6.1.2">		<artwork type="ascii-art" name="" alt="" align="left" pn="section-5. 2-6.1.2">
	.-------------------.		.-------------------.
	| .------.------. |		| .------.------. |
	| | STAR | STAR |&lt;--------------.		| | STAR | STAR |&lt;--------------.
	.--&gt;| SP1 | dele | dele | | |		.--&gt;| SP1 | dele | dele | | |
	| | | srv | cli +-----. |		| | | srv | cli +-----. |
	| | '----+-'------' | | 4		| | '----+-'------' | | 4
	| '------^--|---------' 3 |		| '------^--|---------' 3 |
	| | | | .----|-----.		| | | | .----|-----.
	| | 5 | | .---+--. |		| | 5 | | .---+--. |
	| | | '---&gt;| ACME | |		| | | '---&gt;| ACME | |
	skipping to change at line 2575 ¶		skipping to change at line 2575 ¶
	'-------------------'		'-------------------'
	</artwork>		</artwork>
	</artset>		</artset>
	</figure>		</figure>
	<t indent="0" pn="section-5.2-7">As shown, the STAR delegation profile d escribed in this document applies		<t indent="0" pn="section-5.2-7">As shown, the STAR delegation profile d escribed in this document applies
	straightforwardly; the only extra requirement being the ability to instruct the		straightforwardly; the only extra requirement being the ability to instruct the
	NDC about the allowed TNAuthList values. This can be achieved by a simple		NDC about the allowed TNAuthList values. This can be achieved by a simple
	extension to the CSR template.</t>		extension to the CSR template.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="include" removeIn RFC="false" pn="section-6">		<section anchor="iana-considerations" numbered="true" removeInRFC="false" to c="include" pn="section-6">
	<name slugifiedName="name-iana-considerations">IANA Considerations</name>		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	<section anchor="new-fields-in-the-meta-object-within-a-directory-object" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">		<section anchor="new-fields-in-the-meta-object-within-a-directory-object" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
	<name slugifiedName="name-new-fields-in-the-meta-obje">New Fields in the "meta" Object within a Directory Object</name>		<name slugifiedName="name-new-fields-in-the-meta-obje">New Fields in the "meta" Object within a Directory Object</name>
	<t indent="0" pn="section-6.1-1">This document adds the following entrie s to the "ACME Directory Metadata Fields" registry:</t>		<t indent="0" pn="section-6.1-1">This document adds the following entrie s to the "ACME Directory Metadata Fields" registry:</t>
	<table align="center" pn="table-1">		<table align="center" pn="table-1">
	<thead>		<thead>
	<tr>		<tr>
	<th align="left" colspan="1" rowspan="1">Field Name</th>		<th align="left" colspan="1" rowspan="1">Field Name</th>
	<th align="left" colspan="1" rowspan="1">Field Type</th>		<th align="left" colspan="1" rowspan="1">Field Type</th>
	<th align="left" colspan="1" rowspan="1">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	skipping to change at line 2602 ¶		skipping to change at line 2602 ¶
	<td align="left" colspan="1" rowspan="1">RFC 9115</td>		<td align="left" colspan="1" rowspan="1">RFC 9115</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left" colspan="1" rowspan="1">allow-certificate-get</td >		<td align="left" colspan="1" rowspan="1">allow-certificate-get</td >
	<td align="left" colspan="1" rowspan="1">boolean</td>		<td align="left" colspan="1" rowspan="1">boolean</td>
	<td align="left" colspan="1" rowspan="1">RFC 9115</td>		<td align="left" colspan="1" rowspan="1">RFC 9115</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="new-fields-in-the-order-object" numbered="true" toc="incl ude" removeInRFC="false" pn="section-6.2">		<section anchor="new-fields-in-the-order-object" numbered="true" removeInR FC="false" toc="include" pn="section-6.2">
	<name slugifiedName="name-new-fields-in-the-order-obj">New Fields in the Order Object</name>		<name slugifiedName="name-new-fields-in-the-order-obj">New Fields in the Order Object</name>
	<t indent="0" pn="section-6.2-1">This document adds the following entrie s to the "ACME Order Object Fields" registry:</t>		<t indent="0" pn="section-6.2-1">This document adds the following entrie s to the "ACME Order Object Fields" registry:</t>
	<table align="center" pn="table-2">		<table align="center" pn="table-2">
	<thead>		<thead>
	<tr>		<tr>
	<th align="left" colspan="1" rowspan="1">Field Name</th>		<th align="left" colspan="1" rowspan="1">Field Name</th>
	<th align="left" colspan="1" rowspan="1">Field Type</th>		<th align="left" colspan="1" rowspan="1">Field Type</th>
	<th align="left" colspan="1" rowspan="1">Configurable</th>		<th align="left" colspan="1" rowspan="1">Configurable</th>
	<th align="left" colspan="1" rowspan="1">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	skipping to change at line 2630 ¶		skipping to change at line 2630 ¶
	</tr>		</tr>
	<tr>		<tr>
	<td align="left" colspan="1" rowspan="1">delegation</td>		<td align="left" colspan="1" rowspan="1">delegation</td>
	<td align="left" colspan="1" rowspan="1">string</td>		<td align="left" colspan="1" rowspan="1">string</td>
	<td align="left" colspan="1" rowspan="1">true</td>		<td align="left" colspan="1" rowspan="1">true</td>
	<td align="left" colspan="1" rowspan="1">RFC 9115</td>		<td align="left" colspan="1" rowspan="1">RFC 9115</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="new-fields-in-the-account-object" numbered="true" toc="in clude" removeInRFC="false" pn="section-6.3">		<section anchor="new-fields-in-the-account-object" numbered="true" removeI nRFC="false" toc="include" pn="section-6.3">
	<name slugifiedName="name-new-fields-in-the-account-o">New Fields in the Account Object</name>		<name slugifiedName="name-new-fields-in-the-account-o">New Fields in the Account Object</name>
	<t indent="0" pn="section-6.3-1">This document adds the following entrie s to the "ACME Account Object Fields" registry:</t>		<t indent="0" pn="section-6.3-1">This document adds the following entrie s to the "ACME Account Object Fields" registry:</t>
	<table align="center" pn="table-3">		<table align="center" pn="table-3">
	<thead>		<thead>
	<tr>		<tr>
	<th align="left" colspan="1" rowspan="1">Field Name</th>		<th align="left" colspan="1" rowspan="1">Field Name</th>
	<th align="left" colspan="1" rowspan="1">Field Type</th>		<th align="left" colspan="1" rowspan="1">Field Type</th>
	<th align="left" colspan="1" rowspan="1">Requests</th>		<th align="left" colspan="1" rowspan="1">Requests</th>
	<th align="left" colspan="1" rowspan="1">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	skipping to change at line 2654 ¶		skipping to change at line 2654 ¶
	<td align="left" colspan="1" rowspan="1">delegations</td>		<td align="left" colspan="1" rowspan="1">delegations</td>
	<td align="left" colspan="1" rowspan="1">string</td>		<td align="left" colspan="1" rowspan="1">string</td>
	<td align="left" colspan="1" rowspan="1">none</td>		<td align="left" colspan="1" rowspan="1">none</td>
	<td align="left" colspan="1" rowspan="1">RFC 9115</td>		<td align="left" colspan="1" rowspan="1">RFC 9115</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t indent="0" pn="section-6.3-3">Note that the <tt>delegations</tt> fiel d is only reported by ACME servers that have		<t indent="0" pn="section-6.3-3">Note that the <tt>delegations</tt> fiel d is only reported by ACME servers that have
	<tt>delegation-enabled</tt> set to true in their meta Object.</t>		<tt>delegation-enabled</tt> set to true in their meta Object.</t>
	</section>		</section>
	<section anchor="new-error-types" numbered="true" toc="include" removeInRF C="false" pn="section-6.4">		<section anchor="new-error-types" numbered="true" removeInRFC="false" toc= "include" pn="section-6.4">
	<name slugifiedName="name-new-error-types">New Error Types</name>		<name slugifiedName="name-new-error-types">New Error Types</name>
	<t indent="0" pn="section-6.4-1">This document adds the following entrie s to the "ACME Error Types" registry:</t>		<t indent="0" pn="section-6.4-1">This document adds the following entrie s to the "ACME Error Types" registry:</t>
	<table align="center" pn="table-4">		<table align="center" pn="table-4">
	<thead>		<thead>
	<tr>		<tr>
	<th align="left" colspan="1" rowspan="1">Type</th>		<th align="left" colspan="1" rowspan="1">Type</th>
	<th align="left" colspan="1" rowspan="1">Description</th>		<th align="left" colspan="1" rowspan="1">Description</th>
	<th align="left" colspan="1" rowspan="1">Reference</th>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left" colspan="1" rowspan="1">unknownDelegation</td>		<td align="left" colspan="1" rowspan="1">unknownDelegation</td>
	<td align="left" colspan="1" rowspan="1">An unknown configuration is listed in the <tt>delegation</tt> attribute of the order request</td>		<td align="left" colspan="1" rowspan="1">An unknown configuration is listed in the <tt>delegation</tt> attribute of the order request</td>
	<td align="left" colspan="1" rowspan="1">RFC 9115</td>		<td align="left" colspan="1" rowspan="1">RFC 9115</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="csr-template-registry" numbered="true" toc="include" remo veInRFC="false" pn="section-6.5">		<section anchor="csr-template-registry" numbered="true" removeInRFC="false " toc="include" pn="section-6.5">
	<name slugifiedName="name-csr-template-extensions">CSR Template Extensio ns</name>		<name slugifiedName="name-csr-template-extensions">CSR Template Extensio ns</name>
	<t indent="0" pn="section-6.5-1">IANA is requested to establish a regist ry, "STAR Delegation CSR Template		<t indent="0" pn="section-6.5-1">IANA is requested to establish a regist ry, "STAR Delegation CSR Template
	Extensions", with "Specification Required" as its registration procedure.</t>		Extensions", with "Specification Required" as its registration procedure.</t>
	<t indent="0" pn="section-6.5-2">Each extension registered must specify: </t>		<t indent="0" pn="section-6.5-2">Each extension registered must specify: </t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6 .5-3">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6 .5-3">
	<li pn="section-6.5-3.1">an extension name,</li>		<li pn="section-6.5-3.1">an extension name,</li>
	<li pn="section-6.5-3.2">an extension syntax, as a reference to a CDDL document that defines this extension, and</li>		<li pn="section-6.5-3.2">an extension syntax, as a reference to a CDDL document that defines this extension, and</li>
	<li pn="section-6.5-3.3">the extension's mapping into an X.509 certifi cate extension.</li>		<li pn="section-6.5-3.3">the extension's mapping into an X.509 certifi cate extension.</li>
	</ul>		</ul>
	<t indent="0" pn="section-6.5-4">The initial contents of this registry a re the extensions defined by the CDDL		<t indent="0" pn="section-6.5-4">The initial contents of this registry a re the extensions defined by the CDDL
	in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" d erivedContent="Appendix A"/>.</t>		in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" d erivedContent="Appendix A"/>.</t>
	<table align="center" pn="table-5">		<table align="center" pn="table-5">
	<thead>		<thead>
	<tr>		<tr>
	<th align="left" colspan="1" rowspan="1">Extension Name</th>		<th align="left" colspan="1" rowspan="1">Extension Name</th>
	<th align="left" colspan="1" rowspan="1">Extension Syntax</th>		<th align="left" colspan="1" rowspan="1">Extension Syntax</th>
	<th align="left" colspan="1" rowspan="1">Mapping to X.509 Certific ate Extension</th>		<th align="left" colspan="1" rowspan="1">Mapping to X.509 Certific ate Extension</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left" colspan="1" rowspan="1">keyUsage</td>		<td align="left" colspan="1" rowspan="1">keyUsage</td>
	<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/></td>		<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/></td>
	<td align="left" colspan="1" rowspan="1">		<td align="left" colspan="1" rowspan="1">
	<xref target="RFC5280" format="default" sectionFormat="comma" de rivedContent="RFC5280" section="4.2.1.3" derivedLink="https://rfc-editor.org/rfc /rfc5280#section-4.2.1.3"/></td>		<xref target="RFC5280" sectionFormat="comma" section="4.2.1.3" f ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.3" derivedContent="RFC5280"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left" colspan="1" rowspan="1">extendedKeyUsage</td>		<td align="left" colspan="1" rowspan="1">extendedKeyUsage</td>
	<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/></td>		<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/></td>
	<td align="left" colspan="1" rowspan="1">		<td align="left" colspan="1" rowspan="1">
	<xref target="RFC5280" format="default" sectionFormat="comma" de rivedContent="RFC5280" section="4.2.1.12" derivedLink="https://rfc-editor.org/rf c/rfc5280#section-4.2.1.12"/></td>		<xref target="RFC5280" sectionFormat="comma" section="4.2.1.12" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.1 2" derivedContent="RFC5280"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left" colspan="1" rowspan="1">subjectAltName</td>		<td align="left" colspan="1" rowspan="1">subjectAltName</td>
	<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/></td>		<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/></td>
	<td align="left" colspan="1" rowspan="1">		<td align="left" colspan="1" rowspan="1">
	<xref target="RFC5280" format="default" sectionFormat="comma" de rivedContent="RFC5280" section="4.2.1.6" derivedLink="https://rfc-editor.org/rfc /rfc5280#section-4.2.1.6"/> (note that only specific name formats are allowed: U RI, DNS name, email address)</td>		<xref target="RFC5280" sectionFormat="comma" section="4.2.1.6" f ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.6" derivedContent="RFC5280"/> (note that only specific name formats are allowed: U RI, DNS name, email address)</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t indent="0" pn="section-6.5-6">When evaluating a request for an assign ment in this registry, the designated expert should follow this guidance:</t>		<t indent="0" pn="section-6.5-6">When evaluating a request for an assign ment in this registry, the designated expert should follow this guidance:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6 .5-7">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6 .5-7">
	<li pn="section-6.5-7.1">The definition must include a full CDDL defin ition, which the expert will validate.</li>		<li pn="section-6.5-7.1">The definition must include a full CDDL defin ition, which the expert will validate.</li>
	<li pn="section-6.5-7.2">The definition must include both positive and negative test cases.</li>		<li pn="section-6.5-7.2">The definition must include both positive and negative test cases.</li>
	<li pn="section-6.5-7.3">Additional requirements that are not captured by the CDDL definition are allowed but must be explicitly specified.</li>		<li pn="section-6.5-7.3">Additional requirements that are not captured by the CDDL definition are allowed but must be explicitly specified.</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="include" remo veInRFC="false" pn="section-7">		<section anchor="security-considerations" numbered="true" removeInRFC="false " toc="include" pn="section-7">
	<name slugifiedName="name-security-considerations">Security Considerations </name>		<name slugifiedName="name-security-considerations">Security Considerations </name>
	<section anchor="sec-trust-model" numbered="true" toc="include" removeInRF C="false" pn="section-7.1">		<section anchor="sec-trust-model" numbered="true" removeInRFC="false" toc= "include" pn="section-7.1">
	<name slugifiedName="name-trust-model">Trust Model</name>		<name slugifiedName="name-trust-model">Trust Model</name>
	<t indent="0" pn="section-7.1-1">The ACME trust model needs to be extend ed to include the trust relationship		<t indent="0" pn="section-7.1-1">The ACME trust model needs to be extend ed to include the trust relationship
	between NDC and IdO. Note that once this trust link is established, it		between NDC and IdO. Note that once this trust link is established, it
	potentially becomes recursive. Therefore, there has to be a trust relationship		potentially becomes recursive. Therefore, there has to be a trust relationship
	between each of the nodes in the delegation chain; for example, in case of		between each of the nodes in the delegation chain; for example, in case of
	cascading CDNs, this is contractually defined. Note that when using standard		cascading CDNs, this is contractually defined. Note that when using standard
	<xref target="RFC6125" format="default" sectionFormat="of" derivedContent="RFC61 25"/> identity verification, there are no mechanisms available to the IdO		<xref target="RFC6125" format="default" sectionFormat="of" derivedContent="RFC61 25"/> identity verification, there are no mechanisms available to the IdO
	to restrict the use of the delegated name once the name has been handed over to		to restrict the use of the delegated name once the name has been handed over to
	the first NDC. It is, therefore, expected that contractual measures are in plac e		the first NDC. It is, therefore, expected that contractual measures are in plac e
	to get some assurance that redelegation is not being performed.</t>		to get some assurance that redelegation is not being performed.</t>
	</section>		</section>
	<section anchor="delegation-security-goal" numbered="true" toc="include" r emoveInRFC="false" pn="section-7.2">		<section anchor="delegation-security-goal" numbered="true" removeInRFC="fa lse" toc="include" pn="section-7.2">
	<name slugifiedName="name-delegation-security-goal">Delegation Security Goal</name>		<name slugifiedName="name-delegation-security-goal">Delegation Security Goal</name>
	<t indent="0" pn="section-7.2-1">Delegation introduces a new security go al: only an NDC that has been authorized		<t indent="0" pn="section-7.2-1">Delegation introduces a new security go al: only an NDC that has been authorized
	by the IdO, either directly or transitively, can obtain a certificate with an		by the IdO, either directly or transitively, can obtain a certificate with an
	IdO identity.</t>		IdO identity.</t>
	<t indent="0" pn="section-7.2-2">From a security point of view, the dele gation process has five separate parts:</t>		<t indent="0" pn="section-7.2-2">From a security point of view, the dele gation process has five separate parts:</t>
	<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.		<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-7.
	2-3">		2-3">
	<li pn="section-7.2-3.1" derivedCounter="1.">enabling a specific third		<li derivedCounter="1." pn="section-7.2-3.1">enabling a specific third
	party (the intended NDC) to submit requests for		party (the intended NDC) to submit requests for
	delegated certificates</li>		delegated certificates</li>
	<li pn="section-7.2-3.2" derivedCounter="2.">making sure that any requ est for a delegated certificate matches the		<li derivedCounter="2." pn="section-7.2-3.2">making sure that any requ est for a delegated certificate matches the
	intended "shape" in terms of delegated identities as well as any other		intended "shape" in terms of delegated identities as well as any other
	certificate metadata, e.g., key length, x.509 extensions, etc.</li>		certificate metadata, e.g., key length, x.509 extensions, etc.</li>
	<li pn="section-7.2-3.3" derivedCounter="3.">serving the certificate b		<li derivedCounter="3." pn="section-7.2-3.3">serving the certificate b
	ack to the NDC</li>		ack to the NDC</li>
	<li pn="section-7.2-3.4" derivedCounter="4.">handling revocation of th		<li derivedCounter="4." pn="section-7.2-3.4">handling revocation of th
	e delegation</li>		e delegation</li>
	<li pn="section-7.2-3.5" derivedCounter="5.">handling revocation of th		<li derivedCounter="5." pn="section-7.2-3.5">handling revocation of th
	e certificate itself</li>		e certificate itself</li>
	</ol>		</ol>
	<t indent="0" pn="section-7.2-4">The first part is covered by the NDC's ACME account that is administered by the		<t indent="0" pn="section-7.2-4">The first part is covered by the NDC's ACME account that is administered by the
	IdO, whose security relies on the correct handling of the associated key pair.		IdO, whose security relies on the correct handling of the associated key pair.
	When a compromise of the private key is detected, the delegate <bcp14>MUST</bcp1 4> use the		When a compromise of the private key is detected, the delegate <bcp14>MUST</bcp1 4> use the
	account deactivation procedures defined in <xref target="RFC8555" format="defaul t" sectionFormat="of" derivedContent="RFC8555" section="7.3.6" derivedLink="http s://rfc-editor.org/rfc/rfc8555#section-7.3.6"/>.</t>		account deactivation procedures defined in <xref target="RFC8555" section="7.3.6 " format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rf c8555#section-7.3.6" derivedContent="RFC8555"/>.</t>
	<t indent="0" pn="section-7.2-5">The second part is covered by the act o f checking an NDC's certificate request		<t indent="0" pn="section-7.2-5">The second part is covered by the act o f checking an NDC's certificate request
	against the intended CSR template. The steps of shaping the CSR template		against the intended CSR template. The steps of shaping the CSR template
	correctly, selecting the right CSR template to check against the presented CSR,		correctly, selecting the right CSR template to check against the presented CSR,
	and making sure that the presented CSR matches the selected CSR template are		and making sure that the presented CSR matches the selected CSR template are
	all security relevant.</t>		all security relevant.</t>
	<t indent="0" pn="section-7.2-6">The third part builds on the trust rela tionship between NDC and IdO that is		<t indent="0" pn="section-7.2-6">The third part builds on the trust rela tionship between NDC and IdO that is
	responsible for correctly forwarding the certificate URL from the Order		responsible for correctly forwarding the certificate URL from the Order
	returned by the CA.</t>		returned by the CA.</t>
	<t indent="0" pn="section-7.2-7">The fourth part is associated with the ability of the IdO to unilaterally		<t indent="0" pn="section-7.2-7">The fourth part is associated with the ability of the IdO to unilaterally
	remove the <tt>delegation</tt> object associated with the revoked identity, ther efore,		remove the <tt>delegation</tt> object associated with the revoked identity, ther efore,
	disabling any further NDC requests for such identity. Note that, in more		disabling any further NDC requests for such identity. Note that, in more
	extreme circumstances, the IdO might decide to disable the NDC account,		extreme circumstances, the IdO might decide to disable the NDC account,
	thus entirely blocking any further interaction.</t>		thus entirely blocking any further interaction.</t>
	<t indent="0" pn="section-7.2-8">The fifth is covered by two different m echanisms, depending on the nature of		<t indent="0" pn="section-7.2-8">The fifth is covered by two different m echanisms, depending on the nature of
	the certificate. For STAR, the IdO shall use the cancellation interface		the certificate. For STAR, the IdO shall use the cancellation interface
	defined in <xref target="RFC8739" format="default" sectionFormat="of" derivedCon		defined in <xref target="RFC8739" section="2.3" format="default" sectionFormat="
	tent="RFC8739" section="2.3" derivedLink="https://rfc-editor.org/rfc/rfc8739#sec		of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-2.3" derivedContent=
	tion-2.3"/>. For non-STAR, the certificate revocation		"RFC8739"/>. For non-STAR, the certificate revocation
	interface defined in <xref target="RFC8555" format="default" sectionFormat="of"		interface defined in <xref target="RFC8555" section="7.6" format="default" secti
	derivedContent="RFC8555" section="7.6" derivedLink="https://rfc-editor.org/rfc/r		onFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.6" deriv
	fc8555#section-7.6"/>) is used.</t>		edContent="RFC8555"/>) is used.</t>
	<t indent="0" pn="section-7.2-9">The ACME account associated with the de legation plays a crucial role in the		<t indent="0" pn="section-7.2-9">The ACME account associated with the de legation plays a crucial role in the
	overall security of the presented protocol. This, in turn, means that (in		overall security of the presented protocol. This, in turn, means that (in
	delegation scenarios) the security requirements and verification associated with		delegation scenarios) the security requirements and verification associated with
	an ACME account may be more stringent than in base ACME deployments, since the		an ACME account may be more stringent than in base ACME deployments, since the
	out-of-band configuration of delegations that an account is authorized to use		out-of-band configuration of delegations that an account is authorized to use
	(combined with account authentication) takes the place of the normal ACME		(combined with account authentication) takes the place of the normal ACME
	authorization challenge procedures. Therefore, the IdO <bcp14>MUST</bcp14> ensu re that		authorization challenge procedures. Therefore, the IdO <bcp14>MUST</bcp14> ensu re that
	each account is associated with the exact policies (via their matching <tt>deleg ation</tt> objects)		each account is associated with the exact policies (via their matching <tt>deleg ation</tt> objects)
	that define which domain names can be delegated to the account and how.		that define which domain names can be delegated to the account and how.
	The IdO is expected to use out-of-band means to preregister each NDC to		The IdO is expected to use out-of-band means to preregister each NDC to
	the corresponding account.</t>		the corresponding account.</t>
	</section>		</section>
	<section anchor="new-acme-channels" numbered="true" toc="include" removeIn RFC="false" pn="section-7.3">		<section anchor="new-acme-channels" numbered="true" removeInRFC="false" to c="include" pn="section-7.3">
	<name slugifiedName="name-new-acme-channels">New ACME Channels</name>		<name slugifiedName="name-new-acme-channels">New ACME Channels</name>
	<t indent="0" pn="section-7.3-1">Using the model established in <xref ta rget="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555" sect ion="10.1" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.1"/>, we c an decompose		<t indent="0" pn="section-7.3-1">Using the model established in <xref ta rget="RFC8555" section="10.1" format="default" sectionFormat="of" derivedLink="h ttps://rfc-editor.org/rfc/rfc8555#section-10.1" derivedContent="RFC8555"/>, we c an decompose
	the interactions of the basic delegation workflow, as shown in		the interactions of the basic delegation workflow, as shown in
	<xref target="fig-sec-channels" format="default" sectionFormat="of" derivedConte nt="Figure 14"/>.</t>		<xref target="fig-sec-channels" format="default" sectionFormat="of" derivedConte nt="Figure 14"/>.</t>
	<figure anchor="fig-sec-channels" align="left" suppress-title="false" pn ="figure-14">		<figure anchor="fig-sec-channels" align="left" suppress-title="false" pn ="figure-14">
	<name slugifiedName="name-delegation-channels-topolog">Delegation Chan nels Topology</name>		<name slugifiedName="name-delegation-channels-topolog">Delegation Chan nels Topology</name>
	<artset pn="section-7.3-2.1">		<artset pn="section-7.3-2.1">
	<artwork type="svg" name="" align="left" alt="" pn="section-7.3-2.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 756.0 345.0">		<artwork type="svg" name="" alt="" align="left" pn="section-7.3-2.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 756.0 345.0">
	<g transform="translate(8,16)">		<g transform="translate(8,16)">
	<path d="M 0,16 L 48,16" fill="none" stroke="black"/>		<path d="M 0,16 L 48,16" fill="none" stroke="black"/>
	<path d="M 168,16 L 240,16" fill="none" stroke="black"/>		<path d="M 168,16 L 240,16" fill="none" stroke="black"/>
	<path d="M 48,32 L 160,32" fill="none" stroke="black"/>		<path d="M 48,32 L 160,32" fill="none" stroke="black"/>
	<path d="M 0,48 L 24,48" fill="none" stroke="black"/>		<path d="M 0,48 L 24,48" fill="none" stroke="black"/>
	<path d="M 24,48 L 48,48" fill="none" stroke="black"/>		<path d="M 24,48 L 48,48" fill="none" stroke="black"/>
	<path d="M 168,64 L 192,64" fill="none" stroke="black"/>		<path d="M 168,64 L 192,64" fill="none" stroke="black"/>
	<path d="M 192,64 L 240,64" fill="none" stroke="black"/>		<path d="M 192,64 L 240,64" fill="none" stroke="black"/>
	<path d="M 216,112 L 320,112" fill="none" stroke="black"/>		<path d="M 216,112 L 320,112" fill="none" stroke="black"/>
	<path d="M 320,112 L 432,112" fill="none" stroke="black"/>		<path d="M 320,112 L 432,112" fill="none" stroke="black"/>
	skipping to change at line 2997 ¶		skipping to change at line 2997 ¶
	<text text-anchor="middle" font-family="monospace" x="32" y="3 6" fill="black" font-size="1em">C</text>		<text text-anchor="middle" font-family="monospace" x="32" y="3 6" fill="black" font-size="1em">C</text>
	<text text-anchor="middle" font-family="monospace" x="208" y=" 260" fill="black" font-size="1em">C</text>		<text text-anchor="middle" font-family="monospace" x="208" y=" 260" fill="black" font-size="1em">C</text>
	<text text-anchor="middle" font-family="monospace" x="216" y=" 292" fill="black" font-size="1em">c</text>		<text text-anchor="middle" font-family="monospace" x="216" y=" 292" fill="black" font-size="1em">c</text>
	<text text-anchor="middle" font-family="monospace" x="32" y="3 08" fill="black" font-size="1em">r</text>		<text text-anchor="middle" font-family="monospace" x="32" y="3 08" fill="black" font-size="1em">r</text>
	<text text-anchor="middle" font-family="monospace" x="224" y=" 52" fill="black" font-size="1em">r</text>		<text text-anchor="middle" font-family="monospace" x="224" y=" 52" fill="black" font-size="1em">r</text>
	<text text-anchor="middle" font-family="monospace" x="344" y=" 228" fill="black" font-size="1em">C</text>		<text text-anchor="middle" font-family="monospace" x="344" y=" 228" fill="black" font-size="1em">C</text>
	<text text-anchor="middle" font-family="monospace" x="224" y=" 260" fill="black" font-size="1em">E</text>		<text text-anchor="middle" font-family="monospace" x="224" y=" 260" fill="black" font-size="1em">E</text>
	</g>		</g>
	</svg>		</svg>
	</artwork>		</artwork>
	<artwork type="ascii-art" name="" align="left" alt="" pn="section-7. 3-2.1.2">		<artwork type="ascii-art" name="" alt="" align="left" pn="section-7. 3-2.1.2">
	.-----. ACME Channel .--------.		.-----. ACME Channel .--------.
	| NDC +-------------&gt;| IdO |		| NDC +-------------&gt;| IdO |
	'--+--' | server |		'--+--' | server |
	| '--o-----'		| '--o-----'
	| |		| |
	| | ACME Channel		| | ACME Channel
	| | .------------&gt;-------------.		| | .------------&gt;-------------.
	| | | |		| | | |
	| .--o--+--. .--+---.		| .--o--+--. .--+---.
	| | IdO | | CA |		| | IdO | | CA |
	skipping to change at line 3029 ¶		skipping to change at line 3029 ¶
	</artset>		</artset>
	</figure>		</figure>
	<t indent="0" pn="section-7.3-3">The considerations regarding the securi ty of the ACME Channel and Validation		<t indent="0" pn="section-7.3-3">The considerations regarding the securi ty of the ACME Channel and Validation
	Channel discussed in <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> apply verbatim to the IdO-CA leg.		Channel discussed in <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> apply verbatim to the IdO-CA leg.
	The same can be said for the ACME Channel on the NDC-IdO leg. A slightly		The same can be said for the ACME Channel on the NDC-IdO leg. A slightly
	different set of considerations apply to the ACME Channel between the NDC and CA ,		different set of considerations apply to the ACME Channel between the NDC and CA ,
	which consists of a subset of the ACME interface comprising two API		which consists of a subset of the ACME interface comprising two API
	endpoints: the unauthenticated certificate retrieval and, potentially, non-STAR		endpoints: the unauthenticated certificate retrieval and, potentially, non-STAR
	revocation via certificate private key. No specific security considerations		revocation via certificate private key. No specific security considerations
	apply to the former, but the privacy considerations in		apply to the former, but the privacy considerations in
	<xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RFC87 39" section="6.3" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-6.3"/> do. With regard to the latter, it should be noted that there is		<xref target="RFC8739" section="6.3" format="default" sectionFormat="of" derived Link="https://rfc-editor.org/rfc/rfc8739#section-6.3" derivedContent="RFC8739"/> do. With regard to the latter, it should be noted that there is
	currently no means for an IdO to disable authorizing revocation based on		currently no means for an IdO to disable authorizing revocation based on
	certificate private keys. So, in theory, an NDC could use the revocation API		certificate private keys. So, in theory, an NDC could use the revocation API
	directly with the CA, therefore, bypassing the IdO. The NDC <bcp14>SHOULD NOT</ bcp14>		directly with the CA, therefore, bypassing the IdO. The NDC <bcp14>SHOULD NOT</ bcp14>
	directly use the revocation interface exposed by the CA unless failing		directly use the revocation interface exposed by the CA unless failing
	to do so would compromise the overall security, for example, if the certificate		to do so would compromise the overall security, for example, if the certificate
	private key is compromised and the IdO is not currently reachable.</t>		private key is compromised and the IdO is not currently reachable.</t>
	<t indent="0" pn="section-7.3-4">All other security considerations from <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC85 55"/> and <xref target="RFC8739" format="default" sectionFormat="of" derivedCont ent="RFC8739"/> apply		<t indent="0" pn="section-7.3-4">All other security considerations from <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC85 55"/> and <xref target="RFC8739" format="default" sectionFormat="of" derivedCont ent="RFC8739"/> apply
	as is to the delegation topology.</t>		as is to the delegation topology.</t>
	</section>		</section>
	<section anchor="restricting-cdns-to-the-delegation-mechanism" numbered="t rue" toc="include" removeInRFC="false" pn="section-7.4">		<section anchor="restricting-cdns-to-the-delegation-mechanism" numbered="t rue" removeInRFC="false" toc="include" pn="section-7.4">
	<name slugifiedName="name-restricting-cdns-to-the-del">Restricting CDNs to the Delegation Mechanism</name>		<name slugifiedName="name-restricting-cdns-to-the-del">Restricting CDNs to the Delegation Mechanism</name>
	<t indent="0" pn="section-7.4-1">When a website is delegated to a CDN, t he CDN can in principle modify the website at will, e.g., create and remove page s. This means that a malicious or breached		<t indent="0" pn="section-7.4-1">When a website is delegated to a CDN, t he CDN can in principle modify the website at will, e.g., create and remove page s. This means that a malicious or breached
	CDN can pass the ACME (as well as common non-ACME) HTTPS-based validation		CDN can pass the ACME (as well as common non-ACME) HTTPS-based validation
	challenges and generate a certificate for the site. This is true regardless of		challenges and generate a certificate for the site. This is true regardless of
	whether or not the CNAME mechanisms defined in the current document is used.</t>		whether or not the CNAME mechanisms defined in the current document is used.</t>
	<t indent="0" pn="section-7.4-2">In some cases, this is the desired beha vior; the domain holder trusts the CDN to		<t indent="0" pn="section-7.4-2">In some cases, this is the desired beha vior; the domain holder trusts the CDN to
	have full control of the cryptographic credentials for the site. However, this		have full control of the cryptographic credentials for the site. However, this
	document assumes a scenario where the domain holder only wants to delegate		document assumes a scenario where the domain holder only wants to delegate
	restricted control and wishes to retain the capability to cancel the CDN's		restricted control and wishes to retain the capability to cancel the CDN's
	credentials at a short notice.</t>		credentials at a short notice.</t>
	<t indent="0" pn="section-7.4-3">The following is a possible mitigation when the IdO wishes to ensure that a		<t indent="0" pn="section-7.4-3">The following is a possible mitigation when the IdO wishes to ensure that a
	rogue CDN cannot issue unauthorized certificates:</t>		rogue CDN cannot issue unauthorized certificates:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7 .4-4">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7 .4-4">
	<li pn="section-7.4-4.1">The domain holder makes sure that the CDN can not modify the DNS records for		<li pn="section-7.4-4.1">The domain holder makes sure that the CDN can not modify the DNS records for
	the domain. The domain holder should ensure it is the only entity authorized		the domain. The domain holder should ensure it is the only entity authorized
	to modify the DNS zone. Typically, it establishes a CNAME resource record		to modify the DNS zone. Typically, it establishes a CNAME resource record
	from a subdomain into a CDN-managed domain.</li>		from a subdomain into a CDN-managed domain.</li>
	<li pn="section-7.4-4.2">The domain holder uses a Certification Author ity Authorization (CAA) record <xref target="RFC8659" format="default" sectionFo rmat="of" derivedContent="RFC8659"/> to restrict certificate		<li pn="section-7.4-4.2">The domain holder uses a Certification Author ity Authorization (CAA) record <xref target="RFC8659" format="default" sectionFo rmat="of" derivedContent="RFC8659"/> to restrict certificate
	issuance for the domain to specific CAs that comply with ACME and are known		issuance for the domain to specific CAs that comply with ACME and are known
	to implement <xref target="RFC8657" format="default" sectionFormat="of" derivedC ontent="RFC8657"/>.</li>		to implement <xref target="RFC8657" format="default" sectionFormat="of" derivedC ontent="RFC8657"/>.</li>
	<li pn="section-7.4-4.3">The domain holder uses the ACME-specific CAA mechanism <xref target="RFC8657" format="default" sectionFormat="of" derivedCont ent="RFC8657"/> to		<li pn="section-7.4-4.3">The domain holder uses the ACME-specific CAA mechanism <xref target="RFC8657" format="default" sectionFormat="of" derivedCont ent="RFC8657"/> to
	restrict issuance to a specific CA account that is controlled by it and		restrict issuance to a specific CA account that is controlled by it and
	<bcp14>MUST</bcp14> require "dns-01" as the sole validation method.</li>		<bcp14>MUST</bcp14> require "dns-01" as the sole validation method.</li>
	skipping to change at line 3498 ¶		skipping to change at line 3498 ¶
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-acme-authority-tok en-tnauthlist-08"/>		<seriesInfo name="Internet-Draft" value="draft-ietf-acme-authority-tok en-tnauthlist-08"/>
	<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf- acme-authority-token-tnauthlist-08.txt"/>		<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf- acme-authority-token-tnauthlist-08.txt"/>
	<refcontent>Work in Progress</refcontent>		<refcontent>Work in Progress</refcontent>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="csr-template-schema-cddl" numbered="true" toc="include" rem oveInRFC="false" pn="section-appendix.a">		<section anchor="csr-template-schema-cddl" numbered="true" removeInRFC="fals e" toc="include" pn="section-appendix.a">
	<name slugifiedName="name-csr-template-cddl">CSR Template: CDDL</name>		<name slugifiedName="name-csr-template-cddl">CSR Template: CDDL</name>
	<t indent="0" pn="section-appendix.a-1">Following is the normative definit ion of the CSR template using CDDL <xref target="RFC8610" format="default" secti onFormat="of" derivedContent="RFC8610"/>. The CSR template <bcp14>MUST</bcp14> b e a valid JSON document that is compliant with the syntax defined here.</t>		<t indent="0" pn="section-appendix.a-1">Following is the normative definit ion of the CSR template using CDDL <xref target="RFC8610" format="default" secti onFormat="of" derivedContent="RFC8610"/>. The CSR template <bcp14>MUST</bcp14> b e a valid JSON document that is compliant with the syntax defined here.</t>
	<t indent="0" pn="section-appendix.a-2">There are additional constraints n ot expressed in CDDL that <bcp14>MUST</bcp14> be validated		<t indent="0" pn="section-appendix.a-2">There are additional constraints n ot expressed in CDDL that <bcp14>MUST</bcp14> be validated
	by the recipient, including:</t>		by the recipient, including:</t>
	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app endix.a-3">		<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-app endix.a-3">
	<li pn="section-appendix.a-3.1">the value of each <tt>subjectAltName</tt > entry is compatible with its type and</li>		<li pn="section-appendix.a-3.1">the value of each <tt>subjectAltName</tt > entry is compatible with its type and</li>
	<li pn="section-appendix.a-3.2">the parameters in each <tt>keyTypes</tt> entry form an acceptable combination.</li>		<li pn="section-appendix.a-3.2">the parameters in each <tt>keyTypes</tt> entry form an acceptable combination.</li>
	</ul>		</ul>
	<sourcecode name="" type="cddl" pn="section-appendix.a-4" markers="false">		<sourcecode name="" type="cddl" markers="false" pn="section-appendix.a-4">
	csr-template-schema = {		csr-template-schema = {
	keyTypes: [ + $keyType ]		keyTypes: [ + $keyType ]
	? subject: non-empty&lt;distinguishedName&gt;		? subject: non-empty&lt;distinguishedName&gt;
	extensions: extensions		extensions: extensions
	}		}
	non-empty&lt;M&gt; = (M) .and ({ + any =&gt; any })		non-empty&lt;M&gt; = (M) .and ({ + any =&gt; any })
	mandatory-wildcard = "**"		mandatory-wildcard = "**"
	optional-wildcard = "*"		optional-wildcard = "*"
	skipping to change at line 3607 ¶		skipping to change at line 3607 ¶
	extendedKeyUsageType /= "clientAuth"		extendedKeyUsageType /= "clientAuth"
	extendedKeyUsageType /= "codeSigning"		extendedKeyUsageType /= "codeSigning"
	extendedKeyUsageType /= "emailProtection"		extendedKeyUsageType /= "emailProtection"
	extendedKeyUsageType /= "timeStamping"		extendedKeyUsageType /= "timeStamping"
	extendedKeyUsageType /= "OCSPSigning"		extendedKeyUsageType /= "OCSPSigning"
	extendedKeyUsageType /= oid		extendedKeyUsageType /= oid
	oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"		oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"
	</sourcecode>		</sourcecode>
	</section>		</section>
	<section anchor="csr-template-schema" numbered="true" toc="include" removeIn RFC="false" pn="section-appendix.b">		<section anchor="csr-template-schema" numbered="true" removeInRFC="false" to c="include" pn="section-appendix.b">
	<name slugifiedName="name-csr-template-json-schema">CSR Template: JSON Sch ema</name>		<name slugifiedName="name-csr-template-json-schema">CSR Template: JSON Sch ema</name>
	<t indent="0" pn="section-appendix.b-1">This appendix includes an alternat ive, nonnormative JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in <xref target="I-D.handre ws-json-schema-validation" format="default" sectionFormat="of" derivedContent="j son-schema-07"/>. Note that later versions of this (now-expired) draft describe later versions of the JSON Schema syntax. At the time of writing, a stable refer ence for this syntax is not yet available, and we have chosen to use the draft v ersion, which is currently best supported by tool implementations.</t>		<t indent="0" pn="section-appendix.b-1">This appendix includes an alternat ive, nonnormative JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in <xref target="I-D.handre ws-json-schema-validation" format="default" sectionFormat="of" derivedContent="j son-schema-07"/>. Note that later versions of this (now-expired) draft describe later versions of the JSON Schema syntax. At the time of writing, a stable refer ence for this syntax is not yet available, and we have chosen to use the draft v ersion, which is currently best supported by tool implementations.</t>
	<t indent="0" pn="section-appendix.b-2">The same considerations about addi tional constraints checking discussed in		<t indent="0" pn="section-appendix.b-2">The same considerations about addi tional constraints checking discussed in
	<xref target="csr-template-schema-cddl" format="default" sectionFormat="of" deri vedContent="Appendix A"/> apply here as well.</t>		<xref target="csr-template-schema-cddl" format="default" sectionFormat="of" deri vedContent="Appendix A"/> apply here as well.</t>
	<sourcecode name="" type="json" pn="section-appendix.b-3" markers="false">		<sourcecode name="" type="json" markers="false" pn="section-appendix.b-3">
	{		{
	"title": "JSON Schema for the STAR Delegation CSR template",		"title": "JSON Schema for the STAR Delegation CSR template",
	"$schema": "http://json-schema.org/draft-07/schema#",		"$schema": "http://json-schema.org/draft-07/schema#",
	"$id": "http://ietf.org/acme/drafts/star-delegation/csr-template",		"$id": "http://ietf.org/acme/drafts/star-delegation/csr-template",
	"$defs": {		"$defs": {
	"distinguished-name": {		"distinguished-name": {
	"$id": "#distinguished-name",		"$id": "#distinguished-name",
	"type": "object",		"type": "object",
	"minProperties": 1,		"minProperties": 1,
	"properties": {		"properties": {
	skipping to change at line 3831 ¶		skipping to change at line 3831 ¶
	}		}
	},		},
	"required": [		"required": [
	"extensions",		"extensions",
	"keyTypes"		"keyTypes"
	],		],
	"additionalProperties": false		"additionalProperties": false
	}		}
	</sourcecode>		</sourcecode>
	</section>		</section>
	<section anchor="acknowledgements" numbered="false" toc="include" removeInRF C="false" pn="section-appendix.c">		<section anchor="acknowledgements" numbered="false" removeInRFC="false" toc= "include" pn="section-appendix.c">
	<name slugifiedName="name-acknowledgements">Acknowledgements</name>		<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	<t indent="0" pn="section-appendix.c-1">We would like to thank the followi ng people who contributed significantly to this document with their review comme nts and design proposals: <contact fullname="Richard Barnes"/>, <contact fullnam e="Carsten Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="L ars Eggert"/>, <contact fullname="Frédéric Fieau"/>, <contact fullname="Russ Hou sley"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Eric Kline"/>, <con tact fullname="Sanjay Mishra"/>, <contact fullname="Francesca Palombini"/>, <con tact fullname="Jon Peterson"/>, <contact fullname="Ryan Sleevi"/>, <contact full name="Emile Stephan"/>, and <contact fullname="Éric Vyncke"/>.</t>		<t indent="0" pn="section-appendix.c-1">We would like to thank the followi ng people who contributed significantly to this document with their review comme nts and design proposals: <contact fullname="Richard Barnes"/>, <contact fullnam e="Carsten Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="L ars Eggert"/>, <contact fullname="Frédéric Fieau"/>, <contact fullname="Russ Hou sley"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Eric Kline"/>, <con tact fullname="Sanjay Mishra"/>, <contact fullname="Francesca Palombini"/>, <con tact fullname="Jon Peterson"/>, <contact fullname="Ryan Sleevi"/>, <contact full name="Emile Stephan"/>, and <contact fullname="Éric Vyncke"/>.</t>
	<t indent="0" pn="section-appendix.c-2">This work is partially supported b y the European Commission under Horizon 2020		<t indent="0" pn="section-appendix.c-2">This work is partially supported b y the European Commission under Horizon 2020
	grant agreement no. 688421 Measurement and Architecture for a Middleboxed		grant agreement no. 688421 Measurement and Architecture for a Middleboxed
	Internet (MAMI). This support does not imply endorsement.</t>		Internet (MAMI). This support does not imply endorsement.</t>
	</section>		</section>
	<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc ="include" pn="section-appendix.d">		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc ="include" pn="section-appendix.d">
	<name slugifiedName="name-authors-addresses">Authors' Addresses</name>		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
	<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">		<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
	<organization showOnFrontPage="true">Intuit</organization>		<organization showOnFrontPage="true">Intuit</organization>
End of changes. 129 change blocks.
	163 lines changed or deleted		164 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/