rfc9447xml2.original.xml   rfc9447.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80 " category="std" consensus="true" docName="draft-ietf-acme-authority-token-09" n
<!-- This template is for creating an Internet Draft using xml2rfc, umber="9447" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude=
which is available here: http://xml.resource.org. --> "true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2023-09-12T21:03:27
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ " indexInclude="true" scripts="Common,Latin">
<link href="https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-0
<!ENTITY I-D.ietf-acme-authority-token-tnauthlist SYSTEM "http://xml.resource.or 9" rel="prev"/>
g/public/rfc/bibxml3/reference.I-D.ietf-acme-authority-token-tnauthlist.xml"> <link href="https://dx.doi.org/10.17487/rfc9447" rel="alternate"/>
<!ENTITY I-D.ietf-acme-star SYSTEM "http://xml.resource.org/public/rfc/bibxml3/r <link href="urn:issn:2070-1721" rel="alternate"/>
eference.I-D.ietf-acme-star.xml">
<!ENTITY I-D.ietf-acme-telephone SYSTEM "http://xml.resource.org/public/rfc/bibx
ml3/reference.I-D.ietf-acme-telephone.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC7515 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7515.xml">
<!ENTITY RFC7519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7519.xml">
<!ENTITY RFC7231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7231.xml">
<!ENTITY RFC8226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8226.xml">
<!ENTITY RFC8396 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8396.xml">
<!ENTITY RFC8555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8555.xml">
<!ENTITY RFC8725 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8725.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3986.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4648.xml">
<!ENTITY RFC9115 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9115.xml">
]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-acme-authority-token-09"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="ACME Authority Token">Automated Certificate Management Enviro
if the nment (ACME) Challenges Using an Authority Token</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9447" stream="IETF"/>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<title abbrev="ACME Authority Token">ACME Challenges Using an Authority Toke <organization abbrev="Neustar" showOnFrontPage="true">Neustar, Inc.</organ
n</title> ization>
<address>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <email>jon.peterson@team.neustar</email>
<organization abbrev="Neustar">Neustar, Inc.</organization> </address>
<address> </author>
<author fullname="Mary Barnes" initials="M." surname="Barnes">
<email>jon.peterson@team.neustar</email> <organization abbrev="Neustar" showOnFrontPage="true">Neustar, Inc.</organ
</address> ization>
</author>
<author fullname="Mary Barnes" initials="M." surname=
"Barnes">
<organization abbrev="Neustar">Neustar, Inc.</organization>
<address> <address>
<email>mary.ietf.barnes@gmail.com</email> <email>mary.ietf.barnes@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="David Hancock" initials="D." surname="Hancock">
<author fullname="David Hancock" initials="D." surname="Hancock"> <organization showOnFrontPage="true">Somos</organization>
<organization>Comcast</organization>
<address> <address>
<email>davidhancock.ietf@gmail.com</email> <email>davidhancock.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Chris Wendt" initials="C." surname="Wendt">
<author fullname="Chris Wendt" initials="C." surname="Wendt"> <organization showOnFrontPage="true">Somos</organization>
<organization>Somos</organization>
<address> <address>
<email>chris-ietf@chriswendt.net</email> <email>chris-ietf@chriswendt.net</email>
</address> </address>
</author> </author>
<date month="09" year="2023"/>
<date year="2022" /> <area>sec</area>
<workgroup>acme</workgroup>
<!-- <area>
Security
</area>-->
<keyword>ACME</keyword> <keyword>ACME</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">
<t>
Some proposed extensions to the Automated Certificate Management Enviro nment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token Some proposed extensions to the Automated Certificate Management Enviro nment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token
according to a particular policy. This document specifies a generic Aut hority Token challenge for ACME which supports subtype claims for different iden tifiers or namespaces according to a particular policy. This document specifies a generic Aut hority Token Challenge for ACME that supports subtype claims for different ident ifiers or namespaces
that can be defined separately for specific applications. that can be defined separately for specific applications.
</t> </t>
</abstract> </abstract>
<boilerplate>
<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
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9447" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<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">
<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>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-requirements-l
anguage">Requirements Language</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-acme-authority-token-challe">ACME
Authority Token Challenge</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><
xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-to
ken-type-requirements">Token Type Requirements</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-authority-token-scope"
>Authority Token Scope</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-binding-challenges">Bi
nding Challenges</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-authority-token-challenge-t">Autho
rity Token Challenge tkauth-type Registration</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-acquiring-a-token">Acquiring a Tok
en</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-basic-rest-interface">
Basic REST Interface</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-acme-validation-method
-regi">ACME Validation Method Registration</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-json-web-token-claim-r
egist">JSON Web Token Claim Registration</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-creation-of-acme-autho
rity-">Creation of ACME Authority Token Challenge Types Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.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.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t> <name slugifiedName="name-introduction">Introduction</name>
<xref target="RFC8555">ACME</xref> is a mechanism for automating certific <t indent="0" pn="section-1-1">
ate management on the Internet. It enables administrative entities to prove effe <xref target="RFC8555" format="default" sectionFormat="of" derivedContent
ctive control over ="RFC8555">ACME</xref> is a mechanism for automating certificate management on t
resources like domain names, and automates the process of issuing certifi he Internet. It enables administrative entities to prove effective control over
cates that attest control or ownership of those resources. resources, like domain names, and automates the process of issuing certif
</t><t> icates that attest control or ownership of those resources.
In some cases, proving effective control over an identifier requires an a </t>
ttestation from a third party who has authority over the resource, for example, <t indent="0" pn="section-1-2">
an external policy administrator for a namespace other than the DNS application In some cases, proving effective control over an identifier requires an a
ACME was originally designed to support. In order to automate the process of iss ttestation from a third party who has authority over the resource, for example,
uing certificates for those resources, this specification defines a generic Auth an external policy administrator for a namespace other than the DNS application
ority Token challenge that ACME servers can ACME was originally designed to support. In order to automate the process of iss
uing certificates for those resources, this specification defines a generic Auth
ority Token Challenge that ACME servers can
issue in order to require clients to return an Authority Token that autho rizes a given issuance. The challenge contains a type indication that tells the client what sort of token it needs to acquire. issue in order to require clients to return an Authority Token that autho rizes a given issuance. The challenge contains a type indication that tells the client what sort of token it needs to acquire.
It is expected that the Authority Token challenge will be usable for a va It is expected that the Authority Token Challenge will be usable for a va
riety of identifier types. riety of identifier types.
In particular, this document describes an architecture for Authority Toke In particular, this document describes an architecture for Authority Toke
ns, defines a JSON Web Token (JWT, <xref target="RFC7519"/>) Authority Token for ns, defines a JSON Web Token (JWT) <xref target="RFC7519" format="default" secti
mat along with a protocol for token acquisition, and shows how to integrate thes onFormat="of" derivedContent="RFC7519"/> Authority Token format along with a pro
e tokens into an ACME challenge. tocol for token acquisition, and shows how to integrate these tokens into an ACM
</t><t> E challenge.
As a concrete example, <xref target="I-D.ietf-acme-authority-token-tnauth </t>
list"/> provides a mechanism that allows service providers to acquire certificat <t indent="0" pn="section-1-3">
es corresponding to a Service Provider Code (SPC) as defined in <xref target="RF As a concrete example, <xref target="RFC9448" format="default" sectionFor
C8226"/> by consulting an external authority responsible for those codes. Furthe mat="of" derivedContent="RFC9448"/> provides a mechanism that allows service pro
rmore, Communications Service Providers (CSPs) can delegate authority over numbe viders to acquire certificates corresponding to a Service Provider Code (SPC) as
rs to their customers, and those CSPs who support ACME can then help customers t defined in <xref target="RFC8226" format="default" sectionFormat="of" derivedCo
o acquire certificates for those numbering resources with ACME. This can permit ntent="RFC8226"/> by consulting an external authority responsible for those code
number acquisition flows compatible with those shown in <xref target="RFC8396"/ s. Furthermore, Communications Service Providers (CSPs) can delegate authority o
>. ver numbers to their customers, and those CSPs who support ACME can then help cu
</t> stomers to acquire certificates for those numbering resources with ACME. This c
an permit number acquisition flows compatible with those shown in <xref target="
RFC8396" format="default" sectionFormat="of" derivedContent="RFC8396"/>.
</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section title="Terminology"> <name slugifiedName="name-requirements-language">Requirements Language</na
me>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", <t indent="0" pn="section-2-1">
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
ocument IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref targ D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
et="RFC8174"/> when, and only when, they appear in all capitals, as shown here.< OT RECOMMENDED</bcp14>",
/t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="challenges" numbered="true" toc="include" removeInRFC="fals
e" pn="section-3">
<name slugifiedName="name-acme-authority-token-challe">ACME Authority Toke
n Challenge</name>
<t indent="0" pn="section-3-1">
Proving that a device on the Internet has effective control over a non-In
ternet resource is not as straightforward as proving control over Internet resou
rces, like a DNS zone or a
web page. Provided that the issuer of identifiers in a namespace, or some
one acting on the issuer's behalf, can implement a service that grants Authority
Tokens to the people to whom it has issued identifiers, a generic token could b
e used as a response to an ACME challenge. This specification, therefore, define
s an Authority Token issued by an authority over a namespace to an ACME client f
or delivery to an ACME server in response to a challenge. Authority over a hiera
rchical namespace can also be delegated so that delegates of a root authority ca
n themselves act as Token Authorities for certain types of names.
</t>
<t indent="0" pn="section-3-2">
This architecture assumes a trust relationship between certification auth
orities (CAs) and Token Authorities, i.e., that CAs are willing to accept the at
testation of Token Authorities for particular types of identifiers as sufficient
proof to issue a credential. It furthermore assumes that ACME clients have a re
lationship with Token Authorities, which permits them to authenticate and author
ize the issuance of Authority Tokens to the proper entities. This ACME challenge
has no applicability to identifiers or authorities where those pre-associations
cannot be assumed.
</t>
<t indent="0" pn="section-3-3">
The ACME Authority Token Challenge type, "tkauth-01", is here specified f
or use with the "TNAuthList" (Telephone Number Authentication List) ACME Identif
ier Type described in <xref target="RFC9448" format="default" sectionFormat="of"
derivedContent="RFC9448"/>; in order to use the "tkauth-01" Validation Method w
ith an ACME Identifier Type other than "TNAuthList", that identifier type would
need to be listed in a new registration in the ACME Validation Methods registry
maintained by IANA. "tkauth-01" furthermore supports different token subtypes. T
he token subtype is determined by a new ACME challenge field, tkauth-type. An IA
NA registry is used to manage the values of tkauth-type (see <xref target="IANA-
3" format="default" sectionFormat="of" derivedContent="Section 6.3"/>). Addition
ally, this challenge type also has a new "token-authority" field to designate a
location where a token can be acquired.
<section anchor="challenges" title="ACME Authority Token Challenge"> </t>
<t> <section anchor="req" numbered="true" toc="include" removeInRFC="false" pn
Proving that a device on the Internet has effective control over a non-In ="section-3.1">
ternet resource is not as straightforward as proving control over an Internet re <name slugifiedName="name-token-type-requirements">Token Type Requiremen
sources like a DNS zone or a ts</name>
web page. Provided that the issuer of identifiers in a namespace, or some <t indent="0" pn="section-3.1-1">
one acting on the issuer's behalf, can implement a service that grants Authority IANA will maintain a registry of tkauth-types under a policy of Specifi
Tokens to the people to whom it has issued identifiers, a generic token could b cation Required. In order to register a new tkauth-type, specifications must add
e used as a response to an ACME challenge. This specification, therefore, define ress the following requirements; in cases where a tkauth-type admits of its own
s an Authority Token issued by an authority over a namespace to an ACME client f subtypes, subtypes inherit these requirements.
or delivery to an ACME server in response to a challenge. Authority over a hiera </t>
rchical namespace can also be delegated, so that delegates of a root authority c <t indent="0" pn="section-3.1-2">
an themselves act as Token Authorities for certain types of names.
</t><t>
This architecture assumes a trust relationship between CAs and Token Auth
orities: that CAs are willing to accept the attestation of Token Authorities for
particular types of identifiers as sufficient proof to issue a credential. It f
urthermore assumes that ACME clients have a relationship with Token Authorities
which permits them to authenticate and authorize the issuance of Authority Token
s to the proper entities. This ACME challenge has no applicability to identifier
s or authorities where those pre-associations cannot be assumed.
</t><t>
The ACME Authority Token Challenge type, "tkauth-01", is here specified f
or use with the "TNAuthList" ACME Identifier Type described in <xref target="I-D
.ietf-acme-authority-token-tnauthlist"/>; in order to use "tkauth-01" Validation
Method with an ACME Identifier type other than "TNAuthList," that identifier ty
pe would need to be listed in a new registration in the ACME Validation Methods
registry maintained by IANA. "tkauth-01" furthermore supports different token su
btypes. The token subtype is determined by a new ACME challenge field, tkauth-ty
pe. An IANA registry is used to manage the values of tkauth-type, see <xref targ
et="IANA-3"/>. Additionally, this challenge type also has a new "token-authority
" field to designate a location where a token can be acquired.
</t>
<section anchor="req" title="Token Type Requirements">
<t>
The IANA will maintain a registry of tkauth-types under a policy of Spe
cification Required. In order to register a new tkauth-type, specifications must
address the following requirements; in cases where a tkauth-type admits of its
own subtypes, subtypes inherit these requirements.
</t><t>
While Authority Token types do not need to be specific to a namespace, every token must carry enough information for a CA to determine the name for whi ch certificate issuance is authorized. Some types of Authority Token types might be reusable for a number of different namespaces; others might be specific to a particular type of name. Therefore, While Authority Token types do not need to be specific to a namespace, every token must carry enough information for a CA to determine the name for whi ch certificate issuance is authorized. Some types of Authority Token types might be reusable for a number of different namespaces; others might be specific to a particular type of name. Therefore,
in defining tkauth-types, future specifications must indicate how a tok en conveys to the CA the name(s) that the Token Authority is attesting that the ACME client controls. in defining tkauth-types, future specifications must indicate how a tok en conveys to the CA the name(s) that the Token Authority is attesting that the ACME client controls.
</t><t> </t>
While nothing precludes use cases where an ACME client is itself a Toke <t indent="0" pn="section-3.1-3">
n Authority, an ACME client will typically need a protocol to request and retrie While nothing precludes use cases where an ACME client is itself a Toke
ve an Authority Token. The Token Authority will require certain information from n Authority, an ACME client will typically need a protocol to request and retrie
an ACME client in order to ascertain that it is an authorized entity to request ve an Authority Token. The Token Authority will require certain information from
a certificate for a particular name. The protocols used to request an Authority an ACME client in order to ascertain that it is an authorized entity to request
Token MUST convey to the Token Authority the identifier type and value that wil a certificate for a particular name. The protocols used to request an Authority
l be used in the ACME challenge, as well as the binding (see <xref target="bind" Token <bcp14>MUST</bcp14> convey to the Token Authority the identifier type and
/>), and those MUST be reflected in the Authority Token. A baseline mechanism fo value that will be used in the ACME challenge, as well as the binding (see <xre
r how the Token Authority authenticates and authorizes ACME clients to receive A f target="bind" format="default" sectionFormat="of" derivedContent="Section 3.3"
uthority Tokens is given in <xref target="acquire"/>. />), and those <bcp14>MUST</bcp14> be reflected in the Authority Token. A baseli
</t><t> ne mechanism for how the Token Authority authenticates and authorizes ACME clien
Because the assignment of resources can change over time, demonstration ts to receive Authority Tokens is given in <xref target="acquire" format="defaul
s of authority must be regularly refreshed. Definitions of a tkauth-type MUST sp t" sectionFormat="of" derivedContent="Section 5"/>.
ecify how they manage the freshness of authority assignments. Typically, a CA wi </t>
ll expect a regular refreshing of the token. <t indent="0" pn="section-3.1-4">
</t> Because the assignment of resources can change over time, demonstration
</section> s of authority must be regularly refreshed. Definitions of a tkauth-type <bcp14>
<section anchor="scope" title="Authority Token Scope"> MUST</bcp14> specify how they manage the freshness of authority assignments. Typ
<t> ically, a CA will expect a regular refreshing of the token.
An Authority Token is used to answer a challenge from an ACME server, upo </t>
n a request for the issuance of a certificate. It could be that the Authority To </section>
ken is requested from the Token Authority after a challenge has been received, o <section anchor="scope" numbered="true" toc="include" removeInRFC="false"
r it could be that the Authority Token was acquired prior to the initial ACME cl pn="section-3.2">
ient request. A Token Authority could grant to a client an Authority Token that <name slugifiedName="name-authority-token-scope">Authority Token Scope</
has the exact same scope as the requested certificate; alternatively, an Authori name>
ty Token could attest to all of the resources that the client is eligible to rec <t indent="0" pn="section-3.2-1">
eive certificates for, which could be a superset of the scope of the requested c An Authority Token is used to answer a challenge from an ACME server, upo
ertificate. n a request for the issuance of a certificate. It could be that the Authority To
</t><t> ken is requested from the Token Authority after a challenge has been received, o
For example, imagine a case where an Authority for DNS names knows that a r it could be that the Authority Token was acquired prior to the initial ACME cl
client is eligible to receive certificates for "example.com" and "example.net". ient request. A Token Authority could grant an Authority Token that has the exac
The client asks an ACME server for a certificate for "example.com", the server t same scope as the requested certificate to a client; alternatively, an Authori
directs the client to acquire an Authority Token from the Token Authority. When ty Token could attest to all of the resources that the client is eligible to rec
the client sends an acquisition request (see <xref target="acquire"/>) to the To eive certificates for, which could be a superset of the scope of the requested c
ken Authority, the Token Authority could issue a token scoped just to "example.c ertificate.
om", or a token that attests the client is eligible to receive certificates for </t>
both "example.com" or "example.net". The advantage of the latter is that if, at <t indent="0" pn="section-3.2-2">
a later time (but one within the expiry of the token), the client wanted to acqu For example, imagine a case where a Token Authority for DNS names knows t
ire a certificate for "example.net", it would not have to return to the Token Au hat a client is eligible to receive certificates for "example.com" and "example.
thority, as the Token effectively pre-authorized the issuance of that certificat net". The client asks an ACME server for a certificate for "example.com", and th
e. e server directs the client to acquire an Authority Token from the Token Authori
</t><t> ty. When the client sends an acquisition request (see <xref target="acquire" for
Applications of the Authority Token to different identifier types might r mat="default" sectionFormat="of" derivedContent="Section 5"/>) to the Token Auth
equire different scopes, so registrations of tkauth-types should be clear if and ority, the Token Authority could issue a token scoped just to "example.com" or a
how a scope greater than that of the requested certificate would be conveyed in token that attests the client is eligible to receive certificates for both "exa
a token. mple.com" or "example.net". The advantage of the latter is that if, at a later t
</t> ime (but one within the expiry of the token), the client wanted to acquire a cer
</section> tificate for "example.net", it would not have to return to the Token Authority,
<section anchor="bind" title="Binding Challenges"> as the Token effectively pre-authorized the issuance of that certificate.
<t> </t>
Applications that use the Authority Token need a way to correlate tokens <t indent="0" pn="section-3.2-3">
issued by a Token Authority with the proper ACME client, to prevent replay or cu Applications of the Authority Token to different identifier types might r
t-and-paste attacks using a token issued for a different purpose. To mitigate th equire different scopes, so registrations of tkauth-types should be clear about
is, Authority Tokens contain a binding signed by a Token Authority; an ACME serv if and how a scope greater than that of the requested certificate would be conve
er can use the binding to determine that a Token presented by a client was in fa yed in a token.
ct granted by the Token Authority based on a request from the client, and not fr </t>
om some other entity. It is RECOMMENDED that the ACME account fingerprint be use </section>
d for this purpose. <section anchor="bind" numbered="true" toc="include" removeInRFC="false" p
</t><t> n="section-3.3">
<name slugifiedName="name-binding-challenges">Binding Challenges</name>
<t indent="0" pn="section-3.3-1">
Applications that use the Authority Token need a way to correlate tokens
issued by a Token Authority with the proper ACME client to prevent replay or cut
-and-paste attacks using a token issued for a different purpose. To mitigate thi
s, Authority Tokens contain a binding signed by a Token Authority; an ACME serve
r can use the binding to determine that a Token presented by a client was in fac
t granted by the Token Authority based on a request from the client and not from
some other entity. It is <bcp14>RECOMMENDED</bcp14> that the ACME account finge
rprint be used for this purpose.
</t>
<t indent="0" pn="section-3.3-2">
Creating a binding from an Authority Token to a particular ACME account e ntails that the Token could be reused up until its expiry for multiple challenge s issued by an ACME server. This might be a desirable property Creating a binding from an Authority Token to a particular ACME account e ntails that the Token could be reused up until its expiry for multiple challenge s issued by an ACME server. This might be a desirable property
when using short-lived certificates, for example, or in any cases where t when using short-lived certificates, for example, in any cases where the
he ACME server issues challenges more frequently that an Authority Token can or ACME server issues challenges more frequently that an Authority Token can or sho
should issue tokens, or in cases where the Authority Token scope (see <xref targ uld issue tokens or in cases where the Authority Token scope (see <xref target="
et="scope"/>) is broad, so certificates with a more narrow scope may periodicall scope" format="default" sectionFormat="of" derivedContent="Section 3.2"/>) is br
y be issued. oad, so certificates with a more narrow scope may periodically be issued.
</t><t> </t>
<t indent="0" pn="section-3.3-3">
For some identifier types, it may be more appropriate to bind the Authori ty Token to a nonce specific to the challenge rather than to an ACME account fin gerprint. Any specification of the use of the nonce or other factors for this pu rpose is left to the identifier type profile for the Authority Token. For some identifier types, it may be more appropriate to bind the Authori ty Token to a nonce specific to the challenge rather than to an ACME account fin gerprint. Any specification of the use of the nonce or other factors for this pu rpose is left to the identifier type profile for the Authority Token.
</t><t> </t>
Note that the fingerprint value in the client's JWT is reflected in the A <t indent="0" pn="section-3.3-4">
uthority Token returned by the Token Authority; the Token Authority has no requi Note that the fingerprint value in the client's JWT is reflected in the A
rement to validate that fingerprint. Were a fingerprint to be captured by an att uthority Token returned by the Token Authority; the Token Authority has no requi
acker which had its own account with the Token Authority, it could replay that f rement to validate that fingerprint. Were a fingerprint to be captured by an att
ingerprint in its own JWT in order to receive an Authority Token with that finge acker that had its own account with the Token Authority, it could replay that fi
rprint. However, were the attacker to present that Authority Token to an ACME se ngerprint in its own JWT in order to receive an Authority Token with that finger
rvice, the service would see the fingerprint does not match the attacker's ACME print. However, were the attacker to present that Authority Token to an ACME ser
account fingerprint. So unless an attacker can compromise a target ACME account vice, the service would see the fingerprint does not match the attacker's ACME a
or gain similar privileges, the binding would be secure. ccount fingerprint. So unless an attacker can compromise a target ACME account o
</t> r gain similar privileges, the binding would be secure.
</section> </t>
</section> </section>
</section>
<section anchor="tn" title="Authority Token Challenge tkauth-type Registr <section anchor="tn" numbered="true" toc="include" removeInRFC="false" pn="s
ation"> ection-4">
<t> <name slugifiedName="name-authority-token-challenge-t">Authority Token Cha
This draft specifies a tkauth-type of "atc" which contains a standard llenge tkauth-type Registration</name>
JWT <xref target="RFC7519"/> using a JWS-defined signature string <xref target <t indent="0" pn="section-4-1">
="RFC7515"/>. This document specifies a tkauth-type of "atc", which contains a standard
The "atc" tkauth-type MAY be used for any number of different ACME JWT <xref target="RFC7519" format="default" sectionFormat="of" derivedContent=
identifier types in the ACME challenge. "RFC7519"/> using a signature string defined by a JSON Web Signature (JWS) <xref
</t><t> target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/>
.
The "atc" tkauth-type <bcp14>MAY</bcp14> be used for any number of different ACM
E
Identifier Types in the ACME challenge.
</t>
<t indent="0" pn="section-4-2">
A new JWT claim, "atc", is A new JWT claim, "atc", is
defined below and lists the identifier type used in this Authority defined below and lists the identifier type used in this Authority
Token. The "atc" tkauth-type is restricted to the JWTs; if a Token. The "atc" tkauth-type is restricted to the JWTs; if a
non-JWT format is desired for the ACME Authority Token non-JWT format is desired for the ACME Authority Token
Challenge, a different tkauth-type should be specified and registered in the Challenge, a different tkauth-type should be specified and registered in the
"ACME Authority Token Challenge Types" "ACME Authority Token Challenge Types"
registry defined in Section 8. registry defined in <xref target="IANA-3" format="default" sectionFormat="of" de
</t><t> rivedContent="Section 6.3"/>.
For this ACME Authority Token usage of JWT, the payload of the JWT OPTIO </t>
NALLY contain an "iss" indicating the Token Authority that generated the token, <t indent="0" pn="section-4-3">
if the "x5u" or "x5c" element in the header does not already convey that informa For this ACME Authority Token usage of a JWT, it is <bcp14>OPTIONAL</bcp
tion; typically, this will be the same location that appeared in the "token-auth 14> for the payload of the JWT to contain an "iss", indicating the Token Authori
ority" field of the ACME challenge, when present. In order to satisfy the requir ty that generated the token if the "x5u" or "x5c" element in the header does not
ement for replay prevention the JWT MUST contain a "jti" element, and an "exp" c already convey that information; typically, this will be the same location that
laim; the "exp" claim manages token freshness. In addition to helping to manage appeared in the "token-authority" field of the ACME challenge, when present. In
replay, the "jti" provides a convenient way to reliably track when the same "atc order to satisfy the requirement for replay prevention, the JWT <bcp14>MUST</bc
" Authority Token is being used for multiple challenges over time within its set p14> contain a "jti" element and an "exp" claim; the "exp" claim manages token f
lifetime. reshness. In addition to helping to manage replay, the "jti" provides a convenie
</t><t> nt way to reliably track when the same "atc" Authority Token is being used for m
The JWT payload MUST also contain a new JWT claim, "atc", for Authority ultiple challenges over time within its set lifetime.
Token Challenge, which contains three mandatory elements in a JSON map: the ATC </t>
identifier type ("tktype"), the identifier value ("tkvalue"), and the binding (" <t indent="0" pn="section-4-4">
fingerprint"). The use of "tktype" is restricted to the values in the "ACME Iden The JWT payload <bcp14>MUST</bcp14> also contain a new JWT claim, "atc",
tifier Types" registry as defined by <xref target="RFC8555"/>. The identifier ty for Authority Token Challenge, which contains three mandatory elements in a JSO
pe and value are those given in the ACME challenge and conveyed to the Token Aut N map: the ATC identifier type ("tktype"), the identifier value ("tkvalue"), and
hority by the ACME client. For the purposes of the "atc" tkauth-type, the bindin the binding ("fingerprint"). The use of "tktype" is restricted to the values in
g "fingerprint" is assumed to be a fingerprint of the ACME credential for the ac the "ACME Identifier Types" registry, as defined by <xref target="RFC8555" form
count used to request the certificate, but the specification of how the binding at="default" sectionFormat="of" derivedContent="RFC8555"/>. The identifier type
is generated is left to the identifier type profile for the Authority Token (see and value are those given in the ACME challenge and conveyed to the Token Author
<xref target="bind"/>). The "tkvalue" indicates the scope of the authority that ity by the ACME client. For the purposes of the "atc" tkauth-type, the binding "
the token, and its semantics are outside the scope of this document, as they wi fingerprint" is assumed to be a fingerprint of the ACME credential for the accou
ll be specified by the "tkvalue" identifier in a separate specification. nt used to request the certificate, but the specification of how the binding is
</t><t> generated is left to the identifier type profile for the Authority Token (see <x
Following the example of <xref target="I-D.ietf-acme-authority-to ref target="bind" format="default" sectionFormat="of" derivedContent="Section 3.
ken-tnauthlist"/>, the "tktype" identifier type could be the TNAuthList, with a 3"/>). The "tkvalue" indicates the scope of the authority that the token and its
"tkvalue" as defined in <xref target="RFC8226"/> that the Token Authority is att semantics are outside the scope of this document, as they will be specified by
esting. Practically speaking, that scope may comprise a list of Service Provider the "tkvalue" identifier in a separate specification.
Code elements, telephone number range elements, and/or individual telephone num </t>
bers. So for example: <t indent="0" pn="section-4-5">
</t><t> Following the example of <xref target="RFC9448" format="default"
<figure> sectionFormat="of" derivedContent="RFC9448"/>, the "tktype" identifier type coul
<artwork><![CDATA[ d be the TNAuthList (as defined in <xref target="RFC8226" format="default" secti
{ onFormat="of" derivedContent="RFC8226"/>), which would be the value for the "tkv
"protected": base64url({ alue" element that the Token Authority is attesting. Practically speaking, that
"typ":"JWT", scope may comprise a list of Service Provider Code elements, telephone number ra
"alg":"ES256", nge elements, and/or individual telephone numbers. So for example:
"x5u":"https://authority.example.org/cert" </t>
}), <sourcecode type="" markers="false" pn="section-4-6">
"payload": base64url({ {
"iss":"https://authority.example.org/authz", "protected": base64url({
"exp":1300819380, "typ":"JWT",
"jti":"id6098364921", "alg":"ES256",
"atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint": "x5u":"https://authority.example.org/cert"
"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: }),
9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} "payload": base64url({
}), "iss":"https://authority.example.org/authz",
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "exp":1300819380,
} "jti":"id6098364921",
]]></artwork> "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==",
</figure> "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:
</t> BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}
<t>Optionally, the "atc" claim may contain a fourth boolean element, "ca". I }),
f set to "true", the "ca" element indicates that the Token Authority is granting "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
permission to issue a certification authority certificate rather than an end-en }
tity certificate for the names in question. This permits subordinate delegations </sourcecode>
from the issued certificate (using <xref target="RFC9115"/> or similar mechanis <t indent="0" pn="section-4-7">Optionally, the "atc" claim may contain a f
ms). If the "ca" element is absent, the Token Authority is explicitly withholdin ourth boolean element, "ca". If set to "true", the "ca" element indicates that t
g permission. The "atc" object in the example above would then look like: he Token Authority is granting permission to issue a certification authority cer
<figure> tificate rather than an end-entity certificate for the names in question. This p
<artwork><![CDATA[ ermits subordinate delegations from the issued certificate (using <xref target="
"atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","ca":true, RFC9115" format="default" sectionFormat="of" derivedContent="RFC9115"/> or simil
"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F ar mechanisms). If the "ca" element is absent, the Token Authority is explicitly
8:50: withholding permission. The "atc" object in the example above would then look l
9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } ike:
]]></artwork> </t>
</figure> <sourcecode type="" markers="false" pn="section-4-8">
</t><t> "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==",
"ca":true,"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:
71:D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} }
</sourcecode>
<t indent="0" pn="section-4-9">
Specifications of "tktype" identifier types may define additional optional " atc" elements. Specifications of "tktype" identifier types may define additional optional " atc" elements.
</t> </t>
</section> </section>
<section anchor="acquire" numbered="true" toc="include" removeInRFC="false"
<section anchor="acquire" title="Acquiring a Token"> pn="section-5">
<t> <name slugifiedName="name-acquiring-a-token">Acquiring a Token</name>
The acquisition of an Authority Token requires a network interface, apart fr <t indent="0" pn="section-5-1">
om potential use cases where the entity that acts as an ACME client itself also The acquisition of an Authority Token requires a network interface, apart fr
acts as a Token Authority trusted by the ACME server. Implementations compliant om potential use cases where the entity that acts as an ACME client itself also
with this specification MUST support an HTTPS interface for Authority Token acqu acts as a Token Authority trusted by the ACME server. Implementations compliant
isition as described below, though other interfaces MAY be supported as well. with this specification <bcp14>MUST</bcp14> support an HTTPS interface for Autho
rity Token acquisition as described below, though other interfaces <bcp14>MAY</b
cp14> be supported as well.
</t> </t>
<section anchor="ex" title="Basic REST Interface"> <section anchor="ex" numbered="true" toc="include" removeInRFC="false" pn=
<t> "section-5.1">
In order to request an Authority Token from a Token Authority, a client sen <name slugifiedName="name-basic-rest-interface">Basic REST Interface</na
ds a HTTPS POST request <xref target="RFC7231"/> . This specification assumes th me>
at Token Authority URIs are known to clients through preexisting business relati <t indent="0" pn="section-5.1-1">
onships, and that the credentials and related authentication and authorization f In order to request an Authority Token from a Token Authority, a client sen
or Authority Token acquisition are encompassed in that relationship. Different s ds a HTTPS POST request <xref target="RFC9110" format="default" sectionFormat="o
ervices may organize their web resources in domain-specific ways, but the resour f" derivedContent="RFC9110"/>. This specification assumes that Token Authority U
ce locator should specify the account of the client, an identifier for the servi RIs are known to clients through preexisting business relationships and that the
ce provider, and finally a locator for the token. credentials and related authentication and authorization for Authority Token ac
</t><t> quisition are encompassed in that relationship. Different services may organize
<figure><artwork><![CDATA[ their web resources in domain-specific ways, but the resource locator should spe
cify the account of the client, an identifier for the service provider, and fina
lly a locator for the token.
</t>
<sourcecode type="" markers="false" pn="section-5.1-2">
POST /at/account/:id/token HTTP/1.1 POST /at/account/:id/token HTTP/1.1
Host: authority.example.com Host: authority.example.com
Content-Type: application/json Content-Type: application/json
]]></artwork></figure> </sourcecode>
</t><t>Note that ":id" here is a placeholder for an actual account identifi <t indent="0" pn="section-5.1-3">Note that ":id" here is a placeholder f
er. The body of the POST request MUST contain the Authority Token Challenge elem or an actual account identifier. The body of the POST request <bcp14>MUST</bcp14
ent (the key "atc", colon, and its value) that the client is requesting the Toke > contain the Authority Token Challenge element (the key "atc", colon, and its v
n Authority generate. In this way, the client proposes the scope of the Authorit alue) that the client is requesting the Token Authority generate. In this way, t
y Token it would like to receive from the Token Authority. he client proposes the scope of the Authority Token it would like to receive fro
</t><t> m the Token Authority.
In common use cases, the "tkvalue" in this request is asking that the Token </t>
Authority issue a token that attests the entire scope of authority to which the <t indent="0" pn="section-5.1-4">
client is entitled. The client may also request an Authority Token with some sub In common use cases, the "tkvalue" in this request is asking that the Token
set of its own authority via the "tkvalue" element in the Authority Token Challe Authority issue a token that attests the entire scope of authority to which the
nge object. The way that "tkvalue" is defined will necessarily be specific to th client is entitled. The client may also request an Authority Token with some sub
e identifier type. For the TNAuthlist identifier type, for example, an object re set of its own authority via the "tkvalue" element in the Authority Token Challe
questing an Authority Token could request authority for only a single telephone nge object. The way that "tkvalue" is defined will necessarily be specific to th
number in a way that is defined in the TNAuthList specification. e identifier type. For the TNAuthList identifier type, for example, an object re
</t><t> questing an Authority Token could request authority for only a single telephone
Finally, the JSON object MAY also contain an optional boolean element "ca" w number in a way that is defined in the TNAuthList specification.
hich signifies that the client is requesting that the Token Authority issue an A </t>
uthority Token with the "ca" flag set, as described in <xref target="tn"/>.</t> <t indent="0" pn="section-5.1-5">
<t> Finally, the JSON object <bcp14>MAY</bcp14> also contain an optional boolean
After an HTTPS-level challenge (e.g. a 401 HTTP response code) to verify the element, "ca", which signifies that the client is requesting that the Token Aut
identity of the client and subsequently making an authorization decision about hority issue an Authority Token with the "ca" flag set, as described in <xref ta
whether the client should receive an Authority Token with the requested scope, t rget="tn" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
hen in the success case, the Token Authority MUST return a 200 OK with a body of <t indent="0" pn="section-5.1-6">
type "application/json" containing the Authority Token. After an HTTPS-level challenge (e.g., a 401 HTTP response code) to verify th
</t><t> e identity of the client and subsequently making an authorization decision about
A full example of "atc" token acquisition using the HTTP interface, with whether the client should receive an Authority Token with the requested scope,
the "tktype" of "TNAuthList", is given in <xref target="I-D.ietf-acme-authority- then in the success case, the Token Authority <bcp14>MUST</bcp14> return a 200 O
token-tnauthlist"/> Section 5.5. K with a body of type "application/json" containing the Authority Token.
</t> </t>
</section> <t indent="0" pn="section-5.1-7">
A full example of "atc" token acquisition using the HTTP interface, with
</section> the "tktype" of "TNAuthList", is given in <xref target="RFC9448" format="default
" sectionFormat="of" section="5.5" derivedLink="https://rfc-editor.org/rfc/rfc94
<section anchor="Acknowledgements" title="Acknowledgements"> 48#section-5.5" derivedContent="RFC9448"/>.
<t>We would like to Roman Danyliw and Ben Kaduk for contributions to this </t>
problem statement and framework.</t> </section>
</section> </section>
<section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="iana" title="IANA Considerations"> "section-6">
<section anchor="IANA-1" title="ACME Validation Method Registration"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="IANA-1" numbered="true" toc="include" removeInRFC="false"
<t>This document requests that IANA populate a new ACME Validation Method pn="section-6.1">
(again per <xref target="RFC8555"/>) in the ACME Validation Methods sub-registry <name slugifiedName="name-acme-validation-method-regi">ACME Validation M
of the Automated Certificate Management Environment (ACME) Protocol registry gr ethod Registration</name>
oup for the label "tkauth-01", identifier type "TNAuthList", an ACME value of "Y <t indent="0" pn="section-6.1-1">IANA has added a new ACME Validation Me
", and a reference pointing to [RFCThis]. thod (per <xref target="RFC8555" format="default" sectionFormat="of" derivedCont
</t><t> ent="RFC8555"/>) in the "ACME Validation Methods" subregistry of the "Automated
Note to the RFC Editor: Please replace [RFCThis] throughout this docume Certificate Management Environment (ACME) Protocol" registry group as follows:<
nt with the RFC number assigned to this specification. /t>
</t> <dl newline="false" spacing="normal" indent="3" pn="section-6.1-2">
</section> <dt pn="section-6.1-2.1">Label:</dt>
<dd pn="section-6.1-2.2">tkauth-01</dd>
<section anchor="IANA-2" title="JSON Web Token Claim Registration"> <dt pn="section-6.1-2.3">Identifier Type:</dt>
<t> <dd pn="section-6.1-2.4">TNAuthList</dd>
This document asks IANA to populate a new claim in the "JSON Web <dt pn="section-6.1-2.5">ACME:</dt>
Token Claims" registry as defined in <xref target="RFC7519"/> as follows: <dd pn="section-6.1-2.6">Y</dd>
</t><t><list><t> <dt pn="section-6.1-2.7">Reference:</dt>
Claim name: atc <dd pn="section-6.1-2.8">RFC 9447</dd>
</t><t> </dl>
Claim Description: Authority Token Challenge </section>
</t><t> <section anchor="IANA-2" numbered="true" toc="include" removeInRFC="false"
Change Controller: IESG pn="section-6.2">
</t><t> <name slugifiedName="name-json-web-token-claim-regist">JSON Web Token Cl
Specification document(s): [RFCThis] aim Registration</name>
</t></list></t> <t indent="0" pn="section-6.2-1">
</section> IANA has added a new claim in the "JSON Web Token Claims" registr
<section anchor="IANA-3" title="Creation of ACME Authority Token Challeng y, as defined in <xref target="RFC7519" format="default" sectionFormat="of" deri
e Type Registry"> vedContent="RFC7519"/>, as follows:
<t> </t>
This document requests that the IANA create a new registry for "ACME A <dl newline="false" spacing="normal" indent="3" pn="section-6.2-2">
uthority Token Challenge Types" as used in these challenges, under a policy of S <dt pn="section-6.2-2.1">Claim name:</dt>
pecification Required and following the requirements in <xref target="req"/>, wi <dd pn="section-6.2-2.2">atc</dd>
th three columns: Label, Reference and Description. The registry should be pre-p <dt pn="section-6.2-2.3">Claim Description:</dt>
opulated with a Label of "atc" per <xref target="tn"/> with a Reference value of <dd pn="section-6.2-2.4">Authority Token Challenge</dd>
[RFCThis], and a Description of "JSON Web Token (JWT) challenge type."</t> <dt pn="section-6.2-2.5">Change Controller:</dt>
</section> <dd pn="section-6.2-2.6">IETF</dd>
<dt pn="section-6.2-2.7">Specification document(s):</dt>
<dd pn="section-6.2-2.8">RFC 9447</dd>
</dl>
</section>
<section anchor="IANA-3" numbered="true" toc="include" removeInRFC="false"
pn="section-6.3">
<name slugifiedName="name-creation-of-acme-authority-">Creation of ACME
Authority Token Challenge Types Registry</name>
<t indent="0" pn="section-6.3-1">
IANA has created a new registry for "ACME Authority Token Challenge Ty
pes" as used in these challenges, under a policy of Specification Required and f
ollowing the requirements in <xref target="req" format="default" sectionFormat="
of" derivedContent="Section 3.1"/>, with three columns: Label, Description, and
Reference. The initial content of the registry is as follows:</t>
<dl newline="false" indent="3" spacing="normal" pn="section-6.3-2">
<dt pn="section-6.3-2.1">Label:</dt>
<dd pn="section-6.3-2.2"> atc (as defined in <xref target="tn" format=
"default" sectionFormat="of" derivedContent="Section 4"/>)</dd>
<dt pn="section-6.3-2.3">Description:</dt>
<dd pn="section-6.3-2.4">JSON Web Token (JWT) challenge type</dd>
<dt pn="section-6.3-2.5">Reference:</dt>
<dd pn="section-6.3-2.6">RFC 9447</dd>
</dl>
</section>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
<section anchor="Security" title="Security Considerations"> pn="section-7">
<t> <name slugifiedName="name-security-considerations">Security Considerations
Per the guidance in <xref target="RFC8555"/>, ACME transactions MUST u </name>
se TLS, and similarly the HTTPS REST transactions used to request and acquire Au <t indent="0" pn="section-7-1">
thority Tokens MUST use TLS. These measures are intended to prevent the capture Per the guidance in <xref target="RFC8555" format="default" sectionFor
of Authority Tokens by eavesdroppers. A preexisting trust relationship between t mat="of" derivedContent="RFC8555"/>, ACME transactions <bcp14>MUST</bcp14> use T
he HTTPS REST client and the Token Authority must also exist in order for the pa LS, and similarly, the HTTPS REST transactions used to request and acquire Autho
rties to meaningfully authenticate one another. The security considerations of < rity Tokens <bcp14>MUST</bcp14> use TLS. These measures are intended to prevent
xref target="RFC8555"/> apply to the use of the mechanism in this specification. the capture of Authority Tokens by eavesdroppers. A preexisting trust relationsh
Implementations should follow the best practices identified in <xref target="RF ip between the HTTPS REST client and the Token Authority must also exist in orde
C8725"/>. r for the parties to meaningfully authenticate one another. The security conside
</t><t> rations of <xref target="RFC8555" format="default" sectionFormat="of" derivedCon
As described in <xref target="scope"/>, an Authority Token can tent="RFC8555"/> apply to the use of the mechanism in this specification. Implem
either have a scope that attests all of the resources which a client is eligible entations should follow the best practices identified in <xref target="RFC8725"
to receive certificates for, or potentially a more limited scope that is intend format="default" sectionFormat="of" derivedContent="RFC8725"/>.
ed to capture only those resources for which a client will receive a certificate </t>
from a particular certification authority. Any certification authority that see <t indent="0" pn="section-7-2">
s an Authority Token can learn information about the resources a client can clai As described in <xref target="scope" format="default" sectionFo
m. In cases where this incurs a privacy risk, Authority Token scopes should be l rmat="of" derivedContent="Section 3.2"/>, an Authority Token can either have a s
imited to only the resources that will be attested by the requested ACME certifi cope that attests all of the resources that a client is eligible to receive cert
cate. ificates for or potentially a more limited scope that is intended to capture onl
</t><t> y those resources for which a client will receive a certificate from a particula
In cases where a tkauth-type as defined in <xref target="tn"/> r certification authority. Any certification authority that sees an Authority To
admits of its own subtypes, the security of features like binding challenges (se ken can learn information about the resources a client can claim. In cases where
e <xref target="bind"/>) will depend on the subtype specification. this incurs a privacy risk, Authority Token scopes should be limited to only th
</t><t> e resources that will be attested by the requested ACME certificate.
The capture of Authority Tokens by an adversary could enable an a </t>
ttacker to acquire a certificate from a CA. Therefore, all Authority Tokens MUST <t indent="0" pn="section-7-3">
contain a field that identifies to the CA which ACME client requested the token In cases where a tkauth-type, as defined in <xref target="tn" f
from the Token Authority; here that is the fingerprint specified in <xref targe ormat="default" sectionFormat="of" derivedContent="Section 4"/>, admits of its o
t="tn"/>). All Authority Tokens must specify an expiry (of the token itself as p wn subtypes, the security of features like binding challenges (see <xref target=
roof for a CA, as opposed to the expiry of the name), and for some application, "bind" format="default" sectionFormat="of" derivedContent="Section 3.3"/>) will
it may make sense of that expiry to be quite short. ACME services relying on Aut depend on the subtype specification.
hority Tokens SHOULD not issue certificates with a longer expiry than the expiry </t>
of the Authority Token. Any protocol used to retrieve Authority Tokens from a T <t indent="0" pn="section-7-4">
oken Authority MUST use confidentiality to prevetn eavesdroppers from acquiring The capture of Authority Tokens by an adversary could enable an attacker
an Authority Token. The details of this protocol are out of the scope of this sp to acquire a certificate from a CA. Therefore, all Authority Tokens <bcp14>MUST<
ecification. /bcp14> contain a field that identifies to the CA which ACME client requested th
</t><t> e token from the Token Authority; here, that is the fingerprint specified in <xr
ef target="tn" format="default" sectionFormat="of" derivedContent="Section 4"/>.
All Authority Tokens must specify an expiry (of the token itself as proof for a
CA, as opposed to the expiry of the name), and for some applications, it may ma
ke sense for that expiry to be quite short.
ACME services relying on Authority Tokens <bcp14>SHOULD NOT</bcp14> issue
certificates with a longer expiry than the expiry of the Authority Token. Any p
rotocol used to retrieve Authority Tokens from a Token Authority <bcp14>MUST</bc
p14> use confidentiality to prevent eavesdroppers from acquiring an Authority To
ken. The details of this protocol are out of the scope of this specification.
</t>
<t indent="0" pn="section-7-5">
This document only specifies SHA256 for the fingerprint hash. How ever, the syntax of the fingerprint object would permit other keys if, due to co ncerns about algorithmic agility, a more robust algorithm were required at a fut ure time. Future specifications can define new keys for the fingerprint object a s needed. This document only specifies SHA256 for the fingerprint hash. How ever, the syntax of the fingerprint object would permit other keys if, due to co ncerns about algorithmic agility, a more robust algorithm were required at a fut ure time. Future specifications can define new keys for the fingerprint object a s needed.
</t> </t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references pn="section-8">
<!-- References split into informative and normative --> <name slugifiedName="name-references">References</name>
<references pn="section-8.1">
<!-- There are 2 ways to insert reference entries from the citation librarie <name slugifiedName="name-normative-references">Normative References</na
s: me>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here ( <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
as shown) 119" quoteTitle="true" derivedAnchor="RFC2119">
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml <front>
"?> here <title>Key words for use in RFCs to Indicate Requirement Levels</tit
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x le>
ml") <author fullname="S. Bradner" initials="S." surname="Bradner"/>
Both are cited textually in the same manner: by using xref elements. <date month="March" year="1997"/>
If you use the PI option, xml2rfc will, by default, try to find included fil <abstract>
es in the same <t indent="0">In many standards track documents several words are
directory as the including file. You can also define the XML_LIBRARY environ used to signify the requirements in the specification. These words are often cap
ment variable italized. This document defines these words as they should be interpreted in IET
with a value containing a set of directories to search. These can be either F documents. This document specifies an Internet Best Current Practices for the
in the local Internet Community, and requests discussion and suggestions for improvements.</t
filing system or remote ones accessed by http (http://domain/dir/... ).--> >
</abstract>
<references title="Normative References"> </front>
&RFC2119; <seriesInfo name="BCP" value="14"/>
&RFC8174; <seriesInfo name="RFC" value="2119"/>
&RFC7515; <seriesInfo name="DOI" value="10.17487/RFC2119"/>
&RFC7519; </reference>
&RFC7231; <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7
&RFC3986; 515" quoteTitle="true" derivedAnchor="RFC7515">
&RFC8725; <front>
&RFC4648; <title>JSON Web Signature (JWS)</title>
&RFC8555; <author fullname="M. Jones" initials="M." surname="Jones"/>
&I-D.ietf-acme-authority-token-tnauthlist; <author fullname="J. Bradley" initials="J." surname="Bradley"/>
</references> <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<references title="Informative References"> <date month="May" year="2015"/>
&RFC8226; <abstract>
&RFC8396; <t indent="0">JSON Web Signature (JWS) represents content secured
&RFC9115; with digital signatures or Message Authentication Codes (MACs) using JSON-based
data structures. Cryptographic algorithms and identifiers for use with this spec
ification are described in the separate JSON Web Algorithms (JWA) specification
and an IANA registry defined by that specification. Related encryption capabilit
ies are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7
519" quoteTitle="true" derivedAnchor="RFC7519">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
<date month="May" year="2015"/>
<abstract>
<t indent="0">JSON Web Token (JWT) is a compact, URL-safe means of
representing claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON Web Signature
(JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, e
nabling the claims to be digitally signed or integrity protected with a Message
Authentication Code (MAC) and/or encrypted.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7519"/>
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
</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"/>
<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 clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</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"/>
<author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman
-Andrews"/>
<author fullname="D. McCarney" initials="D." surname="McCarney"/>
<author fullname="J. Kasten" initials="J." surname="Kasten"/>
<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 P
KI are trusted to verify that an applicant for a certificate legitimately repres
ents the domain name(s) in the certificate. As of this writing, this verificatio
n is done through a collection of ad hoc mechanisms. This document describes a p
rotocol that a CA and an applicant can use to automate the process of verificati
on and certificate issuance. The protocol also provides facilities for other cer
tificate management functions, such as certificate revocation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8555"/>
<seriesInfo name="DOI" value="10.17487/RFC8555"/>
</reference>
<reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rfc8
725" quoteTitle="true" derivedAnchor="RFC8725">
<front>
<title>JSON Web Token Best Current Practices</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="D. Hardt" initials="D." surname="Hardt"/>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="February" year="2020"/>
<abstract>
<t indent="0">JSON Web Tokens, also known as JWTs, are URL-safe JS
ON-based security tokens that contain a set of claims that can be signed and/or
encrypted. JWTs are being widely used and deployed as a simple security token fo
rmat in numerous protocols and applications, both in the area of digital identit
y and in other application areas. This Best Current Practices document updates R
FC 7519 to provide actionable guidance leading to secure implementation and depl
oyment of JWTs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="225"/>
<seriesInfo name="RFC" value="8725"/>
<seriesInfo name="DOI" value="10.17487/RFC8725"/>
</reference>
<reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9
110" quoteTitle="true" derivedAnchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateles
s application-level protocol for distributed, collaborative, hypertext informati
on systems. This document describes the overall architecture of HTTP, establishe
s common terminology, and defines aspects of the protocol that are shared by all
versions. In this definition are core protocol elements, extensibility mechanis
ms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t indent="0">This document updates RFC 3864 and obsoletes RFCs 28
18, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="RFC9448" target="https://www.rfc-editor.org/info/rfc9
448" quoteTitle="true" derivedAnchor="RFC9448">
<front>
<title>TNAuthList Profile of Automated Certificate Management Enviro
nment (ACME) Authority Token</title>
<author initials="C" surname="Wendt" fullname="Chris Wendt">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Hancock" fullname="David Hancock">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Barnes" fullname="Mary Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Peterson" fullname="Jon Peterson">
<organization showOnFrontPage="true"/>
</author>
<date year="2023" month="September"/>
</front>
<seriesInfo name="RFC" value="9448"/>
<seriesInfo name="DOI" value="10.17487/RFC9448"/>
</reference>
</references>
<references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<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"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<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 t
he use of certificates in establishing authority over telephone numbers, as a co
mponent of a broader architecture for managing telephone numbers as identities i
n protocols like SIP.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8226"/>
<seriesInfo name="DOI" value="10.17487/RFC8226"/>
</reference>
<reference anchor="RFC8396" target="https://www.rfc-editor.org/info/rfc8
396" quoteTitle="true" derivedAnchor="RFC8396">
<front>
<title>Managing, Ordering, Distributing, Exposing, and Registering T
elephone Numbers (MODERN): Problem Statement, Use Cases, and Framework</title>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="T. McGarry" initials="T." surname="McGarry"/>
<date month="July" year="2018"/>
<abstract>
<t indent="0">The functions of the Public Switched Telephone Netwo
rk (PSTN) are rapidly migrating to the Internet. This is generating new requirem
ents for many traditional elements of the PSTN, including Telephone Numbers (TNs
). TNs no longer serve simply as telephone routing addresses: they are now ident
ifiers that may be used by Internet-based services for a variety of purposes inc
luding session establishment, identity verification, and service enablement. Thi
s problem statement examines how the existing tools for allocating and managing
telephone numbers do not align with the use cases of the Internet environment an
d proposes a framework for Internet-based services relying on TNs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8396"/>
<seriesInfo name="DOI" value="10.17487/RFC8396"/>
</reference>
<reference anchor="RFC9115" target="https://www.rfc-editor.org/info/rfc9
115" quoteTitle="true" derivedAnchor="RFC9115">
<front>
<title>An Automatic Certificate Management Environment (ACME) Profil
e for Generating Delegated Certificates</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="D. López" initials="D." surname="López"/>
<author fullname="A. Pastor Perales" initials="A." surname="Pastor P
erales"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="September" year="2021"/>
<abstract>
<t indent="0">This document defines a profile of the Automatic Cer
tificate Management Environment (ACME) protocol by which the holder of an identi
fier (e.g., a domain name) can allow a third party to obtain an X.509 certificat
e such that the certificate subject is the delegated identifier while the certif
ied public key corresponds to a private key controlled by the third party. A pri
mary use case is that of a Content Delivery Network (CDN), the third party, term
inating TLS sessions on behalf of a content provider (the holder of a domain nam
e). The presented mechanism allows the holder of the identifier to retain contro
l over the delegation and revoke it at any time. Importantly, this mechanism doe
s not require any modification to the deployed TLS clients and servers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9115"/>
<seriesInfo name="DOI" value="10.17487/RFC9115"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">We would like to <contact fullname
="Roman Danyliw"/> and <contact fullname="Ben Kaduk"/> for contributions to this
problem statement and framework.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="Neustar" showOnFrontPage="true">Neustar, Inc.</org
anization>
<address>
<email>jon.peterson@team.neustar</email>
</address>
</author>
<author fullname="Mary Barnes" initials="M." surname="Barnes">
<organization abbrev="Neustar" showOnFrontPage="true">Neustar, Inc.</org
anization>
<address>
<email>mary.ietf.barnes@gmail.com</email>
</address>
</author>
<author fullname="David Hancock" initials="D." surname="Hancock">
<organization showOnFrontPage="true">Somos</organization>
<address>
<email>davidhancock.ietf@gmail.com</email>
</address>
</author>
<author fullname="Chris Wendt" initials="C." surname="Wendt">
<organization showOnFrontPage="true">Somos</organization>
<address>
<email>chris-ietf@chriswendt.net</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 32 change blocks. 
537 lines changed or deleted 966 lines changed or added

This html diff was produced by rfcdiff 1.48.