Movatterモバイル変換

[0]ホーム
URL:

 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" consensus="true" docName="draft-ietf-acme-star-delegation-09" indexInclude="true" ipr="trust200902" number="9115" prepTime="2021-06-11T11:25:00" scripts="Common,Latin" 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" consensus="true" docName="draft-ietf-acme-star-delegation-09" indexInclude="true" ipr="trust200902" number="9115" prepTime="2021-09-20T12:02:22" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation-09" rel="prev"/> <link href="https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation-09" 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 Environment (ACME) Profile for Generating Delegated Certificates</title> <title abbrev="ACME Delegation">An Automatic Certificate Management Environment (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 55skipping to change at line 55
terminating TLS sessions on behalf of a content provider (the holder of a domainterminating TLS sessions on behalf of a content provider (the holder of a domain
name). The presented mechanism allows the holder of the identifier to retainname). The presented mechanism allows the holder of the identifier to retain
control over the delegation and revoke it at any time. Importantly, thiscontrol over the delegation and revoke it at any time. Importantly, this
mechanism does not require any modification to the deployed TLSmechanism 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
<ereftarget="http://www.rfc-editor.org/info/rfc9115" brackets="none"/>. <ereftarget="https://www.rfc-editor.org/info/rfc9115" brackets="non
e"/>.
</t> </t>
</section> </section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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 121skipping 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"/>.  <xref derivedContent="" format="title" sectionFormat="of">Overview</xref></t> <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Overview</xref></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"/>.  <xref derivedContent="" format="title" sectionFormat="of">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"/>.  <xref derivedContent="" format="title" sectionFormat="of">Delegated Identity Profile</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.3.2"> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="2.3.1" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Delegation Configuration</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derivedContent="2.3.1" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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 derivedContent="2.3.2" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Order Object Transmitted from NDC to IdO and to ACME Server (forSTAR)</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derivedContent="2.3.2" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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 derivedContent="2.3.3" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Order Object Transmitted from NDC to IdO and to ACME Server (forNon-STAR)</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.3.1"><xref derivedContent="2.3.3" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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 derivedContent="2.3.4" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Capability Discovery</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.4.1"><xref derivedContent="2.3.4" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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 derivedContent="2.3.5" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Negotiating an Unauthenticated GET</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.5.1"><xref derivedContent="2.3.5" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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 derivedContent="2.3.6" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Terminating the Delegation</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.6.1"><xref derivedContent="2.3.6" format="counter" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Terminating the Delegation</xref></t>
</li> </li>
skipping to change at line 230skipping 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="Appendix A" format="default" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">CSR Template: CDDL</xref></t> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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="Appendix B" format="default" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">CSR Template: JSON Schema</xref></t> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">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="" format="none" sectionFormat="of"/>.  <xref derivedContent="" format="title" sectionFormat="of">Acknowledgements</xref></t> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of"/><xref derivedContent="" format="title" sectionFormat="of">Acknowledgements</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="" format="none" sectionFormat="of"/><xref derivedContent="" format="title" sectionFormat="of">Authors' Addresses</xref></t> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of"/><xref derivedContent="" format="title" sectionFormat="of">Authors' Addresses</xref></t>
</li> </li>
</ul> </ul>
</section> </section>
</toc> </toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true"toc="include" removeInRFC="false" pn="section-1"> <section anchor="introduction" numbered="true"removeInRFC="false" toc="include" 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 format="default" sectionFormat="of" derivedContent="RFC8739"/>, in that some important use cases require both documents to be implemented. To avoid duplication, <t indent="0" pn="section-1-1">This document is related to <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>, in that some important use cases require both documents to be implemented. To avoid duplication,
we give here a bare-bones description of the motivation for this solution. Forwe give here a bare-bones description of the motivation for this solution. For
more details, please refer to the introductory sectionsmore details, please refer to the introductory sections
of <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>.</t>of <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>.</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 itsin 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 content provider, and we consider a Content Delivery Network (CDN) provider contracted to <t indent="0" pn="section-1-3">In the primary use case, the IdO is a content provider, and we consider a Content Delivery Network (CDN) provider contracted to
serve the content over HTTPS. The CDN terminates the HTTPS connection atserve the content over HTTPS. The CDN terminates the HTTPS connection at
skipping to change at line 280skipping to change at line 280
case of long-lived certificates, the IdO uses the <tt>revokeCert</tt> URL exposed by thecase of long-lived certificates, the IdO uses the <tt>revokeCert</tt> URL exposed by the
CA and waits for the explicit revocation based on the Certificate RevocationCA and waits for the explicit revocation based on the Certificate Revocation
List (CRL) and Online Certificate Status Protocol (OCSP) to propagate to theList (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 beway 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 athus 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 format="default" sectionFormat="of" derivedContent="TLS-SUBCERTS"/> and <xref format="default" sectionFormat="of" derivedContent="MGLT-LURK-TLS13"/>. The former extends the TLS certificate chain with a customer-owned signing certificate; the latter separates 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 format="default" sectionFormat="of" derivedContent="TLS-SUBCERTS"/> and <xref format="default" sectionFormat="of" derivedContent="MGLT-LURK-TLS13"/>. The former extends the TLS certificate chain with a customer-owned signing certificate; the latter separates 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="false" pn="section-1.1"> <section anchor="terminology" numbered="true"removeInRFC="false" toc="include" 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 (current owner) of an identifier (e.g., a domain <t indent="0" pn="section-1.1-1.2.1">Identifier Owner, the holder (current owner) of an identifier (e.g., a domain
name) that needs to be delegated. Depending on the context, the term IdO mayname) 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 Identifieralso 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 328skipping 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, specifically a PKCS#10 <xref 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, specifically a PKCS#10 <xref 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="include" removeInRFC="false" pn="section-1.2"> <section anchor="conventions-used-in-this-document" numbered="true"removeInRFC="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</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, theydescribed in BCP 14 <xref format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref 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" removeInRFC="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. For completeness, we include the ACME <t indent="0" pn="section-2-1">This section presents the protocol flow. For completeness, we include the ACME
profile proposed in this document as well as the ACME STAR protocol describedprofile proposed in this document as well as the ACME STAR protocol described
in <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>.</t>in <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>.</t>
<section anchor="proto-preconditions" numbered="true"toc="include" removeInRFC="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 preconditions are met:</t> <t indent="0" pn="section-2.1-1">The protocol assumes the following preconditions are met:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.1-2"> <ulbare="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 the NDC(s) comprising the account <li pn="section-2.1-2.1">The IdO exposes an ACME server interface to the 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 the IdO.</li> <li pn="section-2.1-2.2">The NDC has registered an ACME account with the IdO.</li>
<li pn="section-2.1-2.3">The NDC and IdO have agreed on a "CSR template" to use, including at a minimum: <li pn="section-2.1-2.3">The NDC and IdO have agreed on a "CSR template" to use, including at a minimum:
subject name (e.g., <tt>abc.ido.example</tt>), requested algorithms and keysubject name (e.g., <tt>abc.ido.example</tt>), requested algorithms and key
length, key usage, and extensions. The NDC will uselength, 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 the Certification Authority (CA).</li> <li pn="section-2.1-2.4">The IdO has registered an ACME account with the Certification Authority (CA).</li>
</ul> </ul>
<t indent="0" pn="section-2.1-3">Note that even if the IdO implements the ACME server role, it is not acting as <t indent="0" pn="section-2.1-3">Note that even if the IdO implements the ACME server role, it is not acting as
a CA; in fact, from the point of view of the certificate issuance process, thea 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 isIdO 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="false" pn="section-2.2"> <section anchor="overview" numbered="true"removeInRFC="false" toc="include" 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 presented here covers the main use case of this protocol, <t indent="0" pn="section-2.2-1">For clarity, the protocol overview presented here covers the main use case of this protocol,
namely delegation of STAR certificates. Protocol behavior for non-STAR certificates is similar,namely delegation of STAR certificates. Protocol behavior for non-STAR certificates 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 format="default" sectionFormat="of" derivedContent="Section 2.3"/>. The interaction between the IdO and theworkflow detailed in <xref format="default" sectionFormat="of" derivedContent="Section 2.3"/>. The interaction between the IdO and the
CA is ruled by ACME <xref format="default" sectionFormat="of" derivedContent="RFC8555"/>, ACME STAR <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>, and any other ACME extension thatCA is ruled by ACME <xref format="default" sectionFormat="of" derivedContent="RFC8555"/>, ACME STAR <xref format="default" sectionFormat="of" derivedContent="RFC8739"/>, and any other ACME extension that
applies (e.g., <xref format="default" sectionFormat="of" derivedContent="TOKEN-TNAUTHLIST"/> for Secure Telephone Identity Revisited (STIR)).</t>applies (e.g., <xref format="default" sectionFormat="of" derivedContent="TOKEN-TNAUTHLIST"/> for Secure Telephone Identity Revisited (STIR)).</t>
<t indent="0" pn="section-2.2-3">The outline of the combined protocol for STAR certificates is as follows (<xref format="default" sectionFormat="of" derivedContent="Figure 1"/>):</t> <t indent="0" pn="section-2.2-3">The outline of the combined protocol for STAR certificates is as follows (<xref format="default" sectionFormat="of" derivedContent="Figure 1"/>):</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-4"> <ulbare="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 identifier to IdO.</li> <li pn="section-2.2-4.1">NDC sends an Order1 for the delegated identifier to IdO.</li>
<li pn="section-2.2-4.2">IdO creates an Order1 resource in state <tt>ready</tt> with a <tt>finalize</tt> URL.</li> <li pn="section-2.2-4.2">IdO creates an Order1 resource in state <tt>ready</tt> with a <tt>finalize</tt> URL.</li>
<li pn="section-2.2-4.3">NDC immediately sends a <tt>finalize</tt> request (which includes the CSR) to the IdO.</li> <li pn="section-2.2-4.3">NDC immediately sends a <tt>finalize</tt> request (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 moved to an <tt>invalid</tt> state and <li pn="section-2.2-4.5">If the CSR verification fails, Order1 is moved 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 moves Order1 to state <li pn="section-2.2-4.6">If the CSR verification is successful, IdO moves Order1 to state
<tt>processing</tt> and sends a new Order2 (using its own account) for the delegated<tt>processing</tt> and sends a new Order2 (using its own account) for the delegated
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., Order2 is <tt>valid</tt>), IdO copies the <li pn="section-2.2-4.8">If the ACME STAR run is successful (i.e., Order2 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 certificate 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 subsequent certificates until either Order1 expires or the IdO decides to cancel the 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 certificate 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 subsequent certificates until either Order1 expires or the IdO decides to cancel the automatic renewal process with the CA.</t>
<t indent="0" pn="section-2.2-6">Note that the interactive identifier authorization phase described in <xrefformat="default" sectionFormat="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 delegated <t indent="0" pn="section-2.2-6">Note that the interactive identifier authorization phase described in <xrefsection="7.5" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.5" derivedContent="RFC8555"/> is suppressed on the NDC-IdO side because the delegated
identity contained in the CSR presented to the IdO is validated against theidentity contained in the CSR presented to the IdO is validated against the
configured CSR template (<xref format="default" sectionFormat="of" derivedContent="Section 4.1"/>). Therefore, the NDCconfigured CSR template (<xref format="default" sectionFormat="of" derivedContent="Section 4.1"/>). Therefore, the NDC
sends the <tt>finalize</tt> request, including the CSR, to the IdO immediately aftersends the <tt>finalize</tt> request, including the CSR, to the IdO immediately after
Order1 has been acknowledged. The IdO <bcp14>SHALL</bcp14> buffer a (valid) CSR until theOrder1 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 negotiation of the unauthenticated GET (<xrefformat="default" sectionFormat="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 negotiation of the unauthenticated GET (<xrefsection="3.4" format="default" 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="figure-1"> <figure anchor="fig-endtoend" align="left" suppress-title="false" pn="figure-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" 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" 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 904skipping 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 960skipping 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="false" pn="section-2.3"> <section anchor="sec-profile" numbered="true"removeInRFC="false" toc="include" 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 ACME protocol to be used between the NDC <t indent="0" pn="section-2.3-1">This section defines a profile of the ACME 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="false" toc="include" pn="section-2.3.1">
<name slugifiedName="name-delegation-configuration">Delegation Configuration</name> <name slugifiedName="name-delegation-configuration">Delegation Configuration</name>
<t indent="0" pn="section-2.3.1-1">The IdO must be preconfigured to recognize one or more NDCs and present them with <t indent="0" pn="section-2.3.1-1">The IdO must be preconfigured to recognize 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="exclude" removeInRFC="false" pn="section-2.3.1.1"> <section anchor="account-object-extensions" numbered="true"removeInRFC="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 throughmultiple 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 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 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>
<dlnewline="false" spacing="normal" pn="section-2.3.1.1-3" indent="3"> <dlindent="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 delegations <dd pn="section-2.3.1.1-3.2">A URL from which a list of delegations
configured for this account (<xref format="default" sectionFormat="of" derivedContent="Section 2.3.1.3"/>) can be fetched via aconfigured for this account (<xref format="default" 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="false" pn="figure-2"> <figure anchor="fig-account-object" align="left" suppress-title="false" pn="figure-2">
<name slugifiedName="name-example-account-object-with">Example Account Object with Delegations</name> <name slugifiedName="name-example-account-object-with">Example Account 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" removeInRFC="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-GETdelegation 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 madefield is an array of URLs, each identifying a delegation configuration made
available to the NDC account (<xref format="default" sectionFormat="of" derivedContent="Section 2.3.1.3"/>). The server <bcp14>MAY</bcp14>available to the NDC account (<xref format="default" 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>next</tt> linkreturn an incomplete list, along with a <tt>Link</tt> header field with a <tt>next</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="false"> <sourcecode name="" type="json"markers="false" pn="section-2.3.1.2-2">
HTTP/1.1 200 OKHTTP/1.1 200 OK
Content-Type: application/jsonContent-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</name> <name slugifiedName="name-delegation-objects">Delegation Objects</name>
<t indent="0" pn="section-2.3.1.3-1">This profile extends the ACME resource model with a new read-only <tt>delegation</tt> <t indent="0" pn="section-2.3.1.3-1">This profile extends the ACME resource 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 contains the CSR template (see <xref format="default" sectionFormat="of" derivedContent="Section 4"/>) that <t indent="0" pn="section-2.3.1.3-2">A <tt>delegation</tt> object contains the CSR template (see <xref format="default" sectionFormat="of" derivedContent="Section 4"/>) that
applies to that delegation and, optionally, any related CNAME mapping for theapplies 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>
<dlspacing="normal" newline="false" indent="3" pn="section-2.3.1.3-3"> <dlindent="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 format="default" sectionFormat="of" derivedContent="Section 4"/>.</dd><xref format="default" sectionFormat="of" derivedContent="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, the name is <dd pn="section-2.3.1.3-3.4">A map of FQDN pairs. In each pair, the name is
the delegated identifier; the value is the corresponding NDC name that isthe delegated identifier; the value is the corresponding NDC name that is
aliased in the IdO's zone file to redirect the resolvers to the delegatedaliased 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 format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t><xref format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
<figure anchor="fig-configuration-object" align="left" suppress-title="false" pn="figure-3"> <figure anchor="fig-configuration-object" align="left" suppress-title="false" pn="figure-3">
<name slugifiedName="name-example-delegation-configur">Example Delegation Configuration Object</name> <name slugifiedName="name-example-delegation-configur">Example Delegation 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 1093skipping to change at line 1093
order object on the NDC-IdO side (see Figures <xref format="counter" sectionFormat="of" derivedContent="4"/>order object on the NDC-IdO side (see Figures <xref format="counter" sectionFormat="of" derivedContent="4"/>
and <xref format="counter" sectionFormat="of" derivedContent="7"/>). Theand <xref format="counter" sectionFormat="of" derivedContent="7"/>). The
value of this attribute is the URL pointing to the delegation configurationvalue 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 aattribute in the order object contains a URL that does not correspond to a
configuration available to the requesting ACME account, the IdO <bcp14>MUST</bcp14> return an errorconfiguration available to the requesting ACME account, the IdO <bcp14>MUST</bcp14> return an error
response with status code 403 (Forbidden), providing a problem documentresponse with status code 403 (Forbidden), providing a problem document
<xref format="default" sectionFormat="of" derivedContent="RFC7807"/> with type <tt>urn:ietf:params:acme:error:unknownDelegation</tt>.</t><xref format="default" sectionFormat="of" derivedContent="RFC7807"/> 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="include" removeInRFC="false" pn="section-2.3.2"> <section anchor="sec-profile-star-order-journey" numbered="true"removeInRFC="false" toc="include" pn="section-2.3.2">
<name slugifiedName="name-order-object-transmitted-fr">Order Object Transmitted from NDC to IdO and to ACME Server (STAR)</name> <name slugifiedName="name-order-object-transmitted-fr">Order Object Transmitted 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 certificate, the request object created by the <t indent="0" pn="section-2.3.2-1">If the delegation is for a STAR certificate, the request object created by the
NDC:</t>NDC:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.2-2"> <ulbare="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 indicating the preconfigured delegation <bcp14>MUST</bcp14> have a <tt>delegation</tt> attribute indicating 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>notAfter</tt> fields; and</li> <bcp14>MUST NOT</bcp14> contain the <tt>notBefore</tt> and <tt>notAfter</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, inside it, the fields <bcp14>MUST</bcp14> contain an <tt>auto-renewal</tt> object and, inside it, the fields
listed in <xrefformat="default" sectionFormat="of" derivedContent="RFC8739" section="3.1.1" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.1.1"/>. In particular, thelisted in <xrefsection="3.1.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.1.1" derivedContent="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="false" pn="figure-4"> <figure anchor="fig-star-ndc-neworder" align="left" suppress-title="false" pn="figure-4">
<name slugifiedName="name-new-star-order-from-ndc">New STAR Order from NDC</name> <name slugifiedName="name-new-star-order-from-ndc">New STAR Order from NDC</name>
<sourcecode name="" type="json"pn="section-2.3.2-3.1" markers="false"> <sourcecode name="" type="json"markers="false" pn="section-2.3.2-3.1">
POST /acme/new-order HTTP/1.1POST /acme/new-order HTTP/1.1
Host: acme.ido.exampleHost: acme.ido.example
Content-Type: application/jose+jsonContent-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 1145skipping 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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.2-5"> <ulbare="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> configuration;</li> <bcp14>MUST</bcp14> contain the indicated <tt>delegation</tt> configuration;</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> settings; and</li> <bcp14>MUST</bcp14> contain the indicated <tt>auto-renewal</tt> settings; 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>notAfter</tt> fields.</li> <bcp14>MUST NOT</bcp14> contain the <tt>notBefore</tt> and <tt>notAfter</tt> fields.</li>
</ul> </ul>
<figure anchor="fig-star-ido-order-resource-created" align="left" suppress-title="false" pn="figure-5"> <figure anchor="fig-star-ido-order-resource-created" align="left" suppress-title="false" pn="figure-5">
<name slugifiedName="name-star-order-resource-created">STAR Order Resource Created on IdO</name> <name slugifiedName="name-star-order-resource-created">STAR Order Resource Created on IdO</name>
<sourcecode name="" type="json"pn="section-2.3.2-6.1" markers="false"> <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 1192skipping 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 templatedelegated identifiers. The IdO checks the provided CSR against the template
contained in the <tt>delegation</tt> object that applies to this request, as described incontained in the <tt>delegation</tt> object that applies to this request, as described in
<xref format="default" sectionFormat="of" derivedContent="Section 4.1"/>. If the CSR fails validation for any of the<xref format="default" sectionFormat="of" derivedContent="Section 4.1"/>. If the CSR fails validation for any of the
identifiers, the IdO <bcp14>MUST</bcp14> return an error response with status code 403identifiers, the IdO <bcp14>MUST</bcp14> return an error response with status code 403
(Forbidden) and an appropriate type, e.g., <tt>rejectedIdentifier</tt> or <tt>badCSR</tt>.(Forbidden) and an appropriate type, e.g., <tt>rejectedIdentifier</tt> or <tt>badCSR</tt>.
The error response <bcp14>SHOULD</bcp14> contain subproblems (<xrefformat="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 (<xrefsection="6.7.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-6.7.1" derivedContent="RFC8555"/>)
for each failed identifier. If the CSR is successfully validated, the orderfor each failed identifier. If the CSR is successfully validated, the order
object status moves to <tt>processing</tt> and the twin ACME protocol instance isobject status moves to <tt>processing</tt> and the twin ACME protocol instance is
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 IdO:</t> <t indent="0" pn="section-2.3.2-8">The request object created by the IdO:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.2-9"> <ulbare="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> object sent by the NDC.</li> <bcp14>MUST</bcp14> carry a copy of the <tt>auto-renewal</tt> object sent by the NDC.</li>
</ul> </ul>
<t indent="0" pn="section-2.3.2-10">When the identifiers' authorization has been successfully completed and the <t indent="0" pn="section-2.3.2-10">When the identifiers' authorization 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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.2-11"> <ulbare="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</tt> and</li> <bcp14>MUST</bcp14> move its Order resource status to <tt>valid</tt> 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> URLinto 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 header fields) the renewal timersincludes (via the <tt>Cert-Not-Before</tt> and <tt>Cert-Not-After</tt> HTTP header 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" suppress-title="false" pn="figure-6"> <figure anchor="fig-star-ido-order-resource-updated" align="left" suppress-title="false" pn="figure-6">
<name slugifiedName="name-star-order-resource-updated">STAR Order Resource Updated on IdO</name> <name slugifiedName="name-star-order-resource-updated">STAR Order Resource Updated on IdO</name>
<sourcecode name="" type="json"pn="section-2.3.2-12.1" markers="false"> <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 1253skipping 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 predicated on the NDC being able to fetch <t indent="0" pn="section-2.3.2-13">This delegation protocol is predicated 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 thethe 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 Orderstandard POST-as-GET ACME request. Therefore, before forwarding the Order
request to the CA, the IdO <bcp14>SHOULD</bcp14> ensure that the selected CA supportsrequest to the CA, the IdO <bcp14>SHOULD</bcp14> ensure that the selected CA supports
unauthenticated GET by inspecting the relevant settings in the CA'sunauthenticated GET by inspecting the relevant settings in the CA's
directory object, as per <xrefformat="default" sectionFormat="of" derivedContent="RFC8739" section="3.4" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.4"/>. If the CA does notdirectory object, as per <xrefsection="3.4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.4" derivedContent="RFC8739"/>. If the CA does not
support unauthenticated GET of STAR certificates, the IdO <bcp14>MUST NOT</bcp14> forwardsupport 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 setthe 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>false</tt>. The samethe <tt>allow-certificate-get</tt> in the <tt>auto-renewal</tt> object to <tt>false</tt>. The same
occurs in case the Order request is forwarded and the CA does not reflect theoccurs 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 of<tt>allow-certificate-get</tt> setting in its Order resource. The combination of
<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order resource at<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order resource at
the IdO provides an unambiguous (asynchronous) signal to the NDC about thethe 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</name> <name slugifiedName="name-cname-installation">CNAME Installation</name>
<t indent="0" pn="section-2.3.2.1-1">If one of the objects in the <tt>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 <tt>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 example:</t>CNAME records specified in the <tt>delegation</tt> object to its zone, for example:</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"removeInRFC="false" toc="include" pn="section-2.3.3">
<name slugifiedName="name-order-object-transmitted-fro">Order Object Transmitted from NDC to IdO and to ACME Server (Non-STAR)</name> <name slugifiedName="name-order-object-transmitted-fro">Order Object Transmitted 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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.3-2"> <ulbare="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 indicating the preconfigured delegation <bcp14>MUST</bcp14> have a <tt>delegation</tt> attribute indicating 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> attribute set to true.</li> <bcp14>MUST</bcp14> have the <tt>allow-certificate-get</tt> attribute 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="false"> <sourcecode name="" type="json"markers="false" pn="section-2.3.3-3.1">
POST /acme/new-order HTTP/1.1POST /acme/new-order HTTP/1.1
Host: acme.ido.exampleHost: acme.ido.example
Content-Type: application/jose+jsonContent-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 1315skipping 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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.3-5"> <ulbare="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> configuration; and</li> <bcp14>MUST</bcp14> contain the indicated <tt>delegation</tt> configuration; 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-get</tt> setting.</li> <bcp14>MUST</bcp14> contain the indicated <tt>allow-certificate-get</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 Order Resource Created on IdO</name> <name slugifiedName="name-non-star-order-resource-cre">Non-STAR Order Resource Created on IdO</name>
<sourcecode name="" type="json"pn="section-2.3.3-6.1" markers="false"> <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 1355skipping 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 and the subsequent validation of the CSR by <t indent="0" pn="section-2.3.3-7">The Order finalization by the NDC and the subsequent validation of the CSR by
the IdO proceed in the same way as for the STAR case. If the CSR isthe 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 thesuccessfully 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 IdO:</t> <t indent="0" pn="section-2.3.3-8">The request object created by the IdO:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.3-9"> <ulbare="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> attribute.</li> <bcp14>MUST</bcp14> copy the <tt>allow-certificate-get</tt> attribute.</li>
</ul> </ul>
<t indent="0" pn="section-2.3.3-10">When the identifiers' authorization has been successfully completed and the <t indent="0" pn="section-2.3.3-10">When the identifiers' authorization 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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-2.3.3-11"> <ulbare="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</tt> and</li> <bcp14>MUST</bcp14> move its Order resource status to <tt>valid</tt> 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 Order returned by the CA into its <bcp14>MUST</bcp14> copy the <tt>certificate</tt> field from the Order returned by the CA into its
Order resource, as well as <tt>notBefore</tt> and <tt>notAfter</tt> if these fields exist.</li>Order resource, as well as <tt>notBefore</tt> and <tt>notAfter</tt> if these fields 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 Order Resource Updated on IdO</name> <name slugifiedName="name-non-star-order-resource-upd">Non-STAR Order Resource Updated on IdO</name>
<sourcecode name="" type="json"pn="section-2.3.3-12.1" markers="false"> <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 1412skipping to change at line 1412
selected CA supports unauthenticated GET by inspecting the relevant settingsselected CA supports unauthenticated GET by inspecting the relevant settings
in the CA's directory object, as per <xref format="default" sectionFormat="of" derivedContent="Section 2.3.5"/>. If the CAin the CA's directory object, as per <xref format="default" sectionFormat="of" derivedContent="Section 2.3.5"/>. If the CA
does not support unauthenticated GET of certificate resources, the IdO <bcp14>MUST NOT</bcp14> forward the Order request. Instead, it <bcp14>MUST</bcp14> move the Order status todoes not support unauthenticated GET of certificate resources, 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 <tt>allow-certificate-get</tt> attribute to <tt>false</tt>. The same<tt>invalid</tt> and set the <tt>allow-certificate-get</tt> attribute to <tt>false</tt>. The same
occurs in case the Order request is forwarded and the CA does not reflect theoccurs 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 of<tt>allow-certificate-get</tt> setting in its Order resource. The combination of
<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order resource at<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order resource at
the IdO provides an unambiguous (asynchronous) signal to the NDC about thethe 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" removeInRFC="false" pn="section-2.3.4"> <section anchor="capability-discovery" numbered="true"removeInRFC="false" 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 theobject 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 thisthe 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-STARregardless 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> field:</t>one deployed by the CA) contains the following attribute in the <tt>meta</tt> field:</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 format="default" sectionFormat="of" derivedContent="Section 2.3.5"/>.</dd> <dd pn="section-2.3.4-5.2">See <xref 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="false" 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 delegation of non-STAR certificates, this document <t indent="0" pn="section-2.3.5-1">In order to enable the name delegation of non-STAR certificates, this document
defines a mechanism that allows a server to advertise support for accessingdefines a mechanism that allows a server to advertise support for accessing
certificate resources via unauthenticated GET (in addition tocertificate 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 protocol elements described in this section <t indent="0" pn="section-2.3.5-2">It is worth pointing out that the protocol elements described in this section
have the same names and semantics as those introduced inhave the same names and semantics as those introduced in
<xrefformat="default" sectionFormat="of" derivedContent="RFC8739" 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<xrefsection="3.4" format="default" sectionFormat="of" derivedLink="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, theycertificate 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 located at therather than being wrapped in an <tt>auto-renewal</tt> subobject, they are located at the
top level.</t>top level.</t>
<t anchor="capability-metadata" indent="0" pn="section-2.3.5-3">A server states its availability to grant unauthenticated access to a client's <t anchor="capability-metadata" indent="0" pn="section-2.3.5-3">A server 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> inOrder 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 access the issued certificate via unauthenticated <t indent="0" pn="section-2.3.5-5">A client states its desire to access the issued certificate via unauthenticated
GET by adding an <tt>allow-certificate-get</tt> attribute to the payload of itsGET 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 (andto <tt>true</tt>, the client requests the server to allow unauthenticated GET (and
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 unauthenticated GET has been agreed upon, the <t indent="0" pn="section-2.3.5-8">Note that even when the use of unauthenticated GET has been agreed upon, the
server <bcp14>MUST</bcp14> also allow POST-as-GET requests to the certificate resource.</t>server <bcp14>MUST</bcp14> also allow POST-as-GET requests to the certificate resource.</t>
</section> </section>
<section anchor="terminating-the-delegation" numbered="true"toc="include" 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 differently depending on whether or not this is a STAR certificate.</t> <t indent="0" pn="section-2.3.6-1">Identity delegation is terminated differently depending on whether or not this is a STAR certificate.</t>
<section anchor="by-cancellation-star" numbered="true"toc="exclude" removeInRFC="false" pn="section-2.3.6.1"> <section anchor="by-cancellation-star" numbered="true"removeInRFC="false" toc="exclude" pn="section-2.3.6.1">
<name slugifiedName="name-by-cancellation-star">By Cancellation (STAR)</name> <name slugifiedName="name-by-cancellation-star">By Cancellation (STAR)</name>
<t indent="0" pn="section-2.3.6.1-1">The IdO can terminate the delegation of a STAR certificate by requesting its <t indent="0" pn="section-2.3.6.1-1">The IdO can terminate the delegation of a STAR certificate by requesting its
cancellation (see <xrefformat="default" sectionFormat="of" derivedContent="RFC8739" section="3.1.2" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.1.2"/>).</t>cancellation (see <xrefsection="3.1.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8739#section-3.1.2" derivedContent="RFC8739"/>).</t>
<t indent="0" pn="section-2.3.6.1-2">Cancellation of the ACME STAR certificate is a <t indent="0" pn="section-2.3.6.1-2">Cancellation of the ACME STAR certificate is a
prerogative of the IdO. The NDC does not own the relevant account key on theprerogative 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 thePotentially, since it holds the STAR certificate's private key, it could request the
revocation of a single STAR certificate. However, STAR explicitly disables therevocation 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 renewal process is stopped by the IdO, the last <t indent="0" pn="section-2.3.6.1-3">Shortly after the automatic renewal 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 delegation of a non-STAR certificate by requesting it <t indent="0" pn="section-2.3.6.2-1">The IdO can terminate the delegation 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 <xrefformat="default" sectionFormat="of" derivedContent="RFC8555" section="7.6" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.6"/>, the revocation endpoint can be used <t indent="0" pn="section-2.3.6.2-2">According to <xrefsection="7.6" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.6" derivedContent="RFC8555"/>, the revocation endpoint can be used
with either the account key pair or the certificate key pair. In other words, anwith 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 available viaNDC that learns the <tt>revokeCert</tt> URL of the CA (which is publicly available via
the CA's directory object) would be able to revoke the certificate using thethe CA's directory object) would be able to revoke the certificate using the
associated private key. However, given the trust relationship between the NDC andassociated private key. However, given the trust relationship between the NDC and
IdO expected by the delegation trust model (<xref format="default" sectionFormat="of" derivedContent="Section 7.1"/>), as well asIdO expected by the delegation trust model (<xref format="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 Delegation flow should be proxied, such as the <t indent="0" pn="section-2.4-1">There are cases where the ACME Delegation flow should be proxied, such as the
use case described in <xref format="default" sectionFormat="of" derivedContent="Section 5.1.2"/>. This section describes the behavior ofuse case described in <xref format="default" sectionFormat="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 role -- an "ACME Delegation server" -- <t indent="0" pn="section-2.4-2">An entity implementing the IdO server role -- an "ACME Delegation server" --
may behave, on a per-identity case, either as a proxy into another ACME Delegationmay behave, on a per-identity case, either as a proxy into another ACME Delegation
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 byThe determining factor is whether it can successfully be authorized by
the next-hop ACME server for the identity associated with the certificate request.</t>the next-hop ACME server for the identity associated with the certificate request.</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 1563skipping 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="section-2.4-5.10.1"> <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-2.4-5.10.1">
<li pn="section-2.4-5.10.1.1">The <tt>Location</tt> header, <tt>Link</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>Link</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="include" 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 particular <xref format="default" sectionFormat="of" derivedContent="Section 2"/>, is focused on the protocol between the NDC and IdO, the protocol does affect the ACME server running in the CA. A CA that wishes to support certificate delegation <bcp14>MUST</bcp14> also support unauthenticated certificate fetching, which it declares using <tt>allow-certificate-get</tt> (<xref format="default" sectionFormat="of" derivedContent="Section 2.3.5, Paragraph 3"/>).</t> <t indent="0" pn="section-3-1">Although most of this document, and in particular <xref format="default" sectionFormat="of" derivedContent="Section 2"/>, is focused on the protocol between the NDC and IdO, the protocol does affect the ACME server running in the CA. A CA that wishes to support certificate delegation <bcp14>MUST</bcp14> also support unauthenticated certificate fetching, which it declares using <tt>allow-certificate-get</tt> (<xref format="default" sectionFormat="of" derivedContent="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 constrain the shape of the CSR that the <t indent="0" pn="section-4-1">The CSR template is used to express and constrain the shape of the CSR that the
NDC uses to request the certificate. The CSR is used for every certificateNDC uses to request the certificate. The CSR is used for every certificate
created under the same delegation. Its validation by the IdO is a criticalcreated 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 attribute, this document takes a <t indent="0" pn="section-4-2">Instead of defining every possible CSR attribute, this document takes a
minimalist approach by declaring only the minimum attribute set and deferringminimalist 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" removeInRFC="false" pn="section-4.1"> <section anchor="sec-csr-template-syntax" numbered="true"removeInRFC="false" 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 field (with the exception of <tt>keyTypes</tt>, see below) denotes one of the following:</t> <t indent="0" pn="section-4.1-1">The template is a JSON document. Each field (with the exception of <tt>keyTypes</tt>, see below) denotes one of the following:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2"> <ulbare="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 specifies the literal value of that <li pn="section-4.1-2.1">A mandatory field where the template specifies the literal value of that
field. This is denoted by a literal string, such as <tt>abc.ido.example</tt>.</li>field. This is denoted by a literal string, such as <tt>abc.ido.example</tt>.</li>
<li pn="section-4.1-2.2">A mandatory field where the content of the field is defined by the client. <li pn="section-4.1-2.2">A mandatory field where the content of the field 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 whether the field is included in <li pn="section-4.1-2.3">An optional field where the client decides whether 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 the <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 the
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 format="default" sectionFormat="of" derivedContent="RFC8610"/> document in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" derivedContent="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 format="default" sectionFormat="of" derivedContent="RFC8610"/> document in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix A"/>.
An alternative, nonnormative JSON Schema syntax is given in <xref format="default" sectionFormat="of" derivedContent="Appendix B"/>.An alternative, nonnormative JSON Schema syntax is given in <xref format="default" sectionFormat="of" derivedContent="Appendix B"/>.
While the CSR template must follow the syntax defined here, neither the IdO norWhile 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 subfields 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"/>. Other extension fields of the CSR template are mapped into the CSR according to the table in <xref format="default" sectionFormat="of" derivedContent="Section 6.5"/>.</t> <t indent="0" pn="section-4.1-5">The <tt>subject</tt> field and its subfields 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="https://rfc-editor.org/rfc/rfc5280#section-4.1.2.6" derivedContent="RFC5280"/>. Other extension fields of the CSR template are mapped into the CSR according to the table in <xref format="default" sectionFormat="of" derivedContent="Section 6.5"/>.</t>
<t indent="0" pn="section-4.1-6">The <tt>subjectAltName</tt> field is currently defined for the following identifiers: <t indent="0" pn="section-4.1-6">The <tt>subjectAltName</tt> field is currently defined for the following identifiers:
DNS names, email addresses, and URIs. New identifier types may be added in theDNS names, email addresses, and URIs. New identifier types may be added in the
future by documents that extend this specification. Each new identifier typefuture 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 copied into the CSR. Instead, this property constrains the <tt>SubjectPublicKeyInfo</tt> field of the CSR, which <bcp14>MUST</bcp14> have the type/size defined by 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 copied into the CSR. Instead, this property constrains the <tt>SubjectPublicKeyInfo</tt> field of the CSR, which <bcp14>MUST</bcp14> have the type/size defined by 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 <bcp14>MUST</bcp14> verify that the CSR is consistent <t indent="0" pn="section-4.1-8">When the IdO receives the CSR, it <bcp14>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 additionalwith 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 aconstraints, 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>) tomeaning 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 providedapply application-specific checks on top of the control rules already provided
by the CSR template to ensure the requested domain name is legitimate accordingby 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 format="default" sectionFormat="of" derivedContent="Figure 10"/> represents one possible CSR template <t indent="0" pn="section-4.2-1">The CSR template in <xref format="default" sectionFormat="of" derivedContent="Figure 10"/> represents 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 1654skipping 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" removeInRFC="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 additional use cases implementing the STAR certificate <t indent="0" pn="section-5-1">This nonnormative section describes additional 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" removeInRFC="false" pn="section-5.1"> <section anchor="cdn-interconnection-cdni" numbered="true"removeInRFC="false" 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 format="default" sectionFormat="of" derivedContent="HTTPS-DELEGATION"/> discusses several solutions <t indent="0" pn="section-5.1-1"><xref format="default" sectionFormat="of" derivedContent="HTTPS-DELEGATION"/> 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 theenvironment. 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 terminology, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in <xref target="RFC7336" format="default" sectionFormat="of" derivedContent="RFC7336"/>.</t> <t indent="0" pn="section-5.1-2">This section uses specific CDNI terminology, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in <xref target="RFC7336" format="default" sectionFormat="of" derivedContent="RFC7336"/>.</t>
<section anchor="multiple-parallel-delegates" numbered="true"toc="include" removeInRFC="false" pn="section-5.1.1"> <section anchor="multiple-parallel-delegates" numbered="true"removeInRFC="false" toc="include" pn="section-5.1.1">
<name slugifiedName="name-multiple-parallel-delegates">Multiple Parallel Delegates</name> <name slugifiedName="name-multiple-parallel-delegates">Multiple Parallel Delegates</name>
<t indent="0" pn="section-5.1.1-1">In some cases, the content owner (IdO) would like to delegate authority over a <t indent="0" pn="section-5.1.1-1">In some cases, the content owner (IdO) would like to delegate authority over a
website to multiple NDCs (CDNs). This could happen if the IdO has agreementswebsite to multiple NDCs (CDNs). This could happen if the IdO has agreements
in place with different regional CDNs for different geographical regions or ifin place with different regional CDNs for different geographical regions or if
a "backup" CDN is used to handle overflow traffic by temporarily altering somea "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 caseof 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 ownnaturally, 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 eachseparate 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" removeInRFC="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 (IdO) delegates some domains to a large CDN <t indent="0" pn="section-5.1.2-1">In other cases, a content owner (IdO) 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 withcontractual 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 betweenWhether 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 interface between uCDN and dCDN, by which the <t indent="0" pn="section-5.1.2-3">A mechanism is necessary at the interface between uCDN and dCDN, by which the
uCDN can advertise:</t>uCDN can advertise:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.2-4"> <ulbare="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 provided by the CSR template.</t> <t indent="0" pn="section-5.1.2-5">Note that such mechanism is provided by the CSR template.</t>
<section anchor="two-level-delegation-in-cdni" numbered="true"toc="exclude" removeInRFC="false" pn="section-5.1.2.1"> <section anchor="two-level-delegation-in-cdni" numbered="true"removeInRFC="false" toc="exclude" pn="section-5.1.2.1">
<name slugifiedName="name-two-level-delegation-in-cdn">Two-Level Delegation in CDNI</name> <name slugifiedName="name-two-level-delegation-in-cdn">Two-Level Delegation in CDNI</name>
<t indent="0" pn="section-5.1.2.1-1">A User Agent (UA), e.g., a browser 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 browser 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 theRedirection between the
content provider (CP) and upstream and downstream CDNs is arranged as acontent provider (CP) and upstream and downstream CDNs is arranged as a
CNAME-based aliasing chain, as illustrated in <xref format="default" sectionFormat="of" derivedContent="Figure 11"/>.</t>CNAME-based aliasing chain, as illustrated in <xref format="default" sectionFormat="of" derivedContent="Figure 11"/>.</t>
<figure anchor="fig-cdni-dns-redirection" align="left" suppress-title="false" pn="figure-11"> <figure anchor="fig-cdni-dns-redirection" align="left" suppress-title="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" 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" 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 1987skipping 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="section-5.1.2.1-2.1.2"> <artwork type="ascii-art" name="" alt="" align="left" pn="section-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 2034skipping to change at line 2034
original URI -- in the example, <tt>video.cp.example</tt>. So, in order tooriginal URI -- in the example, <tt>video.cp.example</tt>. So, in order to
successfully complete the handshake, the landing dCDN node has to be configuredsuccessfully complete the handshake, the landing dCDN node has to be configured
with a certificate whose <tt>subjectAltName</tt> field matches <tt>video.cp.example</tt>, i.e., awith a certificate whose <tt>subjectAltName</tt> field matches <tt>video.cp.example</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 format="default" sectionFormat="of" derivedContent="Figure 12"/> illustrates the cascaded delegation flow that allows dCDN to <t indent="0" pn="section-5.1.2.1-4"><xref format="default" sectionFormat="of" derivedContent="Figure 12"/> illustrates the cascaded delegation flow that allows dCDN to
obtain a STAR certificate that bears a name belonging to the content providerobtain 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" pn="figure-12"> <figure anchor="fig-cdni-flow" align="left" suppress-title="false" pn="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" 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" 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 2274skipping 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="section-5.1.2.1-5.1.2"> <artwork type="ascii-art" name="" alt="" align="left" pn="section-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 2312skipping 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 target="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 target="sec-profile-dele-config" format="default" sectionFormat="of" derivedContent="Section 2.3.1"/>.</t>
<olspacing="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">
<lipn="section-5.1.2.1-7.1" derivedCounter="1.">dCDN requests CDNI <liderivedCounter="1." pn="section-5.1.2.1-7.1">dCDN requests CDNI
path metadata to uCDN.</li> path metadata to uCDN.</li>
<lipn="section-5.1.2.1-7.2" derivedCounter="2.">uCDN replies with <liderivedCounter="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>
<lipn="section-5.1.2.1-7.3" derivedCounter="3.">dCDN creates a key pair and the CSR with the delegated name. It then places <liderivedCounter="3." pn="section-5.1.2.1-7.3">dCDN creates a key 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>
<lipn="section-5.1.2.1-7.4" derivedCounter="4.">uCDN forwards the <liderivedCounter="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>
<lipn="section-5.1.2.1-7.5" derivedCounter="5.">CP creates an ord <liderivedCounter="5." pn="section-5.1.2.1-7.5">CP creates an ord
er for a STAR certificate and sends it to the CA. Theer 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>
<lipn="section-5.1.2.1-7.6" derivedCounter="6.">After all authorizations complete successfully, the STAR certificate is <liderivedCounter="6." pn="section-5.1.2.1-7.6">After all authorizations complete successfully, the STAR certificate is
issued.</li>issued.</li>
<lipn="section-5.1.2.1-7.7" derivedCounter="7.">CP notifies uCDN that the STAR certificate is available at the order's <liderivedCounter="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>
<lipn="section-5.1.2.1-7.8" derivedCounter="8.">uCDN forwards the information to dCDN. At this point, the ACME signaling is <liderivedCounter="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>
<lipn="section-5.1.2.1-7.9" derivedCounter="9.">dCDN requests the <liderivedCounter="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>
<lipn="section-5.1.2.1-7.10" derivedCounter="10.">The CA returns <liderivedCounter="10." pn="section-5.1.2.1-7.10">The CA returns
the certificate. Now dCDN is fully configured to handlethe 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 delegation of credentials in the STIR <t indent="0" pn="section-5.2-1">As a second use case, we consider the delegation of credentials in the STIR
ecosystem <xref format="default" sectionFormat="of" derivedContent="RFC9060"/>.</t>ecosystem <xref format="default" sectionFormat="of" derivedContent="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 format="default" sectionFormat="of" derivedContent="RFC8225"/>, and "TNAuthList" is defined in <xref format="default" sectionFormat="of" derivedContent="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 format="default" sectionFormat="of" derivedContent="RFC8225"/>, and "TNAuthList" is defined in <xref format="default" sectionFormat="of" derivedContent="RFC8226"/>.</t>
<t indent="0" pn="section-5.2-3">In the STIR delegated mode, a service provider SP2 -- the NDC -- needs to sign <t indent="0" pn="section-5.2-3">In the STIR delegated mode, a service provider SP2 -- the NDC -- needs to sign
PASSporTs <xref format="default" sectionFormat="of" derivedContent="RFC8225"/> for telephone numbers (e.g., TN=+123) belonging toPASSporTs <xref format="default" sectionFormat="of" derivedContent="RFC8225"/> for telephone numbers (e.g., TN=+123) belonging to
another service provider, SP1 -- the IdO. In order to do that, SP2 needs a STIRanother 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 TNAuthListcertificate and a private key that includes TN=+123 in the TNAuthList
<xref format="default" sectionFormat="of" derivedContent="RFC8226"/> certificate extension.</t><xref format="default" sectionFormat="of" derivedContent="RFC8226"/> certificate extension.</t>
<t indent="0" pn="section-5.2-4">In detail (<xref format="default" sectionFormat="of" derivedContent="Figure 13"/>):</t> <t indent="0" pn="section-5.2-4">In detail (<xref format="default" sectionFormat="of" derivedContent="Figure 13"/>):</t>
<olspacing="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">
<lipn="section-5.2-5.1" derivedCounter="1.">SP1 and SP2 agree on the c <liderivedCounter="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>
<lipn="section-5.2-5.2" derivedCounter="2.">SP2 generates a private/public key pair and sends a CSR to SP1, requesting <liderivedCounter="2." pn="section-5.2-5.2">SP2 generates a private/public key pair and sends a CSR to SP1, requesting
creation of a certificate with an SP1 name, an SP2 public key, and a TNAuthListcreation 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 theextension 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 templateCSR 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>
<lipn="section-5.2-5.3" derivedCounter="3.">SP1 sends an order for the CSR to the CA. The order also requests <liderivedCounter="3." pn="section-5.2-5.3">SP1 sends an order for the CSR to the CA. The order also requests
unauthenticated access to the certificate resource.</li>unauthenticated access to the certificate resource.</li>
<lipn="section-5.2-5.4" derivedCounter="4.">Subsequently, after the required TNAuthList authorizations are successfully <liderivedCounter="4." pn="section-5.2-5.4">Subsequently, after the required TNAuthList authorizations are successfully
completed, the CA moves the order to a "valid" state; at the samecompleted, 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>
<lipn="section-5.2-5.5" derivedCounter="5.">The contents of the order are forwarded from SP1 to SP2 by means of the paired <liderivedCounter="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>
<lipn="section-5.2-5.6" derivedCounter="6.">SP2 dereferences the <tt>star-certificate</tt> URL in the order to fetch the rolling <liderivedCounter="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>
<lipn="section-5.2-5.7" derivedCounter="7.">The STAR certificate is returned to SP2.</li> <liderivedCounter="7." pn="section-5.2-5.7">The STAR certificate is returned to SP2.</li>
</ol> </ol>
<figure anchor="fig-stir-flow" align="left" suppress-title="false" pn="figure-13"> <figure anchor="fig-stir-flow" align="left" suppress-title="false" pn="figure-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" 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" 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 2543skipping 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="308" fill="black" font-size="1em">2</text> <text text-anchor="middle" font-family="monospace" x="72" y="308" 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 2575skipping 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 described in this document applies <t indent="0" pn="section-5.2-7">As shown, the STAR delegation profile described in this document applies
straightforwardly; the only extra requirement being the ability to instruct thestraightforwardly; the only extra requirement being the ability to instruct the
NDC about the allowed TNAuthList values. This can be achieved by a simpleNDC 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" removeInRFC="false" pn="section-6"> <section anchor="iana-considerations" numbered="true"removeInRFC="false" toc="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 entries to the "ACME Directory Metadata Fields" registry:</t> <t indent="0" pn="section-6.1-1">This document adds the following entries 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 2602skipping 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="include" removeInRFC="false" pn="section-6.2"> <section anchor="new-fields-in-the-order-object" numbered="true"removeInRFC="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 entries to the "ACME Order Object Fields" registry:</t> <t indent="0" pn="section-6.2-1">This document adds the following entries 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 2630skipping 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="include" removeInRFC="false" pn="section-6.3"> <section anchor="new-fields-in-the-account-object" numbered="true"removeInRFC="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 entries to the "ACME Account Object Fields" registry:</t> <t indent="0" pn="section-6.3-1">This document adds the following entries 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 2654skipping 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> field is only reported by ACME servers that have <t indent="0" pn="section-6.3-3">Note that the <tt>delegations</tt> field 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" removeInRFC="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 entries to the "ACME Error Types" registry:</t> <t indent="0" pn="section-6.4-1">This document adds the following entries 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" removeInRFC="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 Extensions</name> <name slugifiedName="name-csr-template-extensions">CSR Template Extensions</name>
<t indent="0" pn="section-6.5-1">IANA is requested to establish a registry, "STAR Delegation CSR Template <t indent="0" pn="section-6.5-1">IANA is requested to establish a registry, "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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-3"> <ulbare="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 certificate extension.</li> <li pn="section-6.5-3.3">the extension's mapping into an X.509 certificate extension.</li>
</ul> </ul>
<t indent="0" pn="section-6.5-4">The initial contents of this registry are the extensions defined by the CDDL <t indent="0" pn="section-6.5-4">The initial contents of this registry are the extensions defined by the CDDL
in <xref format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>in <xref format="default" sectionFormat="of" derivedContent="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 Certificate Extension</th> <th align="left" colspan="1" rowspan="1">Mapping to X.509 Certificate 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 format="default" sectionFormat="of" derivedContent="Appendix A"/></td> <td align="left" colspan="1" rowspan="1">See <xref format="default" sectionFormat="of" derivedContent="Appendix A"/></td>
<td align="left" colspan="1" rowspan="1"> <td align="left" colspan="1" rowspan="1">
<xrefformat="default" sectionFormat="comma" derivedContent="RFC5280" section="4.2.1.3" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.3"/></td> <xrefsectionFormat="comma" section="4.2.1.3" format="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 format="default" sectionFormat="of" derivedContent="Appendix A"/></td> <td align="left" colspan="1" rowspan="1">See <xref format="default" sectionFormat="of" derivedContent="Appendix A"/></td>
<td align="left" colspan="1" rowspan="1"> <td align="left" colspan="1" rowspan="1">
<xrefformat="default" sectionFormat="comma" derivedContent="RFC5280" section="4.2.1.12" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.12"/></td> <xrefsectionFormat="comma" section="4.2.1.12" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.12" 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 format="default" sectionFormat="of" derivedContent="Appendix A"/></td> <td align="left" colspan="1" rowspan="1">See <xref format="default" sectionFormat="of" derivedContent="Appendix A"/></td>
<td align="left" colspan="1" rowspan="1"> <td align="left" colspan="1" rowspan="1">
<xrefformat="default" sectionFormat="comma" derivedContent="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: URI, DNS name, email address)</td> <xrefsectionFormat="comma" section="4.2.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.6" derivedContent="RFC5280"/> (note that only specific name formats are allowed: URI, 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 assignment 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 assignment in this registry, the designated expert should follow this guidance:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-7"> <ulbare="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 definition, which the expert will validate.</li> <li pn="section-6.5-7.1">The definition must include a full CDDL definition, 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" removeInRFC="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" removeInRFC="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 extended to include the trust relationship <t indent="0" pn="section-7.1-1">The ACME trust model needs to be extended to include the trust relationship
between NDC and IdO. Note that once this trust link is established, itbetween NDC and IdO. Note that once this trust link is established, it
potentially becomes recursive. Therefore, there has to be a trust relationshippotentially becomes recursive. Therefore, there has to be a trust relationship
between each of the nodes in the delegation chain; for example, in case ofbetween each of the nodes in the delegation chain; for example, in case of
cascading CDNs, this is contractually defined. Note that when using standardcascading CDNs, this is contractually defined. Note that when using standard
<xref format="default" sectionFormat="of" derivedContent="RFC6125"/> identity verification, there are no mechanisms available to the IdO<xref format="default" sectionFormat="of" derivedContent="RFC6125"/> 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 toto 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 placethe first NDC. It is, therefore, expected that contractual measures are in place
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" removeInRFC="false" pn="section-7.2"> <section anchor="delegation-security-goal" numbered="true"removeInRFC="false" 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 goal: only an NDC that has been authorized <t indent="0" pn="section-7.2-1">Delegation introduces a new security goal: only an NDC that has been authorized
by the IdO, either directly or transitively, can obtain a certificate with anby 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 delegation process has five separate parts:</t> <t indent="0" pn="section-7.2-2">From a security point of view, the delegation process has five separate parts:</t>
<olspacing="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">
<lipn="section-7.2-3.1" derivedCounter="1.">enabling a specific third <liderivedCounter="1." pn="section-7.2-3.1">enabling a specific third
party (the intended NDC) to submit requests forparty (the intended NDC) to submit requests for
delegated certificates</li>delegated certificates</li>
<lipn="section-7.2-3.2" derivedCounter="2.">making sure that any request for a delegated certificate matches the <liderivedCounter="2." pn="section-7.2-3.2">making sure that any request for a delegated certificate matches the
intended "shape" in terms of delegated identities as well as any otherintended "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>
<lipn="section-7.2-3.3" derivedCounter="3.">serving the certificate b <liderivedCounter="3." pn="section-7.2-3.3">serving the certificate b
ack to the NDC</li>ack to the NDC</li>
<lipn="section-7.2-3.4" derivedCounter="4.">handling revocation of th <liderivedCounter="4." pn="section-7.2-3.4">handling revocation of th
e delegation</li>e delegation</li>
<lipn="section-7.2-3.5" derivedCounter="5.">handling revocation of th <liderivedCounter="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</bcp14> use theWhen a compromise of the private key is detected, the delegate <bcp14>MUST</bcp14> use the
account deactivation procedures defined in <xrefformat="default" sectionFormat="of" derivedContent="RFC8555" section="7.3.6" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.3.6"/>.</t>account deactivation procedures defined in <xrefsection="7.3.6" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-7.3.6" derivedContent="RFC8555"/>.</t>
<t indent="0" pn="section-7.2-5">The second part is covered by the act of checking an NDC's certificate request <t indent="0" pn="section-7.2-5">The second part is covered by the act of checking an NDC's certificate request
against the intended CSR template. The steps of shaping the CSR templateagainst 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 areand 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 relationship between NDC and IdO that is <t indent="0" pn="section-7.2-6">The third part builds on the trust relationship between NDC and IdO that is
responsible for correctly forwarding the certificate URL from the Orderresponsible 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, therefore,remove the <tt>delegation</tt> object associated with the revoked identity, therefore,
disabling any further NDC requests for such identity. Note that, in moredisabling 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 mechanisms, depending on the nature of <t indent="0" pn="section-7.2-8">The fifth is covered by two different mechanisms, depending on the nature of
the certificate. For STAR, the IdO shall use the cancellation interfacethe certificate. For STAR, the IdO shall use the cancellation interface
defined in <xrefformat="default" sectionFormat="of" derivedCondefined in <xref section="2.3"format="default" sectionFormat="
tent="RFC8739" section="2.3"derivedLink="https://rfc-editor.org/rfc/rfc8739#secof" 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 <xrefformat="default" sectionFormat="of"interface defined in <xref section="7.6"format="default" secti
derivedContent="RFC8555" section="7.6"derivedLink="https://rfc-editor.org/rfc/ronFormat="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 delegation plays a crucial role in the <t indent="0" pn="section-7.2-9">The ACME account associated with the delegation plays a crucial role in the
overall security of the presented protocol. This, in turn, means that (inoverall security of the presented protocol. This, in turn, means that (in
delegation scenarios) the security requirements and verification associated withdelegation scenarios) the security requirements and verification associated with
an ACME account may be more stringent than in base ACME deployments, since thean 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 useout-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> ensure thatauthorization challenge procedures. Therefore, the IdO <bcp14>MUST</bcp14> ensure that
each account is associated with the exact policies (via their matching <tt>delegation</tt> objects)each account is associated with the exact policies (via their matching <tt>delegation</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 toThe 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" removeInRFC="false" pn="section-7.3"> <section anchor="new-acme-channels" numbered="true"removeInRFC="false" toc="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 target="RFC8555"format="default" sectionFormat="of" derivedContent="RFC8555" section="10.1" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.1"/>, we can decompose <t indent="0" pn="section-7.3-1">Using the model established in <xref target="RFC8555"section="10.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.1" derivedContent="RFC8555"/>, we can decompose
the interactions of the basic delegation workflow, as shown inthe interactions of the basic delegation workflow, as shown in
<xref format="default" sectionFormat="of" derivedContent="Figure 14"/>.</t><xref format="default" sectionFormat="of" derivedContent="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 Channels Topology</name> <name slugifiedName="name-delegation-channels-topolog">Delegation Channels 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" 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" 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 2997skipping to change at line 2997
<text text-anchor="middle" font-family="monospace" x="32" y="36" fill="black" font-size="1em">C</text> <text text-anchor="middle" font-family="monospace" x="32" y="36" 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="308" fill="black" font-size="1em">r</text> <text text-anchor="middle" font-family="monospace" x="32" y="308" 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 3029skipping to change at line 3029
</artset> </artset>
</figure> </figure>
<t indent="0" pn="section-7.3-3">The considerations regarding the security of the ACME Channel and Validation <t indent="0" pn="section-7.3-3">The considerations regarding the security of the ACME Channel and Validation
Channel discussed in <xref format="default" sectionFormat="of" derivedContent="RFC8555"/> apply verbatim to the IdO-CA leg.Channel discussed in <xref 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 slightlyThe 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 APIwhich consists of a subset of the ACME interface comprising two API
endpoints: the unauthenticated certificate retrieval and, potentially, non-STARendpoints: the unauthenticated certificate retrieval and, potentially, non-STAR
revocation via certificate private key. No specific security considerationsrevocation via certificate private key. No specific security considerations
apply to the former, but the privacy considerations inapply to the former, but the privacy considerations in
<xrefformat="default" sectionFormat="of" derivedContent="RFC8739" 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<xrefsection="6.3" format="default" sectionFormat="of" derivedLink="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 oncurrently no means for an IdO to disable authorizing revocation based on
certificate private keys. So, in theory, an NDC could use the revocation APIcertificate 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 failingdirectly use the revocation interface exposed by the CA unless failing
to do so would compromise the overall security, for example, if the certificateto 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 format="default" sectionFormat="of" derivedContent="RFC8555"/> and <xref format="default" sectionFormat="of" derivedContent="RFC8739"/> apply <t indent="0" pn="section-7.3-4">All other security considerations from <xref format="default" sectionFormat="of" derivedContent="RFC8555"/> and <xref format="default" sectionFormat="of" derivedContent="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="true"toc="include" removeInRFC="false" pn="section-7.4"> <section anchor="restricting-cdns-to-the-delegation-mechanism" numbered="true"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, the CDN can in principle modify the website at will, e.g., create and remove pages. This means that a malicious or breached <t indent="0" pn="section-7.4-1">When a website is delegated to a CDN, the CDN can in principle modify the website at will, e.g., create and remove pages. This means that a malicious or breached
CDN can pass the ACME (as well as common non-ACME) HTTPS-based validationCDN 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 ofchallenges 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 behavior; the domain holder trusts the CDN to <t indent="0" pn="section-7.4-2">In some cases, this is the desired behavior; the domain holder trusts the CDN to
have full control of the cryptographic credentials for the site. However, thishave full control of the cryptographic credentials for the site. However, this
document assumes a scenario where the domain holder only wants to delegatedocument assumes a scenario where the domain holder only wants to delegate
restricted control and wishes to retain the capability to cancel the CDN'srestricted 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>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-7.4-4"> <ulbare="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 cannot modify the DNS records for <li pn="section-7.4-4.1">The domain holder makes sure that the CDN cannot modify the DNS records for
the domain. The domain holder should ensure it is the only entity authorizedthe domain. The domain holder should ensure it is the only entity authorized
to modify the DNS zone. Typically, it establishes a CNAME resource recordto 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 Authority Authorization (CAA) record <xref format="default" sectionFormat="of" derivedContent="RFC8659"/> to restrict certificate <li pn="section-7.4-4.2">The domain holder uses a Certification Authority Authorization (CAA) record <xref format="default" sectionFormat="of" derivedContent="RFC8659"/> to restrict certificate
issuance for the domain to specific CAs that comply with ACME and are knownissuance for the domain to specific CAs that comply with ACME and are known
to implement <xref format="default" sectionFormat="of" derivedContent="RFC8657"/>.</li>to implement <xref format="default" sectionFormat="of" derivedContent="RFC8657"/>.</li>
<li pn="section-7.4-4.3">The domain holder uses the ACME-specific CAA mechanism <xref format="default" sectionFormat="of" derivedContent="RFC8657"/> to <li pn="section-7.4-4.3">The domain holder uses the ACME-specific CAA mechanism <xref format="default" sectionFormat="of" derivedContent="RFC8657"/> to
restrict issuance to a specific CA account that is controlled by it andrestrict 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 3498skipping to change at line 3498
</t> </t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-authority-token-tnauthlist-08"/> <seriesInfo name="Internet-Draft" value="draft-ietf-acme-authority-token-tnauthlist-08"/>
<format type="TXT"/> <format type="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" removeInRFC="false" pn="section-appendix.a"> <section anchor="csr-template-schema-cddl" numbered="true"removeInRFC="false" 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 definition of the CSR template using CDDL <xref format="default" sectionFormat="of" derivedContent="RFC8610"/>. The CSR template <bcp14>MUST</bcp14> be 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 definition of the CSR template using CDDL <xref format="default" sectionFormat="of" derivedContent="RFC8610"/>. The CSR template <bcp14>MUST</bcp14> be 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 not expressed in CDDL that <bcp14>MUST</bcp14> be validated <t indent="0" pn="section-appendix.a-2">There are additional constraints not expressed in CDDL that <bcp14>MUST</bcp14> be validated
by the recipient, including:</t>by the recipient, including:</t>
<ulspacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a-3"> <ulbare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.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 3607skipping 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 /= oidextendedKeyUsageType /= 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" removeInRFC="false" pn="section-appendix.b"> <section anchor="csr-template-schema" numbered="true"removeInRFC="false" toc="include" pn="section-appendix.b">
<name slugifiedName="name-csr-template-json-schema">CSR Template: JSON Schema</name> <name slugifiedName="name-csr-template-json-schema">CSR Template: JSON Schema</name>
<t indent="0" pn="section-appendix.b-1">This appendix includes an alternative, nonnormative JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in <xref format="default" sectionFormat="of" derivedContent="json-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 reference for this syntax is not yet available, and we have chosen to use the draft version, which is currently best supported by tool implementations.</t> <t indent="0" pn="section-appendix.b-1">This appendix includes an alternative, nonnormative JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in <xref format="default" sectionFormat="of" derivedContent="json-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 reference for this syntax is not yet available, and we have chosen to use the draft version, which is currently best supported by tool implementations.</t>
<t indent="0" pn="section-appendix.b-2">The same considerations about additional constraints checking discussed in <t indent="0" pn="section-appendix.b-2">The same considerations about additional constraints checking discussed in
<xref format="default" sectionFormat="of" derivedContent="Appendix A"/> apply here as well.</t><xref format="default" sectionFormat="of" derivedContent="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 3831skipping 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" removeInRFC="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 following people who contributed significantly to this document with their review comments and design proposals: <contact fullname="Richard Barnes"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Frédéric Fieau"/>, <contact fullname="Russ Housley"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Eric Kline"/>, <contact fullname="Sanjay Mishra"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Jon Peterson"/>, <contact fullname="Ryan Sleevi"/>, <contact fullname="Emile Stephan"/>, and <contact fullname="Éric Vyncke"/>.</t> <t indent="0" pn="section-appendix.c-1">We would like to thank the following people who contributed significantly to this document with their review comments and design proposals: <contact fullname="Richard Barnes"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Frédéric Fieau"/>, <contact fullname="Russ Housley"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Eric Kline"/>, <contact fullname="Sanjay Mishra"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Jon Peterson"/>, <contact fullname="Ryan Sleevi"/>, <contact fullname="Emile Stephan"/>, and <contact fullname="Éric Vyncke"/>.</t>
<t indent="0" pn="section-appendix.c-2">This work is partially supported by the European Commission under Horizon 2020 <t indent="0" pn="section-appendix.c-2">This work is partially supported by the European Commission under Horizon 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxedgrant 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 deleted164 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available fromhttp://tools.ietf.org/tools/rfcdiff/
[8]ページ先頭
©2009-2026 Movatter.jp