rfc9115.original.xml   rfc9115.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
nsus="true" docName="draft-ietf-acme-star-delegation-09" indexInclude="true" ipr <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-ietf-
="trust200902" prepTime="2021-06-11T11:25:00" scripts="Common,Latin" sortRefs="t acme-star-delegation-09" ipr="trust200902" indexInclude="true" number="9115" pre
rue" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lan pTime="2021-06-11T11:25:00" scripts="Common,Latin" submissionType="IETF" updates
g="en"> ="" obsoletes="" category="std" consensus="true" symRefs="true" sortRefs="true"
tocDepth="3" tocInclude="true" xml:lang="en">
<!-- xml2rfc v2v3 conversion 3.4.0 --> <!-- xml2rfc v2v3 conversion 3.4.0 -->
<front> <front>
<title abbrev="ACME Delegation">An ACME Profile for Generating Delegated Cer <title abbrev="ACME Delegation">An Automatic Certificate Management Environm
tificates</title> ent (ACME) Profile for Generating Delegated Certificates</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-star-delegation-09" <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>
</address> </address>
</author> </author>
<author initials="D." surname="López" fullname="Diego López"> <author initials="D." surname="López" fullname="Diego López">
<organization showOnFrontPage="true">Telefonica I+D</organization> <organization showOnFrontPage="true">Telefonica I+D</organization>
<address> <address>
<email>diego.r.lopez@telefonica.com</email> <email>diego.r.lopez@telefonica.com</email>
skipping to change at line 31 skipping to change at line 32
<address> <address>
<email>antonio.pastorperales@telefonica.com</email> <email>antonio.pastorperales@telefonica.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization showOnFrontPage="true">ARM</organization> <organization showOnFrontPage="true">ARM</organization>
<address> <address>
<email>thomas.fossati@arm.com</email> <email>thomas.fossati@arm.com</email>
</address> </address>
</author> </author>
<date month="06" year="2021" day="11"/> <date month="September" year="2021"/>
<area>Security</area> <area>Security</area>
<workgroup>ACME</workgroup> <workgroup>ACME</workgroup>
<keyword>Internet-Draft</keyword> <keyword>Content Delivery Network</keyword>
<keyword>CDN</keyword>
<abstract pn="section-abstract"> <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document defines a profile of t he Automatic Certificate Management Environment <t indent="0" pn="section-abstract-1">This document defines a profile of t he Automatic Certificate Management Environment
(ACME) protocol by which the holder of an identifier (e.g., a domain name) can (ACME) protocol by which the holder of an identifier (e.g., a domain name) can
allow a third party to obtain an X.509 certificate such that the certificate allow a third party to obtain an X.509 certificate such that the certificate
subject is the delegated identifier while the certified public key corresponds subject is the delegated identifier while the certified public key corresponds
to a private key controlled by the third party. to a private key controlled by the third party.
A primary use case is that of a Content Delivery Network (CDN, the third party) A primary use case is that of a Content Delivery Network (CDN), the third party,
terminating TLS sessions on behalf of a content provider (the holder of a domain terminating TLS sessions on behalf of a content provider (the holder of a domain
name). The presented mechanism allows the holder of the identifier to retain name). The presented mechanism allows the holder of the identifier to retain
control over the delegation and revoke it at any time. Importantly, this control over the delegation and revoke it at any time. Importantly, this
mechanism does not require any modification to the deployed TLS mechanism does not require any modification to the deployed TLS
clients and servers.</t> clients and servers.</t>
</abstract> </abstract>
<boilerplate> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc= "exclude" pn="section-boilerplate.1"> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc= "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name > <name slugifiedName="name-status-of-this-memo">Status of This Memo</name >
<t indent="0" pn="section-boilerplate.1-1"> <t indent="0" pn="section-boilerplate.1-1">
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
</t> </t>
<t indent="0" pn="section-boilerplate.1-2"> <t indent="0" pn="section-boilerplate.1-2">
Internet-Drafts are working documents of the Internet Engineering Task This document is a product of the Internet Engineering Task Force
Force (IETF). Note that other groups may also distribute working (IETF). It represents the consensus of the IETF community. It has
documents as Internet-Drafts. The list of current Internet-Drafts is received public review and has been approved for publication by
at <eref target="https://datatracker.ietf.org/drafts/current/" brackets= the Internet Engineering Steering Group (IESG). Further
"none"/>. information on Internet Standards is available in Section 2 of
RFC 7841.
</t> </t>
<t indent="0" pn="section-boilerplate.1-3"> <t indent="0" pn="section-boilerplate.1-3">
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any
and may be updated, replaced, or obsoleted by other documents at any errata, and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference <eref target="http://www.rfc-editor.org/info/rfc9115" brackets="none"/>.
material or to cite them other than as "work in progress."
</t>
<t indent="0" pn="section-boilerplate.1-4">
This Internet-Draft will expire on 13 December 2021.
</t> </t>
</section> </section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl ude" pn="section-boilerplate.2"> <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name> <name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1"> <t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
</t> </t>
<t indent="0" pn="section-boilerplate.2-2"> <t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
skipping to change at line 101 skipping to change at line 100
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p n="section-toc.1"> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name> <name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to c.1-1"> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to c.1-1">
<li pn="section-toc.1-1.1"> <li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction"> Introduction</xref></t> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction"> Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio n-toc.1-1.1.2"> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1"> <li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1">< xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1. 1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te rminology">Terminology</xref></t> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1">< xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1. 1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te rminology">Terminology</xref></t>
</li> </li>
<li pn="section-toc.1-1.1.2.2"> <li pn="section-toc.1-1.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1">< xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1. 2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-co nventions-used-in-this-do">Conventions used in this document</xref></t> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1">< xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1. 2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-co nventions-used-in-this-do">Conventions Used in This Document</xref></t>
</li> </li>
</ul> </ul>
</li> </li>
<li pn="section-toc.1-1.2"> <li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f ormat="title" sectionFormat="of" target="name-protocol-flow">Protocol Flow</xref ></t> <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f ormat="title" sectionFormat="of" target="name-protocol-flow">Protocol Flow</xref ></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio n-toc.1-1.2.2"> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1"> <li pn="section-toc.1-1.2.2.1">
<t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent= "2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-preconditions">Precond itions</xref></t> <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent= "2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-preconditions">Precond itions</xref></t>
</li> </li>
<li pn="section-toc.1-1.2.2.2"> <li pn="section-toc.1-1.2.2.2">
<t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent= "2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-overview">Overview</xr ef></t> <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent= "2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-overview">Overview</xr ef></t>
</li> </li>
<li pn="section-toc.1-1.2.2.3"> <li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent= "2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-delegated-identity-pro file">Delegated Identity Profile</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent= "2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-delegated-identity-pro file">Delegated Identity Profile</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se ction-toc.1-1.2.2.3.2"> <ul bare="true" empty="true" indent="2" spacing="compact" pn="se ction-toc.1-1.2.2.3.2">
<li pn="section-toc.1-1.2.2.3.2.1"> <li pn="section-toc.1-1.2.2.3.2.1">
<t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derived Content="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-delegation -configuration">Delegation Configuration</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.1.1"><xref derived Content="2.3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-delegation -configuration">Delegation Configuration</xref></t>
</li> </li>
<li pn="section-toc.1-1.2.2.3.2.2"> <li pn="section-toc.1-1.2.2.3.2.2">
<t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derived Content="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fr">Order Object Transmitted from NDC to IdO and to ACME Server ( STAR)</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.2.1"><xref derived Content="2.3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fr">Order Object Transmitted from NDC to IdO and to ACME Server ( for STAR)</xref></t>
</li> </li>
<li pn="section-toc.1-1.2.2.3.2.3"> <li pn="section-toc.1-1.2.2.3.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.2.3.1"><xref derived Content="2.3.3" format="counter" sectionFormat="of" target="section-2.3.3"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fro">Order Object Transmitted from NDC to IdO and to ACME Server (non-STAR)</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.3.1"><xref derived Content="2.3.3" format="counter" sectionFormat="of" target="section-2.3.3"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-order-obje ct-transmitted-fro">Order Object Transmitted from NDC to IdO and to ACME Server (for Non-STAR)</xref></t>
</li> </li>
<li pn="section-toc.1-1.2.2.3.2.4"> <li pn="section-toc.1-1.2.2.3.2.4">
<t indent="0" pn="section-toc.1-1.2.2.3.2.4.1"><xref derived Content="2.3.4" format="counter" sectionFormat="of" target="section-2.3.4"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-capability -discovery">Capability Discovery</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.4.1"><xref derived Content="2.3.4" format="counter" sectionFormat="of" target="section-2.3.4"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-capability -discovery">Capability Discovery</xref></t>
</li> </li>
<li pn="section-toc.1-1.2.2.3.2.5"> <li pn="section-toc.1-1.2.2.3.2.5">
<t indent="0" pn="section-toc.1-1.2.2.3.2.5.1"><xref derived Content="2.3.5" format="counter" sectionFormat="of" target="section-2.3.5"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-negotiatin g-an-unauthentica">Negotiating an Unauthenticated GET</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.5.1"><xref derived Content="2.3.5" format="counter" sectionFormat="of" target="section-2.3.5"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-negotiatin g-an-unauthentica">Negotiating an Unauthenticated GET</xref></t>
</li> </li>
<li pn="section-toc.1-1.2.2.3.2.6"> <li pn="section-toc.1-1.2.2.3.2.6">
<t indent="0" pn="section-toc.1-1.2.2.3.2.6.1"><xref derived Content="2.3.6" format="counter" sectionFormat="of" target="section-2.3.6"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-terminatin g-the-delegation">Terminating the Delegation</xref></t> <t indent="0" pn="section-toc.1-1.2.2.3.2.6.1"><xref derived Content="2.3.6" format="counter" sectionFormat="of" target="section-2.3.6"/>.  < xref derivedContent="" format="title" sectionFormat="of" target="name-terminatin g-the-delegation">Terminating the Delegation</xref></t>
</li> </li>
skipping to change at line 213 skipping to change at line 212
</li> </li>
<li pn="section-toc.1-1.7.2.3"> <li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent= "7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-new-acme-channels">New ACME Channels</xref></t> <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent= "7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-new-acme-channels">New ACME Channels</xref></t>
</li> </li>
<li pn="section-toc.1-1.7.2.4"> <li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent= "7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-restricting-cdns-to-th e-del">Restricting CDNs to the Delegation Mechanism</xref></t> <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent= "7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived Content="" format="title" sectionFormat="of" target="name-restricting-cdns-to-th e-del">Restricting CDNs to the Delegation Mechanism</xref></t>
</li> </li>
</ul> </ul>
</li> </li>
<li pn="section-toc.1-1.8"> <li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</ ormat="title" sectionFormat="of" target="name-references">References</xref></t>
xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
</li> n-toc.1-1.8.2">
<li pn="section-toc.1-1.9"> <li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f "8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
ormat="title" sectionFormat="of" target="name-references">References</xref></t> Content="" format="title" sectionFormat="of" target="name-normative-references">
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio Normative References</xref></t>
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-document-histor
y">Document History</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delega">draft-ietf-acme-star-delegation-09</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegat">draft-ietf-acme-star-delegation-08</xref></t>
</li>
<li pn="section-toc.1-1.10.2.3">
<t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent
="A.3" format="counter" sectionFormat="of" target="section-a.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegati">draft-ietf-acme-star-delegation-07</xref></t>
</li>
<li pn="section-toc.1-1.10.2.4">
<t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent
="A.4" format="counter" sectionFormat="of" target="section-a.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegatio">draft-ietf-acme-star-delegation-06</xref></t>
</li>
<li pn="section-toc.1-1.10.2.5">
<t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent
="A.5" format="counter" sectionFormat="of" target="section-a.5"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegation">draft-ietf-acme-star-delegation-05</xref></t>
</li>
<li pn="section-toc.1-1.10.2.6">
<t indent="0" pn="section-toc.1-1.10.2.6.1"><xref derivedContent
="A.6" format="counter" sectionFormat="of" target="section-a.6"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegation-">draft-ietf-acme-star-delegation-04</xref></t>
</li>
<li pn="section-toc.1-1.10.2.7">
<t indent="0" pn="section-toc.1-1.10.2.7.1"><xref derivedContent
="A.7" format="counter" sectionFormat="of" target="section-a.7"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegation-0">draft-ietf-acme-star-delegation-03</xref></t>
</li>
<li pn="section-toc.1-1.10.2.8">
<t indent="0" pn="section-toc.1-1.10.2.8.1"><xref derivedContent
="A.8" format="counter" sectionFormat="of" target="section-a.8"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegation-02">draft-ietf-acme-star-delegation-02</xref></t>
</li>
<li pn="section-toc.1-1.10.2.9">
<t indent="0" pn="section-toc.1-1.10.2.9.1"><xref derivedContent
="A.9" format="counter" sectionFormat="of" target="section-a.9"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-star-
delegation-01">draft-ietf-acme-star-delegation-01</xref></t>
</li>
<li pn="section-toc.1-1.10.2.10">
<t indent="0" pn="section-toc.1-1.10.2.10.1"><xref derivedConten
t="A.10" format="counter" sectionFormat="of" target="section-a.10"/>. <xref deri
vedContent="" format="title" sectionFormat="of" target="name-draft-ietf-acme-sta
r-delegation-00">draft-ietf-acme-star-delegation-00</xref></t>
</li>
<li pn="section-toc.1-1.10.2.11">
<t indent="0" pn="section-toc.1-1.10.2.11.1"><xref derivedConten
t="A.11" format="counter" sectionFormat="of" target="section-a.11"/>. <xref deri
vedContent="" format="title" sectionFormat="of" target="name-draft-sheffer-acme-
star-del">draft-sheffer-acme-star-delegation-01</xref></t>
</li> </li>
<li pn="section-toc.1-1.10.2.12"> <li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.10.2.12.1"><xref derivedConten <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
t="A.12" format="counter" sectionFormat="of" target="section-a.12"/>. <xref deri "8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
vedContent="" format="title" sectionFormat="of" target="name-draft-sheffer-acme- Content="" format="title" sectionFormat="of" target="name-informative-references
star-dele">draft-sheffer-acme-star-delegation-00</xref></t> ">Informative References</xref></t>
</li> </li>
</ul> </ul>
</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="Append ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-template-cd dl">CSR Template: CDDL</xref></t> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Append ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-template-cd dl">CSR Template: CDDL</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="Append ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-template-js on-schema">CSR Template: JSON Schema</xref></t> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Append ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csr-template-js on-schema">CSR Template: JSON Schema</xref></t>
</li> </li>
<li pn="section-toc.1-1.13"> <li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent=" at="none" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedConten
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add t="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledg
resses</xref></t> ements</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li> </li>
</ul> </ul>
</section> </section>
</toc> </toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa lse" pn="section-1"> <section anchor="introduction" numbered="true" toc="include" removeInRFC="fa lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name> <name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">This document is related to <xref target="R FC8739" format="default" sectionFormat="of" derivedContent="RFC8739"/>, in that some important use cases require both documents to be implemented. To avoid dupl ication, <t indent="0" pn="section-1-1">This document is related to <xref target="R FC8739" format="default" sectionFormat="of" derivedContent="RFC8739"/>, in that some important use cases require both documents to be implemented. To avoid dupl ication,
we give here a bare-bones description of the motivation for this solution. For we give here a bare-bones description of the motivation for this solution. For
more details, please refer to the introductory sections more details, please refer to the introductory sections
of <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t> of <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t>
<t indent="0" pn="section-1-2">An Identifier Owner (IdO) has agreements <t indent="0" pn="section-1-2">An Identifier Owner (IdO) has agreements
in place with one or more NDC (Name Delegation Consumer) to use and attest its in place with one or more Name Delegation Consumer (NDC) to use and attest its
identity.</t> identity.</t>
<t indent="0" pn="section-1-3">In the primary use case the IdO is a conten t 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 conte nt provider, and we consider a Content Delivery Network (CDN) provider contracte d to
serve the content over HTTPS. The CDN terminates the HTTPS connection at serve the content over HTTPS. The CDN terminates the HTTPS connection at
one of its edge cache servers and needs to present its clients (browsers, one of its edge cache servers and needs to present its clients (browsers,
mobile apps, set-top-boxes) a certificate whose name matches the domain name of mobile apps, set-top boxes) a certificate whose name matches the domain name of
the URL that is requested, i.e., that of the IdO. Understandably, some IdOs may the URL that is requested, i.e., that of the IdO. Understandably, some IdOs may
balk at sharing their long-term private keys with another organization and, balk at sharing their long-term private keys with another organization;
equally, delegates would rather not have to handle other parties' long-term equally, delegates would rather not have to handle other parties' long-term
secrets. Other relevant use cases are discussed in <xref target="further-use-cas es" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t> secrets. Other relevant use cases are discussed in <xref target="further-use-cas es" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t>
<t indent="0" pn="section-1-4">This document describes a profile of the AC ME protocol <xref target="RFC8555" format="default" sectionFormat="of" derivedCo ntent="RFC8555"/> that allows <t indent="0" pn="section-1-4">This document describes a profile of the AC ME protocol <xref target="RFC8555" format="default" sectionFormat="of" derivedCo ntent="RFC8555"/> that allows
the NDC to request from the IdO, acting as a profiled ACME server, a certificate for the NDC to request from the IdO, acting as a profiled ACME server, a certificate for
a delegated identity - i.e., one belonging to the IdO. The IdO then uses the a delegated identity -- i.e., one belonging to the IdO. The IdO then uses the
ACME protocol (with the extensions described in <xref target="RFC8739" format="d efault" sectionFormat="of" derivedContent="RFC8739"/>) to request ACME protocol (with the extensions described in <xref target="RFC8739" format="d efault" sectionFormat="of" derivedContent="RFC8739"/>) to request
issuance of a Short-Term, Automatically Renewed (STAR) certificate for the same delegated identity. The generated issuance of a Short-Term, Automatically Renewed (STAR) certificate for the same delegated identity. The generated
short-term certificate is automatically renewed by the ACME Certification short-term certificate is automatically renewed by the ACME Certification
Authority (CA), periodically fetched by the NDC and used to terminate HTTPS Authority (CA), is periodically fetched by the NDC, and is used to terminate HTT PS
connections in lieu of the IdO. The IdO can end the delegation at any time by connections in lieu of the IdO. The IdO can end the delegation at any time by
simply instructing the CA to stop the automatic renewal and letting the simply instructing the CA to stop the automatic renewal and letting the
certificate expire shortly thereafter.</t> certificate expire shortly thereafter.</t>
<t indent="0" pn="section-1-5">While the primary use case we address is de <t indent="0" pn="section-1-5">While the primary use case we address is a
legation of STAR certificates, the delegation of STAR certificates, the
mechanism proposed here accommodates also long-lived certificates managed with mechanism proposed here also accommodates long-lived certificates managed with
the ACME protocol. The most noticeable difference between long-lived and STAR the ACME protocol. The most noticeable difference between long-lived and STAR
certificates is the way the termination of the delegation is managed. In the certificates is the way the termination of the delegation is managed. In the
case of long-lived certificates, the IdO uses the revokeCert URL exposed by the case of long-lived certificates, the IdO uses the <tt>revokeCert</tt> URL expose
CA and waits for the explicit revocation based on Certificate Revocation d by the
CA and waits for the explicit revocation based on the Certificate Revocation
List (CRL) and Online Certificate Status Protocol (OCSP) to propagate to the List (CRL) and Online Certificate Status Protocol (OCSP) to propagate to the
relying parties.</t> relying parties.</t>
<t indent="0" pn="section-1-6">In case the delegated identity is a domain name, this document also provides a <t indent="0" pn="section-1-6">In case the delegated identity is a domain name, this document also provides a
way for the NDC to inform the IdO about the CNAME mappings that need to be way for the NDC to inform the IdO about the CNAME mappings that need to be
installed in the IdO's DNS zone to enable the aliasing of the delegated name, installed in the IdO's DNS zone to enable the aliasing of the delegated name,
thus allowing the complete name delegation workflow to be handled using a thus allowing the complete name delegation workflow to be handled using a
single interface.</t> single interface.</t>
<t indent="0" pn="section-1-7">We note that other standardization efforts address the problem of certificate delegation for TLS connections, specifically <xref target="I-D.ietf-tls-subcerts" format="default" sectionFormat="of" derived Content="I-D.ietf-tls-subcerts"/> and <xref target="I-D.mglt-lurk-tls13" format= "default" sectionFormat="of" derivedContent="I-D.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 compone nt. Compared to these other approaches, the current document does not require ch anges to the TLS network stack of the client or the server, nor does it introduc e additional latency to the TLS connection.</t> <t indent="0" pn="section-1-7">We note that other standardization efforts address the problem of certificate delegation for TLS connections, specifically <xref target="I-D.ietf-tls-subcerts" format="default" sectionFormat="of" derived Content="I-D.ietf-tls-subcerts"/> and <xref target="I-D.mglt-lurk-tls13" format= "default" sectionFormat="of" derivedContent="I-D.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 compone nt. Compared to these other approaches, the current document does not require ch anges to the TLS network stack of the client or the server, nor does it introduc e additional latency to the TLS connection.</t>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="f alse" pn="section-1.1"> <section anchor="terminology" numbered="true" toc="include" removeInRFC="f alse" pn="section-1.1">
<name slugifiedName="name-terminology">Terminology</name> <name slugifiedName="name-terminology">Terminology</name>
<dl indent="3" 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"> <dt pn="section-1.1-1.1">IdO</dt>
IdO </dt>
<dd pn="section-1.1-1.2"> <dd pn="section-1.1-1.2">
<t indent="0" pn="section-1.1-1.2.1">Identifier Owner, the holder (c urrent owner) of an identifier (e.g., a domain <t indent="0" pn="section-1.1-1.2.1">Identifier Owner, the holder (c urrent owner) of an identifier (e.g., a domain
name) that needs to be delegated. Depending on the context, the term IdO may name) that needs to be delegated. Depending on the context, the term IdO may
also be used to designate the (profiled) ACME server deployed by the Identifier also be used to designate the (profiled) ACME server deployed by the Identifier
Owner or the ACME client used by the Identifier Owner to interact with the CA.</ t> Owner or the ACME client used by the Identifier Owner to interact with the CA.</ t>
</dd> </dd>
<dt pn="section-1.1-1.3"> <dt pn="section-1.1-1.3">NDC</dt>
NDC </dt>
<dd pn="section-1.1-1.4"> <dd pn="section-1.1-1.4">
<t indent="0" pn="section-1.1-1.4.1">Name Delegation Consumer, the e ntity to which the domain name is <t indent="0" pn="section-1.1-1.4.1">Name Delegation Consumer, the e ntity to which the domain name is
delegated for a limited time. This is a CDN in the primary use delegated for a limited time. This is a CDN in the primary use
case (in fact, readers may note the similarity of the two case (in fact, readers may note the similarity of the two
acronyms). Depending on the context, the term NDC may abbreviations). Depending on the context, the term NDC may
also be used to designate the (profiled) ACME client used by the Name also be used to designate the (profiled) ACME client used by the Name
Delegation Consumer.</t> Delegation Consumer.</t>
</dd> </dd>
<dt pn="section-1.1-1.5"> <dt pn="section-1.1-1.5">CDN</dt>
CDN </dt>
<dd pn="section-1.1-1.6"> <dd pn="section-1.1-1.6">
<t indent="0" pn="section-1.1-1.6.1">Content Delivery Network, a wid ely distributed network that <t indent="0" pn="section-1.1-1.6.1">Content Delivery Network, a wid ely distributed network that
serves the domain's web content to a wide audience at high serves the domain's web content to a wide audience at high
performance.</t> performance.</t>
</dd> </dd>
<dt pn="section-1.1-1.7"> <dt pn="section-1.1-1.7">STAR</dt>
STAR </dt>
<dd pn="section-1.1-1.8"> <dd pn="section-1.1-1.8">
<t indent="0" pn="section-1.1-1.8.1">Short-Term, Automatically Renew ed X.509 certificates.</t> <t indent="0" pn="section-1.1-1.8.1">Short-Term, Automatically Renew ed, as applied to X.509 certificates.</t>
</dd> </dd>
<dt pn="section-1.1-1.9"> <dt pn="section-1.1-1.9">ACME</dt>
ACME </dt>
<dd pn="section-1.1-1.10"> <dd pn="section-1.1-1.10">
<t indent="0" pn="section-1.1-1.10.1">Automated Certificate Manageme nt Environment, a <t indent="0" pn="section-1.1-1.10.1">Automated Certificate Manageme nt Environment, a
certificate management protocol <xref target="RFC8555" format="default" sectionF ormat="of" derivedContent="RFC8555"/>.</t> certificate management protocol <xref target="RFC8555" format="default" sectionF ormat="of" derivedContent="RFC8555"/>.</t>
</dd> </dd>
<dt pn="section-1.1-1.11"> <dt pn="section-1.1-1.11">CA</dt>
CA </dt>
<dd pn="section-1.1-1.12"> <dd pn="section-1.1-1.12">
<t indent="0" pn="section-1.1-1.12.1">A Certification Authority that implements the ACME protocol. In this document, the term is synonymous with "AC ME server deployed by the Certification Authority".</t> <t indent="0" pn="section-1.1-1.12.1">Certification Authority, speci fically one that implements the ACME protocol. In this document, the term is syn onymous with "ACME server deployed by the Certification Authority".</t>
</dd> </dd>
<dt pn="section-1.1-1.13"> <dt pn="section-1.1-1.13">CSR</dt>
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">A PKCS#10 <xref target="RFC298 6" format="default" sectionFormat="of" derivedContent="RFC2986"/> Certificate Si gning Request, as supported by ACME.</t> <t indent="0" pn="section-1.1-1.14.1">Certificate Signing Request, s pecifically a PKCS#10 <xref target="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/> Certificate Signing Request, as supported by ACME.</ t>
</dd> </dd>
<dt pn="section-1.1-1.15"> <dt pn="section-1.1-1.15">FQDN</dt>
FQDN </dt>
<dd pn="section-1.1-1.16"> <dd pn="section-1.1-1.16">
<t indent="0" pn="section-1.1-1.16.1">Fully Qualified Domain Name.</ t> <t indent="0" pn="section-1.1-1.16.1">Fully Qualified Domain Name.</ t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="conventions-used-in-this-document" numbered="true" toc="i nclude" removeInRFC="false" pn="section-1.2"> <section anchor="conventions-used-in-this-document" numbered="true" toc="i nclude" removeInRFC="false" pn="section-1.2">
<name slugifiedName="name-conventions-used-in-this-do">Conventions used <name slugifiedName="name-conventions-used-in-this-do">Conventions Used
in this document</name> in This Document</name>
<t indent="0" pn="section-1.2-1">The key words "MUST", "MUST NOT", "REQU <t indent="0" pn="section-1.2-1">
IRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", </bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" d erivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat= "of" derivedContent="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" d erivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat= "of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="sec-protocol-flow" numbered="true" toc="include" removeInRF C="false" pn="section-2"> <section anchor="sec-protocol-flow" numbered="true" toc="include" removeInRF C="false" pn="section-2">
<name slugifiedName="name-protocol-flow">Protocol Flow</name> <name slugifiedName="name-protocol-flow">Protocol Flow</name>
<t indent="0" pn="section-2-1">This section presents the protocol flow. F or completeness, we include the ACME <t indent="0" pn="section-2-1">This section presents the protocol flow. F or completeness, we include the ACME
profile proposed in this document as well as the ACME STAR protocol described profile proposed in this document as well as the ACME STAR protocol described
in <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t> in <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RF C8739"/>.</t>
<section anchor="proto-preconditions" numbered="true" toc="include" remove InRFC="false" pn="section-2.1"> <section anchor="proto-preconditions" numbered="true" toc="include" remove InRFC="false" pn="section-2.1">
<name slugifiedName="name-preconditions">Preconditions</name> <name slugifiedName="name-preconditions">Preconditions</name>
<t indent="0" pn="section-2.1-1">The protocol assumes the following prec onditions are met:</t> <t indent="0" pn="section-2.1-1">The protocol assumes the following prec onditions are met:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- 2.1-2"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2 .1-2">
<li pn="section-2.1-2.1">The IdO exposes an ACME server interface to t he NDC(s) comprising the account <li pn="section-2.1-2.1">The IdO exposes an ACME server interface to t he NDC(s) comprising the account
management interface;</li> management interface.</li>
<li pn="section-2.1-2.2">The NDC has registered an ACME account with t <li pn="section-2.1-2.2">The NDC has registered an ACME account with t
he IdO;</li> he IdO.</li>
<li pn="section-2.1-2.3">NDC and IdO have agreed on a "CSR template" t <li pn="section-2.1-2.3">The NDC and IdO have agreed on a "CSR templat
o use, including at a minimum: e" to use, including at a minimum:
subject name (e.g., <tt>abc.ido.example</tt>), requested algorithms and key subject name (e.g., <tt>abc.ido.example</tt>), requested algorithms and key
length, key usage, extensions. The NDC will use length, key usage, and extensions. The NDC will use
this template for every CSR created under the same delegation;</li> this template for every CSR created under the same delegation.</li>
<li pn="section-2.1-2.4">IdO has registered an ACME account with the C <li pn="section-2.1-2.4">The IdO has registered an ACME account with t
ertification Authority (CA)</li> he Certification Authority (CA).</li>
</ul> </ul>
<t indent="0" pn="section-2.1-3">Note that even if the IdO implements th e ACME server role, it is not acting as <t indent="0" pn="section-2.1-3">Note that even if the IdO implements th e ACME server role, it is not acting as
a CA: in fact, from the point of view of the certificate issuance process, the a CA; in fact, from the point of view of the certificate issuance process, the
IdO only works as a "policing" forwarder of the NDC's key-pair and is IdO only works as a "policing" forwarder of the NDC's key pair and is
responsible for completing the identity verification process towards the CA.</t> responsible for completing the identity verification process towards the CA.</t>
</section> </section>
<section anchor="overview" numbered="true" toc="include" removeInRFC="fals e" pn="section-2.2"> <section anchor="overview" numbered="true" toc="include" removeInRFC="fals e" pn="section-2.2">
<name slugifiedName="name-overview">Overview</name> <name slugifiedName="name-overview">Overview</name>
<t indent="0" pn="section-2.2-1">For clarity, the protocol overview pres ented here covers the main use case of this protocol, <t indent="0" pn="section-2.2-1">For clarity, the protocol overview pres ented here covers the main use case of this protocol,
namely delegation of STAR certificates. Protocol behavior for non-STAR certifica tes is similar, namely delegation of STAR certificates. Protocol behavior for non-STAR certifica tes is similar,
and the detailed differences are listed in the following sections.</t> and the detailed differences are listed in the following sections.</t>
<t indent="0" pn="section-2.2-2">The interaction between the NDC and the IdO is governed by the profiled ACME <t indent="0" pn="section-2.2-2">The interaction between the NDC and the IdO is governed by the profiled ACME
workflow detailed in <xref target="sec-profile" format="default" sectionFormat=" of" derivedContent="Section 2.3"/>. The interaction between the IdO and the workflow detailed in <xref target="sec-profile" format="default" sectionFormat=" of" derivedContent="Section 2.3"/>. The interaction between the IdO and the
CA is ruled by ACME <xref target="RFC8555" format="default" sectionFormat="of" d CA is ruled by ACME <xref target="RFC8555" format="default" sectionFormat="of" d
erivedContent="RFC8555"/>, ACME STAR <xref target="RFC8739" format="default" sec erivedContent="RFC8555"/>, ACME STAR <xref target="RFC8739" format="default" sec
tionFormat="of" derivedContent="RFC8739"/> as well as any other ACME extension t tionFormat="of" derivedContent="RFC8739"/>, and any other ACME extension that
hat applies (e.g., <xref target="I-D.ietf-acme-authority-token-tnauthlist" format="d
applies (e.g., <xref target="I-D.ietf-acme-authority-token-tnauthlist" format="d efault" sectionFormat="of" derivedContent="I-D.ietf-acme-authority-token-tnauthl
efault" sectionFormat="of" derivedContent="I-D.ietf-acme-authority-token-tnauthl ist"/> for Secure Telephone Identity Revisited (STIR)).</t>
ist"/> for STIR).</t> <t indent="0" pn="section-2.2-3">The outline of the combined protocol fo
<t indent="0" pn="section-2.2-3">The outline of the combined protocol fo r STAR certificates is as follows (<xref target="fig-endtoend" format="default"
r STAR certificates is as follow (<xref target="fig-endtoend" format="default" s sectionFormat="of" derivedContent="Figure 1"/>):</t>
ectionFormat="of" derivedContent="Figure 1"/>):</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- .2-4">
2.2-4"> <li pn="section-2.2-4.1">NDC sends an Order1 for the delegated identif
<li pn="section-2.2-4.1">NDC sends an order Order1 for the delegated i ier to IdO.</li>
dentifier to IdO;</li> <li pn="section-2.2-4.2">IdO creates an Order1 resource in state <tt>r
<li pn="section-2.2-4.2">IdO creates an Order1 resource in state <tt>r eady</tt> with a <tt>finalize</tt> URL.</li>
eady</tt> with a <tt>finalize</tt> URL;</li> <li pn="section-2.2-4.3">NDC immediately sends a <tt>finalize</tt> req
<li pn="section-2.2-4.3">NDC immediately sends a finalize request (whi uest (which includes the CSR) to the IdO.</li>
ch includes the CSR) to the IdO;</li> <li pn="section-2.2-4.4">IdO verifies the CSR according to the agreed
<li pn="section-2.2-4.4">IdO verifies the CSR according to the agreed upon CSR template.</li>
upon CSR template;</li>
<li pn="section-2.2-4.5">If the CSR verification fails, Order1 is move d to an <tt>invalid</tt> state and <li pn="section-2.2-4.5">If the CSR verification fails, Order1 is move d to an <tt>invalid</tt> state and
everything stops;</li> everything stops.</li>
<li pn="section-2.2-4.6">If the CSR verification is successful, IdO mo ves Order1 to state <li pn="section-2.2-4.6">If the CSR verification is successful, IdO mo ves Order1 to state
<tt>processing</tt>, and sends a new Order2 (using its own account) for the dele <tt>processing</tt> and sends a new Order2 (using its own account) for the deleg
gated ated
identifier to the CA;</li> identifier to the CA.</li>
<li pn="section-2.2-4.7">If the ACME STAR protocol fails, Order2 moves <li pn="section-2.2-4.7">If the ACME STAR protocol fails, Order2 moves
to <tt>invalid</tt> and the same state to <tt>invalid</tt>, and the same state
is reflected in Order1 (i.e., the NDC Order);</li> is reflected in Order1 (i.e., the NDC Order).</li>
<li pn="section-2.2-4.8">If the ACME STAR run is successful (i.e., Ord er2 is <tt>valid</tt>), IdO copies the <li pn="section-2.2-4.8">If the ACME STAR run is successful (i.e., Ord er2 is <tt>valid</tt>), IdO copies the
<tt>star-certificate</tt> URL from Order2 to Order1 and updates the Order1 state to <tt>star-certificate</tt> URL from Order2 to Order1 and updates the Order1 state to
<tt>valid</tt>.</li> <tt>valid</tt>.</li>
</ul> </ul>
<t indent="0" pn="section-2.2-5">The NDC can now download, install and u <t indent="0" pn="section-2.2-5">The NDC can now download, install, and
se the short-term certificate bearing use the short-term certificate bearing the name delegated by the IdO. The STAR c
the name delegated by the IdO. This can continue until the STAR certificate ertificate can be used until it expires, at which time the NDC is guaranteed to
expires or the IdO decides to cancel the automatic renewal process with the CA.< find a new certificate it can download, install, and use. This continues with su
/t> bsequent certificates until either Order1 expires or the IdO decides to cancel t
<t indent="0" pn="section-2.2-6">Note that the interactive identifier au he automatic renewal process with the CA.</t>
thorization phase described in Section <t indent="0" pn="section-2.2-6">Note that the interactive identifier au
7.5 of <xref target="RFC8555" format="default" sectionFormat="of" derivedContent thorization phase described in <xref target="RFC8555" format="default" sectionFo
="RFC8555"/> is suppressed on the NDC-IdO side because the delegated rmat="of" derivedContent="RFC8555" section="7.5"/> is suppressed on the NDC-IdO
side because the delegated
identity contained in the CSR presented to the IdO is validated against the identity contained in the CSR presented to the IdO is validated against the
configured CSR template (<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" derivedContent="Section 4.1"/>). Therefore, the NDC configured CSR template (<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" derivedContent="Section 4.1"/>). Therefore, the NDC
sends the finalize request, including the CSR, to the IdO immediately after sends the <tt>finalize</tt> request, including the CSR, to the IdO immediately a
Order1 has been acknowledged. The IdO SHALL buffer a (valid) CSR until the fter
Order1 has been acknowledged. The IdO <bcp14>SHALL</bcp14> buffer a (valid) CSR
until the
Validation phase completes successfully.</t> Validation phase completes successfully.</t>
<t indent="0" pn="section-2.2-7">Also note that the successful negotiati <t indent="0" pn="section-2.2-7">Also note that the successful negotiati
on of the "unauthenticated GET" (Section on of the unauthenticated GET (<xref target="RFC8739" format="default" sectionFo
3.4 of <xref target="RFC8739" format="default" sectionFormat="of" derivedContent rmat="of" derivedContent="RFC8739" section="3.4"/>) is required in order to allo
="RFC8739"/>) is required in order to allow the NDC to access the w the NDC to access the
<tt>star-certificate</tt> URL on the CA.</t> <tt>star-certificate</tt> URL on the CA.</t>
<figure anchor="fig-endtoend" align="left" suppress-title="false" pn="fi gure-1"> <figure anchor="fig-endtoend" align="left" suppress-title="false" pn="fi gure-1">
<name slugifiedName="name-end-to-end-star-delegation-">End to end STAR delegation flow</name> <name slugifiedName="name-end-to-end-star-delegation-">End-to-End STAR Delegation Flow</name>
<artset pn="section-2.2-8.1"> <artset pn="section-2.2-8.1">
<artwork type="svg" name="" align="left" alt="" pn="section-2.2-8.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" height= "841" width="480" viewBox="0 0 480.0 841.0"> <artwork type="svg" name="" align="left" alt="" pn="section-2.2-8.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 720.0 841.0">
<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 1015 skipping to change at line 962
o------------------------------------------------>| o------------------------------------------------>|
| Certificate #n | | Certificate #n |
|<------------------------------------------------o |<------------------------------------------------o
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="sec-profile" numbered="true" toc="include" removeInRFC="f alse" pn="section-2.3"> <section anchor="sec-profile" numbered="true" toc="include" removeInRFC="f alse" pn="section-2.3">
<name slugifiedName="name-delegated-identity-profile">Delegated Identity Profile</name> <name slugifiedName="name-delegated-identity-profile">Delegated Identity Profile</name>
<t indent="0" pn="section-2.3-1">This section defines a profile of the A CME protocol, to be used between the NDC <t indent="0" pn="section-2.3-1">This section defines a profile of the A CME protocol to be used between the NDC
and IdO.</t> and IdO.</t>
<section anchor="sec-profile-dele-config" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.1"> <section anchor="sec-profile-dele-config" numbered="true" toc="include" removeInRFC="false" pn="section-2.3.1">
<name slugifiedName="name-delegation-configuration">Delegation Configu ration</name> <name slugifiedName="name-delegation-configuration">Delegation Configu ration</name>
<t indent="0" pn="section-2.3.1-1">The IdO must be preconfigured to re cognize one or more NDCs, and present them with <t indent="0" pn="section-2.3.1-1">The IdO must be preconfigured to re cognize one or more NDCs and present them with
details about certificate delegations that apply to each one.</t> details about certificate delegations that apply to each one.</t>
<section anchor="account-object-extensions" numbered="true" toc="exclu de" removeInRFC="false" pn="section-2.3.1.1"> <section anchor="account-object-extensions" numbered="true" toc="exclu de" removeInRFC="false" 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 a NDC, and these configurations are described through multiple names to an NDC, and these configurations are described through
<tt>delegation</tt> objects associated with the NDC's Account object on the IdO. <tt>delegation</tt> objects associated with the NDC's account object on the IdO.
</t> </t>
<t indent="0" pn="section-2.3.1.1-2">As shown in <xref target="fig-a ccount-object" format="default" sectionFormat="of" derivedContent="Figure 2"/>, the ACME account resource on the IdO is <t indent="0" pn="section-2.3.1.1-2">As shown in <xref target="fig-a ccount-object" format="default" sectionFormat="of" derivedContent="Figure 2"/>, the ACME account resource on the IdO is
extended with a new <tt>delegations</tt> attribute:</t> extended with a new <tt>delegations</tt> attribute:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect <dl newline="false" spacing="normal" pn="section-2.3.1.1-3">
ion-2.3.1.1-3"> <dt pn="section-2.3.1.1-3.1">delegations (required, string):</dt>
<li pn="section-2.3.1.1-3.1">delegations (required, string): A URL <dd>A URL from which a list of delegations
from which a list of delegations
configured for this account (<xref target="sec-delegation-objects" format="defau lt" sectionFormat="of" derivedContent="Section 2.3.1.3"/>) can be fetched via a configured for this account (<xref target="sec-delegation-objects" format="defau lt" sectionFormat="of" derivedContent="Section 2.3.1.3"/>) can be fetched via a
POST-as-GET request.</li> POST-as-GET request.</dd>
</ul> </dl>
<figure anchor="fig-account-object" align="left" suppress-title="fal se" pn="figure-2"> <figure anchor="fig-account-object" align="left" suppress-title="fal se" pn="figure-2">
<name slugifiedName="name-example-account-object-with">Example Acc ount object with delegations</name> <name slugifiedName="name-example-account-object-with">Example Acc ount Object with Delegations</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.1.1-4 .1"><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-2.3.1.1-4 .1"><![CDATA[
{ {
"status": "valid", "status": "valid",
"contact": [ "contact": [
"mailto:delegation-admin@ido.example" "mailto:delegation-admin@ido.example"
], ],
"termsOfServiceAgreed": true, "termsOfServiceAgreed": true,
"orders": "https://example.com/acme/orders/saHpfB", "orders": "https://example.com/acme/orders/saHpfB",
"delegations": "https://acme.ido.example/acme/delegations/adFqoz" "delegations": "https://acme.ido.example/acme/delegations/adFqoz"
} }
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="delegation-lists" numbered="true" toc="exclude" remov eInRFC="false" pn="section-2.3.1.2"> <section anchor="delegation-lists" numbered="true" toc="exclude" remov eInRFC="false" 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 POST-as-GET delegation configurations created by the IdO can be fetched via a POST-as-GET
request. The result of the request MUST be a JSON object whose <tt>delegations< request. The result of the request <bcp14>MUST</bcp14> be a JSON object whose <
/tt> tt>delegations</tt>
field is an array of URLs, each identifying a delegation configuration made field is an array of URLs, each identifying a delegation configuration made
available to the NDC account (<xref target="sec-delegation-objects" format="defa available to the NDC account (<xref target="sec-delegation-objects" format="defa
ult" sectionFormat="of" derivedContent="Section 2.3.1.3"/>). The server MAY ult" sectionFormat="of" derivedContent="Section 2.3.1.3"/>). The server <bcp14>
return an incomplete list, along with a Link header field with a <tt>next</tt> l MAY</bcp14>
ink return an incomplete list, along with a <tt>Link</tt> header field with a <tt>ne
xt</tt> link
relation indicating where further entries can be acquired.</t> relation indicating where further entries can be acquired.</t>
<artwork name="" type="" align="left" alt="" pn="section-2.3.1.2-2"> <![CDATA[ <sourcecode name="" type="json" pn="section-2.3.1.2-2"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Link: <https://acme.ido.example/acme/directory>;rel="index" Link: <https://acme.ido.example/acme/directory>;rel="index"
Link: <https://acme.ido.example/acme/delegations/adFqoz?cursor=2>;rel="next" Link: <https://acme.ido.example/acme/delegations/adFqoz?/
cursor=2>;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"
] ]
} }
]]></artwork> ]]></sourcecode>
<t>Note that in the figure above, https://acme.ido.example/acme/delegations/adFq
oz?cursor=2 includes a line break
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" toc="exclude" removeInRFC="false" pn="section-2.3.1.3">
<name slugifiedName="name-delegation-objects">Delegation Objects</na me> <name slugifiedName="name-delegation-objects">Delegation Objects</na me>
<t indent="0" pn="section-2.3.1.3-1">This profile extends the ACME r esource model with a new read-only delegation <t indent="0" pn="section-2.3.1.3-1">This profile extends the ACME r esource model with a new read-only <tt>delegation</tt>
object that represents a delegation configuration that applies to a given NDC.</ t> object that represents a delegation configuration that applies to a given NDC.</ t>
<t indent="0" pn="section-2.3.1.3-2">A delegation object contains th <t indent="0" pn="section-2.3.1.3-2">A <tt>delegation</tt> object co
e CSR template (see <xref target="sec-csr-template" format="default" sectionForm ntains the CSR template (see <xref target="sec-csr-template" format="default" se
at="of" derivedContent="Section 4"/>) that ctionFormat="of" derivedContent="Section 4"/>) that
applies to that delegation, and optionally any related CNAME mapping for the applies to that delegation and, optionally, any related CNAME mapping for the
delegated identifiers. Its structure is as follows:</t> delegated identifiers. Its structure is as follows:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect <dl spacing="normal" newline="false" indent="3" pn="section-2.3.1.3-
ion-2.3.1.3-3"> 3">
<li pn="section-2.3.1.3-3.1">csr-template (required, object): CSR <dt pn="section-2.3.1.3-3.1">csr-template (required, object):</dt>
template as defined in <dd>CSR template, as defined in
<xref target="sec-csr-template" format="default" sectionFormat="of" derivedConte <xref target="sec-csr-template" format="default" sectionFormat="of" derivedConte
nt="Section 4"/>.</li> nt="Section 4"/>.</dd>
<li pn="section-2.3.1.3-3.2">cname-map (optional, object): a map o <dt pn="section-2.3.1.3-3.2">cname-map (optional, object):</dt>
f FQDN pairs. In each pair, the name is <dd>A map of FQDN pairs. In each pair, the name is
the delegated identifier, the value is the corresponding NDC name that is the delegated identifier; the value is the corresponding NDC name that is
aliased in the IdO's zone file to redirect the resolvers to the delegated aliased in the IdO's zone file to redirect the resolvers to the delegated
entity. Both names and values MUST 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>.</li> .'.
</ul> This field is only meaningful for identifiers of type <tt>dns</tt>.</dd>
<t indent="0" pn="section-2.3.1.3-4">An example delegation object in </dl>
JSON format is shown in <t indent="0" pn="section-2.3.1.3-4">An example <tt>delegation</tt>
object in JSON format is shown in
<xref target="fig-configuration-object" format="default" sectionFormat="of" deri vedContent="Figure 3"/>.</t> <xref target="fig-configuration-object" format="default" sectionFormat="of" deri vedContent="Figure 3"/>.</t>
<figure anchor="fig-configuration-object" align="left" suppress-titl e="false" pn="figure-3"> <figure anchor="fig-configuration-object" align="left" suppress-titl e="false" pn="figure-3">
<name slugifiedName="name-example-delegation-configur">Example Del <name slugifiedName="name-example-delegation-configur">Example Del
egation Configuration object</name> egation Configuration Object</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.1.3-5 <sourcecode name="" type="json" pn="section-2.3.1.3-5.1"><![CDATA[
.1"><![CDATA[
{ {
"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 1126 skipping to change at line 1079
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth" "serverAuth"
] ]
} }
}, },
"cname-map": { "cname-map": {
"abc.ido.example.": "abc.ndc.example." "abc.ido.example.": "abc.ndc.example."
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.1.3-6">In order to indicate which spec ific delegation applies to the requested <t indent="0" pn="section-2.3.1.3-6">In order to indicate which spec ific delegation applies to the requested
certificate a new <tt>delegation</tt> attribute is added to the certificate, a new <tt>delegation</tt> attribute is added to the
request object on the NDC-IdO side (see <xref target="fig-star-ndc-neworder" for order object on the NDC-IdO side (see Figures <xref target="fig-star-ndc-neworde
mat="default" sectionFormat="of" derivedContent="Figure 4"/> r" format="counter" sectionFormat="of" derivedContent="Figure 4"/>
and <xref target="fig-non-star-ndc-neworder" format="default" sectionFormat="of" and <xref target="fig-non-star-ndc-neworder" format="counter" sectionFormat="of"
derivedContent="Figure 7"/>). The derivedContent="Figure 7"/>). The
value of this attribute is the URL pointing to the delegation configuration value of this attribute is the URL pointing to the delegation configuration
object that is to be used for this certificate request. If the <tt>delegation</ tt> object that is to be used for this certificate request. If the <tt>delegation</ tt>
attribute in the Order object contains a URL that does not correspond to a attribute in the order object contains a URL that does not correspond to a
configuration available to the requesting ACME account, the IdO MUST return an e configuration available to the requesting ACME account, the IdO <bcp14>MUST</bcp
rror 14> return an error
response with status code 403 (Forbidden), providing a problem document response with status code 403 (Forbidden), providing a problem document
<xref target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC78 07"/> with type <tt>urn:ietf:params:acme:error:unknownDelegation</tt>.</t> <xref target="RFC7807" format="default" sectionFormat="of" derivedContent="RFC78 07"/> with type <tt>urn:ietf:params:acme:error:unknownDelegation</tt>.</t>
</section> </section>
</section> </section>
<section anchor="sec-profile-star-order-journey" numbered="true" toc="in clude" removeInRFC="false" pn="section-2.3.2"> <section anchor="sec-profile-star-order-journey" numbered="true" toc="in clude" removeInRFC="false" pn="section-2.3.2">
<name slugifiedName="name-order-object-transmitted-fr">Order Object Tr ansmitted from NDC to IdO and to ACME Server (STAR)</name> <name slugifiedName="name-order-object-transmitted-fr">Order Object Tr ansmitted from NDC to IdO and to ACME Server (STAR)</name>
<t indent="0" pn="section-2.3.2-1">If the delegation is for a STAR cer tificate, the request object created by the <t indent="0" pn="section-2.3.2-1">If the delegation is for a STAR cer tificate, the request object created by the
NDC:</t> NDC:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.2-2"> -2.3.2-2">
<li pn="section-2.3.2-2.1">MUST have a <tt>delegation</tt> attribute <li pn="section-2.3.2-2.1"><bcp14>MUST</bcp14> have a <tt>delegation
indicating the preconfigured 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">MUST have entries in the <tt>identifiers< /tt> field for each delegated name <li pn="section-2.3.2-2.2"><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">MUST NOT contain the <tt>notBefore</tt> a <li pn="section-2.3.2-2.3"><bcp14>MUST NOT</bcp14> contain the <tt>n
nd <tt>notAfter</tt> fields;</li> otBefore</tt> and <tt>notAfter</tt> fields; and</li>
<li pn="section-2.3.2-2.4">MUST contain an <tt>auto-renewal</tt> obj <li pn="section-2.3.2-2.4"><bcp14>MUST</bcp14> contain an <tt>auto-r
ect and inside it, the fields enewal</tt> object and, inside it, the fields
listed in Section 3.1.1 of <xref target="RFC8739" format="default" sectionFormat listed in <xref target="RFC8739" format="default" sectionFormat="of" derivedCont
="of" derivedContent="RFC8739"/>. In particular, the ent="RFC8739" section="3.1.1"/>. In particular, the
<tt>allow-certificate-get</tt> attribute MUST be present and set to true.</li> <tt>allow-certificate-get</tt> attribute <bcp14>MUST</bcp14> be present and set
to true.</li>
</ul> </ul>
<figure anchor="fig-star-ndc-neworder" align="left" suppress-title="fa lse" pn="figure-4"> <figure anchor="fig-star-ndc-neworder" align="left" suppress-title="fa lse" pn="figure-4">
<name slugifiedName="name-new-star-order-from-ndc">New STAR Order fr om NDC</name> <name slugifiedName="name-new-star-order-from-ndc">New STAR Order fr om NDC</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.2-3.1"> <![CDATA[ <sourcecode name="" type="json" pn="section-2.3.2-3.1"><![CDATA[
POST /acme/new-order HTTP/1.1 POST /acme/new-order HTTP/1.1
Host: acme.ido.example Host: acme.ido.example
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
"nonce": "Alc00Ap6Rt7GMkEl3L1JX5", "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
"url": "https://acme.ido.example/acme/new-order" "url": "https://acme.ido.example/acme/new-order"
skipping to change at line 1185 skipping to change at line 1138
"auto-renewal": { "auto-renewal": {
"end-date": "2021-04-20T00:00:00Z", "end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600, // 4 days "lifetime": 345600, // 4 days
"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"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.2-4">The Order object that is created on <t indent="0" pn="section-2.3.2-4">The order object that is created on
the IdO:</t> the IdO:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.2-5"> -2.3.2-5">
<li pn="section-2.3.2-5.1">MUST start in the <tt>ready</tt> state;</ <li pn="section-2.3.2-5.1"><bcp14>MUST</bcp14> start in the <tt>read
li> y</tt> state;</li>
<li pn="section-2.3.2-5.2">MUST contain an <tt>authorizations</tt> a <li pn="section-2.3.2-5.2"><bcp14>MUST</bcp14> contain an <tt>author
rray with zero elements;</li> izations</tt> array with zero elements;</li>
<li pn="section-2.3.2-5.3">MUST contain the indicated <tt>delegation <li pn="section-2.3.2-5.3"><bcp14>MUST</bcp14> contain the indicated
</tt> configuration;</li> <tt>delegation</tt> configuration;</li>
<li pn="section-2.3.2-5.4">MUST contain the indicated <tt>auto-renew <li pn="section-2.3.2-5.4"><bcp14>MUST</bcp14> contain the indicated
al</tt> settings;</li> <tt>auto-renewal</tt> settings; and</li>
<li pn="section-2.3.2-5.5">MUST NOT contain the <tt>notBefore</tt> a <li pn="section-2.3.2-5.5"><bcp14>MUST NOT</bcp14> contain the <tt>n
nd <tt>notAfter</tt> fields.</li> otBefore</tt> and <tt>notAfter</tt> fields.</li>
</ul> </ul>
<figure anchor="fig-star-ido-order-resource-created" align="left" supp ress-title="false" pn="figure-5"> <figure anchor="fig-star-ido-order-resource-created" align="left" supp ress-title="false" pn="figure-5">
<name slugifiedName="name-star-order-resource-created">STAR Order Re source Created on IdO</name> <name slugifiedName="name-star-order-resource-created">STAR Order Re source Created on IdO</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.2-6.1"> <![CDATA[ <sourcecode name="" type="json" pn="section-2.3.2-6.1"><![CDATA[
{ {
"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 1222 skipping to change at line 1175
"allow-certificate-get": true "allow-certificate-get": true
}, },
"delegation": "delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen", "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize" "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.2-7">The Order is then finalized by the NDC supplying the CSR containing the <t indent="0" pn="section-2.3.2-7">The Order is then finalized by the NDC supplying the CSR containing the
delegated identifiers. The IdO checks the provided CSR against the template delegated identifiers. The IdO checks the provided CSR against the template
contained in the delegation object that applies to this request, as described in contained in the <tt>delegation</tt> object that applies to this request, as des cribed in
<xref target="sec-csr-template-syntax" format="default" sectionFormat="of" deriv edContent="Section 4.1"/>. If the CSR fails validation for any of the <xref target="sec-csr-template-syntax" format="default" sectionFormat="of" deriv edContent="Section 4.1"/>. If the CSR fails validation for any of the
identifiers, the IdO MUST return an error response with status code 403 identifiers, the IdO <bcp14>MUST</bcp14> return an error response with status co de 403
(Forbidden) and an appropriate type, e.g., <tt>rejectedIdentifier</tt> or <tt>ba dCSR</tt>. (Forbidden) and an appropriate type, e.g., <tt>rejectedIdentifier</tt> or <tt>ba dCSR</tt>.
The error response SHOULD contain subproblems (Section 6.7.1 of <xref target="RF The error response <bcp14>SHOULD</bcp14> contain subproblems (<xref target="RFC8
C8555" format="default" sectionFormat="of" derivedContent="RFC8555"/>) 555" format="default" sectionFormat="of" derivedContent="RFC8555" section="6.7.1
for each failed identifier. If the CSR is successfully validated, the Order "/>)
for each failed identifier. If the CSR is successfully validated, the order
object status moves to <tt>processing</tt> and the twin ACME protocol instance i s object status moves to <tt>processing</tt> and the twin ACME protocol instance i s
initiated on the IdO-CA side.</t> initiated on the IdO-CA side.</t>
<t indent="0" pn="section-2.3.2-8">The request object created by the I dO:</t> <t indent="0" pn="section-2.3.2-8">The request object created by the I dO:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.2-9"> -2.3.2-9">
<li pn="section-2.3.2-9.1">MUST copy the identifiers sent by the NDC <li pn="section-2.3.2-9.1"><bcp14>MUST</bcp14> copy the identifiers
;</li> sent by the NDC;</li>
<li pn="section-2.3.2-9.2">MUST strip the <tt>delegation</tt> attrib <li pn="section-2.3.2-9.2"><bcp14>MUST</bcp14> strip the <tt>delegat
ute;</li> ion</tt> attribute; and</li>
<li pn="section-2.3.2-9.3">MUST carry a copy of the <tt>auto-renewal <li pn="section-2.3.2-9.3"><bcp14>MUST</bcp14> carry a copy of the <
</tt> object sent by the NDC.</li> tt>auto-renewal</tt> object sent by the NDC.</li>
</ul> </ul>
<t indent="0" pn="section-2.3.2-10">When the identifiers' authorizatio n has been successfully completed and the <t indent="0" pn="section-2.3.2-10">When the identifiers' authorizatio n has been successfully completed and the
certificate has been issued by the CA, the IdO:</t> certificate has been issued by the CA, the IdO:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.2-11"> -2.3.2-11">
<li pn="section-2.3.2-11.1">MUST move its Order resource status to < <li pn="section-2.3.2-11.1"><bcp14>MUST</bcp14> move its Order resou
tt>valid</tt>;</li> rce status to <tt>valid</tt> and</li>
<li pn="section-2.3.2-11.2">MUST copy the <tt>star-certificate</tt> <li pn="section-2.3.2-11.2"><bcp14>MUST</bcp14> copy the <tt>star-ce
field from the STAR Order returned by the CA rtificate</tt> field from the STAR Order returned by the CA
into its Order resource. When dereferenced, the <tt>star-certificate</tt> URL into its Order resource. When dereferenced, the <tt>star-certificate</tt> URL
includes (via the Cert-Not-Before and Cert-Not-After HTTP header fields) the ren ewal timers includes (via the <tt>Cert-Not-Before</tt> and <tt>Cert-Not-After</tt> HTTP head er fields) the renewal timers
needed by the NDC to inform its certificate reload logic.</li> needed by the NDC to inform its certificate reload logic.</li>
</ul> </ul>
<figure anchor="fig-star-ido-order-resource-updated" align="left" supp ress-title="false" pn="figure-6"> <figure anchor="fig-star-ido-order-resource-updated" align="left" supp ress-title="false" pn="figure-6">
<name slugifiedName="name-star-order-resource-updated">STAR Order Re source Updated on IdO</name> <name slugifiedName="name-star-order-resource-updated">STAR Order Re source Updated on IdO</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.2-12.1" ><![CDATA[ <sourcecode name="" type="json" pn="section-2.3.2-12.1"><![CDATA[
{ {
"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 1278 skipping to change at line 1231
"delegation": "delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen", "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize", "finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize",
"star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9" "star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.2-13">This delegation protocol is predic ated on the NDC being able to fetch <t indent="0" pn="section-2.3.2-13">This delegation protocol is predic ated on the NDC being able to fetch
certificates periodically using an unauthenticated HTTP GET, since in general certificates periodically using an unauthenticated HTTP GET, since, in general,
the NDC does not possess an account on the CA and therefore cannot issue the the NDC does not possess an account on the CA; as a consequence, it cannot issue
the
standard POST-as-GET ACME request. Therefore, before forwarding the Order standard POST-as-GET ACME request. Therefore, before forwarding the Order
request to the CA, the IdO SHOULD ensure that the selected CA supports request to the CA, the IdO <bcp14>SHOULD</bcp14> ensure that the selected CA sup
"unauthenticated GET" by inspecting the relevant settings in the CA's ports
<tt>directory</tt> object, as per Section 3.4 of <xref target="RFC8739" format=" unauthenticated GET by inspecting the relevant settings in the CA's
default" sectionFormat="of" derivedContent="RFC8739"/>. If the CA does not directory object, as per <xref target="RFC8739" format="default" sectionFormat="
support "unauthenticated GET" of STAR certificates, the IdO MUST NOT forward of" derivedContent="RFC8739" section="3.4"/>. If the CA does not
the Order request. Instead, it MUST move the Order status to <tt>invalid</tt> a support unauthenticated GET of STAR certificates, the IdO <bcp14>MUST NOT</bcp14
nd set > 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> in the <tt>auto-renewal</tt> object to <tt>fa lse</tt>. The same the <tt>allow-certificate-get</tt> in the <tt>auto-renewal</tt> object to <tt>fa lse</tt>. The same
occurs in case the Order request is forwarded and the CA does not reflect the occurs in case the Order request is forwarded and the CA does not reflect the
<tt>allow-certificate-get</tt> setting in its Order resource. The combination o f <tt>allow-certificate-get</tt> setting in its Order resource. The combination o f
<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at <tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at
the IdO provides an unambiguous (asynchronous) signal to the NDC about the the IdO provides an unambiguous (asynchronous) signal to the NDC about the
failure reason.</t> failure reason.</t>
<section anchor="sec-cname-installation" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.2.1"> <section anchor="sec-cname-installation" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.2.1">
<name slugifiedName="name-cname-installation">CNAME Installation</na me> <name slugifiedName="name-cname-installation">CNAME Installation</na me>
<t indent="0" pn="section-2.3.2.1-1">If an identifier object of type <t indent="0" pn="section-2.3.2.1-1">If one of the objects in the <t
<tt>dns</tt> was included, the IdO can add the t>identifiers</tt> list is of type <tt>dns</tt>, the IdO can add the
CNAME records specified in the delegation object to its zone, e.g.:</t> CNAME records specified in the <tt>delegation</tt> object to its zone, for examp
<artwork name="" type="" align="left" alt="" pn="section-2.3.2.1-2"> le:</t>
<![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-2.3.2.1-2"><![CDATA[
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" toc ="include" removeInRFC="false" pn="section-2.3.3">
<name slugifiedName="name-order-object-transmitted-fro">Order Object T ransmitted from NDC to IdO and to ACME Server (non-STAR)</name> <name slugifiedName="name-order-object-transmitted-fro">Order Object T ransmitted from NDC to IdO and to ACME Server (Non-STAR)</name>
<t indent="0" pn="section-2.3.3-1">If the delegation is for a non-STAR certificate, the request object created by <t indent="0" pn="section-2.3.3-1">If the delegation is for a non-STAR certificate, the request object created by
the NDC:</t> the NDC:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.3-2"> -2.3.3-2">
<li pn="section-2.3.3-2.1">MUST have a <tt>delegation</tt> attribute <li pn="section-2.3.3-2.1"><bcp14>MUST</bcp14> have a <tt>delegation
indicating the preconfigured 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">MUST have entries in the <tt>identifiers< <li pn="section-2.3.3-2.2"><bcp14>MUST</bcp14> have entries in the <
/tt> field for each delegated name tt>identifiers</tt> field for each delegated name
present in the configuration;</li> present in the configuration; and</li>
<li pn="section-2.3.3-2.3">MUST have the <tt>allow-certificate-get</ <li pn="section-2.3.3-2.3"><bcp14>MUST</bcp14> have the <tt>allow-ce
tt> attribute set to true.</li> rtificate-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>
<artwork name="" type="" align="left" alt="" pn="section-2.3.3-3.1"> <![CDATA[ <sourcecode name="" type="json" pn="section-2.3.3-3.1"><![CDATA[
POST /acme/new-order HTTP/1.1 POST /acme/new-order HTTP/1.1
Host: acme.ido.example Host: acme.ido.example
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg", "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
"nonce": "IYBkoQfaCS80UcCn9qH8Gt", "nonce": "IYBkoQfaCS80UcCn9qH8Gt",
"url": "https://acme.ido.example/acme/new-order" "url": "https://acme.ido.example/acme/new-order"
skipping to change at line 1342 skipping to change at line 1295
"type": "dns", "type": "dns",
"value": "abc.ido.example" "value": "abc.ido.example"
} }
], ],
"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"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.3-4">The Order object that is created on <t indent="0" pn="section-2.3.3-4">The order object that is created on
the IdO:</t> the IdO:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.3-5"> -2.3.3-5">
<li pn="section-2.3.3-5.1">MUST start in the <tt>ready</tt> state;</ <li pn="section-2.3.3-5.1"><bcp14>MUST</bcp14> start in the <tt>read
li> y</tt> state;</li>
<li pn="section-2.3.3-5.2">MUST contain an <tt>authorizations</tt> a <li pn="section-2.3.3-5.2"><bcp14>MUST</bcp14> contain an <tt>author
rray with zero elements;</li> izations</tt> array with zero elements;</li>
<li pn="section-2.3.3-5.3">MUST contain the indicated <tt>delegation <li pn="section-2.3.3-5.3"><bcp14>MUST</bcp14> contain the indicated
</tt> configuration;</li> <tt>delegation</tt> configuration; and</li>
<li pn="section-2.3.3-5.4">MUST contain the indicated <tt>allow-cert <li pn="section-2.3.3-5.4"><bcp14>MUST</bcp14> contain the indicated
ificate-get</tt> setting.</li> <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 Orde r Resource Created on IdO</name> <name slugifiedName="name-non-star-order-resource-cre">Non-STAR Orde r Resource Created on IdO</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.3-6.1"> <![CDATA[ <sourcecode name="" type="json" pn="section-2.3.3-6.1"><![CDATA[
{ {
"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"
} }
], ],
"delegation": "delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen", "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"allow-certificate-get": true, "allow-certificate-get": true,
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize" "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.3-7">The Order finalization by the NDC a nd the subsequent validation of the CSR by <t indent="0" pn="section-2.3.3-7">The Order finalization by the NDC a nd the subsequent validation of the CSR by
the IdO proceed in the same way as for the STAR case. If the CSR is the IdO proceed in the same way as for the STAR case. If the CSR is
successfully validated, the Order object status moves to <tt>processing</tt> and the successfully validated, the order object status moves to <tt>processing</tt> and the
twin ACME protocol instance is initiated on the IdO-CA side.</t> twin ACME protocol instance is initiated on the IdO-CA side.</t>
<t indent="0" pn="section-2.3.3-8">The request object created by the I dO:</t> <t indent="0" pn="section-2.3.3-8">The request object created by the I dO:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.3-9"> -2.3.3-9">
<li pn="section-2.3.3-9.1">MUST copy the identifiers sent by the NDC <li pn="section-2.3.3-9.1"><bcp14>MUST</bcp14> copy the identifiers
;</li> sent by the NDC;</li>
<li pn="section-2.3.3-9.2">MUST strip the <tt>delegation</tt> attrib <li pn="section-2.3.3-9.2"><bcp14>MUST</bcp14> strip the <tt>delegat
ute;</li> ion</tt> attribute; and</li>
<li pn="section-2.3.3-9.3">MUST copy the <tt>allow-certificate-get</ <li pn="section-2.3.3-9.3"><bcp14>MUST</bcp14> copy the <tt>allow-ce
tt> attribute.</li> rtificate-get</tt> attribute.</li>
</ul> </ul>
<t indent="0" pn="section-2.3.3-10">When the identifiers' authorizatio n has been successfully completed and the <t indent="0" pn="section-2.3.3-10">When the identifiers' authorizatio n has been successfully completed and the
certificate has been issued by the CA, the IdO:</t> certificate has been issued by the CA, the IdO:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-2.3.3-11"> -2.3.3-11">
<li pn="section-2.3.3-11.1">MUST move its Order resource status to < <li pn="section-2.3.3-11.1"><bcp14>MUST</bcp14> move its Order resou
tt>valid</tt>;</li> rce status to <tt>valid</tt> and</li>
<li pn="section-2.3.3-11.2">MUST copy the <tt>certificate</tt> field <li pn="section-2.3.3-11.2"><bcp14>MUST</bcp14> copy the <tt>certifi
from the Order returned by the CA into its cate</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 fie lds exist.</li> Order resource, as well as <tt>notBefore</tt> and <tt>notAfter</tt> if these fie lds exist.</li>
</ul> </ul>
<figure anchor="fig-non-star-ido-order-resource-updated" align="left" suppress-title="false" pn="figure-9"> <figure anchor="fig-non-star-ido-order-resource-updated" align="left" suppress-title="false" pn="figure-9">
<name slugifiedName="name-non-star-order-resource-upd">Non-STAR Orde r Resource Updated on IdO</name> <name slugifiedName="name-non-star-order-resource-upd">Non-STAR Orde r Resource Updated on IdO</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.3-12.1" ><![CDATA[ <sourcecode name="" type="json" pn="section-2.3.3-12.1"><![CDATA[
{ {
"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 1418 skipping to change at line 1371
"https://acme.ido.example/acme/delegation/gm0wfLYHBen", "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"allow-certificate-get": true, "allow-certificate-get": true,
"authorizations": [], "authorizations": [],
"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize", "finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize",
"certificate": "https://acme.ca.example/acme/order/YtR23SsdG9" "certificate": "https://acme.ca.example/acme/order/YtR23SsdG9"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t indent="0" pn="section-2.3.3-13">At this point of the protocol flow , the same considerations as in <t indent="0" pn="section-2.3.3-13">At this point of the protocol flow , the same considerations as in
<xref target="sec-cname-installation" format="default" sectionFormat="of" derive dContent="Section 2.3.2.1"/> apply.</t> <xref target="sec-cname-installation" format="default" sectionFormat="of" derive dContent="Section 2.3.2.1"/> apply.</t>
<t indent="0" pn="section-2.3.3-14">Before forwarding the Order reques <t indent="0" pn="section-2.3.3-14">Before forwarding the Order reques
t to the CA, the IdO SHOULD ensure that the t to the CA, the IdO <bcp14>SHOULD</bcp14> ensure that the
selected CA supports "unauthenticated GET" by inspecting the relevant settings selected CA supports unauthenticated GET by inspecting the relevant settings
in the CA's <tt>directory</tt> object, as per <xref target="sec-nego-allow-cert- in the CA's directory object, as per <xref target="sec-nego-allow-cert-get" form
get" format="default" sectionFormat="of" derivedContent="Section 2.3.5"/>. If t at="default" sectionFormat="of" derivedContent="Section 2.3.5"/>. If the CA
he CA does not support unauthenticated GET of certificate resources, the IdO <bcp14>MU
does not support "unauthenticated GET" of certificate resources, the IdO MUST ST
NOT forward the Order request. Instead, it MUST move the Order status to NOT</bcp14> forward the Order request. Instead, it <bcp14>MUST</bcp14> move the
Order status to
<tt>invalid</tt> and set the <tt>allow-certificate-get</tt> attribute to <tt>fal se</tt>. The same <tt>invalid</tt> and set the <tt>allow-certificate-get</tt> attribute to <tt>fal se</tt>. The same
occurs in case the Order request is forwarded and the CA does not reflect the occurs in case the Order request is forwarded and the CA does not reflect the
<tt>allow-certificate-get</tt> setting in its Order resource. The combination o f <tt>allow-certificate-get</tt> setting in its Order resource. The combination o f
<tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at <tt>invalid</tt> status and denied <tt>allow-certificate-get</tt> in the Order r esource at
the IdO provides an unambiguous (asynchronous) signal to the NDC about the the IdO provides an unambiguous (asynchronous) signal to the NDC about the
failure reason.</t> failure reason.</t>
</section> </section>
<section anchor="capability-discovery" numbered="true" toc="include" rem oveInRFC="false" pn="section-2.3.4"> <section anchor="capability-discovery" numbered="true" toc="include" rem oveInRFC="false" 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 to discov er support for this profile, the directory <t indent="0" pn="section-2.3.4-1">In order to help a client discover support for this profile, the directory
object of an ACME server (typically, one deployed by the IdO) contains the object of an ACME server (typically, one deployed by the IdO) contains the
following attribute in the <tt>meta</tt> field:</t> following attribute in the <tt>meta</tt> field:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <dl spacing="compact" newline="false" indent="3" pn="section-2.3.4-2">
n-2.3.4-2"> <dt pn="section-2.3.4-2.1">delegation-enabled (optional, boolean):</
<li pn="section-2.3.4-2.1">delegation-enabled (optional, boolean): B dt>
oolean flag indicating support for <dd>Boolean flag indicating support for
the profile specified in this memo. An ACME server that supports this the profile specified in this memo. An ACME server that supports this
delegation profile MUST include this key, and MUST set it to true.</li> delegation profile <bcp14>MUST</bcp14> include this key and <bcp14>MUST</bcp14>
</ul> set it to true.</dd>
<t indent="0" pn="section-2.3.4-3">The IdO MUST declare its support fo </dl>
r delegation using <tt>delegation-enabled</tt> <t indent="0" pn="section-2.3.4-3">The IdO <bcp14>MUST</bcp14> declare
its support for delegation using <tt>delegation-enabled</tt>
regardless of whether it supports delegation of STAR certificates, non-STAR regardless of whether it supports delegation of STAR certificates, non-STAR
certificates or both.</t> certificates, or both.</t>
<t indent="0" pn="section-2.3.4-4">In order to help a client to discov <t indent="0" pn="section-2.3.4-4">In order to help a client discover
er support for certificate fetching using support for certificate fetching using
unauthenticated HTTP GET, the directory object of an ACME server (typically, unauthenticated HTTP GET, the directory object of an ACME server (typically,
one deployed by the CA) contains the following attribute in the <tt>meta</tt> fi eld:</t> one deployed by the CA) contains the following attribute in the <tt>meta</tt> fi eld:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <dl spacing="compact" newline="false" indent="3" pn="section-2.3.4-5">
n-2.3.4-5"> <dt pn="section-2.3.4-5.1">allow-certificate-get (optional, boolean)
<li pn="section-2.3.4-5.1">allow-certificate-get (optional, boolean) :</dt>
: See <xref target="sec-nego-allow-cert-get" format="default" sectionFormat="of" <dd>See <xref target="sec-nego-allow-cert-get" format="default" secti
derivedContent="Section 2.3.5"/>.</li> onFormat="of" derivedContent="Section 2.3.5"/>.</dd>
</ul> </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" toc="include" removeInRFC="false" pn="section-2.3.5">
<name slugifiedName="name-negotiating-an-unauthentica">Negotiating an Unauthenticated GET</name> <name slugifiedName="name-negotiating-an-unauthentica">Negotiating an Unauthenticated GET</name>
<t indent="0" pn="section-2.3.5-1">In order to enable the name delegat ion of non-STAR certificates, this document <t indent="0" pn="section-2.3.5-1">In order to enable the name delegat ion of non-STAR certificates, this document
defines a mechanism that allows a server to advertise support for accessing defines a mechanism that allows a server to advertise support for accessing
certificate resources via unauthenticated GET (in addition to certificate resources via unauthenticated GET (in addition to
POST-as-GET), and a client to enable this service with per-Order granularity.</t > POST-as-GET) and a client to enable this service with per-Order granularity.</t>
<t indent="0" pn="section-2.3.5-2">It is worth pointing out that the p rotocol elements described in this section <t indent="0" pn="section-2.3.5-2">It is worth pointing out that the p rotocol elements described in this section
have the same names and semantics as those introduced in Section 3.4 of have the same names and semantics as those introduced in
<xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RFC87 <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RFC87
39"/> for the STAR use case (except, of course, they apply to the 39" section="3.4"/> for the STAR use case (except, of course, they apply to the
certificate resource rather than the star-certificate resource). However, they certificate resource rather than the star-certificate resource). However, they
differ in terms of their position in the directory meta and order objects: differ in terms of their position in the directory meta and order objects;
rather than being wrapped in an auto-renewal sub-object they are located at the rather than being wrapped in an <tt>auto-renewal</tt> subobject, they are locate
top-level.</t> d at the
top level.</t>
<t anchor="capability-metadata" indent="0" pn="section-2.3.5-3">A serv er states its availability to grant unauthenticated access to a client's <t anchor="capability-metadata" indent="0" pn="section-2.3.5-3">A serv er states its availability to grant unauthenticated access to a client's
Order certificate by setting the <tt>allow-certificate-get</tt> attribute to <tt >true</tt> in Order certificate by setting the <tt>allow-certificate-get</tt> attribute to <tt >true</tt> in
the <tt>meta</tt> field inside the directory object:</t> the <tt>meta</tt> field inside the directory object:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <dl spacing="compact" newline="false" indent="3" pn="section-2.3.5-4">
n-2.3.5-4"> <dt pn="section-2.3.5-4.1">allow-certificate-get (optional, boolean)
<li pn="section-2.3.5-4.1">allow-certificate-get (optional, boolean) :</dt>
: If this field is present and set <dd>If this field is present and set
to <tt>true</tt>, the server allows GET (and HEAD) requests to certificate URLs. to <tt>true</tt>, the server allows GET (and HEAD) requests to certificate URLs.
</li> </dd>
</ul> </dl>
<t indent="0" pn="section-2.3.5-5">A client states its desire to acces s the issued certificate via unauthenticated <t indent="0" pn="section-2.3.5-5">A client states its desire to acces s the issued certificate via unauthenticated
GET by adding an <tt>allow-certificate-get</tt> attribute to the payload of its GET by adding an <tt>allow-certificate-get</tt> attribute to the payload of its
newOrder request and setting it to <tt>true</tt>.</t> newOrder request and setting it to <tt>true</tt>.</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <dl spacing="compact" newline="false" indent="3" pn="section-2.3.5-6">
n-2.3.5-6"> <dt pn="section-2.3.5-6.1">allow-certificate-get (optional, boolean)
<li pn="section-2.3.5-6.1">allow-certificate-get (optional, boolean) :</dt>
: If this field is present and set <dd>If this field is present and set
to <tt>true</tt>, the client requests the server to allow unauthenticated GET (a nd to <tt>true</tt>, the client requests the server to allow unauthenticated GET (a nd
HEAD) to the certificate associated with this Order.</li> HEAD) to the certificate associated with this Order.</dd>
</ul> </dl>
<t indent="0" pn="section-2.3.5-7">If the server accepts the request, <t indent="0" pn="section-2.3.5-7">If the server accepts the request,
it MUST reflect the attribute setting in the it <bcp14>MUST</bcp14> reflect the attribute setting in the
resulting order object.</t> resulting order object.</t>
<t indent="0" pn="section-2.3.5-8">Note that even when the use of unau thenticated GET has been agreed upon, the <t indent="0" pn="section-2.3.5-8">Note that even when the use of unau thenticated GET has been agreed upon, the
server MUST also allow POST-as-GET requests to the certificate resource.</t> server <bcp14>MUST</bcp14> also allow POST-as-GET requests to the certificate re source.</t>
</section> </section>
<section anchor="terminating-the-delegation" numbered="true" toc="includ e" removeInRFC="false" pn="section-2.3.6"> <section anchor="terminating-the-delegation" numbered="true" toc="includ e" removeInRFC="false" pn="section-2.3.6">
<name slugifiedName="name-terminating-the-delegation">Terminating the Delegation</name> <name slugifiedName="name-terminating-the-delegation">Terminating the Delegation</name>
<t indent="0" pn="section-2.3.6-1">Identity delegation is terminated d ifferently depending on whether this is a STAR certificate or not.</t> <t indent="0" pn="section-2.3.6-1">Identity delegation is terminated d ifferently depending on whether or not this is a STAR certificate.</t>
<section anchor="by-cancellation-star" numbered="true" toc="exclude" r emoveInRFC="false" pn="section-2.3.6.1"> <section anchor="by-cancellation-star" numbered="true" toc="exclude" r emoveInRFC="false" pn="section-2.3.6.1">
<name slugifiedName="name-by-cancellation-star">By Cancellation (STA R)</name> <name slugifiedName="name-by-cancellation-star">By Cancellation (STA R)</name>
<t indent="0" pn="section-2.3.6.1-1">The IdO can terminate the deleg ation of a STAR certificate by requesting its <t indent="0" pn="section-2.3.6.1-1">The IdO can terminate the deleg ation of a STAR certificate by requesting its
cancellation (see Section 3.1.2 of <xref target="RFC8739" format="default" secti onFormat="of" derivedContent="RFC8739"/>).</t> cancellation (see <xref target="RFC8739" format="default" sectionFormat="of" der ivedContent="RFC8739" section="3.1.2"/>).</t>
<t indent="0" pn="section-2.3.6.1-2">Cancellation of the ACME STAR c ertificate is a <t indent="0" pn="section-2.3.6.1-2">Cancellation of the ACME STAR c ertificate is a
prerogative of the IdO. The NDC does not own the relevant account key on the prerogative of the IdO. The NDC does not own the relevant account key on the
CA, therefore it can't issue a cancellation request for the STAR certificate. CA; therefore, it can't issue a cancellation request for the STAR certificate.
Potentially, since it holds the STAR certificate's private key, it could request the Potentially, since it holds the STAR certificate's private key, it could request the
revocation of a single STAR certificate. However, STAR explicitly disables the revocation of a single STAR certificate. However, STAR explicitly disables the
revokeCert interface.</t> revokeCert interface.</t>
<t indent="0" pn="section-2.3.6.1-3">Shortly after the automatic ren ewal process is stopped by the IdO, the last <t indent="0" pn="section-2.3.6.1-3">Shortly after the automatic ren ewal process is stopped by the IdO, the last
issued STAR certificate expires and the delegation terminates.</t> issued STAR certificate expires and the delegation terminates.</t>
</section> </section>
<section anchor="by-revocation-non-star" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.6.2"> <section anchor="by-revocation-non-star" numbered="true" toc="exclude" removeInRFC="false" pn="section-2.3.6.2">
<name slugifiedName="name-by-revocation-non-star">By Revocation (non -STAR)</name> <name slugifiedName="name-by-revocation-non-star">By Revocation (Non -STAR)</name>
<t indent="0" pn="section-2.3.6.2-1">The IdO can terminate the deleg ation of a non-STAR certificate by requesting it <t indent="0" pn="section-2.3.6.2-1">The IdO can terminate the deleg ation of a non-STAR certificate by requesting it
to be revoked using the revokeCert 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 Section 7.6 of <xr <t indent="0" pn="section-2.3.6.2-2">According to <xref target="RFC8
ef target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555" 555" format="default" sectionFormat="of" derivedContent="RFC8555" section="7.6"/
/>, the revocation endpoint can be used >, the revocation endpoint can be used
with either the account keypair, or the certificate keypair. In other words, an with either the account key pair or the certificate key pair. In other words, an
NDC that learns the revokeCert URL of the CA (which is publicly available via NDC that learns the <tt>revokeCert</tt> URL of the CA (which is publicly availab
the CA's Directory object) would be able to revoke the certificate using the le via
associated private key. However, given the trust relationship between NDC and the CA's directory object) would be able to revoke the certificate using the
associated private key. However, given the trust relationship between the NDC an
d
IdO expected by the delegation trust model (<xref target="sec-trust-model" forma t="default" sectionFormat="of" derivedContent="Section 7.1"/>), as well as IdO expected by the delegation trust model (<xref target="sec-trust-model" forma t="default" sectionFormat="of" derivedContent="Section 7.1"/>), as well as
the lack of incentives for the NDC to prematurely terminate the delegation, the lack of incentives for the NDC to prematurely terminate the delegation,
this does not represent a significant security risk.</t> this does not represent a significant security risk.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="proxy-behavior" numbered="true" toc="include" removeInRFC ="false" pn="section-2.4"> <section anchor="proxy-behavior" numbered="true" toc="include" removeInRFC ="false" pn="section-2.4">
<name slugifiedName="name-proxy-behavior">Proxy Behavior</name> <name slugifiedName="name-proxy-behavior">Proxy Behavior</name>
<t indent="0" pn="section-2.4-1">There are cases where the ACME Delegati on flow should be proxied, such as the <t indent="0" pn="section-2.4-1">There are cases where the ACME Delegati on flow should be proxied, such as the
use case described in <xref target="sec-cdni-dele" format="default" sectionForma t="of" derivedContent="Section 5.1.2"/>. This section describes the behavior of use case described in <xref target="sec-cdni-dele" format="default" sectionForma t="of" derivedContent="Section 5.1.2"/>. This section describes the behavior of
such proxies.</t> such proxies.</t>
<t indent="0" pn="section-2.4-2">An entity implementing the IdO server r ole - an "ACME Delegation server" - <t indent="0" pn="section-2.4-2">An entity implementing the IdO server r ole -- an "ACME Delegation server" --
may behave, on a per-identity case, either as a proxy into another ACME Delegati on may behave, on a per-identity case, either as a proxy into another ACME Delegati on
server, or it may behave as an IdO and obtain a certificate directly. server or as an IdO and obtain a certificate directly.
The determining factor is whether it can successfully be authorized by The determining factor is whether it can successfully be authorized by
the next-hop ACME server for the identity associated with the certificate reques t.</t> the next-hop ACME server for the identity associated with the certificate reques t.</t>
<t indent="0" pn="section-2.4-3">The identities supported by each server and the disposition for each of them <t indent="0" pn="section-2.4-3">The identities supported by each server and the disposition for each of them
are preconfigured.</t> are preconfigured.</t>
<t indent="0" pn="section-2.4-4">Following is the proxy's behavior for e ach of the messages exchanged in the <t indent="0" pn="section-2.4-4">Following is the proxy's behavior for e ach of the messages exchanged in the
ACME Delegation process:</t> ACME Delegation process:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- <dl spacing="compact" newline="true" indent="3" pn="section-2.4-5">
2.4-5"> <dt pn="section-2.4-5.1">New-order request:</dt>
<li pn="section-2.4-5.1"> <dd>
<t indent="0" pn="section-2.4-5.1.1">New-order request:
</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.1.2"> <ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.1.2">
<li pn="section-2.4-5.1.2.1">The complete <tt>identifiers</tt> obj <li pn="section-2.4-5.1.2.1">The complete <tt>identifiers</tt> att
ect MUST be copied as-is.</li> ribute <bcp14>MUST</bcp14> be copied as is.</li>
<li pn="section-2.4-5.1.2.2">Similarly, the <tt>auto-renewal</tt> <li pn="section-2.4-5.1.2.2">Similarly, the <tt>auto-renewal</tt>
object MUST be copied as-is.</li> object <bcp14>MUST</bcp14> be copied as is.</li>
</ul> </ul>
</li> </dd>
<li pn="section-2.4-5.2"> <dt pn="section-2.4-5.2">New-order response:</dt>
<t indent="0" pn="section-2.4-5.2.1">New-order response: <dd>
</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.2.2"> <ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.2.2">
<li pn="section-2.4-5.2.2.1">The <tt>status</tt>, <tt>expires</tt> <li pn="section-2.4-5.2.2.1">The <tt>status</tt>, <tt>expires</tt>
, <tt>authorizations</tt>, <tt>identifiers</tt> and <tt>auto-renewal</tt> , <tt>authorizations</tt>, <tt>identifiers</tt>, and <tt>auto-renewal</tt>
attributes/objects MUST be copied as-is.</li> attributes/objects <bcp14>MUST</bcp14> be copied as is.</li>
<li pn="section-2.4-5.2.2.2">The <tt>finalize</tt> URL is rewritte <li pn="section-2.4-5.2.2.2">The <tt>finalize</tt> URL is rewritte
n, so that the <tt>finalize</tt> request will be n so that the <tt>finalize</tt> request will be
made to the proxy.</li> made to the proxy.</li>
<li pn="section-2.4-5.2.2.3">Similarly, the <tt>Location</tt> head <li pn="section-2.4-5.2.2.3">Similarly, the <tt>Location</tt> head
er MUST be rewritten to point to an Order object on the proxy.</li> er <bcp14>MUST</bcp14> be rewritten to point to an order object on the proxy.</l
<li pn="section-2.4-5.2.2.4">Any <tt>Link</tt> relations MUST be r i>
ewritten to point to the proxy.</li> <li pn="section-2.4-5.2.2.4">Any <tt>Link</tt> relations <bcp14>MU
ST</bcp14> be rewritten to point to the proxy.</li>
</ul> </ul>
</li> </dd>
<li pn="section-2.4-5.3"> <dt pn="section-2.4-5.3">Get Order response:</dt>
<t indent="0" pn="section-2.4-5.3.1">Get Order response: <dd>
</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.3.2"> <ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.3.2">
<li pn="section-2.4-5.3.2.1">The <tt>status</tt>, <tt>expires</tt> <li pn="section-2.4-5.3.2.1">The <tt>status</tt>, <tt>expires</tt>
, <tt>authorizations</tt>, <tt>identifiers</tt> and <tt>auto-renewal</tt> , <tt>authorizations</tt>, <tt>identifiers</tt>, and <tt>auto-renewal</tt>
attributes/objects MUST be copied as-is.</li> attributes/objects <bcp14>MUST</bcp14> be copied as is.</li>
<li pn="section-2.4-5.3.2.2">Similarly, the <tt>star-certificate</ tt> URL (or the <tt>certificate</tt> URL in case of <li pn="section-2.4-5.3.2.2">Similarly, the <tt>star-certificate</ tt> URL (or the <tt>certificate</tt> URL in case of
non-STAR requests) MUST be copied as-is.</li> non-STAR requests) <bcp14>MUST</bcp14> be copied as is.</li>
<li pn="section-2.4-5.3.2.3">The <tt>finalize</tt> URL is rewritte <li pn="section-2.4-5.3.2.3">The <tt>finalize</tt> URL is rewritte
n, so that the <tt>finalize</tt> request will be n so that the <tt>finalize</tt> request will be
made to the proxy.</li> made to the proxy.</li>
<li pn="section-2.4-5.3.2.4">The <tt>Location</tt> header MUST be <li pn="section-2.4-5.3.2.4">The <tt>Location</tt> header <bcp14>M
rewritten to point to an Order object on the proxy.</li> UST</bcp14> be rewritten to point to an order object on the proxy.</li>
<li pn="section-2.4-5.3.2.5">Any <tt>Link</tt> relations MUST be r <li pn="section-2.4-5.3.2.5">Any <tt>Link</tt> relations <bcp14>MU
ewritten to point to the proxy.</li> ST</bcp14> be rewritten to point to the proxy.</li>
</ul> </ul>
</li> </dd>
<li pn="section-2.4-5.4"> <dt pn="section-2.4-5.4"><tt>finalize</tt> request:</dt>
<t indent="0" pn="section-2.4-5.4.1">Finalize request: <dd>
</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.4.2"> <ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.4.2">
<li pn="section-2.4-5.4.2.1">The CSR MUST be copied as-is.</li> <li pn="section-2.4-5.4.2.1">The CSR <bcp14>MUST</bcp14> be copied
</ul> as is.</li>
</li> </ul></dd>
<li pn="section-2.4-5.5"> <dt pn="section-2.4-5.5"><tt>finalize</tt> response:</dt>
<t indent="0" pn="section-2.4-5.5.1">Finalize response: <dd>
</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.5.2"> <ul spacing="compact" bare="false" empty="false" indent="3" pn="sect ion-2.4-5.5.2">
<li pn="section-2.4-5.5.2.1">The <tt>Location</tt> header, <tt>Lin k</tt> relations and the <tt>finalize</tt> URLs are rewritten as for Get Order.< /li> <li pn="section-2.4-5.5.2.1">The <tt>Location</tt> header, <tt>Lin k</tt> relations, and the <tt>finalize</tt> URLs are rewritten as for Get Order. </li>
</ul> </ul>
</li> </dd>
</ul> </dl>
<t indent="0" pn="section-2.4-6">We note that all the above messages are <t indent="0" pn="section-2.4-6">We note that all the above messages are
authenticated, and therefore each proxy 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" toc="include" removeInRFC= "false" pn="section-3">
<name slugifiedName="name-ca-behavior">CA Behavior</name> <name slugifiedName="name-ca-behavior">CA Behavior</name>
<t indent="0" pn="section-3-1">Although most of this document, and in part icular <xref target="sec-protocol-flow" format="default" sectionFormat="of" deri vedContent="Section 2"/> is focused on the protocol between the NDC and to IdO, the protocol does affect the ACME server running in the CA. A CA that wishes to support certificate delegation MUST also support unauthenticated certificate fet ching, which it declares using <tt>allow-certificate-get</tt> (<xref target="cap ability-metadata" 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 part icular <xref target="sec-protocol-flow" format="default" sectionFormat="of" deri vedContent="Section 2"/>, is focused on the protocol between the NDC and IdO, th e protocol does affect the ACME server running in the CA. A CA that wishes to su pport certificate delegation <bcp14>MUST</bcp14> also support unauthenticated ce rtificate fetching, which it declares using <tt>allow-certificate-get</tt> (<xre f target="capability-metadata" format="default" sectionFormat="of" derivedConten t="Section 2.3.5, Paragraph 3"/>).</t>
</section> </section>
<section anchor="sec-csr-template" numbered="true" toc="include" removeInRFC ="false" pn="section-4"> <section anchor="sec-csr-template" numbered="true" toc="include" removeInRFC ="false" pn="section-4">
<name slugifiedName="name-csr-template">CSR Template</name> <name slugifiedName="name-csr-template">CSR Template</name>
<t indent="0" pn="section-4-1">The CSR template is used to express and con strain the shape of the CSR that the <t indent="0" pn="section-4-1">The CSR template is used to express and con strain the shape of the CSR that the
NDC uses to request the certificate. The CSR is used for every certificate NDC uses to request the certificate. The CSR is used for every certificate
created under the same delegation. Its validation by the IdO is a critical created under the same delegation. Its validation by the IdO is a critical
element in the security of the whole delegation mechanism.</t> element in the security of the whole delegation mechanism.</t>
<t indent="0" pn="section-4-2">Instead of defining every possible CSR attr ibute, this document takes a <t indent="0" pn="section-4-2">Instead of defining every possible CSR attr ibute, this document takes a
minimalist approach by declaring only the minimum attribute set and deferring minimalist approach by declaring only the minimum attribute set and deferring
the registration of further, more specific, attributes to future documents.</t> the registration of further, more-specific attributes to future documents.</t>
<section anchor="sec-csr-template-syntax" numbered="true" toc="include" re moveInRFC="false" pn="section-4.1"> <section anchor="sec-csr-template-syntax" numbered="true" toc="include" re moveInRFC="false" pn="section-4.1">
<name slugifiedName="name-template-syntax">Template Syntax</name> <name slugifiedName="name-template-syntax">Template Syntax</name>
<t indent="0" pn="section-4.1-1">The template is a JSON document. Each f <t indent="0" pn="section-4.1-1">The template is a JSON document. Each f
ield (with the exception of <tt>keyTypes</tt>, see below) denotes one of:</t> ield (with the exception of <tt>keyTypes</tt>, see below) denotes one of the fol
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- lowing:</t>
4.1-2"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
<li pn="section-4.1-2.1">A mandatory field, where the template specifi .1-2">
es the literal value of that <li pn="section-4.1-2.1">A mandatory field where the template specifie
s the literal value of that
field. This is denoted by a literal string, such as <tt>abc.ido.example</tt>.</l i> field. This is denoted by a literal string, such as <tt>abc.ido.example</tt>.</l i>
<li pn="section-4.1-2.2">A mandatory field, where the content of the f ield is defined by the client. <li pn="section-4.1-2.2">A mandatory field where the content of the fi eld is defined by the client.
This is denoted by <tt>**</tt>.</li> This is denoted by <tt>**</tt>.</li>
<li pn="section-4.1-2.3">An optional field, where the client decides w <li pn="section-4.1-2.3">An optional field where the client decides wh
hether the field is included in ether the field is included in
the CSR and if so, what its value is. This is denoted by <tt>*</tt>.</li> the CSR and, if so, what its value is. This is denoted by <tt>*</tt>.</li>
</ul> </ul>
<t indent="0" pn="section-4.1-3">The NDC MUST NOT include in the CSR any fields, 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 t he
template.</t> template.</t>
<t indent="0" pn="section-4.1-4">The structure of the template object is <t indent="0" pn="section-4.1-4">The structure of the template object is
defined by the CDDL <xref target="RFC8610" format="default" sectionFormat="of" defined by the Concise Data Definition Language (CDDL) <xref target="RFC8610" f
derivedContent="RFC8610"/> document in <xref target="csr-template-schema-cddl" f ormat="default" sectionFormat="of" derivedContent="RFC8610"/> document in <xref
ormat="default" sectionFormat="of" derivedContent="Appendix B"/>. target="csr-template-schema-cddl" format="default" sectionFormat="of" derivedCon
An alternative, non-normative JSON Schema syntax is given in <xref target="csr-t tent="Appendix B"/>.
emplate-schema" format="default" sectionFormat="of" derivedContent="Appendix C"/ An alternative, nonnormative JSON Schema syntax is given in <xref target="csr-te
>. mplate-schema" format="default" sectionFormat="of" derivedContent="Appendix C"/>
.
While the CSR template must follow the syntax defined here, neither the IdO nor While the CSR template must follow the syntax defined here, neither the IdO nor
the NDC are expected to validate it at run-time.</t> the NDC are expected to validate it at runtime.</t>
<t indent="0" pn="section-4.1-5">The <tt>subject</tt> field and its subf <t indent="0" pn="section-4.1-5">The <tt>subject</tt> field and its subf
ields are mapped into the <tt>subject</tt> field of the CSR, as per <xref target ields are mapped into the <tt>subject</tt> field of the CSR, as per <xref target
="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, Secti ="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280" section=
on 4.1.2.6. Other extension fields of the CSR template are mapped into the CSR a "4.1.2.6"/>. Other extension fields of the CSR template are mapped into the CSR
ccording to the table in <xref target="csr-template-registry" format="default" s according to the table in <xref target="csr-template-registry" format="default"
ectionFormat="of" derivedContent="Section 6.5"/>.</t> sectionFormat="of" derivedContent="Section 6.5"/>.</t>
<t indent="0" pn="section-4.1-6">The <tt>subjectAltName</tt> field is cu rrently defined for the following identifiers: <t indent="0" pn="section-4.1-6">The <tt>subjectAltName</tt> field is cu rrently defined for the following identifiers:
DNS names, email addresses, and URIs. New identifier types may be added in the DNS names, email addresses, and URIs. New identifier types may be added in the
future by documents that extend this specification. Each new identifier type future by documents that extend this specification. Each new identifier type
SHALL have an associated identifier validation challenge that the CA can <bcp14>SHALL</bcp14> have an associated identifier validation challenge that the CA can
use to obtain proof of the requester's control over it.</t> use to obtain proof of the requester's control over it.</t>
<t indent="0" pn="section-4.1-7">The <tt>keyTypes</tt> property is not c <t indent="0" pn="section-4.1-7">The <tt>keyTypes</tt> property is not c
opied into the CSR. Instead, this property constrains the <tt>SubjectPublicKeyIn opied into the CSR. Instead, this property constrains the <tt>SubjectPublicKeyIn
fo</tt> field of the CSR, which MUST have the type/size defined by one of the ar fo</tt> field of the CSR, which <bcp14>MUST</bcp14> have the type/size defined b
ray members of the <tt>keyTypes</tt> property.</t> y one of the array members of the <tt>keyTypes</tt> property.</t>
<t indent="0" pn="section-4.1-8">When the IdO receives the CSR, it MUST <t indent="0" pn="section-4.1-8">When the IdO receives the CSR, it <bcp1
verify that the CSR is consistent 4>MUST</bcp14> verify that the CSR is consistent
with the template contained in the <tt>delegation</tt> object referenced in the with the template contained in the <tt>delegation</tt> object referenced in the
Order. The IdO MAY enforce additional Order. The IdO <bcp14>MAY</bcp14> enforce additional
constraints, e.g., by restricting field lengths. In this regard, note that a constraints, e.g., by restricting field lengths. In this regard, note that a
<tt>subjectAltName</tt> of type <tt>DNS</tt> can be specified using the wildcard notation, <tt>subjectAltName</tt> of type <tt>DNS</tt> can be specified using the wildcard notation,
meaning that the NDC can be required (<tt>**</tt>) or offered the possibility (< tt>*</tt>) to meaning that the NDC can be required (<tt>**</tt>) or offered the possibility (< tt>*</tt>) to
define the delegated domain name by itself. If this is the case, the IdO MUST define the delegated domain name by itself. If this is the case, the IdO <bcp14 >MUST</bcp14>
apply application-specific checks on top of the control rules already provided apply application-specific checks on top of the control rules already provided
by the CSR template to ensure the requested domain name is legitimate according by the CSR template to ensure the requested domain name is legitimate according
to its local policy.</t> to its local policy.</t>
</section> </section>
<section anchor="example" numbered="true" toc="include" removeInRFC="false " pn="section-4.2"> <section anchor="example" numbered="true" toc="include" removeInRFC="false " pn="section-4.2">
<name slugifiedName="name-example">Example</name> <name slugifiedName="name-example">Example</name>
<t indent="0" pn="section-4.2-1">The CSR template in <xref target="fig-c sr-template" format="default" sectionFormat="of" derivedContent="Figure 10"/> re presents one possible CSR template <t indent="0" pn="section-4.2-1">The CSR template in <xref target="fig-c sr-template" format="default" sectionFormat="of" derivedContent="Figure 10"/> re presents one possible CSR template
governing the delegation exchanges provided in the rest of this document.</t> governing the delegation exchanges provided in the rest of this document.</t>
<figure anchor="fig-csr-template" align="left" suppress-title="false" pn ="figure-10"> <figure anchor="fig-csr-template" align="left" suppress-title="false" pn ="figure-10">
<name slugifiedName="name-example-csr-template">Example CSR template</ <name slugifiedName="name-example-csr-template">Example CSR Template</
name> name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-2.1"><![C <sourcecode name="" type="json" pn="section-4.2-2.1"><![CDATA[
DATA[
{ {
"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 1673 skipping to change at line 1624
}, },
"keyUsage": [ "keyUsage": [
"digitalSignature" "digitalSignature"
], ],
"extendedKeyUsage": [ "extendedKeyUsage": [
"serverAuth", "serverAuth",
"clientAuth" "clientAuth"
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="further-use-cases" numbered="true" toc="include" removeInRF C="false" pn="section-5"> <section anchor="further-use-cases" numbered="true" toc="include" removeInRF C="false" 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 non-normative section describes additi <t indent="0" pn="section-5-1">This nonnormative section describes additio
onal use cases that use STAR certificate nal use cases implementing the STAR certificate
delegation in non-trivial ways.</t> delegation in nontrivial ways.</t>
<section anchor="cdn-interconnection-cdni" numbered="true" toc="include" r emoveInRFC="false" pn="section-5.1"> <section anchor="cdn-interconnection-cdni" numbered="true" toc="include" r emoveInRFC="false" pn="section-5.1">
<name slugifiedName="name-cdn-interconnection-cdni">CDN Interconnection (CDNI)</name> <name slugifiedName="name-cdn-interconnection-cdni">CDN Interconnection (CDNI)</name>
<t indent="0" pn="section-5.1-1"><xref target="I-D.ietf-cdni-interfaces- https-delegation" format="default" sectionFormat="of" derivedContent="I-D.ietf-c dni-interfaces-https-delegation"/> discusses several solutions <t indent="0" pn="section-5.1-1"><xref target="I-D.ietf-cdni-interfaces- https-delegation" format="default" sectionFormat="of" derivedContent="I-D.ietf-c dni-interfaces-https-delegation"/> discusses several solutions
addressing different delegation requirements for the CDNI (CDN Interconnection) addressing different delegation requirements for the CDN Interconnection (CDNI)
environment. This section discusses two of the stated requirements in the environment. This section discusses two of the stated requirements in the
context of the STAR delegation workflow.</t> context of the STAR delegation workflow.</t>
<t indent="0" pn="section-5.1-2">This section uses specifically CDNI ter minology, e.g., "uCDN" and "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 termino logy, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in <xref targe t="RFC7336" format="default" sectionFormat="of" derivedContent="RFC7336"/>.</t>
<section anchor="multiple-parallel-delegates" numbered="true" toc="inclu de" removeInRFC="false" pn="section-5.1.1"> <section anchor="multiple-parallel-delegates" numbered="true" toc="inclu de" removeInRFC="false" pn="section-5.1.1">
<name slugifiedName="name-multiple-parallel-delegates">Multiple Parall el Delegates</name> <name slugifiedName="name-multiple-parallel-delegates">Multiple Parall el Delegates</name>
<t indent="0" pn="section-5.1.1-1">In some cases the content owner (Id <t indent="0" pn="section-5.1.1-1">In some cases, the content owner (I
O) would like to delegate authority over a dO) would like to delegate authority over a
web site to multiple NDCs (CDNs). This could happen if the IdO has agreements website to multiple NDCs (CDNs). This could happen if the IdO has agreements
in place with different regional CDNs for different geographical regions, or if in place with different regional CDNs for different geographical regions or if
a "backup" CDN is used to handle overflow traffic by temporarily altering some a "backup" CDN is used to handle overflow traffic by temporarily altering some
of the CNAME mappings in place. The STAR delegation flow enables this use case of the CNAME mappings in place. The STAR delegation flow enables this use case
naturally, since each CDN can authenticate separately to the IdO (via its own naturally, since each CDN can authenticate separately to the IdO (via its own
separate account) specifying its CSR, and the IdO is free to allow or deny each separate account) specifying its CSR, and the IdO is free to allow or deny each
certificate request according to its own policy.</t> certificate request according to its own policy.</t>
</section> </section>
<section anchor="sec-cdni-dele" numbered="true" toc="include" removeInRF C="false" pn="section-5.1.2"> <section anchor="sec-cdni-dele" numbered="true" toc="include" removeInRF C="false" pn="section-5.1.2">
<name slugifiedName="name-chained-delegation">Chained Delegation</name > <name slugifiedName="name-chained-delegation">Chained Delegation</name >
<t indent="0" pn="section-5.1.2-1">In other cases, a content owner (Id O) delegates some domains to a large CDN <t indent="0" pn="section-5.1.2-1">In other cases, a content owner (Id O) delegates some domains to a large CDN
(uCDN), which in turn delegates to a smaller regional CDN, dCDN. The IdO has a (uCDN), which in turn delegates to a smaller regional CDN (dCDN). The IdO has a
contractual relationship with uCDN, and uCDN has a similar relationship with contractual relationship with uCDN, and uCDN has a similar relationship with
dCDN. However IdO may not even know about dCDN.</t> dCDN. However, IdO may not even know about dCDN.</t>
<t indent="0" pn="section-5.1.2-2">If needed, the STAR protocol can be chained to support this use case: uCDN <t indent="0" pn="section-5.1.2-2">If needed, the STAR protocol can be chained to support this use case: uCDN
could forward requests from dCDN to IdO, and forward responses back to dCDN. could forward requests from dCDN to IdO and forward responses back to dCDN.
Whether such proxying is allowed is governed by policy and contracts between Whether such proxying is allowed is governed by policy and contracts between
the parties.</t> the parties.</t>
<t indent="0" pn="section-5.1.2-3">A mechanism is necessary at the int erface between uCDN and dCDN by which the <t indent="0" pn="section-5.1.2-3">A mechanism is necessary at the int erface between uCDN and dCDN, by which the
uCDN can advertise:</t> uCDN can advertise:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="sectio <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
n-5.1.2-4"> -5.1.2-4">
<li pn="section-5.1.2-4.1">The names that the dCDN is allowed to use <li pn="section-5.1.2-4.1">the names that the dCDN is allowed to use
;</li> and</li>
<li pn="section-5.1.2-4.2">The policy for creating the key material <li pn="section-5.1.2-4.2">the policy for creating the key material
(allowed algorithms, minimum key (allowed algorithms, minimum key
lengths, key usage, etc.) that the dCDN needs to satisfy.</li> lengths, key usage, etc.) that the dCDN needs to satisfy.</li>
</ul> </ul>
<t indent="0" pn="section-5.1.2-5">Note that such mechanism is provide d by the CSR template.</t> <t indent="0" pn="section-5.1.2-5">Note that such mechanism is provide d by the CSR template.</t>
<section anchor="two-level-delegation-in-cdni" numbered="true" toc="ex clude" removeInRFC="false" pn="section-5.1.2.1"> <section anchor="two-level-delegation-in-cdni" numbered="true" toc="ex clude" removeInRFC="false" pn="section-5.1.2.1">
<name slugifiedName="name-two-level-delegation-in-cdn">Two-Level Del egation in CDNI</name> <name slugifiedName="name-two-level-delegation-in-cdn">Two-Level Del egation in CDNI</name>
<t indent="0" pn="section-5.1.2.1-1">A User Agent (UA), browser or s <t indent="0" pn="section-5.1.2.1-1">A User Agent (UA), e.g., a brow
et-top-box, wants to fetch the video resource at ser or set-top box, wants to fetch the video resource at
the following URI: <tt>https://video.cp.example/movie</tt>. Redirection between the following URI: <tt>https://video.cp.example/movie</tt>.
Content Provider (CP), upstream, and downstream CDNs is arranged as a Redirection between the
CNAME-based aliasing chain as illustrated in <xref target="fig-cdni-dns-redirect content provider (CP) and upstream and downstream CDNs is arranged as a
ion" format="default" sectionFormat="of" derivedContent="Figure 11"/>.</t> CNAME-based aliasing chain, as illustrated in <xref target="fig-cdni-dns-redirec
tion" format="default" sectionFormat="of" derivedContent="Figure 11"/>.</t>
<figure anchor="fig-cdni-dns-redirection" align="left" suppress-titl e="false" pn="figure-11"> <figure anchor="fig-cdni-dns-redirection" align="left" suppress-titl e="false" pn="figure-11">
<name slugifiedName="name-dns-redirection">DNS Redirection</name> <name slugifiedName="name-dns-redirection">DNS Redirection</name>
<artset pn="section-5.1.2.1-2.1"> <artset pn="section-5.1.2.1-2.1">
<artwork type="svg" name="" align="left" alt="" pn="section-5.1. 2.1-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" height="489" width="520" viewBox="0 0 520.0 489.0"> <artwork type="svg" name="" align="left" alt="" pn="section-5.1. 2.1-2.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox="0 0 780.0 489.0">
<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 2042 skipping to change at line 1994
| '-----------------------------------+ | | | '-----------------------------------+ | |
| A 192.0.2.1 | +-----+ dCDN | | A 192.0.2.1 | +-----+ dCDN |
| | | | | | | | | |
'--------------------------------------->| TLS | | '--------------------------------------->| TLS | |
SNI: video.cp.example | | | | SNI: video.cp.example | | | |
| '-----' | | '-----' |
'------------' '------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t indent="0" pn="section-5.1.2.1-3">Unlike HTTP-based redirection, where the original URL is supplanted by the one <t indent="0" pn="section-5.1.2.1-3">Unlike HTTP-based redirection, where the original URL is supplanted by the one
found in the Location header of the 302 response, DNS redirection is completely found in the <tt>Location</tt> header of the 302 response, DNS redirection is co mpletely
transparent to the User Agent. As a result, the TLS connection to the dCDN transparent to the User Agent. As a result, the TLS connection to the dCDN
edge is done with a Server Name Indication (SNI) equal to the <tt>host</tt> in t he edge is done with a Server Name Indication (SNI) equal to the <tt>host</tt> in t he
original URI - in the example, <tt>video.cp.example</tt>. So, in order to original URI -- in the example, <tt>video.cp.example</tt>. So, in order to
successfully complete the handshake, the landing dCDN node has to be configured successfully complete the handshake, the landing dCDN node has to be configured
with a certificate whose subjectAltName matches <tt>video.cp.example</tt>, i.e., with a certificate whose <tt>subjectAltName</tt> field matches <tt>video.cp.exam
a ple</tt>, i.e., a
Content Provider's name.</t> content provider's name.</t>
<t indent="0" pn="section-5.1.2.1-4"><xref target="fig-cdni-flow" fo rmat="default" sectionFormat="of" derivedContent="Figure 12"/> illustrates the c ascaded delegation flow that allows dCDN to <t indent="0" pn="section-5.1.2.1-4"><xref target="fig-cdni-flow" fo rmat="default" sectionFormat="of" derivedContent="Figure 12"/> illustrates the c ascaded delegation flow that allows dCDN to
obtain a STAR certificate that bears a name belonging to the Content Provider obtain a STAR certificate that bears a name belonging to the content provider
with a private key that is only known to the dCDN.</t> with a private key that is only known to the dCDN.</t>
<figure anchor="fig-cdni-flow" align="left" suppress-title="false" p n="figure-12"> <figure anchor="fig-cdni-flow" align="left" suppress-title="false" p n="figure-12">
<name slugifiedName="name-two-levels-delegation-in-cd">Two levels delegation in CDNI</name> <name slugifiedName="name-two-levels-delegation-in-cd">Two-Level D elegation in CDNI</name>
<artset pn="section-5.1.2.1-5.1"> <artset pn="section-5.1.2.1-5.1">
<artwork type="svg" name="" align="left" alt="" pn="section-5.1. 2.1-5.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" height="553" width="464" viewBox="0 0 464.0 553.0"> <artwork type="svg" name="" align="left" alt="" pn="section-5.1. 2.1-5.1.1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox="0 0 696.0 553.0">
<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 2334 skipping to change at line 2287
| .-+----.----+-.------. | | | | .-+----.----+-.------. | | |
| | | STAR | +------------' | | | | STAR | +------------' |
| dCDN | CDNI | dele | HTTP | | | | dCDN | CDNI | dele | HTTP | | |
| | | cli | |<--------------' | | | cli | |<--------------'
| '------'------'------' | | '------'------'------' |
'---------------------------' '---------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t indent="0" pn="section-5.1.2.1-6">uCDN is configured to delegate to dCDN, and CP is configured to delegate to uCDN, both as defined in <xref targ et="sec-profile-dele-config" format="default" sectionFormat="of" derivedContent= "Section 2.3.1"/>.</t> <t indent="0" pn="section-5.1.2.1-6">uCDN is configured to delegate to dCDN, and CP is configured to delegate to uCDN, both as defined in <xref targ et="sec-profile-dele-config" format="default" sectionFormat="of" derivedContent= "Section 2.3.1"/>.</t>
<ol spacing="compact" type="1" indent="adaptive" start="1" pn="secti <ol spacing="normal" type="1" indent="adaptive" start="1" pn="sectio
on-5.1.2.1-7"><li pn="section-5.1.2.1-7.1" derivedCounter="1.">dCDN requests CDN n-5.1.2.1-7">
I path metadata to uCDN;</li> <li pn="section-5.1.2.1-7.1" derivedCounter="1.">dCDN requests CDNI
path metadata to uCDN.</li>
<li pn="section-5.1.2.1-7.2" derivedCounter="2.">uCDN replies with , among other CDNI metadata, the STAR delegation <li pn="section-5.1.2.1-7.2" derivedCounter="2.">uCDN replies with , among other CDNI metadata, the STAR delegation
configuration, which includes the delegated Content Provider's name;</li> configuration, which includes the delegated content provider's name.</li>
<li pn="section-5.1.2.1-7.3" derivedCounter="3.">dCDN creates a ke <li pn="section-5.1.2.1-7.3" derivedCounter="3.">dCDN creates a ke
y-pair and the CSR with the delegated name. It then places y pair and the CSR with the delegated name. It then places
an order for the delegated name to uCDN;</li> an order for the delegated name to uCDN.</li>
<li pn="section-5.1.2.1-7.4" derivedCounter="4.">uCDN forwards the <li pn="section-5.1.2.1-7.4" derivedCounter="4.">uCDN forwards the
received order to the Content Provider (CP);</li> received order to the content provider (CP).</li>
<li pn="section-5.1.2.1-7.5" derivedCounter="5.">CP creates an ord er for a STAR certificate and sends it to the CA. The <li pn="section-5.1.2.1-7.5" derivedCounter="5.">CP creates an ord er for a STAR certificate and sends it to the CA. The
order also requests unauthenticated access to the certificate resource;</li> order also requests unauthenticated access to the certificate resource.</li>
<li pn="section-5.1.2.1-7.6" derivedCounter="6.">After all authori zations complete successfully, the STAR certificate is <li pn="section-5.1.2.1-7.6" derivedCounter="6.">After all authori zations complete successfully, the STAR certificate is
issued;</li> issued.</li>
<li pn="section-5.1.2.1-7.7" derivedCounter="7.">CP notifies uCDN that the STAR certificate is available at the order's <li pn="section-5.1.2.1-7.7" derivedCounter="7.">CP notifies uCDN that the STAR certificate is available at the order's
star-certificate URL;</li> <tt>star-certificate</tt> URL.</li>
<li pn="section-5.1.2.1-7.8" derivedCounter="8.">uCDN forwards the <li pn="section-5.1.2.1-7.8" derivedCounter="8.">uCDN forwards the
information to dCDN. At this point the ACME signalling is information to dCDN. At this point, the ACME signaling is
complete;</li> complete.</li>
<li pn="section-5.1.2.1-7.9" derivedCounter="9.">dCDN requests the <li pn="section-5.1.2.1-7.9" derivedCounter="9.">dCDN requests the
STAR certificate using unauthenticated GET from the CA;</li> STAR certificate using unauthenticated GET from the CA.</li>
<li pn="section-5.1.2.1-7.10" derivedCounter="10.">the CA returns <li pn="section-5.1.2.1-7.10" derivedCounter="10.">The CA returns
the certificate. Now dCDN is fully configured to handle the certificate. Now dCDN is fully configured to handle
HTTPS traffic in-lieu of the Content Provider.</li> HTTPS traffic in lieu of the content provider.</li>
</ol> </ol>
<t indent="0" pn="section-5.1.2.1-8">Note that 9. and 10. repeat unt il 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" toc="include" removeInRFC="false" pn="section-5.2">
<name slugifiedName="name-secure-telephone-identity-r">Secure Telephone Identity Revisited (STIR)</name> <name slugifiedName="name-secure-telephone-identity-r">Secure Telephone Identity Revisited (STIR)</name>
<t indent="0" pn="section-5.2-1">As a second use case, we consider the d elegation of credentials in the STIR <t indent="0" pn="section-5.2-1">As a second use case, we consider the d elegation of credentials in the STIR
ecosystem <xref target="I-D.ietf-stir-cert-delegation" format="default" section ecosystem <xref target="RFC9060" format="default" sectionFormat="of" derivedCon
Format="of" derivedContent="I-D.ietf-stir-cert-delegation"/>.</t> tent="RFC9060"/>.</t>
<t indent="0" pn="section-5.2-2">This section uses STIR terminology. The <t indent="0" pn="section-5.2-2">This section uses STIR terminology. The
term PASSPorT is defined in <xref target="RFC8225" format="default" sectionForm term Personal Assertion Token (PASSporT) is defined in <xref target="RFC8225" f
at="of" derivedContent="RFC8225"/>, and "TNAuthList" in <xref target="RFC8226" f ormat="default" sectionFormat="of" derivedContent="RFC8225"/>, and "TNAuthList"
ormat="default" sectionFormat="of" derivedContent="RFC8226"/>.</t> is defined in <xref target="RFC8226" format="default" sectionFormat="of" derived
<t indent="0" pn="section-5.2-3">In the STIR <tt>delegated</tt> mode, a Content="RFC8226"/>.</t>
service provider SP2 - the NDC - needs to sign <t indent="0" pn="section-5.2-3">In the STIR delegated mode, a service p
PASSPorT's <xref target="RFC8225" format="default" sectionFormat="of" derivedCon rovider SP2 -- the NDC -- needs to sign
tent="RFC8225"/> for telephone numbers (e.g., TN=+123) belonging to PASSporTs <xref target="RFC8225" format="default" sectionFormat="of" derivedCont
another service provider, SP1 - the IdO. In order to do that, SP2 needs a STIR ent="RFC8225"/> for telephone numbers (e.g., TN=+123) belonging to
certificate, and private key, that includes TN=+123 in the TNAuthList another service provider, SP1 -- the IdO. In order to do that, SP2 needs a STIR
certificate and a private key that includes TN=+123 in the TNAuthList
<xref target="RFC8226" format="default" sectionFormat="of" derivedContent="RFC82 26"/> certificate extension.</t> <xref target="RFC8226" format="default" sectionFormat="of" derivedContent="RFC82 26"/> certificate extension.</t>
<t indent="0" pn="section-5.2-4">In details (<xref target="fig-stir-flow <t indent="0" pn="section-5.2-4">In detail (<xref target="fig-stir-flow"
" format="default" sectionFormat="of" derivedContent="Figure 13"/>):</t> format="default" sectionFormat="of" derivedContent="Figure 13"/>):</t>
<ol spacing="compact" type="1" indent="adaptive" start="1" pn="section-5 <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.
.2-5"><li pn="section-5.2-5.1" derivedCounter="1.">SP1 and SP2 agree on the conf 2-5">
iguration of the delegation - in particular, <li pn="section-5.2-5.1" derivedCounter="1.">SP1 and SP2 agree on the c
the CSR template that applies;</li> onfiguration of the delegation -- in particular,
<li pn="section-5.2-5.2" derivedCounter="2.">SP2 generates a private/p the CSR template that applies.</li>
ublic key-pair and sends a CSR to SP1 requesting <li pn="section-5.2-5.2" derivedCounter="2.">SP2 generates a private/p
creation of a certificate with: SP1 name, SP2 public key, and a TNAuthList ublic key pair and sends a CSR to SP1, requesting
creation of a certificate with an SP1 name, an SP2 public key, and a TNAuthList
extension with the list of TNs that SP1 delegates to SP2. (Note that the extension with the list of TNs that SP1 delegates to SP2. (Note that the
CSR sent by SP2 to SP1 needs to be validated against the CSR template CSR sent by SP2 to SP1 needs to be validated against the CSR template
agreed upon in step 1.);</li> agreed upon in step 1.).</li>
<li pn="section-5.2-5.3" derivedCounter="3.">SP1 sends an order for th e CSR to the CA. The order also requests <li pn="section-5.2-5.3" derivedCounter="3.">SP1 sends an order for th e CSR to the CA. The order also requests
unauthenticated access to the certificate resource;</li> unauthenticated access to the certificate resource.</li>
<li pn="section-5.2-5.4" derivedCounter="4.">Subsequently, after the r equired TNAuthList authorizations are successfully <li pn="section-5.2-5.4" derivedCounter="4.">Subsequently, after the r equired TNAuthList authorizations are successfully
completed, the CA moves the order to a "valid" state; at the same completed, the CA moves the order to a "valid" state; at the same
time the star-certificate endpoint is populated;</li> time, the star-certificate endpoint is populated.</li>
<li pn="section-5.2-5.5" derivedCounter="5.">The order contents are fo <li pn="section-5.2-5.5" derivedCounter="5.">The contents of the order
rwarded from SP1 to SP2 by means of the paired are forwarded from SP1 to SP2 by means of the paired
"delegation" order;</li> "delegation" order.</li>
<li pn="section-5.2-5.6" derivedCounter="6.">SP2 dereferences the star <li pn="section-5.2-5.6" derivedCounter="6.">SP2 dereferences the <tt>
-certificate URL in the order to fetch the rolling star-certificate</tt> URL in the order to fetch the rolling
STAR certificate bearing the delegated identifiers;</li> STAR certificate bearing the delegated identifiers.</li>
<li pn="section-5.2-5.7" derivedCounter="7.">The STAR certificate is r eturned to SP2.</li> <li pn="section-5.2-5.7" derivedCounter="7.">The STAR certificate is r eturned to SP2.</li>
</ol> </ol>
<figure anchor="fig-stir-flow" align="left" suppress-title="false" pn="f igure-13"> <figure anchor="fig-stir-flow" align="left" suppress-title="false" pn="f igure-13">
<name slugifiedName="name-delegation-in-stir">Delegation in STIR</name > <name slugifiedName="name-delegation-in-stir">Delegation in STIR</name >
<artset pn="section-5.2-6.1"> <artset pn="section-5.2-6.1">
<artwork type="svg" name="" align="left" alt="" pn="section-5.2-6.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" height= "377" width="408" viewBox="0 0 408.0 377.0"> <artwork type="svg" name="" align="left" alt="" pn="section-5.2-6.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 612.0 377.0">
<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 2590 skipping to change at line 2545
| | .-+----.------. | | 7 | | .-+----.------. | | 7
| | | STAR | +-----' | | | | STAR | +-----' |
'-->| SP2 | dele | HTTP | | | '-->| SP2 | dele | HTTP | | |
| | cli | |<--------------' | | cli | |<--------------'
| '----+-'-+----' | | '----+-'-+----' |
'-------------------' '-------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t indent="0" pn="section-5.2-7">As shown, the STAR delegation profile d escribed in this document applies <t indent="0" pn="section-5.2-7">As shown, the STAR delegation profile d escribed in this document applies
straightforwardly, the only extra requirement being the ability to instruct the straightforwardly; the only extra requirement being the ability to instruct the
NDC about the allowed TNAuthList values. This can be achieved by a simple NDC about the allowed TNAuthList values. This can be achieved by a simple
extension to the CSR template.</t> extension to the CSR template.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="include" removeIn RFC="false" pn="section-6"> <section anchor="iana-considerations" numbered="true" toc="include" removeIn RFC="false" pn="section-6">
<name slugifiedName="name-iana-considerations">IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-6-1">[[RFC Editor: please replace XXXX below by the RFC number.]]</t>
<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" toc="include" removeInRFC="false" pn="section-6.1">
<name slugifiedName="name-new-fields-in-the-meta-obje">New Fields in the "meta" Object within a Directory Object</name> <name slugifiedName="name-new-fields-in-the-meta-obje">New Fields in the "meta" Object within a Directory Object</name>
<t indent="0" pn="section-6.1-1">This document adds the following entrie s to the ACME Directory Metadata Fields registry:</t> <t indent="0" pn="section-6.1-1">This document adds the following entrie s to the "ACME Directory Metadata Fields" registry:</t>
<table align="center" pn="table-1"> <table align="center" pn="table-1">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Field Name</th> <th align="left" colspan="1" rowspan="1">Field Name</th>
<th align="left" colspan="1" rowspan="1">Field Type</th> <th align="left" colspan="1" rowspan="1">Field Type</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">delegation-enabled</td> <td align="left" colspan="1" rowspan="1">delegation-enabled</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 XXXX</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 XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9115</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="new-fields-in-the-order-object" numbered="true" toc="incl ude" removeInRFC="false" pn="section-6.2"> <section anchor="new-fields-in-the-order-object" numbered="true" toc="incl ude" removeInRFC="false" pn="section-6.2">
<name slugifiedName="name-new-fields-in-the-order-obj">New Fields in the Order Object</name> <name slugifiedName="name-new-fields-in-the-order-obj">New Fields in the Order Object</name>
<t indent="0" pn="section-6.2-1">This document adds the following entrie s to the ACME Order Object Fields registry:</t> <t indent="0" pn="section-6.2-1">This document adds the following entrie s to the "ACME Order Object Fields" registry:</t>
<table align="center" pn="table-2"> <table align="center" pn="table-2">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Field Name</th> <th align="left" colspan="1" rowspan="1">Field Name</th>
<th align="left" colspan="1" rowspan="1">Field Type</th> <th align="left" colspan="1" rowspan="1">Field Type</th>
<th align="left" colspan="1" rowspan="1">Configurable</th> <th align="left" colspan="1" rowspan="1">Configurable</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<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">true</td> <td align="left" colspan="1" rowspan="1">true</td>
<td align="left" colspan="1" rowspan="1">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9115</td>
</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 XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9115</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="new-fields-in-the-account-object" numbered="true" toc="in clude" removeInRFC="false" pn="section-6.3"> <section anchor="new-fields-in-the-account-object" numbered="true" toc="in clude" removeInRFC="false" pn="section-6.3">
<name slugifiedName="name-new-fields-in-the-account-o">New Fields in the Account Object</name> <name slugifiedName="name-new-fields-in-the-account-o">New Fields in the Account Object</name>
<t indent="0" pn="section-6.3-1">This document adds the following entrie s to the ACME Account Object Fields registry:</t> <t indent="0" pn="section-6.3-1">This document adds the following entrie s to the "ACME Account Object Fields" registry:</t>
<table align="center" pn="table-3"> <table align="center" pn="table-3">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Field Name</th> <th align="left" colspan="1" rowspan="1">Field Name</th>
<th align="left" colspan="1" rowspan="1">Field Type</th> <th align="left" colspan="1" rowspan="1">Field Type</th>
<th align="left" colspan="1" rowspan="1">Requests</th> <th align="left" colspan="1" rowspan="1">Requests</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<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 XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9115</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t indent="0" pn="section-6.3-3">Note that the <tt>delegations</tt> fiel d is only reported by ACME servers that have <t indent="0" pn="section-6.3-3">Note that the <tt>delegations</tt> fiel d is only reported by ACME servers that have
<tt>delegation-enabled</tt> set to true in their meta Object.</t> <tt>delegation-enabled</tt> set to true in their meta Object.</t>
</section> </section>
<section anchor="new-error-types" numbered="true" toc="include" removeInRF C="false" pn="section-6.4"> <section anchor="new-error-types" numbered="true" toc="include" removeInRF C="false" pn="section-6.4">
<name slugifiedName="name-new-error-types">New Error Types</name> <name slugifiedName="name-new-error-types">New Error Types</name>
<t indent="0" pn="section-6.4-1">This document adds the following entrie s to the ACME Error Type registry:</t> <t indent="0" pn="section-6.4-1">This document adds the following entrie s to the "ACME Error Types" registry:</t>
<table align="center" pn="table-4"> <table align="center" pn="table-4">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Type</th> <th align="left" colspan="1" rowspan="1">Type</th>
<th align="left" colspan="1" rowspan="1">Description</th> <th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">unknownDelegation</td> <td align="left" colspan="1" rowspan="1">unknownDelegation</td>
<td align="left" colspan="1" rowspan="1">An unknown configuration <td align="left" colspan="1" rowspan="1">An unknown configuration
is listed in the <tt>delegations</tt> attribute of the request Order</td> is listed in the <tt>delegation</tt> attribute of the order request</td>
<td align="left" colspan="1" rowspan="1">RFC XXXX</td> <td align="left" colspan="1" rowspan="1">RFC 9115</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="csr-template-registry" numbered="true" toc="include" remo veInRFC="false" pn="section-6.5"> <section anchor="csr-template-registry" numbered="true" toc="include" remo veInRFC="false" pn="section-6.5">
<name slugifiedName="name-csr-template-extensions">CSR Template Extensio ns</name> <name slugifiedName="name-csr-template-extensions">CSR Template Extensio ns</name>
<t indent="0" pn="section-6.5-1">IANA is requested to establish a regist ry "STAR Delegation CSR Template <t indent="0" pn="section-6.5-1">IANA is requested to establish a regist ry, "STAR Delegation CSR Template
Extensions", with "Specification Required" as its registration procedure.</t> Extensions", with "Specification Required" as its registration procedure.</t>
<t indent="0" pn="section-6.5-2">Each extension registered must specify: </t> <t indent="0" pn="section-6.5-2">Each extension registered must specify: </t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6
6.5-3"> .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 <li pn="section-6.5-3.2">an extension syntax, as a reference to a CDDL
document that defines this extension.</li> document that defines this extension, and</li>
<li pn="section-6.5-3.3">The extension's mapping into an X.509 certifi <li pn="section-6.5-3.3">the extension's mapping into an X.509 certifi
cate extension.</li> cate extension.</li>
</ul> </ul>
<t indent="0" pn="section-6.5-4">The initial contents of this registry a re the extensions defined by the CDDL <t indent="0" pn="section-6.5-4">The initial contents of this registry a re the extensions defined by the CDDL
in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" d erivedContent="Appendix B"/>.</t> in <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" d erivedContent="Appendix B"/>.</t>
<table align="center" pn="table-5"> <table align="center" pn="table-5">
<thead> <thead>
<tr> <tr>
<th align="left" colspan="1" rowspan="1">Extension Name</th> <th align="left" colspan="1" rowspan="1">Extension Name</th>
<th align="left" colspan="1" rowspan="1">Extension Syntax</th> <th align="left" colspan="1" rowspan="1">Extension Syntax</th>
<th align="left" colspan="1" rowspan="1">Mapping to X.509 Certific ate Extension</th> <th align="left" colspan="1" rowspan="1">Mapping to X.509 Certific ate Extension</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">keyUsage</td> <td align="left" colspan="1" rowspan="1">keyUsage</td>
<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix B"/></td> <td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix B"/></td>
<td align="left" colspan="1" rowspan="1"> <td align="left" colspan="1" rowspan="1">
<xref target="RFC5280" format="default" sectionFormat="of" deriv edContent="RFC5280"/>, Section 4.2.1.3</td> <xref target="RFC5280" format="default" sectionFormat="comma" de rivedContent="RFC5280" section="4.2.1.3"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">extendedKeyUsage</td> <td align="left" colspan="1" rowspan="1">extendedKeyUsage</td>
<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix B"/></td> <td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix B"/></td>
<td align="left" colspan="1" rowspan="1"> <td align="left" colspan="1" rowspan="1">
<xref target="RFC5280" format="default" sectionFormat="of" deriv edContent="RFC5280"/>, Section 4.2.1.12</td> <xref target="RFC5280" format="default" sectionFormat="comma" de rivedContent="RFC5280" section="4.2.1.12"/></td>
</tr> </tr>
<tr> <tr>
<td align="left" colspan="1" rowspan="1">subjectAltName</td> <td align="left" colspan="1" rowspan="1">subjectAltName</td>
<td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix B"/></td> <td align="left" colspan="1" rowspan="1">See <xref target="csr-tem plate-schema-cddl" format="default" sectionFormat="of" derivedContent="Appendix B"/></td>
<td align="left" colspan="1" rowspan="1"> <td align="left" colspan="1" rowspan="1">
<xref target="RFC5280" format="default" sectionFormat="of" deriv edContent="RFC5280"/>, Section 4.2.1.6 (note that only specific name formats are allowed: URI, DNS name, email address)</td> <xref target="RFC5280" format="default" sectionFormat="comma" de rivedContent="RFC5280" section="4.2.1.6"/> (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 assign ment in this registry, the designated expert should follow this guidance:</t> <t indent="0" pn="section-6.5-6">When evaluating a request for an assign ment in this registry, the designated expert should follow this guidance:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- 6.5-7"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6 .5-7">
<li pn="section-6.5-7.1">The definition must include a full CDDL defin ition, which the expert will validate.</li> <li pn="section-6.5-7.1">The definition must include a full CDDL defin ition, which the expert will validate.</li>
<li pn="section-6.5-7.2">The definition must include both positive and negative test cases.</li> <li pn="section-6.5-7.2">The definition must include both positive and negative test cases.</li>
<li pn="section-6.5-7.3">Additional requirements that are not captured by the CDDL definition are allowed but must be explicitly specified.</li> <li pn="section-6.5-7.3">Additional requirements that are not captured by the CDDL definition are allowed but must be explicitly specified.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="include" remo veInRFC="false" pn="section-7"> <section anchor="security-considerations" numbered="true" toc="include" remo veInRFC="false" pn="section-7">
<name slugifiedName="name-security-considerations">Security Considerations </name> <name slugifiedName="name-security-considerations">Security Considerations </name>
<section anchor="sec-trust-model" numbered="true" toc="include" removeInRF C="false" pn="section-7.1"> <section anchor="sec-trust-model" numbered="true" toc="include" removeInRF C="false" pn="section-7.1">
<name slugifiedName="name-trust-model">Trust Model</name> <name slugifiedName="name-trust-model">Trust Model</name>
<t indent="0" pn="section-7.1-1">The ACME trust model needs to be extend ed to include the trust relationship <t indent="0" pn="section-7.1-1">The ACME trust model needs to be extend ed to include the trust relationship
between NDC and IdO. Note that once this trust link is established, it between NDC and IdO. Note that once this trust link is established, it
potentially becomes recursive. Therefore, there has to be a trust relationship potentially becomes recursive. Therefore, there has to be a trust relationship
between each of the nodes in the delegation chain; for example, in case of between each of the nodes in the delegation chain; for example, in case of
cascading CDNs this is contractually defined. Note that using standard cascading CDNs, this is contractually defined. Note that when using standard
<xref target="RFC6125" format="default" sectionFormat="of" derivedContent="RFC61 <xref target="RFC6125" format="default" sectionFormat="of" derivedContent="RFC61
25"/> identity verification there are no mechanisms available to the IdO 25"/> identity verification, there are no mechanisms available to the IdO
to restrict the use of the delegated name once the name has been handed over to to restrict the use of the delegated name once the name has been handed over to
the first NDC. It is therefore expected that contractual measures are in place the first NDC. It is, therefore, expected that contractual measures are in plac
to get some assurance that re-delegation is not being performed.</t> e
to get some assurance that redelegation is not being performed.</t>
</section> </section>
<section anchor="delegation-security-goal" numbered="true" toc="include" r emoveInRFC="false" pn="section-7.2"> <section anchor="delegation-security-goal" numbered="true" toc="include" r emoveInRFC="false" pn="section-7.2">
<name slugifiedName="name-delegation-security-goal">Delegation Security Goal</name> <name slugifiedName="name-delegation-security-goal">Delegation Security Goal</name>
<t indent="0" pn="section-7.2-1">Delegation introduces a new security go al: only an NDC that has been authorised <t indent="0" pn="section-7.2-1">Delegation introduces a new security go al: only an NDC that has been authorized
by the IdO, either directly or transitively, can obtain a certificate with an by the IdO, either directly or transitively, can obtain a certificate with an
IdO identity.</t> IdO identity.</t>
<t indent="0" pn="section-7.2-2">From a security point of view, the dele gation process has five separate parts:</t> <t indent="0" pn="section-7.2-2">From a security point of view, the dele gation process has five separate parts:</t>
<ol spacing="compact" type="1" indent="adaptive" start="1" pn="section-7 <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7.
.2-3"><li pn="section-7.2-3.1" derivedCounter="1.">Enabling a specific third par 2-3">
ty (the intended NDC) to submit requests for <li pn="section-7.2-3.1" derivedCounter="1.">enabling a specific third
delegated certificates;</li> party (the intended NDC) to submit requests for
<li pn="section-7.2-3.2" derivedCounter="2.">Making sure that any requ delegated certificates</li>
est for a delegated certificate matches the <li pn="section-7.2-3.2" derivedCounter="2.">making sure that any requ
est for a delegated certificate matches the
intended "shape" in terms of delegated identities as well as any other intended "shape" in terms of delegated identities as well as any other
certificate metadata, e.g., key length, x.509 extensions, etc.;</li> certificate metadata, e.g., key length, x.509 extensions, etc.</li>
<li pn="section-7.2-3.3" derivedCounter="3.">Serving the certificate b <li pn="section-7.2-3.3" derivedCounter="3.">serving the certificate b
ack to the NDC;</li> ack to the NDC</li>
<li pn="section-7.2-3.4" derivedCounter="4.">A process for handling re <li pn="section-7.2-3.4" derivedCounter="4.">handling revocation of th
vocation of the delegation;</li> e delegation</li>
<li pn="section-7.2-3.5" derivedCounter="5.">A process for handling re <li pn="section-7.2-3.5" derivedCounter="5.">handling revocation of th
vocation of the 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 MUST use the When a compromise of the private key is detected, the delegate <bcp14>MUST</bcp1
account deactivation procedures defined in Section 7.3.6 of <xref target="RFC855 4> use the
5" format="default" sectionFormat="of" derivedContent="RFC8555"/>.</t> account deactivation procedures defined in <xref target="RFC8555" format="defaul
t" sectionFormat="of" derivedContent="RFC8555" section="7.3.6"/>.</t>
<t indent="0" pn="section-7.2-5">The second part is covered by the act o f checking an NDC's certificate request <t indent="0" pn="section-7.2-5">The second part is covered by the act o f checking an NDC's certificate request
against the intended CSR template. The steps of shaping the CSR template against the intended CSR template. The steps of shaping the CSR template
correctly, selecting the right CSR template to check against the presented CSR, correctly, selecting the right CSR template to check against the presented CSR,
and making sure that the presented CSR matches the selected CSR template are and making sure that the presented CSR matches the selected CSR template are
all security relevant.</t> all security relevant.</t>
<t indent="0" pn="section-7.2-6">The third part builds on the trust rela tionship between NDC and IdO that is <t indent="0" pn="section-7.2-6">The third part builds on the trust rela tionship between NDC and IdO that is
responsible for correctly forwarding the certificate URL from the Order responsible for correctly forwarding the certificate URL from the Order
returned by the CA.</t> returned by the CA.</t>
<t indent="0" pn="section-7.2-7">The fourth part is associated with the ability of the IdO to unilaterally <t indent="0" pn="section-7.2-7">The fourth part is associated with the ability of the IdO to unilaterally
remove the delegation object associated with the revoked identity, therefore remove the <tt>delegation</tt> object associated with the revoked identity, ther efore,
disabling any further NDC requests for such identity. Note that, in more disabling any further NDC requests for such identity. Note that, in more
extreme circumstances, the IdO might decide to disable the NDC account extreme circumstances, the IdO might decide to disable the NDC account,
thus entirely blocking any further interaction.</t> thus entirely blocking any further interaction.</t>
<t indent="0" pn="section-7.2-8">The fifth is covered by two different m echanisms, depending on the nature of <t indent="0" pn="section-7.2-8">The fifth is covered by two different m echanisms, depending on the nature of
the certificate. For STAR, the IdO shall use the cancellation interface the certificate. For STAR, the IdO shall use the cancellation interface
defined in Section 2.3 of <xref target="RFC8739" format="default" sectionFormat= defined in <xref target="RFC8739" format="default" sectionFormat="of" derivedCon
"of" derivedContent="RFC8739"/>. For non-STAR, the certificate revocation tent="RFC8739" section="2.3"/>. For non-STAR, the certificate revocation
interface defined in Section 7.6 of <xref target="RFC8555" format="default" sect interface defined in <xref target="RFC8555" format="default" sectionFormat="of"
ionFormat="of" derivedContent="RFC8555"/>) is used.</t> derivedContent="RFC8555" section="7.6"/>) is used.</t>
<t indent="0" pn="section-7.2-9">The ACME account associated with the de legation plays a crucial role in the <t indent="0" pn="section-7.2-9">The ACME account associated with the de legation plays a crucial role in the
overall security of the presented protocol. This, in turn, means that in overall security of the presented protocol. This, in turn, means that (in
delegation scenarios the security requirements and verification associated with delegation scenarios) the security requirements and verification associated with
an ACME account may be more stringent than in traditional ACME, since the an ACME account may be more stringent than in base ACME deployments, since the
out-of-band configuration of delegations that an account is authorized to use, out-of-band configuration of delegations that an account is authorized to use
combined with account authentication, takes the place of the normal ACME (combined with account authentication) takes the place of the normal ACME
authorization challenge procedures. Therefore, the IdO MUST ensure that authorization challenge procedures. Therefore, the IdO <bcp14>MUST</bcp14> ensu
re that
each account is associated with the exact policies (via their matching <tt>deleg ation</tt> objects) each account is associated with the exact policies (via their matching <tt>deleg ation</tt> objects)
that define which domain names can be delegated to the account and how. that define which domain names can be delegated to the account and how.
The IdO is expected to use out of band means to pre-register each NDC to The IdO is expected to use out-of-band means to preregister each NDC to
the corresponding account.</t> the corresponding account.</t>
</section> </section>
<section anchor="new-acme-channels" numbered="true" toc="include" removeIn RFC="false" pn="section-7.3"> <section anchor="new-acme-channels" numbered="true" toc="include" removeIn RFC="false" 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 Section <t indent="0" pn="section-7.3-1">Using the model established in <xref ta
10.1 of <xref target="RFC8555" format="default" sectionFormat="of" derivedConten rget="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555" sect
t="RFC8555"/>, we can decompose ion="10.1"/>, we can decompose
the interactions of the basic delegation workflow as shown in the interactions of the basic delegation workflow, as shown in
<xref target="fig-sec-channels" format="default" sectionFormat="of" derivedConte nt="Figure 14"/>.</t> <xref target="fig-sec-channels" format="default" sectionFormat="of" derivedConte nt="Figure 14"/>.</t>
<figure anchor="fig-sec-channels" align="left" suppress-title="false" pn ="figure-14"> <figure anchor="fig-sec-channels" align="left" suppress-title="false" pn ="figure-14">
<name slugifiedName="name-delegation-channels-topolog">Delegation Chan nels Topology</name> <name slugifiedName="name-delegation-channels-topolog">Delegation Chan nels Topology</name>
<artset pn="section-7.3-2.1"> <artset pn="section-7.3-2.1">
<artwork type="svg" name="" align="left" alt="" pn="section-7.3-2.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" height= "345" width="504" viewBox="0 0 504.0 345.0"> <artwork type="svg" name="" align="left" alt="" pn="section-7.3-2.1. 1"><svg xmlns="http://www.w3.org/2000/svg" class="diagram" version="1.1" viewBox ="0 0 756.0 345.0">
<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 3043 skipping to change at line 2998
(subset of) ACME Channel [1] (subset of) ACME Channel [1]
[1] Unauthenticated certificate fetch and non-STAR certificate [1] Unauthenticated certificate fetch and non-STAR certificate
revocation. revocation.
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t indent="0" pn="section-7.3-3">The considerations regarding the securi ty of the ACME Channel and Validation <t indent="0" pn="section-7.3-3">The considerations regarding the securi ty of the ACME Channel and Validation
Channel discussed in <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> apply verbatim to the IdO-CA leg. Channel discussed in <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> apply verbatim to the IdO-CA leg.
The same can be said for the ACME channel on the NDC-IdO leg. A slightly The same can be said for the ACME Channel on the NDC-IdO leg. A slightly
different set of considerations apply to the ACME Channel between NDC and CA, different set of considerations apply to the ACME Channel between the NDC and CA
,
which consists of a subset of the ACME interface comprising two API which consists of a subset of the ACME interface comprising two API
endpoints: the unauthenticated certificate retrieval and, potentially, non-STAR endpoints: the unauthenticated certificate retrieval and, potentially, non-STAR
revocation via certificate private key. No specific security considerations revocation via certificate private key. No specific security considerations
apply to the former, but the privacy considerations in Section 6.3 of apply to the former, but the privacy considerations in
<xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RFC87 <xref target="RFC8739" format="default" sectionFormat="of" derivedContent="RFC87
39"/> do. With regards to the latter, it should be noted that there is 39" section="6.3"/> do. With regard to the latter, it should be noted that ther
currently no means for an IdO to disable authorising revocation based on e is
currently no means for an IdO to disable authorizing revocation based on
certificate private keys. So, in theory, an NDC could use the revocation API certificate private keys. So, in theory, an NDC could use the revocation API
directly with the CA, therefore bypassing the IdO. The NDC SHOULD NOT directly with the CA, therefore, bypassing the IdO. The NDC <bcp14>SHOULD NOT</ bcp14>
directly use the revocation interface exposed by the CA unless failing directly use the revocation interface exposed by the CA unless failing
to do so would compromise the overall security, for example if the certificate to do so would compromise the overall security, for example, if the certificate
private key is compromised and the IdO is not currently reachable.</t> private key is compromised and the IdO is not currently reachable.</t>
<t indent="0" pn="section-7.3-4">All other security considerations from <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC85 55"/> and <xref target="RFC8739" format="default" sectionFormat="of" derivedCont ent="RFC8739"/> apply <t indent="0" pn="section-7.3-4">All other security considerations from <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC85 55"/> and <xref target="RFC8739" format="default" sectionFormat="of" derivedCont ent="RFC8739"/> apply
as-is to the delegation topology.</t> as is to the delegation topology.</t>
</section> </section>
<section anchor="restricting-cdns-to-the-delegation-mechanism" numbered="t rue" toc="include" removeInRFC="false" pn="section-7.4"> <section anchor="restricting-cdns-to-the-delegation-mechanism" numbered="t rue" toc="include" removeInRFC="false" 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 web site is delegated to a CDN, <t indent="0" pn="section-7.4-1">When a website is delegated to a CDN, t
the CDN can in principle modify the web he CDN can in principle modify the website at will, e.g., create and remove page
site at will, create and remove pages. This means that a malicious or breached s. This means that a malicious or breached
CDN can pass the ACME (as well as common non-ACME) HTTPS-based validation CDN can pass the ACME (as well as common non-ACME) HTTPS-based validation
challenges and generate a certificate for the site. This is true regardless of challenges and generate a certificate for the site. This is true regardless of
whether the CNAME mechanisms defined in the current document is used or not.</t> whether or not the CNAME mechanisms defined in the current document is used.</t>
<t indent="0" pn="section-7.4-2">In some cases, this is the desired beha <t indent="0" pn="section-7.4-2">In some cases, this is the desired beha
vior: the domain holder trusts the CDN to vior; the domain holder trusts the CDN to
have full control of the cryptographic credentials for the site. The current have full control of the cryptographic credentials for the site. However, this
document however assumes a scenario where the domain holder only wants to delega document assumes a scenario where the domain holder only wants to delegate
te restricted control and wishes to retain the capability to cancel the CDN's
restricted control, and wishes to retain the capability to cancel the CDN's
credentials at a short notice.</t> credentials at a short notice.</t>
<t indent="0" pn="section-7.4-3">The following is a possible mitigation when the IdO wishes to ensure that a <t indent="0" pn="section-7.4-3">The following is a possible mitigation when the IdO wishes to ensure that a
rogue CDN cannot issue unauthorized certificates:</t> rogue CDN cannot issue unauthorized certificates:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section- 7.4-4"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7 .4-4">
<li pn="section-7.4-4.1">The domain holder makes sure that the CDN can not modify the DNS records for <li pn="section-7.4-4.1">The domain holder makes sure that the CDN can not modify the DNS records for
the domain. The domain holder should ensure it is the only entity authorized the domain. The domain holder should ensure it is the only entity authorized
to modify the DNS zone. Typically, it establishes a CNAME resource record to modify the DNS zone. Typically, it establishes a CNAME resource record
from a subdomain into a CDN-managed domain.</li> from a subdomain into a CDN-managed domain.</li>
<li pn="section-7.4-4.2">The domain holder uses a CAA record <xref tar get="RFC8659" format="default" sectionFormat="of" derivedContent="RFC8659"/> to restrict certificate <li pn="section-7.4-4.2">The domain holder uses a Certification Author ity Authorization (CAA) record <xref target="RFC8659" format="default" sectionFo rmat="of" derivedContent="RFC8659"/> to restrict certificate
issuance for the domain to specific CAs that comply with ACME and are known issuance for the domain to specific CAs that comply with ACME and are known
to implement <xref target="RFC8657" format="default" sectionFormat="of" derivedC ontent="RFC8657"/>.</li> to implement <xref target="RFC8657" format="default" sectionFormat="of" derivedC ontent="RFC8657"/>.</li>
<li pn="section-7.4-4.3">The domain holder uses the ACME-specific CAA mechanism <xref target="RFC8657" format="default" sectionFormat="of" derivedCont ent="RFC8657"/> to <li pn="section-7.4-4.3">The domain holder uses the ACME-specific CAA mechanism <xref target="RFC8657" format="default" sectionFormat="of" derivedCont ent="RFC8657"/> to
restrict issuance to a specific account key which is controlled by it, and restrict issuance to a specific CA account that is controlled by it and
MUST require "dns-01" as the sole validation method.</li> <bcp14>MUST</bcp14> require "dns-01" as the sole validation method.</li>
</ul> </ul>
<t indent="0" pn="section-7.4-5">We note that the above solution may nee d to be tweaked depending on the exact <t indent="0" pn="section-7.4-5">We note that the above solution may nee d to be tweaked depending on the exact
capabilities and authorisation flows supported by the selected CA. capabilities and authorization flows supported by the selected CA.
In addition, this mitigation may be bypassed if a malicious or misconfigured CA In addition, this mitigation may be bypassed if a malicious or misconfigured CA
does not comply with CAA restrictions.</t> does not comply with CAA restrictions.</t>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="true" toc="include" removeInRFC=
"false" pn="section-8">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-8-1">We would like to thank the following people
who contributed significantly to this document with their review comments and d
esign proposals: Richard Barnes, Carsten Bormann, Roman Danyliw, Lars Eggert, <c
ontact fullname="Frédéric" asciiFullname="Frederic"/> Fieau, Russ Housley, Ben K
aduk, Eric Kline, Sanjay Mishra, Francesca Palombini, Jon Peterson, Ryan Sleevi,
Emile Stephan, <contact fullname="Éric" asciiFullname="Eric"/> Vyncke.</t>
<t indent="0" pn="section-8-2">This work is partially supported by the Eur
opean Commission under Horizon 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxed
Internet (MAMI). This support does not imply endorsement.</t>
</section>
</middle> </middle>
<back> <back>
<references pn="section-9">
<displayreference target="I-D.ietf-acme-authority-token-tnauthlist" to="TOKEN-TN
AUTHLIST"/>
<displayreference target="I-D.ietf-cdni-interfaces-https-delegation" to="HTTPS-D
ELEGATION"/>
<displayreference target="I-D.ietf-tls-subcerts" to="TLS-SUBCERTS"/>
<displayreference target="I-D.mglt-lurk-tls13" to="MGLT-LURK-TLS13"/>
<displayreference target="I-D.handrews-json-schema-validation" to="json-schema-0
7"/>
<references pn="section-8">
<name slugifiedName="name-references">References</name> <name slugifiedName="name-references">References</name>
<references pn="section-9.1"> <references pn="section-8.1">
<name slugifiedName="name-normative-references">Normative References</na me> <name slugifiedName="name-normative-references">Normative References</na me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.
le> xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7807.
<date month="March" year="1997"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<t indent="0">In many standards track documents several words are xml"/>
used to signify the requirements in the specification. These words are often ca <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.
pitalized. This document defines these words as they should be interpreted in IE xml"/>
TF documents. This document specifies an Internet Best Current Practices for th <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
e Internet Community, and requests discussion and suggestions for improvements.< xml"/>
/t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8739.
</abstract> xml"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2
986" quoteTitle="true" derivedAnchor="RFC2986">
<front>
<title>PKCS #10: Certification Request Syntax Specification Version
1.7</title>
<author fullname="M. Nystrom" initials="M." surname="Nystrom">
<organization showOnFrontPage="true"/>
</author>
<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization showOnFrontPage="true"/>
</author>
<date month="November" year="2000"/>
<abstract>
<t indent="0">This memo represents a republication of PKCS #10 v1.
7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and ch
ange control is retained within the PKCS process. The body of this document, ex
cept for the security considerations section, is taken directly from the PKCS #9
v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Int
ernet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2986"/>
<seriesInfo name="DOI" value="10.17487/RFC2986"/>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280" quoteTitle="true" derivedAnchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper">
<organization showOnFrontPage="true"/>
</author>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization showOnFrontPage="true"/>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization showOnFrontPage="true"/>
</author>
<author fullname="S. Boeyen" initials="S." surname="Boeyen">
<organization showOnFrontPage="true"/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization showOnFrontPage="true"/>
</author>
<author fullname="W. Polk" initials="W." surname="Polk">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2008"/>
<abstract>
<t indent="0">This memo profiles the X.509 v3 certificate and X.50
9 v2 certificate revocation list (CRL) for use in the Internet. An overview of
this approach and model is provided as an introduction. The X.509 v3 certificat
e format is described in detail, with additional information regarding the forma
t and semantics of Internet name forms. Standard certificate extensions are des
cribed and two Internet-specific extensions are defined. A set of required cert
ificate extensions is specified. The X.509 v2 CRL format is described in detail
along with standard and Internet-specific extensions. An algorithm for X.509 c
ertification path validation is described. An ASN.1 module and examples are pro
vided in the appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC7807" target="https://www.rfc-editor.org/info/rfc7
807" quoteTitle="true" derivedAnchor="RFC7807">
<front>
<title>Problem Details for HTTP APIs</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization showOnFrontPage="true"/>
</author>
<author fullname="E. Wilde" initials="E." surname="Wilde">
<organization showOnFrontPage="true"/>
</author>
<date month="March" year="2016"/>
<abstract>
<t indent="0">This document defines a "problem detail" as a way to
carry machine- readable details of errors in a HTTP response to avoid the need
to define new error response formats for HTTP APIs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7807"/>
<seriesInfo name="DOI" value="10.17487/RFC7807"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc8
555" quoteTitle="true" derivedAnchor="RFC8555">
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author fullname="R. Barnes" initials="R." surname="Barnes">
<organization showOnFrontPage="true"/>
</author>
<author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman
-Andrews">
<organization showOnFrontPage="true"/>
</author>
<author fullname="D. McCarney" initials="D." surname="McCarney">
<organization showOnFrontPage="true"/>
</author>
<author fullname="J. Kasten" initials="J." surname="Kasten">
<organization showOnFrontPage="true"/>
</author>
<date month="March" year="2019"/>
<abstract>
<t indent="0">Public Key Infrastructure using X.509 (PKIX) certifi
cates are used for a number of purposes, the most significant of which is the au
thentication of domain names. Thus, certification authorities (CAs) in the Web
PKI are trusted to verify that an applicant for a certificate legitimately repre
sents the domain name(s) in the certificate. As of this writing, this verificat
ion is done through a collection of ad hoc mechanisms. This document describes
a protocol that a CA and an applicant can use to automate the process of verific
ation and certificate issuance. The protocol also provides facilities for other
certificate management functions, such as certificate revocation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8555"/>
<seriesInfo name="DOI" value="10.17487/RFC8555"/>
</reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
610" quoteTitle="true" derivedAnchor="RFC8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convent
ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
res</title>
<author fullname="H. Birkholz" initials="H." surname="Birkholz">
<organization showOnFrontPage="true"/>
</author>
<author fullname="C. Vigano" initials="C." surname="Vigano">
<organization showOnFrontPage="true"/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization showOnFrontPage="true"/>
</author>
<date month="June" year="2019"/>
<abstract>
<t indent="0">This document proposes a notational convention to ex
press Concise Binary Object Representation (CBOR) data structures (RFC 7049). I
ts main goal is to provide an easy and unambiguous way to express structures for
protocol messages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
</reference>
<reference anchor="RFC8739" target="https://www.rfc-editor.org/info/rfc8
739" quoteTitle="true" derivedAnchor="RFC8739">
<front>
<title>Support for Short-Term, Automatically Renewed (STAR) Certific
ates in the Automated Certificate Management Environment (ACME)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer">
<organization showOnFrontPage="true"/>
</author>
<author fullname="D. Lopez" initials="D." surname="Lopez">
<organization showOnFrontPage="true"/>
</author>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios">
<organization showOnFrontPage="true"/>
</author>
<author fullname="A. Pastor Perales" initials="A." surname="Pastor P
erales">
<organization showOnFrontPage="true"/>
</author>
<author fullname="T. Fossati" initials="T." surname="Fossati">
<organization showOnFrontPage="true"/>
</author>
<date month="March" year="2020"/>
<abstract>
<t indent="0">Public key certificates need to be revoked when they
are compromised, that is, when the associated private key is exposed to an unau
thorized entity. However, the revocation process is often unreliable. An altern
ative to revocation is issuing a sequence of certificates, each with a short val
idity period, and terminating the sequence upon compromise. This memo proposes
an Automated Certificate Management Environment (ACME) extension to enable the i
ssuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8739"/>
<seriesInfo name="DOI" value="10.17487/RFC8739"/>
</reference>
</references> </references>
<references pn="section-9.2"> <references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References </name> <name slugifiedName="name-informative-references">Informative References </name>
<reference anchor="I-D.ietf-acme-authority-token-tnauthlist" target="htt
ps://www.ietf.org/archive/id/draft-ietf-acme-authority-token-tnauthlist-08.txt"
quoteTitle="true" derivedAnchor="I-D.ietf-acme-authority-token-tnauthlist">
<front>
<title>TNAuthList profile of ACME Authority Token</title>
<author fullname="Chris Wendt">
<organization showOnFrontPage="true">Comcast</organization>
</author>
<author fullname="David Hancock">
<organization showOnFrontPage="true">Comcast</organization>
</author>
<author fullname="Mary Barnes">
<organization showOnFrontPage="true">Independent</organization>
</author>
<author fullname="Jon Peterson">
<organization showOnFrontPage="true">Neustar Inc.</organization>
</author>
<date day="27" month="March" year="2021"/>
<abstract>
<t indent="0"> This document defines a profile of the Automated
Certificate
Management Environment (ACME) Authority Token for the automated and
authorized creation of certificates for VoIP Telephone Providers to
support Secure Telephony Identity (STI) using the TNAuthList defined
by STI certificates.
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ac
</abstract> me-authority-token-tnauthlist.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-authority-tok
en-tnauthlist-08"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-cdni-interfaces-https-delegation" target="ht
tps://www.ietf.org/archive/id/draft-ietf-cdni-interfaces-https-delegation-05.txt
" quoteTitle="true" derivedAnchor="I-D.ietf-cdni-interfaces-https-delegation">
<front>
<title>CDNI extensions for HTTPS delegation</title>
<author fullname="Frederic Fieau">
<organization showOnFrontPage="true">Orange</organization>
</author>
<author fullname="Emile Stephan">
<organization showOnFrontPage="true">Orange</organization>
</author>
<author fullname="Sanjay Mishra">
<organization showOnFrontPage="true">Verizon</organization>
</author>
<date day="12" month="March" year="2021"/>
<abstract>
<t indent="0"> The delivery of content over HTTPS involving mult
iple CDNs raises
credential management issues. This document proposes extensions in
CDNI Control and Metadata interfaces to setup HTTPS delegation from
an Upstream CDN (uCDN) to a Downstream CDN (dCDN).
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-cd
</abstract> ni-interfaces-https-delegation.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-cdni-interfaces-ht
tps-delegation-05"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-stir-cert-delegation" target="https://www.ie
tf.org/archive/id/draft-ietf-stir-cert-delegation-04.txt" quoteTitle="true" deri
vedAnchor="I-D.ietf-stir-cert-delegation">
<front>
<title>STIR Certificate Delegation</title>
<author fullname="Jon Peterson">
<organization showOnFrontPage="true">Neustar, Inc.</organization>
</author>
<date day="22" month="February" year="2021"/>
<abstract>
<t indent="0"> The Secure Telephone Identity Revisited (STIR) ce
rtificate profile
provides a way to attest authority over telephone numbers and related
identifiers for the purpose of preventing telephone number spoofing.
This specification details how that authority can be delegated from a
parent certificate to a subordinate certificate. This supports a
number of use cases, including those where service providers grant
credentials to enterprises or other customers capable of signing
calls with STIR.
</t> <reference anchor='RFC9060' target='https://www.rfc-editor.org/info/rfc9060'>
</abstract> <front>
</front> <title>Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-stir-cert-delegati <author initials='J' surname='Peterson' fullname='Jon Peterson'>
on-04"/> <organization />
<refcontent>Work in Progress</refcontent> </author>
</reference> <date year='2021' month='August'/>
<reference anchor="I-D.ietf-tls-subcerts" target="https://www.ietf.org/a </front>
rchive/id/draft-ietf-tls-subcerts-10.txt" quoteTitle="true" derivedAnchor="I-D.i <seriesInfo name="RFC" value="9060"/>
etf-tls-subcerts"> <seriesInfo name="DOI" value="10.17487/RFC9060"/>
<front> </reference>
<title>Delegated Credentials for TLS</title>
<author fullname="Richard Barnes">
<organization showOnFrontPage="true">Cisco</organization>
</author>
<author fullname="Subodh Iyengar">
<organization showOnFrontPage="true">Facebook</organization>
</author>
<author fullname="Nick Sullivan">
<organization showOnFrontPage="true">Cloudflare</organization>
</author>
<author fullname="Eric Rescorla">
<organization showOnFrontPage="true">Mozilla</organization>
</author>
<date day="24" month="January" year="2021"/>
<abstract>
<t indent="0"> The organizational separation between the operato
r of a TLS endpoint
and the certification authority can create limitations. For example,
the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the
certification authority. This document describes a mechanism by
which operators may delegate their own credentials for use in TLS,
without breaking compatibility with peers that do not support this
specification.
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tl
</abstract> s-subcerts.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-subcerts-10"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.mglt-lurk-tls13" target="https://www.ietf.org/arc
hive/id/draft-mglt-lurk-tls13-04.txt" quoteTitle="true" derivedAnchor="I-D.mglt-
lurk-tls13">
<front>
<title>LURK Extension version 1 for (D)TLS 1.3 Authentication</title
>
<author fullname="Daniel Migault">
<organization showOnFrontPage="true">Ericsson</organization>
</author>
<date day="25" month="January" year="2021"/>
<abstract>
<t indent="0"> This document describes the LURK Extension 'tls13
' which enables
interactions between a LURK Client and a LURK Server in a context of
authentication with (D)TLS 1.3.
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.mglt-lu
</abstract> rk-tls13.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-mglt-lurk-tls13-04"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.handrew
<refcontent>Work in Progress</refcontent> s-json-schema-validation.xml"/>
</reference>
<reference anchor="json-schema-07" target="https://datatracker.ietf.org/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.
doc/html/draft-handrews-json-schema-validation-01" quoteTitle="true" derivedAnch xml"/>
or="json-schema-07"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7336.
<front> xml"/>
<title>JSON Schema Validation: A Vocabulary for Structural Validatio <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8225.
n of JSON</title> xml"/>
<author initials="A." surname="Wright" fullname="Austin Wright"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8226.
<organization showOnFrontPage="true"/> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8657.
<author initials="H." surname="Andrews" fullname="Henry Andrews"> xml"/>
<organization showOnFrontPage="true"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8659.
</author> xml"/>
<author initials="G." surname="Luff" fullname="Geraint Luff">
<organization showOnFrontPage="true"/>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6
125" quoteTitle="true" derivedAnchor="RFC6125">
<front>
<title>Representation and Verification of Domain-Based Application S
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
tificates in the Context of Transport Layer Security (TLS)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
">
<organization showOnFrontPage="true"/>
</author>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization showOnFrontPage="true"/>
</author>
<date month="March" year="2011"/>
<abstract>
<t indent="0">Many application technologies enable secure communic
ation between two entities by means of Internet Public Key Infrastructure Using
X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This
document specifies procedures for representing and verifying the identity of ap
plication services in such interactions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
</reference>
<reference anchor="RFC7336" target="https://www.rfc-editor.org/info/rfc7
336" quoteTitle="true" derivedAnchor="RFC7336">
<front>
<title>Framework for Content Distribution Network Interconnection (C
DNI)</title>
<author fullname="L. Peterson" initials="L." surname="Peterson">
<organization showOnFrontPage="true"/>
</author>
<author fullname="B. Davie" initials="B." surname="Davie">
<organization showOnFrontPage="true"/>
</author>
<author fullname="R. van Brandenburg" initials="R." role="editor" su
rname="van Brandenburg">
<organization showOnFrontPage="true"/>
</author>
<date month="August" year="2014"/>
<abstract>
<t indent="0">This document presents a framework for Content Distr
ibution Network Interconnection (CDNI). The purpose of the framework is to prov
ide an overall picture of the problem space of CDNI and to describe the relation
ships among the various components necessary to interconnect CDNs. CDNI require
s the specification of interfaces and mechanisms to address issues such as reque
st routing, distribution metadata exchange, and logging information exchange acr
oss CDNs. The intent of this document is to outline what each interface needs t
o accomplish and to describe how these interfaces and mechanisms fit together, w
hile leaving their detailed specification to other documents. This document, in
combination with RFC 6707, obsoletes RFC 3466.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7336"/>
<seriesInfo name="DOI" value="10.17487/RFC7336"/>
</reference>
<reference anchor="RFC8225" target="https://www.rfc-editor.org/info/rfc8
225" quoteTitle="true" derivedAnchor="RFC8225">
<front>
<title>PASSporT: Personal Assertion Token</title>
<author fullname="C. Wendt" initials="C." surname="Wendt">
<organization showOnFrontPage="true"/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2018"/>
<abstract>
<t indent="0">This document defines a method for creating and vali
dating a token that cryptographically verifies an originating identity or, more
generally, a URI or telephone number representing the originator of personal com
munications. The Personal Assertion Token, PASSporT, is cryptographically signe
d to protect the integrity of the identity of the originator and to verify the a
ssertion of the identity information at the destination. The cryptographic sign
ature is defined with the intention that it can confidently verify the originati
ng persona even when the signature is sent to the destination party over an inse
cure channel. PASSporT is particularly useful for many personal-communications
applications over IP networks and other multi-hop interconnection scenarios wher
e the originating and destination parties may not have a direct trusted relation
ship.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8225"/>
<seriesInfo name="DOI" value="10.17487/RFC8225"/>
</reference>
<reference anchor="RFC8226" target="https://www.rfc-editor.org/info/rfc8
226" quoteTitle="true" derivedAnchor="RFC8226">
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization showOnFrontPage="true"/>
</author>
<author fullname="S. Turner" initials="S." surname="Turner">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2018"/>
<abstract>
<t indent="0">In order to prevent the impersonation of telephone n
umbers on the Internet, some kind of credential system needs to exist that crypt
ographically asserts authority over telephone numbers. This document describes
the use of certificates in establishing authority over telephone numbers, as a c
omponent of a broader architecture for managing telephone numbers as identities
in protocols like SIP.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8226"/>
<seriesInfo name="DOI" value="10.17487/RFC8226"/>
</reference>
<reference anchor="RFC8657" target="https://www.rfc-editor.org/info/rfc8
657" quoteTitle="true" derivedAnchor="RFC8657">
<front>
<title>Certification Authority Authorization (CAA) Record Extensions
for Account URI and Automatic Certificate Management Environment (ACME) Method
Binding</title>
<author fullname="H. Landau" initials="H." surname="Landau">
<organization showOnFrontPage="true"/>
</author>
<date month="November" year="2019"/>
<abstract>
<t indent="0">The Certification Authority Authorization (CAA) DNS
record allows a domain to communicate an issuance policy to Certification Author
ities (CAs) but only allows a domain to define a policy with CA-level granularit
y. However, the CAA specification (RFC 8659) also provides facilities for an ext
ension to admit a more granular, CA-specific policy. This specification defines
two such parameters: one allowing specific accounts of a CA to be identified by
URIs and one allowing specific methods of domain control validation as defined b
y the Automatic Certificate Management Environment (ACME) protocol to be require
d.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8657"/>
<seriesInfo name="DOI" value="10.17487/RFC8657"/>
</reference>
<reference anchor="RFC8659" target="https://www.rfc-editor.org/info/rfc8
659" quoteTitle="true" derivedAnchor="RFC8659">
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Reco
rd</title>
<author fullname="P. Hallam-Baker" initials="P." surname="Hallam-Bak
er">
<organization showOnFrontPage="true"/>
</author>
<author fullname="R. Stradling" initials="R." surname="Stradling">
<organization showOnFrontPage="true"/>
</author>
<author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman
-Andrews">
<organization showOnFrontPage="true"/>
</author>
<date month="November" year="2019"/>
<abstract>
<t indent="0">The Certification Authority Authorization (CAA) DNS
Resource Record allows a DNS domain name holder to specify one or more Certifica
tion Authorities (CAs) authorized to issue certificates for that domain name. CA
A Resource Records allow a public CA to implement additional controls to reduce
the risk of unintended certificate mis-issue. This document defines the syntax
of the CAA record and rules for processing CAA records by CAs.</t>
<t indent="0">This document obsoletes RFC 6844.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8659"/>
<seriesInfo name="DOI" value="10.17487/RFC8659"/>
</reference>
</references> </references>
</references> </references>
<section anchor="document-history" numbered="true" toc="include" removeInRFC <section anchor="csr-template-schema-cddl" numbered="true" toc="include" rem
="false" pn="section-appendix.a"> oveInRFC="false" pn="section-appendix.a">
<name slugifiedName="name-document-history">Document History</name>
<t indent="0" pn="section-appendix.a-1">[[Note to RFC Editor: please remov
e before publication.]]</t>
<section anchor="draft-ietf-acme-star-delegation-09" numbered="true" toc="
include" removeInRFC="false" pn="section-a.1">
<name slugifiedName="name-draft-ietf-acme-star-delega">draft-ietf-acme-s
tar-delegation-09</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.1-1">
<li pn="section-a.1-1.1">A few remaining comments by Ben Kaduk.</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-08" numbered="true" toc="
include" removeInRFC="false" pn="section-a.2">
<name slugifiedName="name-draft-ietf-acme-star-delegat">draft-ietf-acme-
star-delegation-08</name>
<t indent="0" pn="section-a.2-1">Extensive reviews by multiple IETF cont
ributors and IESG members (many thanks to all involved, your names are in the Ac
knowledgments). Specifically:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.2-2">
<li pn="section-a.2-2.1">More clarity in the Terminology, and correct
distinction between CA and ACME server.</li>
<li pn="section-a.2-2.2">Explicit description of "delegations list", t
he object returned by the <tt>delegations</tt> URL.</li>
<li pn="section-a.2-2.3">The <tt>delegation</tt> is no longer part of
the identifier, rather it is a property of the order.</li>
<li pn="section-a.2-2.4">Clarified the negotiation of unauthenticated
GET for fetching certificates. This includes some normative changes.</li>
<li pn="section-a.2-2.5">Explicit description of the changes required
on the CA: support for unauthenticated GET.</li>
<li pn="section-a.2-2.6">Some changes to IANA registrations and a chan
ge to the registration policy of a new registry.</li>
<li pn="section-a.2-2.7">More detail about security considerations rel
ated to pre-registration of the NDC as an ACME account on IdO.</li>
<li pn="section-a.2-2.8">Minor changes to the CSR Template schemas.</l
i>
<li pn="section-a.2-2.9">Many editorial changes.</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-07" numbered="true" toc="
include" removeInRFC="false" pn="section-a.3">
<name slugifiedName="name-draft-ietf-acme-star-delegati">draft-ietf-acme
-star-delegation-07</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.3-1">
<li pn="section-a.3-1.1">SecDir comments by Russ Housley.</li>
<li pn="section-a.3-1.2">In particular, reorganized some parts of the
document to clarify handling of non-STAR certificates.</li>
<li pn="section-a.3-1.3">And changed the document's title accordingly.
</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-06" numbered="true" toc="
include" removeInRFC="false" pn="section-a.4">
<name slugifiedName="name-draft-ietf-acme-star-delegatio">draft-ietf-acm
e-star-delegation-06</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.4-1">
<li pn="section-a.4-1.1">CDDL schema to address Roman's remaining comm
ents.</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-05" numbered="true" toc="
include" removeInRFC="false" pn="section-a.5">
<name slugifiedName="name-draft-ietf-acme-star-delegation">draft-ietf-ac
me-star-delegation-05</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.5-1">
<li pn="section-a.5-1.1">Detailed AD review by Roman Danyliw.</li>
<li pn="section-a.5-1.2">Some comments that were left unaddressed in R
yan Sleevi's review.</li>
<li pn="section-a.5-1.3">Numerous other edits for clarity and consiste
ncy.</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-04" numbered="true" toc="
include" removeInRFC="false" pn="section-a.6">
<name slugifiedName="name-draft-ietf-acme-star-delegation-">draft-ietf-a
cme-star-delegation-04</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.6-1">
<li pn="section-a.6-1.1">Delegation of non-STAR certificates.</li>
<li pn="section-a.6-1.2">More IANA clarity, specifically on certificat
e extensions.</li>
<li pn="section-a.6-1.3">Add delegation configuration object and exten
d account and order objects
accordingly.</li>
<li pn="section-a.6-1.4">A lot more depth on Security Considerations.<
/li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-03" numbered="true" toc="
include" removeInRFC="false" pn="section-a.7">
<name slugifiedName="name-draft-ietf-acme-star-delegation-0">draft-ietf-
acme-star-delegation-03</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.7-1">
<li pn="section-a.7-1.1">Consistency with the latest changes in the ba
se ACME STAR document,
e.g. star-delegation-enabled capability renamed and moved.</li>
<li pn="section-a.7-1.2">Proxy use cases (recursive delegation) and th
e definition of proxy behavior.</li>
<li pn="section-a.7-1.3">More detailed analysis of the CDNI and STIR u
se cases, including
sequence diagrams.</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-02" numbered="true" toc="
include" removeInRFC="false" pn="section-a.8">
<name slugifiedName="name-draft-ietf-acme-star-delegation-02">draft-ietf
-acme-star-delegation-02</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.8-1">
<li pn="section-a.8-1.1">Security considerations: review by Ryan Sleev
i.</li>
<li pn="section-a.8-1.2">CSR template simplified: instead of being a J
SON Schema document itself,
it is now a simple JSON document which validates to a JSON Schema.</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-01" numbered="true" toc="
include" removeInRFC="false" pn="section-a.9">
<name slugifiedName="name-draft-ietf-acme-star-delegation-01">draft-ietf
-acme-star-delegation-01</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.9-1">
<li pn="section-a.9-1.1">Refinement of the CDNI use case.</li>
<li pn="section-a.9-1.2">Addition of the CSR template (partial, more w
ork required).</li>
<li pn="section-a.9-1.3">Further security considerations (work in prog
ress).</li>
</ul>
</section>
<section anchor="draft-ietf-acme-star-delegation-00" numbered="true" toc="
include" removeInRFC="false" pn="section-a.10">
<name slugifiedName="name-draft-ietf-acme-star-delegation-00">draft-ietf
-acme-star-delegation-00</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.10-1">
<li pn="section-a.10-1.1">Republished as a working group draft.</li>
</ul>
</section>
<section anchor="draft-sheffer-acme-star-delegation-01" numbered="true" to
c="include" removeInRFC="false" pn="section-a.11">
<name slugifiedName="name-draft-sheffer-acme-star-del">draft-sheffer-acm
e-star-delegation-01</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.11-1">
<li pn="section-a.11-1.1">Added security considerations about disallow
ing CDNs from issuing
certificates for a delegated domain.</li>
</ul>
</section>
<section anchor="draft-sheffer-acme-star-delegation-00" numbered="true" to
c="include" removeInRFC="false" pn="section-a.12">
<name slugifiedName="name-draft-sheffer-acme-star-dele">draft-sheffer-ac
me-star-delegation-00</name>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-
a.12-1">
<li pn="section-a.12-1.1">Initial version, some text extracted from dr
aft-sheffer-acme-star-requests-02</li>
</ul>
</section>
</section>
<section anchor="csr-template-schema-cddl" numbered="true" toc="include" rem
oveInRFC="false" pn="section-appendix.b">
<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.b-1">Following is the normative definit <t indent="0" pn="section-appendix.b-1">Following is the normative definit
ion of the CSR template, using CDDL <xref target="RFC8610" format="default" sect ion of the CSR template using CDDL <xref target="RFC8610" format="default" secti
ionFormat="of" derivedContent="RFC8610"/>. The CSR template MUST be a valid JSON onFormat="of" derivedContent="RFC8610"/>. The CSR template <bcp14>MUST</bcp14> b
document, compliant with the syntax defined here.</t> e a valid JSON document that is compliant with the syntax defined here.</t>
<t indent="0" pn="section-appendix.b-2">There are additional constraints n <t indent="0" pn="section-appendix.b-2">There are additional constraints n
ot expressed in CDDL that MUST be validated ot expressed in CDDL that <bcp14>MUST</bcp14> be validated
by the recipient, including:</t> by the recipient, including:</t>
<ul spacing="compact" bare="false" empty="false" indent="3" pn="section-ap <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
pendix.b-3"> endix.b-3">
<li pn="section-appendix.b-3.1">The value of each <tt>subjectAltName</tt <li pn="section-appendix.b-3.1">the value of each <tt>subjectAltName</tt
> entry is compatible with its type;</li> > entry is compatible with its type and</li>
<li pn="section-appendix.b-3.2">The parameters in each <tt>keyTypes</tt> <li pn="section-appendix.b-3.2">the parameters in each <tt>keyTypes</tt>
entry form an acceptable combination.</li> entry form an acceptable combination.</li>
</ul> </ul>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-4"><![ CDATA[ <sourcecode name="" type="cddl" pn="section-appendix.b-4"><![CDATA[
csr-template-schema = { csr-template-schema = {
keyTypes: [ + $keyType ] keyTypes: [ + $keyType ]
? subject: non-empty<distinguishedName> ? subject: non-empty<distinguishedName>
extensions: extensions extensions: extensions
} }
non-empty<M> = (M) .and ({ + any => any }) non-empty<M> = (M) .and ({ + any => any })
mandatory-wildcard = "**" mandatory-wildcard = "**"
optional-wildcard = "*" optional-wildcard = "*"
skipping to change at line 3728 skipping to change at line 3208
extendedKeyUsageType /= "serverAuth" extendedKeyUsageType /= "serverAuth"
extendedKeyUsageType /= "clientAuth" extendedKeyUsageType /= "clientAuth"
extendedKeyUsageType /= "codeSigning" extendedKeyUsageType /= "codeSigning"
extendedKeyUsageType /= "emailProtection" extendedKeyUsageType /= "emailProtection"
extendedKeyUsageType /= "timeStamping" extendedKeyUsageType /= "timeStamping"
extendedKeyUsageType /= "OCSPSigning" extendedKeyUsageType /= "OCSPSigning"
extendedKeyUsageType /= oid extendedKeyUsageType /= oid
oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*" oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="csr-template-schema" numbered="true" toc="include" removeIn RFC="false" pn="section-appendix.c"> <section anchor="csr-template-schema" numbered="true" toc="include" removeIn RFC="false" pn="section-appendix.b">
<name slugifiedName="name-csr-template-json-schema">CSR Template: JSON Sch ema</name> <name slugifiedName="name-csr-template-json-schema">CSR Template: JSON Sch ema</name>
<t indent="0" pn="section-appendix.c-1">This appendix includes an alternat ive, non-normative, JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in <xref target="json-sch ema-07" format="default" sectionFormat="of" derivedContent="json-schema-07"/>. N ote that later versions of this (now expired) draft describe later versions of t he JSON Schema syntax. At the time of writing, a stable reference for this synta x is not yet available, and we have chosen to use the draft version which is cur rently best supported by tool implementations.</t> <t indent="0" pn="section-appendix.c-1">This appendix includes an alternat ive, nonnormative JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in <xref target="I-D.handre ws-json-schema-validation" format="default" sectionFormat="of" derivedContent="I -D.handrews-json-schema-validation"/>. Note that later versions of this (now-exp ired) draft describe later versions of the JSON Schema syntax. At the time of wr iting, a stable reference for this syntax is not yet available, and we have chos en to use the draft version, which is currently best supported by tool implement ations.</t>
<t indent="0" pn="section-appendix.c-2">The same considerations about addi tional constraints checking discussed in <t indent="0" pn="section-appendix.c-2">The same considerations about addi tional constraints checking discussed in
<xref target="csr-template-schema-cddl" format="default" sectionFormat="of" deri vedContent="Appendix B"/> apply here as well.</t> <xref target="csr-template-schema-cddl" format="default" sectionFormat="of" deri vedContent="Appendix B"/> apply here as well.</t>
<artwork name="" type="" align="left" alt="" pn="section-appendix.c-3"><![ CDATA[ <sourcecode name="" type="json" pn="section-appendix.c-3"><![CDATA[
{ {
"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 3952 skipping to change at line 3432
], ],
"additionalProperties": false "additionalProperties": false
} }
}, },
"required": [ "required": [
"extensions", "extensions",
"keyTypes" "keyTypes"
], ],
"additionalProperties": false "additionalProperties": false
} }
]]></artwork> ]]></sourcecode>
</section>
<section anchor="acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.c">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-8-1">We would like to thank the following people
who contributed significantly to this document with their review comments and d
esign proposals: <contact fullname="Richard Barnes"/>, <contact fullname="Carste
n Bormann"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Lars Egger
t"/>, <contact fullname="Frédéric Fieau"/>, <contact fullname="Russ Housley"/>,
<contact fullname="Ben Kaduk"/>, <contact fullname="Eric Kline"/>, <contact full
name="Sanjay Mishra"/>, <contact fullname="Francesca Palombini"/>, <contact full
name="Jon Peterson"/>, <contact fullname="Ryan Sleevi"/>, <contact fullname="Emi
le Stephan"/>, and <contact fullname="Éric Vyncke"/>.</t>
<t indent="0" pn="section-8-2">This work is partially supported by the Eur
opean Commission under Horizon 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxed
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>
<address> <address>
<email>yaronf.ietf@gmail.com</email> <email>yaronf.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="López" fullname="Diego López"> <author initials="D." surname="López" fullname="Diego López">
skipping to change at line 3982 skipping to change at line 3469
</address> </address>
</author> </author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization showOnFrontPage="true">ARM</organization> <organization showOnFrontPage="true">ARM</organization>
<address> <address>
<email>thomas.fossati@arm.com</email> <email>thomas.fossati@arm.com</email>
</address> </address>
</author> </author>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIANwdw2AAA+192Xbb2LXg+/kKXFXWsmiTtCSPJacqYUl2WSlPEeUklbpO
CyQhCmUSYABQMlNyVr/2J/Rbv96Hfuo/6PxJf0nv8QwASMlOcm/uoJWUJQBn
3mfPQ6/XM1VazZL9aJBFg4OXT6M3RX6WzpLoLC+ib5MsKeIqzabRYTJLpnGV
TKKDpKjSs3QMf5QmHo2K5GKfm8o3aZ6ZST7O4jl0Oynis6qXJtVZLx7Pk15Z
xUVvYj/s7XxpsKdpXqz2o7KaGJMuiv2oKpZltbez8+XOnomLJN6Phsl4WaTV
ylzmxftpkS8XPKp5n6zg0WQ/OsqqpMiSqneIYxoDQ2WT/xbP8gzmsYLJLtJ9
E0XF2TiZlNVqJk+jqMrH3q9pNkmySh+UeVEVyVlp/17Ngz+rIh3bj8f5fA5t
7ds0m6WZGyb5UPVmaVn1oJNRPoPP8t7tO9xuEbtuyuWo9mScZ2WSlUtochbP
ysSYeFmd5wWspwevcSR49X0/Gp4nZ2dJQc/4AL6PizwLnufFNM7SP9H+064t
04peJPM4ncGQ2OKsj2f2yyk+6sNsgoEO+9GLv/yfRfInb5zDFA7RfxwOcwJH
fpZnADbR0Z1Df7gJNuwX/VkOLX9Z2e8aow760Zu4rAAu3wBUzmhjdPRBVkGj
PBpMAW7+8r+zti9vOqGY++ovqIsF97BpYif96FleltCxN6OT83wel8GLcAKD
45f+qBV93z/j738ZF3Max6QZ3MQ5PLpIEHp/LOHSlONzaNXbebRPPfSgdUy/
weWaJgA151W1KPfv3p3EVVwV8fh9UtB59mEKd+Fu3j2v5rO7fDfP4ZYUyWXZ
87u+iGfpRG7oLnfNaGLrV8PXr6IhfRX9xn4Fy4l+k4/j0XIWFytCHkO4w+Nq
CbvnfRflZxH2sEV9WiCmn5786477t0U6Pa/sYzlqOOE0C9/Vmj7vA0DQompt
nycZzC58V2v7LcD28uys1vBbgII0q9wrWA483tvZfWxMr9eL4lGJGw1ox5yc
p2UEm7xEXBBNkjPAAWUURwvBrLAF1XkC66hyPNexj1Gjl3EWTxNq+TS7SOEm
4u9mG1FdB7sADJXPotEqujxPx+fU03k+myQF9htnUYrYC3qDB9tJf9rvwsgT
GAi2DJfSicZxZuLZLL+EF9V5WkyiRVxUK0B9UT6q8Dvo5Xf9BztfRmNvYuWS
RosrGtJ7YwBd/ZiMqwhWja8mllJ4U4HJwsq9lvB6sRzNYPWAvwG/FUVSLvJs
UhqYB+5VeoGj8susKvLZDJrAsrEPb9p9M8CP5wh1yxK6j+E/NBOYKe5IdADN
cTuBOsEdgs9eJRXSkGj74PBVt95fxwARmacZU72TF8OoTMoSILeMAHpHyXk8
O+N+x9IvnMlFivu/XTsL2XZD296PACMk8HECiBw3Z56M4eal5TyiwyhrJ4l/
efsHm1IkeDhGdiPKL/Cx22+8XHCT4bOL/D20rSLYgDiDDUvnCYx+NF8AKQPc
NlvhotPSuBlMcgDQLK+g8R+XaZFQu3k+4RPGnmF8Hmsxy1cwe9gYM56lSOxo
1DIpYD5lny/DPJ1MZkCkvkDqUuQTwAPIFNRuBvxeJDOCFOj+p5/+6fjZweNH
9778+LELV5FPsMznsBaduj3h0s50lFfntssSOxpRgxndoWTSj04Ani7ydBJN
louZrKdrLpNoCuAQnSe43GgETEZvlONFnSTluEgXiq1w2fO8QnDEJ4jZcPdg
ZrMlPoGtfZYXZp4XuD1wRLOyG8HwCIfAKfDZ0WnqVgCrA/tFW1IaGMFfOWwg
MGJH7uBfX2YIWkeT153oHOhJPC0SWloJlAHGicdJdJnCHsDcgcBENI9XhwfR
9isAO48lw3tQwi4VHZwQbiSeW1wBFwdHgd3RoHijzFFGM27cK3wIM8GTa8J/
lzqEfUVmhS7ENXev464OATVgTwIFQ8DEyELaE7A/Pzl5M5R7BM0jvagJ3x16
jS0y3ltYm6FNOcPlRclkiqsAwqXASvPNEmAGcUfkZtK3CtnbowJuJnzahfMd
IQaLFws43hKYzCpfAMB8SMoO7oWHKC/Pc9gqvPQRoHcYT9Ciw8EwJYOP3h6/
YChPGZ7hJJIJwH4/6XctApM9h3W/Bca0IKY2HuElprsBr0oYZwUQPHuPV748
jwtEXdAuLSJgfqc93Cgfo5YMMTHc+HPENh5bgnvSNTAXQEowhOJyaJEvZ4Bc
YmqBqOI8xjPKI2QfkKjRC0ShaVLecuPCYY4Bc5X96DV9ATc+uQivcow3Jy3H
y7JEopHBhThbFvh1Dz7q0Ud0M+qEFe/pqJW0ojRiaaXcrwcPHnz8yNvKGJfO
AK8KIVfa/uisyOe65QDQY6ICsTfEhDtnEOrWjh6Qg4kbBBBoa08OFeFxlODm
0BHl3umeyN2CJxluDkGNCVeyTeeGbUCUAHmAyJLug2ydwyUdb2EmLctlnI0T
pkxDYLuq3gmcT9fxIXjk0TGIfJfQ1/bwZHDcqa+Oxi4RhJuLlDVMWWZMJqak
QQj4/G4QeQRDFjKkEHdasmOJkHAMiE/Ejdw+GHQAvSZFCtSJm58leMlsczxQ
vNjLkumKxRKMIIxDECVuGNz0ZXjN9CCAT4oS6KhOYx1VhSFNibRmhawjsbty
86KDAY4N8sOC/rQL5sUCS4xTnCWVNjD+DiUfFkjaaP9mtCqQgM9gIXAHfmsZ
qQZ2BtQbT4CzLUvcY2/KsDw8Tf8USmJ8PBYAYGyR45YxQRyjKJtP6OqDwJnz
hUYkPgm6AdSD/OqEMIpp3L0+7eY8h5sFOCMdJ4C58LKjLJogNI6AHiQA8F73
uDM4XROMI8zlZSwcoDJpjkh7C07tvJDxyXiDcYvg0zUL6VripndPOCmERMLU
cCq0QQxnBk6Y6F2MBEOvBnwDLEZaUVthnUYxtkIC7B3xsX1vXqSwO9sHxy86
1OFr0hkEHw9BiFuWqJkRNPD6YPimw0QrX8R4DQWXGECvKwQpQcRMyy3tbsFM
RMo92sS8ocOydPhCp+FTgwegqxXcyRKq3b94lC9ZSDh4NQBYmAPNhCkJS470
lrk0g3cmJrY+zbT1rTI6fDWM/oSIEr5KMgIYukKzNC5xaeFxQ2uaNsDesmTE
rncQdShwxYQWe+CBHMgZCkDMLTIFQ4xByN7gPzPi15LiDPgrvHUJwm8iRJkI
GRPiYqKEMzmDXUBuWK4gX9Ecpj/HKfv325sKbiUKGR5WAsK+SMb0LaK3n376
xVHvkKT3XjUre6gcgr6AIhK4yOv5dFb1ZsviPX6zew/IJd08PBiYK1GLCc+J
RvMmAwgAtp8ZgghoMCAqILw5sJ3A1afTDPfE+/4JdTJDvhH2IAE4swwY00Q4
QV94g11EeW6STKg5sDfEoZaozeMjgqPOqj6winPoTHA2ME3KUgD0FDmybXJF
oV1B5N/yAXXhBVHaNCmVvOKCM2E74dDG7xWCmMuLlKoJRc/gb+oSbrGy7IRY
UzwdwNwosWTjld+9Oz2AlS++iE4IO+WzfLqCCzh5bfYbLH3Xl/e2dVG47cCg
XyfJm0hkeXulVPKxtwIQ32GygFOnK5M5bvpD1bUYlO4rMI/QH91z6EDJJtx2
OHzCLPDxtnI/HZ/9ceKg0F63SOiRJRfZXWolG74s21rI94RPYG7AekWW2zkY
wL4CtoF9XCfV8KIEqUEnTjviM94pKn0c5sDbFwMLME9J8mBBmbhMQosoZKQN
UQjVsYhQt+EVoAfYTqDOyJkTGy5oAuAJep3FxLQIvAEI4kaPizxbzcvOzU4I
ceznnFDLXuPWmaht82B3Ya2wu+vkNQS9S4BHwEfAqVfAbi4J88q1QjBEvTVC
hS/tAC64TEZWiiNMgN0APzRJif4D+J6n03NoDDwdKTozQrjEAOzfgE9tKKqQ
5pFdYF9bhDaLNRo2WCEerPfd3H3niRJWksA9G+AgIa8aOV6VRTtVRZRNyaTP
vIlHbr2DRxXDKkNQyZcisG1tuntrZrGF8xwe00TffHcw/GJ3R4SEvS8fPwQi
EjAagu+PWWjoouRTLheofeGBcALQ4bNfE7Q8W+JJ/BpkRVboHfJNQzhjPAjg
dIFXEnntZamE3lsvynRMJ9CEU0ZbL98OT7a6/G/06jX9fvz012+Pjp8e4u/D
54MXL+wvRr4YPn/99sWh+821PHj98uXTV4fcGJ5GwSOz9XLw/RYrLrZevzk5
ev1q8GKrMUuSUEWzhLhpAQItMqqlCWSvbw7e/N//tXtft3d3F2QwFch2H92H
Py5BtuPR8my2kj/h8FYGqFwSF9gLQDfgl0UKrFHJB3AOVIHYcthU84VjA58B
C2N+2o++AGLaU5jqIWPzUWRl0TKpbsMyJdwev2TtlWWVMuBcuihIpNl4tpwk
FmaNSthWTmhuEl52mHzsQTqJHXZAu1umJqkytLwpEsAUTGdLWhi1hKV5zz8y
yNg+4xIxGA95liv7FzSh45sn1b4xPSvdMTePOqCAolmmT8k74N/tskMbVKSl
spYoHy0zxHkelrBtn8g4iLtRZ1ckU0CaSUHCDQ8nHTgSB3PCZiq94hRJw0L6
PhIf4mgLLjIgBzgquKxbosbrylkR7wqnEAHnkc6X8302JJJmnmif8BCn8Wjc
Tyd5P/kQ46GfdrpO+QTQN0W0cT5n7RjcTOhmlmTT6rxL93RZwnK7nv5BJGac
+GUKx88UkkBDp0p0NiF6gisYA73EsZaoz2poFKBP3AjegJvt3ToEjMoC4Bss
4w5TAK7KyvqtuFngoMhnuLOkmkPe0mqCDLAFg/3I0n6rMFrkaB8CUn+RJpeW
xQz0HqKBAdgd0z1DgQ3nwcgACGnJqqatRY5SZDbdwp27BCHD2QRgn4Gqwkn0
FnFa0CEBU8PGkzIdieFe7rOCq5X2YGluo2QeAEc4ROk4LbiLr+FLXAjgeuyO
GZluiD9y+cYzapDyYJyTdpUU50gPrIKClpCWtocumUaQp9isq+g7nIcGmIsU
poSrBOrYa3xMhJN5r66Jrf4GFfMwQad6YLSA5ngngDoEovr5PqMbZUlJnheV
ha9s8hTjU1x95uhyoDc0VvS0MyJUKBgcP0TRLdo0JsnYPCYqIVB3vJw58hyo
O7seGvYRro+sUZvFohZ9a282c3VAmICTLBV7+NIo+XPEett6Vf4+yXpVhk9w
W2EUMgOfHB13ZBvzZUXKDb0d+XyU4lY5kkQNWk40LuVwou2ffjpLpz3gm6sc
/vPxY4fwOp5ESUIuoImcbsxr/O+u1Va02iUBhwrmJZUfYSbqQhoDZOfLYoyn
gcIjXONT5PZXpyoxn56lIBSmf0pOUUmkKDydz0Hghc9nK51VpB9aXfM2yyhC
auX+DY87nl5YJ8b31n1DOLCYeEpkoRPLBbL1HpmgHs5suwABnLGxSpaKSrP8
gmUL2IDTNCMngFNZN4Ac4HXC4nCJ8YpU+aLc1D1exOUYUczZctZlWTNHAUEG
JAUpGpCj6FRwEfR72hWDIu8acPn8/V60zQoa1LchRyRkoNM8YPS8CY6YMZs3
1xbmxN+MPZkoNHXboPeciJVOnCw3Z7NkLFhElratNhxGEfS00zp+saxtlLaV
icC7U55Ah7dwnC8EEHDfyJ3KuywEhUyUpANYg0yKtOKLidXXyGM+3gplUxlJ
bivOHJXgGaIr2PFZHqN1irV2qmPnLWnX9I8SMkWRWjgLjQZW/H+tEjeOhIJi
mi1BxoV/Z/RFHRsYVo6XqljALZkkY9JOwlLHSGFna3TuSvBqegXLH1Q+1r0I
7O+C5kTXtzhHchYw/0MmGOZR/0FENl1nckpZiEKtIHNyAhY9nDtaSmGjxvGy
rqO1BlnalpgQpdApvGqO6Dp0gUOJ5w7yS9MYD4u133kGWHOJbJSPHRCbIu0Z
l0VPn/VA7KziD4BYmRABfOdFYoHZlFaVWMdoPisq0+wGs/OwItkzjIAgMnoj
pG/x+D1A2wxttRPPFEPCXjRaIu0GnLBNa+zQSiykGM/JiM9HhRr/ds3QvD1A
TUoWHLt3/7JkmldpYFrYWhJVw+MgJWb07dOTrWhbz/xe/35Us+N31KabFnxs
TJIQtRIV89Tn8Xgs+mKz5joLyBC0/vnPfwYWAwizifo9+ulH3o88sz9tL/vm
KqLBo+jKvdRfcb/DJ/wroazoytzRru+41+7Zxpcw7gGrpYKuh8xyb35pbmn3
t9zrWzrmnU0vb5naapqLbn9p2wmYfnK7ISnoUNF983Z5r/nz9Q3Ha766Sbsf
ole5ExHg591N2zkvQZB64pu3C7BpedN2n7u+iBDF57T71z6/gUN/pFEIxhN6
3mj385YBc69dcxHX72f7Ij7lHI4V9934/AYhUNysXevibzbeMcvMSWlf3qzd
v81++i9vsi9AJ/7sKCL+9XcdL2q7ZP+Y+9m8ZH9fOGu+lHv75z8P0HvAKob+
7OGJ5suN57fxx2+3XeNkOsjKNJhsv13bVm/8WTtP39LwxW7j9SZ8tvEn/0dc
317j9d9kffWfH/r9/rvWN/+g5579LfcFuWEyFPgaIY5U+GrraTZhFxJ2Jwq8
LoAF3/pIik4X13SkHJBEQPmmFVLM1Ywq6x37fRtfVwxHbIgNVYdGNP2kcv2i
ZpglcY09hGoTofCpHkt0Yg4h3coSZL1RIrYPlfbIBXCcTzOU02o+wiWrWtTz
FWY1Zz8u8WMWV5521xXx50H9IBnck3hMTsi8mC8AzbKW/jWbIJ5agwF5OJOS
TMVr9LUok9mZLyvGZV3fX3PNUznZzJezKgVBj1QMJRuZofuuKmxIEvS2UxxO
rfBenRf5cnpuTt3aTqOcZo16xzIfpwQfVmvAKnhdH3+pMhqf5kCtduzMCsAp
a+jx16iYtZCi5gyranRdoWqffXd0fFaIeVMtT9GHmw3ypAj1T2hbJdAuBapl
0w6aga2GiPWPMSnBEXi9phxzpkBknd51rqI28OL4ZMNQ8sXTAThUv0yUDNC2
/ub18KQXlz1EPKIw6MsNhrdbJTm5be1HWyRVbHXxIWk+xhU8/YGQxBbGSlX5
vjdwPJmn2S89gxaGFr2j1qiQKl+foQiZjpMBaUi3KLYwofckk9OQGi8lXWDk
1V1Ub9/lT+6W8fPF2Tc8J2+X/Kb4uW9X4/bex3fjybM/5n/aMh8DtBVChkVe
3EkdyggG/Al8lNvm4Q70J4RL9hTvYxw2t6rmuAZC60DCeEizdonUiuc0eW0H
7x260UPnewzgDhdXcabqxMnuP8KIDIoz02WTS30wZQN4YzYh00AGF7qIyc0G
1gFIjVCRYBfyhoyjdeuI5vEkMfEFgBV7Glqr741gXdYiRsOXg+9hkcDKUggV
bLY6IOJuAj5C11O9xi/S7H10To5DES9FDQoZ3PhTaJK9NxQeQ6r0jNzncC2X
ZGMTB3l0eCoQgcrWx2O+73Kx0OP57m5/N9rb2Ylef2fEvad3slok+4S6RVd/
F2P/DM5pP/r5NRAN/VMMy9dPYHpfbWG47IetG7Zt3IZfjJdFmRdf7UlvuPgt
wxghvGiCAG46wN18elY8fgoUGF1BPrHt5TB98GI0erj79L60vXubqSYCGBmE
Gb+TYVuuKgZCI/tw++4njjad71yevfj++TdJRrhLEETjYjMlLS070AKRwqIo
Q+L7fRKtsTRmnkNrn6SgVatHhmjXrVGchIS+SKwXyYbrZHmCVEkxRlkRvUe6
GFh6uXNRbjvTltNNl0kSNfXTFNjgmybpzsaV17f42CzYYxO1zdnKxpoFXslq
PFJEF1gH0bfhCNZbSiRrElgiSyK3/sx8esurA3obLCkuhW1EnTCcddvq+tgr
8jI9mGO0ravwuoxx9oju0A8rQj+Akv3cCfHh38xeOJfHdfZP/g4I7jJRD3sX
ionbg4iQupE4JfJDTOMyqTltk8M2wRwxnIwkBLOX+YwdAvJwHmhO1MiRbzCM
jxk4PDqaUWmpAa5Tg5YiPz7zVv9W34gByRIEguJ5EqMrGyr08Yi9QyWSAwgQ
6AnQEQ640zvcBE9YJVEiDsImW45wdoY5uwD+LX/nczb+8QIi+4nRw/tkhWjY
obZI3tDbNxQb+x1/g2xGOuklY/tUsBJ9irs2OVgCBcLvAJ4Wew8eFrv+J1bF
or0l40kZ93BDe8PnA/h+Sz7+SP++E4Qp/kN20sSRAU0sVtjJwcCOQdxb8rp4
g4EC2ZjGuH3bvZ7lYwCbaiXP6fFHGcS5EvnjyNCDWYXuhN4beHf4aujtGj2q
OTVt2XfvdGF2LrDxb9GJKehia5JO0eXO7pT28M62U0b8u9b2zAKgDtO2NLqh
H5mX1TvtYKA26z5uDz7LJmP3DDuo8YxtMFfnHNdJkwLYyDkeeWYp4TAS4QA1
BCGIfPLxbeKcxoLYpYaA4sknhD4nE2uyVI6wJkMFplEhArhqMo7B1vRgBJr3
x4+GQyDwLToDtXwhLJphHKceSMGUcExkgMmDy3OpWEfkArKYlr6AbwUlf0sc
3yvWf393jDeVzJnlG9QxdtGiNuDBoWoitSYkxQ2mVuaBK/QFTxf5ROjWMbBJ
UeSFupZJlDFLaTAyHM39nXvR9rO8GKVwphmG5VGYEDPcGvpiPX3ZOvro8c4j
dIQlWZqQMAy2j+5E+xhKMi/3kTvap6H3lxlqajMHyaeiKeEtEs3CSRFn5Tyt
yKEfZRixq1o/qVzcLZhJ58DGhk6FQIdgpvcjsEhZssIL0hZZxkEDddVZNxBj
9PQCGQkjGIhnoH1m7861N8Ux/OxE5ut0PA4tanBcBH60QU+CoVRSECg79Sji
qdBO4maRhQhjq9A5X4OjbZiCAzQ7DLpXC7zyEACj35DzADvP4N8DNPvLeKVt
qa3Q7QjdNnrisaF6GHZzpKjyKBWA5S7QO9W68Ik9PrrXR5mnHllPHBLFxY0x
SUlXXWjIIO8b3XvTpPLPQrkQ3QR2T6JwBlQlCKlHSTdi3h7mzqAUqQBmnudl
BYxbTRTYJJCBxHuHpDJmIlCfSF5GQCMwovDh/WUx21Y6Mpsi6Xg6REouZPV9
OrlePQEooLqbXLw+++781duHO5dTbQ3YlKn4YDbe2RksHh5Xj759+f7p7N6L
3V/97oF+BnO4fhC7HUTKOkQMF/EK3YnaFuMBZjtvVAkTA+ybz+QQhlcK2sIL
hKyND2Y+3wEkvjdhRm1rb2dvt7dzv7e3c7Kzs0//+73H06RnCYYMwZf37j94
uLPTdfzI3bvR/WgSrzTHzFYrkIkuKuCG3N3e0rw4ny1Jyl6XlqeBNU3vP7if
3DuffDN7f3J/8PSy3+9n3yVvsrer35/8+G31u98/fF7XUDWoqrIar4DSEx5k
fKzId0uU0gEhU2KpKNEpOR1KxIEsjlE/S+Is12EKz2B8KlogIi1/Soo8SsS5
u9GY/bwkIDHEwO2YbU3DEFWVHM1dfj4+bFeH0j6w6lF83xxsPujt7Aawadov
kIB329XZfG8+sjLVrLsxN70vLbfF3ORifOSxG7fi8+6EXYgHN7hFskL1Z7se
pdE1uHvy+nFxNs3v2nZtFwfaCl+hypee3gG5Rt4VOlb9zIG7JnBFwhvFLGtm
3e+C1Afoacgh4KpPERDURAPrFB3WtnKejN/bSCEM+2aXQc+b0OozTMMzsSlA
t/InhRdg5rtRmg3uiI5/xumQu67vgERsWabBlsZb3GYGN9rI4BqPweWEORlH
JC+KlNxm4UJ1I4msKZIfiUS7oNZTNLedjuIJTBmYV9zj2qASsKZ4AsRe4ZxL
618YPew/Un7GepV2jOXWziSQwI4a7lQa+j86B9GuEzdUpJHVO+9nzy/bOkBX
l2lWS7FCTsEY25JiWqK0Sms4vncwIHFOPIs3sskhTRjnC37qa3CIDXNA/8QR
kCJdNEQsx8o5hA60YkU5jBY2PLed86wNRRk4xILrzehWzUHYOrQGO6/2gImN
3/DFRNsGXT68uM5Bt7kreEDkCM8Ywap15fzw5NiV+0ljH1t8TIX710gmDx/x
XfEnYyIO6W8ODlBHWzNJKO0VxtgIiLW7tVJPYo/aRltRJaFcvVd51WNCSRtl
nxGxJJ46sJyUHZG92MsbqUyBjBfGxYfI0SWroCxPgYyO7Gg0y6fp+Fqr5H+R
4X9sMszd1IGu0d04buttdVLs3SuHh9Mvb0rOOaZiIzl/K5/45DzM0eNQKZpv
NFuGpxID3ECaFVHokJE1TJETZEWSZCZZVHddp+vz7dOTLiDkjAObOGXTzObD
sgqmRV5i9kMiempJVl90xWEcHoAGSGxBuItQm+ZHCez+YoQSfZgXXDDiXiTc
UdkXpk1KLWwgjyPoQj0xNW7he/MnEpGDZIfj10vT7sQ/otxNi8SlbrIZypSh
t1EXg1ulObX2TyURxMTA3nvqh0Y4gEeRB3Z7jUxtTXjB2qxNjpVBCUO2zDjV
oadvBLKcUNBO5dEN96VHLoIwJ1i5YZLYrhtRgaaVYmJvlKT4VK3jqEPKx2jp
xZY2G1EwW9GsUbCrpY/+bmmcFQdKrJmYHBkO00qgTs416lDjO0wY57Zk+xOg
7pQkvI3rrxHfmDcNT8clTKILCANOl5jGYTsGbnZ8XuQZ/NWh/DpIsTynA02e
ZJCrQ6AG3qiUvDKYUYGMl0ccgxV6h7F9IfVesQYzzCSjqnbfBhZdxqXS4okD
MfQpiCcSaErjohYSI4XFOrCR7WcWAe2CzB/vM1UFolG3esii6oYPawT/69S9
GiTcVPlai8EnqH3bQo6vUf0qWv2PrPrlZJAbMIZb3n8azenR99+8z399Fh8M
H++8HR9kX/7x+eNvq3//mtO/mYbyhqxnixLzxy9/9c3bi5fpNL3/p3yynPT7
/Xj8/fun38Xx4+kff7tqUWK2mgd9ReYrvdn/WZWZGynqP7Zq8m8rl2yAx7+x
5HLv94ez8+9XaxWIFmivVyLWwPdGikQZVtJUhulTiY1ejkqkaoD9PUVb7lRL
QtyE4xknjiGgIHnMFRm75JhMNwFp1fVT5lr9VPQJ+imzWT8V/bvQT1ltzXX0
9D+AQmqTLmqdGsoqoUxUG7Lr5zbZYHLhPEClGpKj5EN6A4f0/0Jzfws0x918
um7m++p4796wnHzb0M1swpQ1/cw6TNnU0QwqZqltaicxirj0aV2H7DTrvcaY
lJ45oymZfeTAGYC3b9ZrPqJP1nyYNs3HGv3CDTQfxtN8RBs0H7xMTJzQc2CF
8BRqPoyV5a/VfIS6WT6hmvbDeNqP5p59ivbDNLQfN5Rl/kvV8XdTdUQH8SIe
peg0Gh2mJeUUW4Uui+fJbIE2HM4agRlR5TsLXtYdT0R+BiALx8YpQ2ppALcB
TbMilXP2NxPdvu4EnuvGpQ5rOPSdzpMqFspWC9HqcYLrie/mPcrzWRJnnf3o
G/4NME089dUC3vJMpEiJnK9rihlM6ZTMc4CGQbg+rq2i+IGqwUQ1bTT1R9fG
5YJMKfMce9czQ5NgwQxPnj/x1ZOTBBPHMV/gH4k3EKupT5s7cmoKeFJMZqh/
hgO6PE9Q2Yyj2Xlfm+JetTWhnhxmgFVj+p8DTUE9BFTB4/RpEWa9oj0Auugm
QGfagO5gEMJc9Ckw13q928FuaMMu2jE6389XmiaHzQxvm4jcKtzaugk338vz
Xk/WDvvUmuevlqjeuHBcV9TAK/YBzxX28yieXGBPZRKcLSfiwaNspT4Uz9ZC
rygRtOYHR2riGTw6fFd8sLJLpVBiikxkMR8IaY/R7LSIsyWnXEQgJYJxCbM8
dy7KjDrF3GFZElUShKmpKi9q2VhNHTEtLuKiTOYxrqrk/K0Yb2ezn9ecK9G6
YYJsgoGEZ9M9bicfxskCuASk57CHJePflYsZrksclr5InRlYoYiTNVue/RLd
u5/nl8mFxLKsDGd4pHVj+KewbWmBxqxUgulqNxLvCkcMebJmuW/8WbD17bLA
RL20H6gc98wfKCxbT3xaJGaXzBlKhDnDkkHAYSUzOFW8G2NL4no4BSzW99EM
FE5JV0Sh0erKzdQQ9g0BpGrAoiaSyi283So5w1aYlW1leYebczmI3pEZMHXk
om65bTjuUxHPkXjn20iemsctEjudi3DevFVyxeky4rfPnw4OO8pucV44bwMw
ho+C0eRSehuNOdU517PLyqXir99FCyowODrsLWICRok32lm6v6zSlUpVBuAp
5Bdl+czuVW4P+n/3/ZUdcjvp9tymMmtFiZwtks9BVhlEiTTC6tVy0bfmFz3b
MSIRrciieeYq9eWyjHJoYlDWuKIoE4w0Jqzp3e9+IzPwpepRlpyrtm1hLlOd
y7fZFcmLY4BxWpSqn3enJeq9bNsRy7kzdT3xgtzwU6+0rrGJKkIDlS105LLc
VhTO6dUYUC6qsjUOGilAKK9upfbGb1bAiGNKRQlElugJy+ehjdBVWKqbAs/a
Bhit/EgUBPhxMAIG/Pie/HuN3HqY0t5vkteTatbLTRkA9CLHWV3YLB2u2FPg
8oCxfYEsrI4PmPyaFYZG5HDxfABYhAXcUt+HOAqWYwuLBUpQN7++eZOjIStl
YUN8MiqqDFK2tggLrNBdGHNxNtUWEMzb+kN0ClLTpjG6Rz3pnRYw4kIPyKmU
tj+pheTXxRlKiSrK5si3cG3WTWRCgAIuAimK0cwslgplyaR5gJrw0+VytgDm
KgB68OpKK/nG30+A2DZ2swG1hqO+eF+0dhADzoaqUZzDceAn71VQf9R/WHPx
7Nr+ZDlwj1kVJdH+GHJmCH8mqVzrxIdXjgQWwPMXI++o/gSnfqbyC8isGjKn
I04EolFkrZWwcuvKoimMSynmiqBgw86ASBqrPTqs8QYdqSiISQtGGjZMlUvr
k7Vbazyq4d2AvgNhjjXHDqh+eKT5E8rzdGGT74iFw0gVAFaXyfH4sEU9cJy8
pICgRz16BFjIVzQbhmKuLYRXOENU40wf4qMAaGhORkxkf9fAIFayIrnG6oIs
leZ6TLgtpKPjeuhRkZbvtYBC/mEVfSMp0gnk0YWy0EKLnDrCokovQpRSkpfn
eiJwZT+klDUGi/5yQQdj+fpawUHScE6ylPIRcOGpIEuSVmnEcW36dpAgqG8e
qZQobClJpmn59UpRMKjLyx/1kLvaqq+Bv9iKeobKYeJISZcLJ6Bo5bLpxiiI
yI3R0o4ftFJV5qVC94iuVofKSQPhBpA8Rep8ogWUw5xJBPqo7D2hk+aTp+QD
MV4JEu+cegMvd2ClGSXWmOMcSjBRRu88XwQaBAU3u9a29EVtoamS5Z6bpUmt
6gs5hig7plg4La1AZZ1HGDHMDYJc4LeCNWOssiK10QUfVrfKMKW/1w2IZSXG
WaNphkt6qXXR1I9eSAzIG7ejV9aFRBaHppLbqg7lfCyhB4xIbRrmRwm2sbpL
Ly371HbI5QRmUgCh3e2tvXk4H/b5dxM6ZT0sMNunQuXw15orQLc2XbJjBVMg
W5Blf8u7mrxq/Ypo8CBzPecrvizQsSrD2rJOveB9qCwGVfoYceQaZtCxkgye
afumvRAqdqq+2zo7OyphSKJvnIE+sPzmWX2AQbaCXtPs/anD89d06vVwO/oW
xKTX/2gHU9+19oTQ23LPTxtv1OiQc5V6y8qo6NH5twWKk39ISHhWy2Pu4AD9
E9ZdbK9VA3zqS+w256eINNxxTk7n5izuExZW67UoMRM/cX0jtG1ZjImdBMKr
zYYnQgtnisENMJo3UNkwvx1FVJXLEbGrcaVCObIbyP5ZVsP6oMY9RedoP53B
fVlOz7kArOZecLXOOKrbi8l2lVC8WlYf2V42XnrZ8xeuHkxLMZbcSRau9hTy
UzGIxaItCIr9LLPM6QuQR8eqbgPe4cu0PGdnE9UVrynl6SR//bCuQGgzHnQl
4UZaqbmkVKPIGvURMKNtikMSi78giD3R8Dx7LH6CIab1QVqitLRVBQHdFezy
PyGTdlWor1h5Hi8S3/vHGp1x47lqbu4LoTVBU0fVwVxRKL+8w7XFoSQnk+eQ
5GWg48L0cHfQjmJEHW59kpRjljVcnudhyh9rOCDTEBmPOS3iGbNrPFsMiqBC
SxQVqci9Xje3it9TvVyqxhVTOj2tZIoT5rNmrQyXeNa6XTVXWTbRniWFraTB
FbEKK7BKKjgtrCqJW7oe3aF4kSUlsNL5lVqoVCBgSEGWrQCjAZgMNz7MSJI+
7bMfUc5B1i76pcpRgSeTPdW0R0A9UdGDxdAvO2iEzsk0R8WBiI8bYGk1OGEU
GanLrie/2FmowZNZSrgRGMgSecleqDAlte/byp48GrG2sW3DCTKdyNOok9a/
blJa5lLAy2pZNeOXwCnrVG3aqnA+p7dv80CZTV/WMhBrZbXsiVPqeYOqOz/n
GdMrSxj3DAg5doc+rHyTKPtX6/6c3varwdigEzUJe/VIkFKwK1VQkQ6eugRP
XbjWM1Grs4WkHklg9GRlVJd6TYuo6slrfq7G/h4cHr5QfeHD3R2gH/ZSkrwa
wvYY5JUY5NfJDC2bA6y/CPCQkaqQDcgZZf5CzSFB+5BaRHwpqOAXKR3WdY29
uprtAdYlwitVrQg/cZe6HDxumIGn2kEMB7OxcVq4gVaDAXdcPSeRmGDGvmXW
o5q2vJWnklJLDTcEC2SZH4kLHNVJVAOXMEn1Vg7/e94/sNUP9h7voMpK1Vn3
UXPbf9iPXtP0XVUxGcunIzY7Xsv4rcWuKuJVmlsuqHFFRmp/zZJG7NTdD6m4
TApy3m8Vnp1V3ePu9w2WJSdzaTdKMAutFvpOJIvy2+MjDKNHV3K/+BTiOtEX
SO4rAXRByEgLFCeLLYLyjDE5sZXAhfIRgs2aQxiukMMaicwX+70PPZIJdG6G
VR29mDngd8ZxRloe2GVRZADBgoMKc7RSiW/EdYXUAAQo0u222J3qhAJZX2kB
ReGe/XPtOw8tddLhJpbvYKx+OuRDtNnvjrKzvA0emZMKA1Jwd+6WyKZ7aCJ3
NejYz36ezEeaGrB9Hb6fLd7DIhknqVY7ptHVJkU10FbexjLPQ/6BJRIIY0mj
hfxGHoWWZNSRC6sOvLL6NnXDy8H3UYLxzUHBcmO3syo1VQFps5HisfMfbyWX
+ZRUkpKmAV1wur68YRpXyoaSwQ05VdW0w+tOMw7y4WSMznrQnag6JUuj2yyt
OTZKXPWkbSSKnYi0hmdUCZQ4e2LD2CQOX5yinVGcQHyNKlrDvALg6PRIucbV
L5EpHlHVWBwUnIchOyp4wUU9mxdP0mSQx8fCFTTkW4EFGQGdzig+wqbRMEqg
fJxHHiHiw+nl1KtVLYezmcJxzglLKjY0EmNHyRUjqhm6YrZOcgC2cfqakDzM
Oepnd8XLEfC4NtsHl7bU4/QYZ1XQlS5lSKpmtBbJz/eybqTBtJmYGikwizJ+
mo2LFfFFLg+T/e4FwS98ubdz/7F93ch9CXLM3oOHv4U7eDwceB36aZjWT2JN
Hs5rs3DeOAen+Hu3ZN9szb25MfNmS97Nj+LG3si5uT7jZiPf5ro4sXf+Frbl
2VyTZVMjyzZk2PTza9otZT7Y5dzE8RupMv38vLUUmUE5ZcykHj2TtNpvgQoe
oM2E++GnPaCNPbKkaPx+yB42TR4OCVuvKCHy+GejtKFvz8+oc8DQFym0voxX
IrEdHL4C9AxEGHBNJgNuw8OjjjF+cVayyFhTbdkj73ovZTSyxWk5XiIDAzO/
YBkony1JO2WEucG7bp0J/BsvyJnZFuWccBo0mfoMOybJLtIiz1hMrFmI7DSq
y1wxKUH1JBxGGCcSsz5YMate20Mr7PZr5TpIQWH5KbSr0HTZGJPP8ulKiePW
Et5scVH4Cf7aDfM2YxFcTGV5795D6w35UotQvIkLZK1mtrBISZ6OZT535++J
ipcZOn6SOzHbQ2fpeyIKSr7U9INqC7K/mMtkFJUpkw5b+wKredDWlx1bUJP6
O0d+Oqh6jS4s5L1Cu4ou/nAB1AnRHTby0gS52Cm77dp30ySfFvHiHDdSPizZ
NnZm4mhrFI/fLxdbBKueaglIxASrpMAyyN4IPMkZklIki3AL8yIuUiS3KICR
m3OOzvTC3/lJuwkUaNKiVmqr7yKOluzdbK+fIbzj+1qQJhRnOmaPPqf7LBNM
SUrVKr3CJJSqRmrQGv3EFaNlCFtpoVqWk8IK0Wew9859ivyhMzaymRbbXCj9
aPFbj9oDTjhn3tGzV1pFjjXMGmvrJzDsUvajJhQq3JUMssyGiFPhLC6mdMvN
Nl6RjtVdwsXElFquLX1ezvEmFAEkdSO8UV66MYJGutNYdXVJ8OQZ7Qkol9SQ
Cs7iQVETrfHd/NzICOIVwLVxgMdHKYT8vDCprEQf0KfkccbJgroOpVjNsbCj
Y9lkTxEcQNY+Tc7wrdOwFOvxRQFtOJrVTuNy3Gdaig6vDl1/mthvRbNjTeUr
sZ8S6CSTer1xhgrV3dKOlqoiJ60BqdrZ3O65SSMlS9CAGmNSLK8OLpIOq2Kn
vSd1JP4Co/HhI0pe2vujjtXk+olnLEV5lL+fCE7QBcBSYQOfyMcyf3K0Rz2w
sproe4W8b4G0cFvbxrMpIsbzOQCzKk/hS2ACRJLpUsMlshKA26txv1ObCB46
q/ZhrPJsFfgE0qYHm2SZ2xZGXh2QTi7z3gv08fXt03BBkNjgrgNnUUSDKV67
7bcDuEKjIr/EZ7DmMql66CM8yj/A1Yoz9hQkSwGNh4PnjSAcp694e3y0H51q
HB193R8vbCDdHGZPkUrHkp8/dZXlNZ9C9IbXCOjg4A3MbrkAKTGJ5wyvWAWa
/2aqgAcJ8jOZ5ukeE5rujag+ANUJwGnRzaGAuNlsSZprJaPEoBGGyspe4Wal
+fO50m30qT9BEdz++vb1HYp+QY+vpAOpnXtV66BeYre1FJp01NZBSyG37bhT
++QqQn0TfHrwpr2D62Zx55oZUMVGIqq8C0s4B7sP+JrK52o93TUdbPq55c/m
Vkv71kf+sq7g/xe1Esb1n9pRe1vTl2LEfeq6ZZG/iFqO+srtmi7wTm/TT/2o
r6K3A/jr5AWdHh4inab92R6tO2pCoq0zuKY0Xu2or2T3Yd58BnfgFK+Cw574
+9A86ltu/3t/4F+8usrNnzVHbVdydbNHm4aI1t7qevuWFf6CP1lzq92GB+u4
/qibHYQ/2+O1t7qlg+tGbzvqsIPwZxDtfrnX3+nv9V2pzSsB5jtM/jZ30PZz
Fa3ZgxvNXjZR7katA/9n+AoIWQM7XzODGy9hE2a7yU8N3ANtQwsxU60DHr1H
eVHh8DYjcQ8jBYVoeu18ix/wOVN0E1GnHMryCwyC40XyDGNQl5nVvKkLijrZ
iCB1b2fPsptdAkd/qiQ2spPcbGUqTLUFLGPifGYc+4JBpciHc3QFM854sp5e
QutoIF+M5XbJWIfqRankIym6UN0UHUl4K8UYvDrqRMA5u3jh0/O8tMHIxtuN
o6inCxYw6UandchBnmeYo1nSRhya1jwY1A+KqeV5/D5R33SOnmCGEdMCo/zB
3t/OwdHIknwBjqvWhWo1ZGPH6E/SnCTMr5/0u8hF1XixWyWx0Rg15lgm9Y2x
PJXVYo/jSZApjMVhPxZSBBFj3VUb7u709SiJCzxi1pwnWL7OM8LVZ6lb4Llm
R5ooiZwcqJiHDxRrmLxW1sZn466C7/Sf4CoreuCVXbG7T42O1rokTou2zTUL
8WLrAGVxgf+MZ6myCv1NDRB5WMpMhDny0O9Dfx8cnrnif/5g0daDthH8mQb/
2N/6tqt1bHF7Q6Sdd3Rpa4Z8VG/J8/9a9/4TJit/2lM4uKbl/fpTYdlg6E8f
k8K2P2O2tNo7dD4bWvabnNQtOtgrJib8qHYDLuh1Gx98ZQdruRN3hPdtttnd
CRrVL0t7IzsQM6qsPrUX5po24T9nl5Pohm10Wxn+bm1uY6+MbOgV/dbGu141
T+nKspFruKH2Nljo+/GntNm149z7lHE2z+1L10aB54oAR4BHb337OBZ47vjA
Y/HqpjZ12KGfQGTybsSV8J012JErV79S7eMQotW/aoLRrSboOFRrMW4NVtp+
Wrg6JqLMyp1c5hEFcgc5KETLg4zdUtRcYSFuq9MXBR8rVYDubPyStZ+YsaJh
hlhXFBzVJ7t93myrgqQ9X8TVeaQ+o9r7E7PX51tdJJxMFEk5zG6OBWtZaUyt
taGnJg0SkoYZB516WLK8h2b5NVzOE3NPZs6uoMiAACvRw4A1lyxneOwCWsKU
peQfis/FREAleGLl/NRUFbZxG3FfNkI0sxr+Rr4eE5evoo3/IY3ZE/Ogjydq
5+4P3MJnceQ11mhNvTRPUrMOJs6NyavYHuT6uP+a061VFT4xD/sRZ89Hh/Ew
jsFxvz5P7B1xGE2Ls+JQzSfmEa01y6WKO+2c1bC2RuLa4ED5iNZ3izpt5HgA
WeeJedx2IJzEP1YhQxT+Ybquyjp5U+ahGWvOGUh5vU/Ml/U70jpv9mBpiwa3
aeoOBk/M7k5fHak4X13Z4gT9CpCI6sBV9vAvPtvICEMhVhxaI1ma9eBmLq2/
Uw34As01LAvhCicEFzpBczNMe9b02uDAWo5Ac+HjbGgeorc0iHTw/eIchTYb
dn6cXKRogJxgNPgRxtYOOL3KGCsRqj0Ebr9LilYfGjOCwIo57tkmJsbeDPRS
rsoqmWN1XGfPLquUoSOwYbcaebEb367LDlL4IHozGA7f5MWJ7zZqDbqP9/Yo
6pYMvyev0K8Aa6lvBV+wyffITdi6aiWTUwoX7UqqGUzsslDcMHyzB5Kqejj1
PMsDQKfRaf2///4/y2AyjK/sEWRLdlPbZkP1yauv7uzu3esEspnREMb6HLow
iV2ZBAe/+xl4Jhzb06WZ8uxiPpAg0zXuTRB9zhKeYniZkR6o20Tjb2AtvFtc
UXhbJ0BisLLPttb8hGNnUbezT0QNF4GzwHmSGVtjQsLql3kjh3cvjDUhL5Km
O5aXUpvIIg7D9RGYFMni73K8c0iZGJHH3GNOM3Ux44R5yKilceaBrgCI2T61
QHrEp+CG0CxC3n5Cb86n1pJCijOAzk9eic0NewzMstAxnPy2QxYVExqcs6Yt
xcFl/hZOR4lLzBrUggo8xJDUusQYuOFwkxfRbr9DZB17lE2qE2TZM5/+tRE/
HOFz6B/Q9aHNZovUzWUssH6GbnfrFJI81T3i6FMRsRkD1pestHbiZASX5KGS
+VnJXsm51alWjfq7hMTPxvoTQVssqXY5cRduZ8R+z/NzGQWJKuFW83HjiaKf
pfVuRXil6ttBRlHukzgFbORV8SnbZyjhhsF6na2yyInk4ijNXAoJh76EjJjn
bU2chXXsqPEQNhmsQHNDidSmP+r7ksEaxZEqlkWS4X9+3uinT0oN3F8rwLTL
wDVbziZFUfitlXlVYvGEGvi5bwKDwR98AY9l3Xv1fu2fTQHSmcyuZIX1Fg9a
WrA15Y5qhK4bhOYaqoKubRI1dEC7N2oSKH+uHaXPE/O0PsEne+0bdmX1eDda
i7MuXYl4GQCiSOoKjvjz0LX1IcOX0K1o7kZ7FEJcUyT3VCFs5yNI3vskUfwT
RPCG8maD6H2rVmtJ6L61ngRyNjImlKG3xKwVl1mrQGqzWDaz4dmIICH1hhzk
p+eVYFGVf0hvDXS2iH1XREkGR+EDLikbUkQMViKKGiQ4td4uHoWhqKvS+uqx
j1E8Pk+TC41MKykRhnFk3guJ8d1OoqPBqwFKBF7+YWN++AH4rejpJK3yYh9E
4QTDwlG+R5+e38EPx96p/Qg/Zvay/+4dCQAYyfKMg3UEzW+h/L+lhViQ6SDj
gUvtwm+0uJXd48mknq9SK5LIijifg+3mpeonZHgN6wEG8Iqfsc1I/0CPavjj
WAkW3hkftNb+gXerJRnrleZMw05hX2i38Nv2XGtrPm/fQ7+WzWduVFAO59O2
6EB55NHs83asZQOv3xRMKFffSu+aXknsZeuX7bs4kCRHf9U+hp18MrCJyuAz
dnE9CJb+ZmQo8oWbEbDtfpBQ6YW2EdKCm27zt3ix7iIWYHiUacu665fnkc0G
4YYSZL7WtHlyIk+pkCkFb3zmAbgewl2XLT4ktL0QGGnZ5RAw67u6zMjgeOgD
2iDTxzVxEUNsbB355t66mOwwFk7uYgNi/Sj86KkNtuCsn20RixEmxEU07orj
Sjx+icGOaXlOpnb5mGsMeisLov7deFtdFg23hn4cIcEuigBb5JRXWZj3kulM
lgXSFoo3dASIv6MQLApeFWdnjtfOvA/ZXF17yPGtXc65ZKULFpMoaNcFzyOM
akJfItieloBTbNgHt0p1C9cMTtHv+g92vlyrZDghBSLWAJk5CUpDlOwWx+J5
4SJl2uKMzbURxQCI9jwYkSBz5B5x4H1U/7mKXsqiYEm8ngNvPa59+w/Cf6/2
EzUffcYnm5vDsBr24y2FE0qv3yX4hOO1m0HEe/3d/hozWbjaeuzQXz/s7t4N
hq15d/wNVvsQsxYqlidUbmMOyVTBmm9J8cJ85T46wrAzD2uPggDlDuIkil1N
kOmUjN1BYkoOGU6nmUuX4d0FSWCecAkuuAAYc15Umi/ORrCjM/oynWD2S+v+
zbkzOLsGYgxNHBCT9luuvf2m63zKdRBKKqSap/41vZKRjNOSXbBtJUsk62eF
a6XIB+xk4AKzghAjVv8VCYcsx4uK9PJ+YgFvaO8EIqANkSbS8XJo2jBY4tOH
moCkzquj3zilG3yJuQVt8Iafb5DxFpFNPzOhr5/TK8DCiObsb8uFaGq5EEUf
/MqDu7GkKOfGszR7j6TJUqOEymqYhctdCjMY5+jrX+AqS9hz1uJphdeKnNmc
71S8aV5+Gjj0ubKMn8c2klv5E04jo65fXvordoRCWCdXdY309SJNXOx/sHY2
92j5WlFcP9wldbxNrEdB3kpPK5tnMctdxIBv7XLxQ4Zy5HDoNT2TZMMtRkk5
BEmJbzMPo4kIbZGchJlDANICdhLLk5PxkwOaNdOTTRCBi/MDbeYgEi4LyRal
EVU4P+TfKfoHkAIwSDwNTCiReMYXDexnWRjuKiImNR55rIkF+m/zeGZMIMdL
fnnyMQOO0ibomcKn+4z8YgZS4Vo1+TKrZ0sXU00hNZIqQ/MtUuZTdGEkdIAi
PYrZrSka2XUto5ygesaYsxA1qbGbly0EdJEml906QGqiW5zmGQeESnQYWh1K
Nl88RUabMbDF6wCbxYQ+WkXbGnxDhwxL73DE0Wieenm4ufKHBzB+ZQSyW7yM
33OpEK0OhJlYApzf3to6KIpdwE5li/I/bQWJ9evKW0od6ZXfwjHJGEUKc38Q
60jAliz0FeSgnW70gbgdP2kMhu6w/QBNWqJ5CRTKEjUl9jVS9w/seeBqya6K
TcPEyOEJknr9xu0CtTTnFGAkzbdxQeUfEeFcJB4RgekBx0p4XDP1qpNkPMEo
JuGv+XNDcC2OpDbha0I+GtbsVSC4u5lqYguXAwR3l/L9MhsQk+0CQDt1qMd3
2iTbKJdMDWBcysEsuaaR0elPAFlX2DoQHgL7qstxfE+zHP+TTXOsmX7YfLxm
22KumEJZFyS9Pu9kS8Sk8c1TFn4DrZlUa6qSBcExgrbCVWDPks2laFGqrGWz
PKOysJHJgaYXWMckqwKP3zVIa+f1m9n4zr+DXi3zWqocg64cPlBQvnLZTYdS
gDVJKeHOTRMjU8CkwKQRV3HKBUFheboh9YJldctQWMHPNCv46WXJl1TYRI69
LWGt6lhd4nby18lS3AmK5YXubW2vZinqtj41b7ciey+hu+HE55q9SoL/aXd8
/MvxgZZYeBwEsSGYjA1Vt8hZRuO0AMmWS1B6VczmBEScxksqDtkyOHQYfMOA
xC9LSo5MiaNHs1zvgJsdhWvGdMssFjqrzus36TL3orgdp9INqwQwzyFZt0zT
ieUZrB41EG4lJeYTUswQJsC3gaSmBSHsgXBnk55Tcv8+9a55S7stJl3Fw8aF
qLaimno69Y7Govc9XlqRWBuM+KR9Fq84teByjHoDSkOt0QiUO2HWSC/orrSG
Eou2v6sB012xy4oPhZ//oRwnWVykueIAe8s9YQXvasCH1hZhtL6ULlLSUHGe
QNIyirKFa+IUsRWKsJkGyNMal1UvP+uNJLI49LPw1ZfCatgh8Uq73NUc7ds1
XJdO99qegbPqkyzIKRRpK8loYeUBEIB5iiYscuqyWjky1BBCXHkyr3aiIYHD
n3QLPICUAdiEYpSR/lIiANGPxlIJrCVtU9kxnjpLBFwvu481/jhmSjgZuy+w
6eeY0OLk3OYQ8NO+kQSxJPpIByRARenme6qyY5GK89Abyzcgcuc8fTyW0+4S
4BwAaGTJDCTUtzaLE8udniDo37rdnf5unb6zI1iMrj3IdwArY5QwC8ayngmj
uAR2uCWZBzKTZOjjoppkIcTsBjK/MF7YaKCfvwbnFYAGbtyHMK7z6yvaWlLr
3LKm3UAjJ9liyYjZND1Do5x6utX+PorWtQwe+nPe9Hng5PB1sJT+pnZr/Mc3
TK9PC7uzJhC3T6/Wjek2dc10DgZrx73SPJetbemM7qzbbA18XRu3erXhMKLQ
QF03cG9uST+/cZn2FPx4VBOt8Tv/uu2hP2oYELBNpbnxyndCKP9h950x8J9G
Pb5G7mFWj7WUOqGRHJnVZF1qmPeuXYttXjFGdJIvyPlSK47XyuNyZjnFKXXS
GSwJ5+k21OhjTRskDpwO30h5ObiqI2gx93QvWOUbZsqIlIv2Sra6OHX5H2lw
WaJyQ4AvegjJ2BpDa8sZsm4zrTaXcM1cLnQXlgH2St2Fy6pz3QeDrmHiIJkC
S6ncoyftunCMDwlyKeNm4O0Gb46MOo6V+6xe2gAHwJQXKSqFcQLdaOEXIrKl
Mz3BFwme3z4owgL8r9No2AMNt8ME20EKo6JLulMrg47rbXzy8pDYxbD24ATL
m2I2N4Epa2IE/rPC7tPKq2zCiW1V7CrIod2lAiX1HRJPUYqLqKF8uaqdavoA
jtwF0FyzN6ULP4Ux84LcOTnTIU1L2WavSzxIq8ayDEhYd2q0WsSlJcthOSup
Dv3q9YnrpmUYB0iNMkWaqRdr80quwUmOFQA4TZWnQcDv6zxw11fLavIpH8fU
9A2uO1cQWTgd0sTbEyqQjcHDwBQ2MKC6OreCGwuhIW6AzgPwIYg0lNTfhqZ6
RYAEizFfdOylzGSlMjfw8N9LlamM6lpsuq60DFm8mPMhsWWB0+dQxlVguiml
FzBanEc0wT4M9RGzQaQr8SW0HJF9F5j4X3I4e2JFHGH28XGKJZmx8C1tYDIx
OiTCkMMs257yDs5knnMaOnzX4YAEiVN3uWSN5bpZIlFn6ZqGVbErLsNlmiY3
g6DQr/GzWUvWL6dR9wQ9giiGCy/Bs2Qbs0XsgtRr3cjP98m1Hie2/gzjS+HM
sfwaTgK1JaU9I2CdKbEs2a5sClyBbswjqWnRguiG+tLtvI2d97nkqkKFO1Vk
tQKglwQgnBppx22SIIUso7aFZKITZOdxV8agSCpN6e/qCJD2isR2Xeyt0viL
IFAqsdwbxfuME6u/8cr6xC5x6BxESWXi/by5bh5+6frYFPl0aS8C3nmupsfk
S8RHX8ntLIzBrsxJZgx1a16n3p3i1AeYWk3V6W6PBZOGXQsRkWmnamYRH0Gp
t2Qna6iWZm28P+UZQoCrLQ69OEmKQgcI4l0dXJog9HUmlojlSCbFvg64tt48
zuKpTRnbb90XCoyBzwcD6VPDTB4+QCzoG6VCVhCPgSxANnKO+608an8wKNW6
NF8owWLNA4YtwG6Ryw1via3u5WbwCOW3tbNW5NTzxvOzl/nd4A2N3FLs5Dkf
nbb3SzraAnZyW2ZMBFMuTwKdSZ1R0rtEW5jbY2d3S2qiYcLMxM+rPQfclU/q
RVpYiYlIWhNsckK6hAkBsCXACsbvKWlDTQ1HOgdj72kqSFY5EZffoVayK9Qc
D/qICDUbqaBB74aKYog5ioRKBNToxhyLodtAtYOBsfXp/DNn8BIiCQSYrN6D
MZ4+7OuUE07i3oS5LlED9V5YQsUmiyRHInh5nvPJkPfVxK+Ap4yk73imrFKK
eQHRSEdUzGrL2IeBcnrnJWC1/egYTh8z8H0TFxkSiIO4wBzd0TeoZMpgq44B
ILPoMM5Ws/SyG73AjBhPp1O4I93o55S2G+AM6QHqcr7aelb85V8mf/kX2ACE
kXGaPvNeATbFF3e/RlfCeAmdgwATPYctnmGMzzcw7nfxZPm+Gz2F76LvgPHC
UKA4+xHO5yWgiCLuRs/IIFuO4+hNPCM9WtqNfgWH+AYLy5V4vMcrmPJwlsAO
QFdzdIEeVskCdrl1zn/5H23TfUoPYa6/WWXj94lG2qFGhmJSMJCKbOgNuHu6
xJzpMIUD2Hu4ghSYR+VcniNuRLXvzt6O4SLWNhMpAFM/evj48f29XeCiyDI9
19rEg2J8nqJFasmBLgCdL9MJsAyj/AOgWso2m2HV45eDl0cdrUAoWRotpKYE
qHC/8qJMJA81ei2h9dAgpB4qGD0H8Qv4dHSiZq1+HrU6UxPjNWJ2nKO1WGQW
D+pJEZ9VPQpfjMfzpEchNJ7T5c6XXOjkDOAUK0NylRkLsaOVA4n+zTp8bNT7
7yKRG0D92DyxR09PnrkLlRd8L46eDr+1OfC352hYoDtZSppSoDYX+ewC7YEr
IExaNr6wBUBqdxyOYOhl2iX/wJe4SWOuam/jA/3ku6xbZmMmSFzAZQcZClEm
IVhwzqzoC/hUnG3Eyd8WmtnytdLo2rklHv2aSz+0R4Xunm+PX6ifYaDRJXEk
wlhLAGYyWQnz52KXulq7nhmE2FU1kE9zLuN1OzrAvaAU+aTVTqbAVlmdemu0
MdZIlLJRAS+k/LRGYRLH6/JSS272TbtFzKCkcLfxcLmWw9q3dwmn0DI17HpI
bLb0gUlO0ZvVdywVyiXfqOwUup5y/k+uwkuXgj3Q+go/HB0qkRXrpD4ybjJp
dRrwMCyUlC4UhRgYSHIS+Wk0AMvCX46ahq1XL/v00a6+pCo3hBzIqVT3+0ZX
9hFejmEyPkyL4Or7tAEHOQqCV2GReTEFBgj5Yjpv8jGxPg3WkzbnOwdMqO8g
0Kb3K9lhdxJpsU2/o1ui7HPZiGerGy7wIS6QfOd4ywinsGsiU9dbZQv2u2Hn
D7DzQ4IKmPHgUMk+bqBPuR2E6hZzcTeUrWbJGdVqk3ouJF16JJSmh51SNU/Y
jYJ4IrrkeOgs4Clm07ppVOpjfNM9uo/SjKdGWH9EPb4IdLtkzG6Y1hwNYW2u
z+r4GPjQhbY8sZdnEy1C45ugcq8II8bhBpAAPQNerNi2CFwssGG+71fo8HjD
TbmHm3Lg9tILc47ZnVOup1AT1Ex4ReBtnUGYK3oZRfUBNNzHk4JBKsc6DrRe
JO4TXBmXVXYJ/Leth6O3lR2vPrn1EIVj5NrCqmOw5zdRkAXZbbYqU1cQCfOs
UHw75hawg3o1tWA5HMeMhu8U+Kd4ftMd3cMdHbajzX3/6jjoxxkHnicUlUZ0
a59C3qRIHrsBxkGNLKeWIfcoPAimipSAW+LbwhpyIo+pw69kEvc6veFKd3Gl
x6Qtmns12Wh3dVN9R+DWelTbwuRKaT1ifZU6drC1lotYR4m2mVsmiWNKvtg3
nP4OT594SrKxUswE9oa7PAUMtOBO/P7gQzRGbNqRAVWgWjddyYkOYqVKYZz7
H3UPKEoz8Pn4qOFJqDqIm86KFnok0RgYn0TyKRE0KvJAsZckxHIG9TVdqmMO
gXgYfrPPgRqNyBvfJ7+lOrVjn8L7XAeSrvgLS9U5W3Sub+tdWnDSQrIxg3cI
+F0WpNPYk2LbKsL1/bLuXn0Rr8gTZ7rnOp5MzWhyRPB0DjaXgzrQAk5LFylN
xGIa4ttxGbaeIjkRNCpAYWyXVePDpqH+j9aAxBFrQz2RftAddk5iKs6KO3Ol
trgbtAqJBwmQEbK7sLuIb41sOcnoKypYo93tRz9Ed6KfyZ9UGuYXGq2xT8QV
mlern7OkMV3SNcPlfG28zBrQjfvdAJy4hi+/hhG3X3aiPmLr7Z9gNGQDv/qa
/vnYMcaWiuzZyldfcRkeLe0Yvtgy3p8tje9GjXbGPEEmma6KOg1SSWB8wC4+
JdnXoHfOa4PDa4uv+Ls+/A3gEm1t//CHf779rn+7c7X9A/xS+wv/uNPZMtq8
lxf+/LXTu5GbXGNz5ZB+EUkpo/2opTM+qrCs0foPtcTR+i+EUSb4udlX8ewt
3Pj131J8zYD5xfVfsQEFl93+DYCThc+7sIFlLHWmgsdUJkpfGPeRbGVQoKpR
JCt6Er0+OtyPsBbj4/s7/d3dew/uf4nBTf1dvzGXztqXOQxBqoC3QcWq/ehn
8DJ4hAtwDWA+QCAqhMjj4WA4HPTefHcw3O1d7P63B4wNhs8Hvb0HD02jI1zm
+rJcrr+D7xr93Xt8f31/8PJT+3uwu7e+P3i5sb/hMFhoN3r57bPebu0ZC8H3
MC0LclPxrLrJhkAr6Gx33Wiw0sZo9IxHu//4JqO57bpmNNiHxmj0jEd7eP8m
o7nNtKMZH9bXwHet/loDwHd27j/AODpo6kqyAfBS1/RHC2TTywZse2140rao
W/uo9+BWPWptBTsbtIIv72Fu9nv3Wz9/sLfb/rnOqbmhzWJy0JwT/fAZ2cnf
sAuYclsXtJIbdgEn3NYFrc4YocUAI5lPGA5fDZl0t1EZpuJPEfsGH8kLqn9S
f3w7+tnPwrF6lqTjKXsBvjoHDWHlzvQvj4+oB5vyh/WntkHIL/ncRzixr3E+
wXC4qc2aeY1PoEMUFiasP2z5AB48RbcC4ByR2Wz5AqNxrvkEHgxUW9/+GkOU
cZ4tb8fHL9a8SWTU19ls1TaxxH9tWjeZL44tELj+I79i4PqP8kmCcwXOZcNX
xAMAe1JJOv/1X2KSr2EVzxebO3x9MHxz7bB5CmwV/KeFd9vp7b3rbG//c38H
OLZ/7v+w2/vyHTz88t3tTgeYPmSbG6KRJ1ivk5C01iHVkZukH5yaOd5ULLsb
agI2ylAsK4mwQ/4bqejn0LscRb7oEf7q9dh1hluVoNQT8McS67SydLeDpmUv
tpMiRlTOdFH/26iQ4HSYk46MqEmDWtu01QLvcwLShJO6wWeXIGNTSfk4KlmQ
cUkP2JqOVipbRxyltlVSuahRcdxIuJjxGIPAMvX3JkUTzVMm5hmyrbPUCJVk
oXkuz2fOAm+1cc4fsk0hsEbKtLFYviem2Rj5zu5/LL6yo5FfCpYUzFip1N9b
dTtoy3hha3dSTdOf8VjYAZbA2r9714OEPrD3d1l7sPPoLj/7QtqlE68NKmXo
Y1QucIvybk1tcddfonQCEO7VUg0En15Wq6cqI37R8pWtbVpJlVjWt7rn8zR7
wxallIrm7to3C/+xjhVUjXUPvQFYStyyrz52XdNmbdlP7sKrQPvJbX2R7K9t
zyLd5/TiC3uf096JgTdubWq9bLkrGBz+WTwr2V9bi+46+bAN4Ly31wLaOnCq
V0TetKKu/45wR7OOc+ueNWs6tw6D/qvTpGjvo15w+cYTTbLlPKh3TE/Xyafd
xmetYmfzs1ZpsvlZUwbcNOL6b1rkLffBuw2wpxrvsAR0CAYbjm7ticjzd58O
5L6Y2Abmwft/Q0CvyaqtUBrUDf9rQbRRddx7wTJoywuWNtuB4e93nZoCa3fT
ByiObvwAhc2/D0B7J/S3hGWjtdhb4LINJrdUs+1DvLbFKpyrgEk4Av4k5A9S
eeKBeJytXp/VzuancJd/BjxrnXZ4X3zs3qBpcB/9xvZ3Pa6PwT0X6Ti44tpn
C+8U4ohmhfvPwAFeDftWeA/3fe3er9n/oKuWq7Pu8kQtSoFu/YuaTqDxvq4S
aHzQ0Ai0deEUAm1vrT6g8VLVAY0XgTagOadAGeC/etcKVwEfVxOp/45n2nav
8Oen2t/XHb/sSCsI0DtP6dFsGQX6jvb3nqqj9YO6lqP1o0DB0fpFoNuov31X
e/Kx3sVnbduCwr9Qbtj6g1OOiHakrh75WVsPno8c9vIWJVwUR18fHUr63vpa
Pn4iSIaKwXUAWUNW9G6tGMhrb0dn9O7w1bDxcCP063itN4Bett8CerXuJuBP
8/NgJmuPlr7acCvo/e01DSM2gba9qMMh/jRg8a+eOOfvI41DXlaOcNXGvf6W
BH/X5rlFOvJ/xXO+/j66dRNO2Xx16st5e3z0D7qYZZFes5R13NL1PKLf/Dr2
tYZK/hqGtDGAz0x1a8yokUE2D/CRtHz/H/Le7yZuHgEA
</rfc> </rfc>
 End of changes. 240 change blocks. 
1952 lines changed or deleted 767 lines changed or added

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