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/