rfc9448xml2.original.xml   rfc9448.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2. cName="draft-ietf-acme-authority-token-tnauthlist-13" number="9448" submissionTy
6.0) --> pe="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symR
efs="true" updates="" obsoletes="" xml:lang="en" prepTime="2023-09-12T21:07:25"
<!DOCTYPE rfc [ indexInclude="true" scripts="Common,Latin" tocDepth="3">
<!ENTITY nbsp "&#160;"> <link href="https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-t
<!ENTITY zwsp "&#8203;"> nauthlist-13" rel="prev"/>
<!ENTITY nbhy "&#8209;"> <link href="https://dx.doi.org/10.17487/rfc9448" rel="alternate"/>
<!ENTITY wj "&#8288;"> <link href="urn:issn:2070-1721" rel="alternate"/>
]>
<rfc ipr="trust200902" docName="draft-ietf-acme-authority-token-tnauthlist-13" c
ategory="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
<front> <front>
<title abbrev="ACME TNAuthList Auth Token">TNAuthList profile of ACME Author <title abbrev="ACME TNAuthList Authority Token">TNAuthList Profile of Automa
ity Token</title> ted Certificate Management Environment (ACME) Authority Token</title>
<seriesInfo name="RFC" value="9448" stream="IETF"/>
<author initials="C." surname="Wendt" fullname="Chris Wendt"> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Somos Inc.</organization> <organization showOnFrontPage="true">Somos Inc.</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>chris-ietf@chriswendt.net</email> <email>chris-ietf@chriswendt.net</email>
</address> </address>
</author> </author>
<author initials="D." surname="Hancock" fullname="David Hancock"> <author initials="D." surname="Hancock" fullname="David Hancock">
<organization>Comcast</organization> <organization showOnFrontPage="true">Somos Inc.</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>davidhancock.ietf@gmail.com</email> <email>davidhancock.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Barnes" fullname="Mary Barnes"> <author initials="M." surname="Barnes" fullname="Mary Barnes">
<organization>Neustar Inc.</organization> <organization showOnFrontPage="true">Neustar Inc.</organization>
<address> <address>
<postal> <postal>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>mary.ietf.barnes@gmail.com</email> <email>mary.ietf.barnes@gmail.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Peterson" fullname="Jon Peterson"> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization>Neustar Inc.</organization> <organization showOnFrontPage="true">Neustar Inc.</organization>
<address> <address>
<postal> <postal>
<street>1800 Sutter St Suite 570</street> <extaddr>Suite 570</extaddr>
<city>Concord, CA 94520</city> <street>1800 Sutter St</street>
<country>US</country> <city>Concord</city>
<region>CA</region>
<code>94520</code>
<country>United States of America</country>
</postal> </postal>
<email>jon.peterson@neustar.biz</email> <email>jon.peterson@neustar.biz</email>
</address> </address>
</author> </author>
<date month="09" year="2023"/>
<date year="2023"/>
<area>sec</area> <area>sec</area>
<workgroup>acme</workgroup>
<keyword>STIR</keyword> <keyword>STIR</keyword>
<abstract pn="section-abstract">
<abstract> <t indent="0" pn="section-abstract-1">This document defines a profile of t
he Automated Certificate Management Environment (ACME) Authority Token for the a
<t>This document defines a profile of the Automated Certificate Management Envir utomated and authorized creation of certificates for Voice over IP (VoIP) teleph
onment (ACME) Authority Token for the automated and authorized creation of certi one providers to support Secure Telephone Identity (STI) using the TNAuthList de
ficates for VoIP Telephone Providers to support Secure Telephony Identity (STI) fined by STI certificates.</t>
using the TNAuthList defined by STI certificates.</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/rfc9448" 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" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-acme-new-order
-identifiers-">ACME New-Order Identifiers for TNAuthList</xref></t>
</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-tnauthlist-identifier-autho">TNAut
hList Identifier Authorization</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-tnauthlist-authority-token">TNAuth
List Authority Token</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-iss-claim">"iss" Claim
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-exp-claim">"exp" Claim
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-jti-claim">"jti" Claim
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-atc-claim">"atc" Claim
</xref></t>
</li>
<li pn="section-toc.1-1.5.2.5">
<t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent=
"5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-acquiring-the-token-fr
om-th">Acquiring the Token from the Token Authority</xref></t>
</li>
<li pn="section-toc.1-1.5.2.6">
<t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent=
"5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-token-authority-respon
sibil">Token Authority Responsibilities</xref></t>
</li>
<li pn="section-toc.1-1.5.2.7">
<t indent="0" pn="section-toc.1-1.5.2.7.1"><xref derivedContent=
"5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-scope-of-the-tnauthlis
t">Scope of the TNAuthList</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-validating-the-tnauthlist-a">Valid
ating the TNAuthList Authority Token</xref></t>
</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-using-acme-issued-certifica">Using
ACME-Issued Certificates with JSON Web Signature</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-usage-considerations">Usage Consid
erations</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-large-number-of-noncon
tiguo">Large Number of Noncontiguous TNAuthList Values</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.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 anchor="introduction" numbered="true" removeInRFC="false" toc="incl
<section anchor="introduction"><name>Introduction</name> ude" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t><xref target="RFC8555"/> is a mechanism for automating certificate management <t indent="0" pn="section-1-1"><xref target="RFC8555" format="default" sec
on the Internet. It enables administrative entities to prove effective control tionFormat="of" derivedContent="RFC8555"/> describes a mechanism for automating
over resources like domain names, and automates the process of generating and is certificate management on the Internet. It enables administrative entities to pr
suing certificates. <xref target="I-D.ietf-acme-authority-token"/> extends ACME ove effective control over resources like domain names, and it automates the pro
to provide a general method of extending the authority and authorization of enti cess of generating and issuing certificates. <xref target="RFC9447" format="defa
ties to control a resource via a third party Token Authority beyond the Certific ult" sectionFormat="of" derivedContent="RFC9447"/> extends ACME to provide a gen
ation Authority (CA).</t> eral method of extending the authority and authorization of entities to control
a resource via a third party Token Authority beyond the certification authority
<t>This document is a profile document using the Authority Token mechanism defin (CA).</t>
ed in <xref target="I-D.ietf-acme-authority-token"/>. It is a profile that spec <t indent="0" pn="section-1-2">This document is a profile document using t
ifically addresses the STIR problem statement <xref target="RFC7340"/> which ide he Authority Token mechanism defined in <xref target="RFC9447" format="default"
ntifies the need for Internet credentials that can attest authority for the orig sectionFormat="of" derivedContent="RFC9447"/>. It is a profile that specificall
inator of VoIP calls in order to detect impersonation, which is currently an ena y addresses the Secure Telephone Identity Revisited (STIR) problem statement des
bler for common attacks associated with illegal robocalling, voicemail hacking, cribed in <xref target="RFC7340" format="default" sectionFormat="of" derivedCont
and swatting. These credentials are used to sign PASSporTs <xref target="RFC822 ent="RFC7340"/>, which identifies the need for Internet credentials that can att
5"/>, which can be carried in using protocols such as SIP <xref target="RFC8224" est authority for the originator of VoIP calls in order to detect impersonation,
/>. Currently, the only defined credentials for this purpose are the certificat which is currently an enabler for common attacks associated with illegal roboca
es specified in <xref target="RFC8226"/> using the TNAuthList. This document de lling, voicemail hacking, and swatting. These credentials are used to sign Pers
fines the use of the TNAuthList Authority Token in the ACME challenge to proof t onal Assertion Tokens (PASSporTs) <xref target="RFC8225" format="default" sectio
he authoritative use of the contents of the TNAuthList, including a Service Prov nFormat="of" derivedContent="RFC8225"/>, which can be carried in using protocols
ider Token (SPC), a Telephone Number, or a set of telephone numbers or telephone such as SIP <xref target="RFC8224" format="default" sectionFormat="of" derivedC
number blocks.</t> ontent="RFC8224"/>. Currently, the only defined credentials for this purpose ar
e the certificates specified in <xref target="RFC8226" format="default" sectionF
<t>This document also describes the ability for a telephone authority to authori ormat="of" derivedContent="RFC8226"/> using the TNAuthList. This document defin
ze the creation of CA types of certificates for delegation as defined in <xref t es the use of the TNAuthList Authority Token in the ACME challenge to prove the
arget="RFC9060"/>.</t> authoritative use of the contents of the TNAuthList, including a Service Provide
r Code (SPC), a telephone number, or a set of telephone numbers or telephone num
</section> ber blocks.</t>
<section anchor="terminology"><name>Terminology</name> <t indent="0" pn="section-1-3">This document also describes the ability fo
r a telephone authority to authorize the creation of CA types of certificates fo
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", r delegation, as defined in <xref target="RFC9060" format="default" sectionForma
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this do t="of" derivedContent="RFC9060"/>.</t>
cument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xr </section>
ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown <section anchor="terminology" numbered="true" removeInRFC="false" toc="inclu
here.</t> de" pn="section-2">
<name slugifiedName="name-requirements-language">Requirements Language</na
</section> me>
<section anchor="acme-new-order-identifiers-for-tnauthlist"><name>ACME new-order <t indent="0" pn="section-2-1">
identifiers for TNAuthList</name> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
<t>In <xref target="RFC8555"/>, Section 7 defines the procedure that an ACME cli D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
ent uses to order a new certificate from a CA. The new-order request contains an OT RECOMMENDED</bcp14>",
identifier field that specifies the identifier objects the order corresponds to "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
. This draft defines a new type of identifier object called TNAuthList. A TNAut be interpreted as
hList identifier contains the identity information to be populated in the TN Aut described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
horization List of the new certificate. For the TNAuthList identifier, the new-o f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
rder request includes a type set to the string "TNAuthList". The value of the TN mat="of" derivedContent="RFC8174"/>
AuthList identifier MUST be set to the details of the TNAuthList requested.</t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>The format of the string that represents the TNAuthList MUST be constructed u </section>
sing base64url encoding, as per <xref target="RFC8555"/> base64url encoding desc <section anchor="acme-new-order-identifiers-for-tnauthlist" numbered="true"
ribed in Section 5 of <xref target="RFC4648"/> according to the profile specifie removeInRFC="false" toc="include" pn="section-3">
d in JSON Web Signature in Section 2 of <xref target="RFC7515"/>. The base64url <name slugifiedName="name-acme-new-order-identifiers-">ACME New-Order Iden
encoding MUST NOT include any padding characters and the TNAuthList ASN.1 object tifiers for TNAuthList</name>
MUST encoded using DER encoding rules.</t> <t indent="0" pn="section-3-1"><xref target="RFC8555" section="7" sectionF
ormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8555#sect
<t>An example of an ACME order object “identifiers” field containing a TNAuthLis ion-7" derivedContent="RFC8555"/> defines the procedure that an ACME client uses
t certificate would look as follows,</t> to order a new certificate from a CA. The new-order request contains an identif
ier field that specifies the identifier objects the order corresponds to. This
<figure><artwork><![CDATA[ document defines a new type of identifier object called TNAuthList. A TNAuthList
identifier contains the identity information to be populated in the TNAuthList
of the new certificate. For the TNAuthList identifier, the new-order request inc
ludes a type set to the string "TNAuthList". The value of the TNAuthList identif
ier <bcp14>MUST</bcp14> be set to the details of the TNAuthList requested.</t>
<t indent="0" pn="section-3-2">The string that represents the TNAuthList <
bcp14>MUST</bcp14> be
constructed using base64url encoding, as described in
<xref target="RFC4648" section="5" sectionFormat="of" format="default" derive
dLink="https://rfc-editor.org/rfc/rfc4648#section-5" derivedContent="RFC4648"/>
and as defined in <xref target="RFC7515" section="2" sectionFormat="of" format="
default" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-2" derivedConte
nt="RFC7515">JSON Web Signature</xref>.
The base64url encoding <bcp14>MUST NOT</bcp14> include any padding charact
ers, and the TNAuthList ASN.1 object <bcp14>MUST</bcp14> be encoded using DER en
coding rules.</t>
<t indent="0" pn="section-3-3">An example of an ACME order object "identif
iers" field containing a TNAuthList certificate is as follows:</t>
<sourcecode type="" markers="false" pn="section-3-4">
"identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}] "identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}]
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-3-5">where the "value" object string represents
<t>where the "value" object string represents the arbitrary length base64url enc the arbitrary length of the base64url-encoded string.</t>
oded string.</t> <t indent="0" pn="section-3-6">A full new-order request would look as foll
ows:</t>
<t>A full new-order request would look as follows,</t> <sourcecode type="" markers="false" pn="section-3-7">
<figure><artwork><![CDATA[
POST /acme/new-order HTTP/1.1 POST /acme/new-order HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg", "kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "5XJ1L3lEkMG7tR6pA00clA", "nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/new-order" "url": "https://example.com/acme/new-order"
}), }),
"payload": base64url({ "payload": base64url({
"identifiers": [{"type":"TNAuthList","value":"F83n...n27DN3"}], "identifiers": [{"type":"TNAuthList","value":"F83n...n27DN3"}],
"notBefore": "2021-01-01T00:00:00Z", "notBefore": "2021-01-01T00:00:00Z",
"notAfter": "2021-01-08T00:00:00Z" "notAfter": "2021-01-08T00:00:00Z"
}), }),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
} }
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-3-8">On receiving a valid new-order request, the
<t>On receiving a valid new-order request, the ACME server creates an authorizat ACME server creates an authorization object (<xref target="RFC8555" section="7.
ion object, <xref target="RFC8555"/> Section 7.1.4, containing the challenge tha 1.4" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/
t the ACME client must satisfy to demonstrate authority for the identifiers spec rfc/rfc8555#section-7.1.4" derivedContent="RFC8555"/>), containing the challenge
ified by the new order (in this case, the TNAuthList identifier). The CA adds th that the ACME client must satisfy to demonstrate authority for the identifiers
e authorization object URL to the "authorizations" field of the order object, an specified by the new order (in this case, the TNAuthList identifier). The CA add
d returns the order object to the ACME client in the body of a 201 (Created) res s the authorization object URL to the "authorizations" field of the order object
ponse.</t> and returns the order object to the ACME client in the body of a 201 (Created)
response.</t>
<figure><artwork><![CDATA[ <sourcecode type="" markers="false" pn="section-3-9">
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: application/json Content-Type: application/json
Replay-Nonce: MYAuvOpaoIiywTezizk5vw Replay-Nonce: MYAuvOpaoIiywTezizk5vw
Location: https://example.com/acme/order/1234 Location: https://example.com/acme/order/1234
{ {
"status": "pending", "status": "pending",
"expires": "2022-01-08T00:00:00Z", "expires": "2022-01-08T00:00:00Z",
"notBefore": "2022-01-01T00:00:00Z", "notBefore": "2022-01-01T00:00:00Z",
"notAfter": "2022-01-08T00:00:00Z", "notAfter": "2022-01-08T00:00:00Z",
"identifiers":[{"type":"TNAuthList", "identifiers":[{"type":"TNAuthList",
"value":"F83n2a...avn27DN3"}], "value":"F83n2a...avn27DN3"}],
"authorizations": [ "authorizations": [
"https://example.com/acme/authz/1234" "https://example.com/acme/authz/1234"
], ],
"finalize": "https://example.com/acme/order/1234/finalize" "finalize": "https://example.com/acme/order/1234/finalize"
} }
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="tnauthlist-identifier-authorization" numbered="true" remove
<section anchor="tnauthlist-identifier-authorization"><name>TNAuthList Identifie InRFC="false" toc="include" pn="section-4">
r Authorization</name> <name slugifiedName="name-tnauthlist-identifier-autho">TNAuthList Identifi
er Authorization</name>
<t>On receiving the new-order response, the ACME client queries the referenced a <t indent="0" pn="section-4-1">On receiving the new-order response, the AC
uthorization object to obtain the challenges for the identifier contained in the ME client queries the referenced authorization object to obtain the challenges f
new-order request as shown in the following example request and response.</t> or the identifier contained in the new-order request, as shown in the following
example request and response.</t>
<figure><artwork><![CDATA[ <sourcecode type="" markers="false" pn="section-4-2">
POST /acme/authz/1234 HTTP/1.1 POST /acme/authz/1234 HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": " https://example.com/acme/acct/evOfKhNU60wg", "kid": " https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg", "nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/1234" "url": "https://example.com/acme/authz/1234"
}), }),
"payload": "", "payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps" "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
} }
]]></artwork></figure> </sourcecode>
<sourcecode type="" markers="false" pn="section-4-3">
<figure><artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Link: <https://example.com/acme/some-directory&gt;;rel="index" Link: <https://example.com/acme/some-directory&gt;;rel="index"
{ {
"status": "pending", "status": "pending",
"expires": "2022-01-08T00:00:00Z", "expires": "2022-01-08T00:00:00Z",
"identifier": { "identifier": {
"type":"TNAuthList", "type":"TNAuthList",
"value":"F83n2a...avn27DN3" "value":"F83n2a...avn27DN3"
}, },
"challenges": [ "challenges": [
{ {
"type": "tkauth-01", "type": "tkauth-01",
"tkauth-type": "atc", "tkauth-type": "atc",
"token-authority": "https://authority.example.org", "token-authority": "https://authority.example.org",
"url": "https://example.com/acme/chall/prV_B7yEyA4", "url": "https://example.com/acme/chall/prV_B7yEyA4",
"token": "IlirfxKKXAsHtmzK29Pj8A" "token": "IlirfxKKXAsHtmzK29Pj8A"
} }
] ]
} }
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-4-4">When processing a certificate order contain
<t>When processing a certificate order containing an identifier of type "TNAuthL ing an identifier of type "TNAuthList", a CA uses the Authority Token challenge
ist", a CA uses the Authority Token challenge type of "tkauth-01" with a "tkauth type of "tkauth-01" with a "tkauth-type" of "atc" in <xref target="RFC9447" form
-type" of "atc" in <xref target="I-D.ietf-acme-authority-token"/> to verify that at="default" sectionFormat="of" derivedContent="RFC9447"/> to verify that the re
the requesting ACME client has authenticated and authorized control over the re questing ACME client has authenticated and authorized control over the requested
quested resources represented by the "TNAuthList" value.</t> resources represented by the "TNAuthList" value.</t>
<t indent="0" pn="section-4-5">The challenge "token-authority" parameter i
<t>The challenge "token-authority" parameter is only used in cases where the VoI s only used in cases where the VoIP telephone network requires the CA to identif
P telephone network requires the CA to identify the Token Authority. This is cur y the Token Authority. This is currently not the case for the Signature-based Ha
rently not the case for the SHAKEN <xref target="ATIS-1000080"/> certificate fra ndling of Asserted information using toKENs (SHAKEN) <xref target="ATIS-1000080"
mework governance, but may be used by other frameworks. If a "token-authority" p format="default" sectionFormat="of" derivedContent="ATIS-1000080"/> certificate
arameter is present, then the ACME client MAY use the "token-authority" value to framework governance but may be used by other frameworks. If a "token-authority
identify the URL representing the Token Authority that will provide the TNAuthL " parameter is present, then the ACME client <bcp14>MAY</bcp14> use the "token-a
ist Authority Token response to the challenge. If the "token-authority" paramete uthority" value to identify the URL representing the Token Authority that will p
r is not present, then the ACME client MUST identify the Token Authority based o rovide the TNAuthList Authority Token response to the challenge. If the "token-a
n locally configured information or local policies.</t> uthority" parameter is not present, then the ACME client <bcp14>MUST</bcp14> ide
ntify the Token Authority based on locally configured information or local polic
<t>The ACME client responds to the challenge by posting the TNAuthList Authority ies.</t>
Token to the challenge URL identified in the returned ACME authorization object <t indent="0" pn="section-4-6">The ACME client responds to the challenge b
, an example of which follows.</t> y posting the TNAuthList Authority Token to the challenge URL identified in the
returned ACME authorization object, an example of which follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="" markers="false" pn="section-4-7">
POST /acme/chall/prV_B7yEyA4 HTTP/1.1 POST /acme/chall/prV_B7yEyA4 HTTP/1.1
Host: boulder.example.com Host: boulder.example.com
Content-Type: application/jose+json Content-Type: application/jose+json
{ {
"protected": base64url({ "protected": base64url({
"alg": "ES256", "alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg", "kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw", "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://boulder.example.com/acme/authz/asdf/0" "url": "https://boulder.example.com/acme/authz/asdf/0"
}), }),
"payload": base64url({ "payload": base64url({
"tkauth": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" "tkauth": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"
}), }),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
} }
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-4-8">The "tkauth" field is defined as a new fiel
<t>The "tkauth" field is defined as a new field in the challenge object specific d in the challenge object specific to the tkauth-01 challenge type that should c
to the tkauth-01 challenge type that should contain the TNAuthList Authority To ontain the TNAuthList Authority Token defined in the next section.</t>
ken defined in the next section.</t> </section>
<section anchor="tnauthlist-authority-token" numbered="true" removeInRFC="fa
</section> lse" toc="include" pn="section-5">
<section anchor="tnauthlist-authority-token"><name>TNAuthList Authority Token</n <name slugifiedName="name-tnauthlist-authority-token">TNAuthList Authority
ame> Token</name>
<t indent="0" pn="section-5-1">The TNAuthList Authority Token is a profile
<t>The Telephone Number Authority List Authority Token (TNAuthList Authority Tok instance of the ACME Authority Token defined in <xref target="RFC9447" format="
en) is a profile instance of the ACME Authority Token defined in <xref target="I default" sectionFormat="of" derivedContent="RFC9447"/>.</t>
-D.ietf-acme-authority-token"/>.</t> <t indent="0" pn="section-5-2">The TNAuthList Authority Token protected he
ader <bcp14>MUST</bcp14> comply with "Request Authentication" (<xref target="RFC
<t>The TNAuthList Authority Token Protected header MUST comply with the Authorit 8555" section="6.2" sectionFormat="of" format="default" derivedLink="https://rfc
y Token Protected header as defined in <xref target="I-D.ietf-acme-authority-tok -editor.org/rfc/rfc8555#section-6.2" derivedContent="RFC8555"/>).</t>
en"/>.</t> <t indent="0" pn="section-5-3">The TNAuthList Authority Token Payload <bcp
14>MUST</bcp14> include the mandatory claims "exp", "jti", and "atc" and <bcp14>
<t>The TNAuthList Authority Token Payload MUST include the mandatory claims "exp MAY</bcp14> include the optional claims defined for the Authority Token detailed
", "jti", and "atc", and MAY include the optional claims defined for the Authori in the next subsections.</t>
ty Token detailed in the next subsections.</t> <section anchor="iss-claim" numbered="true" removeInRFC="false" toc="inclu
de" pn="section-5.1">
<section anchor="iss-claim"><name>"iss" claim</name> <name slugifiedName="name-iss-claim">"iss" Claim</name>
<t indent="0" pn="section-5.1-1">The "iss" claim is an optional claim de
<t>The "iss" claim is an optional claim defined in <xref target="RFC7519"/> Sect fined in <xref target="RFC7519" section="4.1.1" sectionFormat="comma" format="de
ion 4.1.1. It can be used as a URL identifying the Token Authority that issued fault" derivedLink="https://rfc-editor.org/rfc/rfc7519#section-4.1.1" derivedCon
the TNAuthList Authority Token beyond the "x5u" or other Header claims that iden tent="RFC7519"/>. It can be used as a URL identifying the Token Authority that
tify the location of the certificate or certificate chain of the Token Authority issued the TNAuthList Authority Token beyond the "x5u" or other header claims th
used to validate the TNAuthList Authority Token.</t> at identify the location of the certificate or certificate chain of the Token Au
thority used to validate the TNAuthList Authority Token.</t>
</section> </section>
<section anchor="exp-claim"><name>"exp" claim</name> <section anchor="exp-claim" numbered="true" removeInRFC="false" toc="inclu
de" pn="section-5.2">
<t>The "exp" claim, defined in <xref target="RFC7519"/> Section 4.1.4, MUST be i <name slugifiedName="name-exp-claim">"exp" Claim</name>
ncluded and contains the DateTime value of the ending date and time that the TNA <t indent="0" pn="section-5.2-1">The "exp" claim, defined in <xref targe
uthList Authority Token expires.</t> t="RFC7519" section="4.1.4" sectionFormat="comma" format="default" derivedLink="
https://rfc-editor.org/rfc/rfc7519#section-4.1.4" derivedContent="RFC7519"/>, <b
</section> cp14>MUST</bcp14> be included and contains the DateTime value of the ending date
<section anchor="jti-claim"><name>"jti" claim</name> and time that the TNAuthList Authority Token expires.</t>
</section>
<t>The "jti" claim, defined in <xref target="RFC7519"/> Section 4.1.7, MUST be i <section anchor="jti-claim" numbered="true" removeInRFC="false" toc="inclu
ncluded and contains a unique identifier for this TNAuthList Authority Token tra de" pn="section-5.3">
nsaction.</t> <name slugifiedName="name-jti-claim">"jti" Claim</name>
<t indent="0" pn="section-5.3-1">The "jti" claim, defined in <xref targe
</section> t="RFC7519" section="4.1.7" sectionFormat="comma" format="default" derivedLink="
<section anchor="atc-claim"><name>"atc" claim</name> https://rfc-editor.org/rfc/rfc7519#section-4.1.7" derivedContent="RFC7519"/>, <b
cp14>MUST</bcp14> be included and contains a unique identifier for this TNAuthLi
<t>The "atc" claim MUST be included and is defined in <xref target="I-D.ietf-acm st Authority Token transaction.</t>
e-authority-token"/>. It contains a JSON object with the following elements:</t </section>
> <section anchor="atc-claim" numbered="true" removeInRFC="false" toc="inclu
de" pn="section-5.4">
<t><list style="symbols"> <name slugifiedName="name-atc-claim">"atc" Claim</name>
<t>a "tktype" key with a string value equal to "TNAuthList" to represent a TNA <t indent="0" pn="section-5.4-1">The "atc" claim <bcp14>MUST</bcp14> be
uthList profile of the authority token <xref target="I-D.ietf-acme-authority-tok included and is defined in <xref target="RFC9447" format="default" sectionFormat
en"/> defined by this document. "tktype" is a required key and MUST be included. ="of" derivedContent="RFC9447"/>. It contains a JSON object with the following
</t> elements:</t>
<t>a "tkvalue" key with a string value equal to the base64url encoding of the <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
TN Authorization List certificate extension ASN.1 object using DER encoding rule .4-2">
s. "tkvalue" is a required key and MUST be included.</t> <li pn="section-5.4-2.1">a "tktype" key with a string value equal to "
<t>a "ca" key with a boolean value set to either true when the requested certi TNAuthList" to represent a TNAuthList profile of the Authority Token <xref targe
ficate is allowed to be a CA cert for delegation uses or false when the requeste t="RFC9447" format="default" sectionFormat="of" derivedContent="RFC9447"/> defin
d certificate is not intended to be a CA cert, only an end-entity certificate. " ed by this document. "tktype" is a required key and <bcp14>MUST</bcp14> be inclu
ca" is an optional key, if not included the "ca" value is considered false by de ded.</li>
fault.</t> <li pn="section-5.4-2.2">a "tkvalue" key with a string value equal to
<t>a "fingerprint" key is constructed as defined in <xref target="RFC8555"/> S the base64url encoding of the TNAuthList certificate extension ASN.1 object usin
ection 8.1 corresponding to the computation of the "Thumbprint" step using the A g DER encoding rules. "tkvalue" is a required key and <bcp14>MUST</bcp14> be inc
CME account key credentials. "fingerprint" is a required key and MUST be include luded.</li>
d.</t> <li pn="section-5.4-2.3">a "ca" key with a boolean value set to either
</list></t> true when the requested certificate is allowed to be a CA cert for delegation u
ses or false when the requested certificate is not intended to be a CA cert, onl
<t>An example of the TNAuthList Authority Token is as follows:</t> y an end-entity certificate. "ca" is an optional key; if not included, the "ca"
value is considered false by default.</li>
<figure><artwork><![CDATA[ <li pn="section-5.4-2.4">a "fingerprint" key constructed as defined in
<xref target="RFC8555" section="8.1" sectionFormat="comma" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc8555#section-8.1" derivedContent="RFC855
5"/>, corresponding to the computation of the "Thumbprint" step using the ACME a
ccount key credentials. "fingerprint" is a required key and <bcp14>MUST</bcp14>
be included.</li>
</ul>
<t indent="0" pn="section-5.4-3">An example of the TNAuthList Authority
Token is as follows:</t>
<sourcecode type="" markers="false" pn="section-5.4-4">
{ {
"protected": base64url({ "protected": base64url({
"typ":"JWT", "typ":"JWT",
"alg":"ES256", "alg":"ES256",
"x5u":"https://authority.example.org/cert" "x5u":"https://authority.example.org/cert"
}), }),
"payload": base64url({ "payload": base64url({
"iss":"https://authority.example.org", "iss":"https://authority.example.org",
"exp":1640995200, "exp":1640995200,
"jti":"id6098364921", "jti":"id6098364921",
"atc":{"tktype":"TNAuthList", "atc":{"tktype":"TNAuthList",
"tkvalue":"F83n2a...avn27DN3", "tkvalue":"F83n2a...avn27DN3",
"ca":false, "ca":false,
"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71: "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"} D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}
}), }),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
} }
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="acquiring-the-token-from-the-token-authority" numbered="t
<section anchor="acquiring-the-token-from-the-token-authority"><name>Acquiring t rue" removeInRFC="false" toc="include" pn="section-5.5">
he token from the Token Authority</name> <name slugifiedName="name-acquiring-the-token-from-th">Acquiring the Tok
en from the Token Authority</name>
<t>Following <xref target="I-D.ietf-acme-authority-token"/> Section 5, the autho <t indent="0" pn="section-5.5-1">Following <xref target="RFC9447" sectio
rity token should be acquired using a RESTful HTTP POST transaction as follows:< n="5" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org
/t> /rfc/rfc9447#section-5" derivedContent="RFC9447"/>, the Authority Token should b
e acquired using a RESTful HTTP POST transaction as follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="" markers="false" pn="section-5.5-2">
POST /at/account/:id/token HTTP/1.1 POST /at/account/:id/token HTTP/1.1
Host: authority.example.org Host: authority.example.org
Content-Type: application/json Content-Type: application/json
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-5.5-3">The request will pass the account ident
<t>The request will pass the account id as a string in the request parameter "id ifier as a string in the request parameter "id". This string will be managed as
". This string will be managed as an identifier specific to the Token Authority an identifier specific to the Token Authority's relationship with a Communicati
's relationship with a communications service provider (CSP). There is assumed t ons Service Provider (CSP). There is assumed to also be a corresponding authenti
o also be a corresponding authentication procedure that can be verified for the cation procedure that can be verified for the success of this transaction, for e
success of this transaction. For example, an HTTP authorization header containin xample, an HTTP authorization header containing valid authorization credentials,
g a valid authorization credentials as defined in <xref target="RFC7231"/> Secti as defined in <xref target="RFC9110" section="11.6.2" sectionFormat="comma" for
on 14.8.</t> mat="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11.6.2" de
rivedContent="RFC9110"/>.</t>
<t>The body of the POST request MUST contain a JSON object with key value pairs <t indent="0" pn="section-5.5-4">The body of the POST request <bcp14>MUS
corresponding to values that are requested as the content of the claims in the i T</bcp14> contain a JSON object with key value pairs corresponding to values tha
ssued token. As an example, the body SHOULD contain a JSON object as follows:</t t are requested as the content of the claims in the issued token. As an example,
> the body <bcp14>SHOULD</bcp14> contain a JSON object as follows:</t>
<sourcecode type="" markers="false" pn="section-5.5-5">
<figure><artwork><![CDATA[
{ {
"tktype":"TNAuthList", "tktype":"TNAuthList",
"tkvalue":"F83n2a...avn27DN3", "tkvalue":"F83n2a...avn27DN3",
"ca":false, "ca":false,
"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3 "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" :BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"
} }
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-5.5-6">If successful, the response to the POST
<t>The response to the POST request if successful returns a 200 OK with a JSON b request returns a 200 (OK) with a JSON body that contains, at a minimum, the TN
ody that contains, at a minimum, the TNAuthList Authority Token as a JSON object AuthList Authority Token as a JSON object with a key of "token" and the base64ur
with a key of "token" and the base64url encoded string representing the atc tok l-encoded string representing the atc token. JSON is easily extensible, so users
en. JSON is easily extensible, so users of this specification may want to pass o of this specification may want to pass other pieces of information relevant to
ther pieces of information relevant to a specific application.</t> a specific application.</t>
<t indent="0" pn="section-5.5-7">An example of a successful response wou
<t>An example successful response would be as follows:</t> ld be as follows:</t>
<sourcecode type="" markers="false" pn="section-5.5-8">
<figure><artwork><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
{"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"} {"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"}
]]></artwork></figure> </sourcecode>
<t indent="0" pn="section-5.5-9">If the request is not successful, the r
<t>If the request is not successful, the response should indicate the error cond esponse should indicate the error condition. Specifically, for the case that th
ition. Specifically, for the case that the authorization credentials are invali e authorization credentials are invalid or if the account identifier provided do
d or if the Account ID provided does not exist, the response code MUST be 403 - es not exist, the response code <bcp14>MUST</bcp14> be 403 (Forbidden). Other 4x
Forbidden. Other 4xx and 5xx responses MUST follow standard <xref target="RFC723 x and 5xx responses <bcp14>MUST</bcp14> follow standard HTTP error condition con
1"/> HTTP error condition conventions.</t> ventions <xref target="RFC9110" format="default" sectionFormat="of" derivedConte
nt="RFC9110"/>.</t>
</section> </section>
<section anchor="token-authority-responsibilities"><name>Token Authority Respons <section anchor="token-authority-responsibilities" numbered="true" removeI
ibilities</name> nRFC="false" toc="include" pn="section-5.6">
<name slugifiedName="name-token-authority-responsibil">Token Authority R
<t>When creating the TNAuthList Authority Token, the Token Authority MUST valida esponsibilities</name>
te that the information contained in the ASN.1 TNAuthList accurately represents <t indent="0" pn="section-5.6-1">When creating the TNAuthList Authority
the service provider code (SPC) or telephone number (TN) resources the requestin Token, the Token Authority <bcp14>MUST</bcp14> validate that the information con
g party is authorized to represent based on their pre-established and verified s tained in the ASN.1 TNAuthList accurately represents the service provider code (
ecure relationship between the Token Authority and the requesting party. Note th SPC) or telephone number (TN) resources the requesting party is authorized to re
at the fingerprint in the token request is not meant to be verified by the Token present based on their pre-established, verified, and secure relationship betwee
Authority, but rather is meant to be signed as part of the token so that the pa n the Token Authority and the requesting party. Note that the fingerprint in the
rty that requests the token can, as part of the challenge response, allow the AC token request is not meant to be verified by the Token Authority but rather is
ME server to validate the token requested and used came from the same party that meant to be signed as part of the token so that the party that requests the toke
controls the ACME client.</t> n can, as part of the challenge response, allow the ACME server to validate that
the token requested and used came from the same party that controls the ACME cl
</section> ient.</t>
<section anchor="scope-of-the-tnauthlist"><name>Scope of the TNAuthList</name> </section>
<section anchor="scope-of-the-tnauthlist" numbered="true" removeInRFC="fal
<t>Because this specification specifically involves the TNAuthList defined in <x se" toc="include" pn="section-5.7">
ref target="RFC8226"/> which involves SPC, TNBlock, and individual TNs, the clie <name slugifiedName="name-scope-of-the-tnauthlist">Scope of the TNAuthLi
nt may also request an Authority Token with some subset of its own authority as st</name>
the TNAuthList provided in the "tkvalue" element in the "atc" JSON object. Gener <t indent="0" pn="section-5.7-1">Because this specification specifically
ally, the scope of authority representing a communications service provider is r involves the TNAuthList defined in <xref target="RFC8226" format="default" sect
epresented by a particular SPC (e.g. in North America, an operating company numb ionFormat="of" derivedContent="RFC8226"/>, which involves SPC, telephone number
er (OCN) or service provider identifier (SPID)). That provider is also generally ranges, and individual telephone numbers, the client may also request an Authori
associated, based on number allocations, with a particular set of different TN ty Token with some subset of its own authority as the TNAuthList provided in the
Blocks and/or TNs. TNAuthList can be constructed to define a limited scope of th "tkvalue" element in the "atc" JSON object. Generally, the scope of authority r
e TNBlocks or TNs either associated with an SPC or with the scope of TN Blocks o epresenting a CSP is represented by a particular SPC (e.g., in North America, an
r TNs the client has authority over.</t> operating company number (OCN) or service provider identifier (SPID)). Based on
number allocations, that provider is also generally associated
<t>As recommended in <xref target="I-D.ietf-acme-authority-token"/> security con with a particular set of different telephone number ranges and/or telepho
siderations, an Authority Token can either have a scope that attests all of the ne numbers. The TNAuthList can be constructed to define a limited scope of the
resources which a client is eligible to receive certificates for, or potentially TelephoneNumberRanges or TelephoneNumbers (<xref target="RFC8226" sectionFormat=
a more limited scope that is intended to capture only those resources for which "comma" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc
a client will receive a certificate from a particular certification authority. 8226#section-9" derivedContent="RFC8226"/>) either associated with an SPC or wit
Any certification authority that sees an Authority Token can learn information h the scope of telephone number ranges or telephone numbers the client has autho
about the resources a client can claim. In cases where this incurs a privacy ri rity over.</t>
sk, Authority Token scopes should be limited to only the resources that will be <t indent="0" pn="section-5.7-2">As recommended in the Security Consider
attested by the requested ACME certificate.</t> ations section in <xref target="RFC9447" format="default" sectionFormat="of" der
ivedContent="RFC9447"/>, an Authority Token can either have a scope that attests
</section> all of the resources that a client is eligible to receive certificates for or p
</section> otentially a more limited scope that is intended to capture only those resources
<section anchor="validating-the-tnauthlist-authority-token"><name>Validating the for which a client will receive a certificate from a particular certification a
TNAuthList Authority Token</name> uthority. Any certification authority that sees an Authority Token can learn in
formation about the resources a client can claim. In cases where this incurs a
<t>Upon receiving a response to the challenge, the ACME server MUST perform the privacy risk, Authority Token scopes should be limited to only the resources tha
following steps to determine the validity of the response.</t> t will be attested by the requested ACME certificate.</t>
</section>
<t><list style="symbols"> </section>
<t>Verify that the value of the "atc" claim is a well-formed JSON object conta <section anchor="validating-the-tnauthlist-authority-token" numbered="true"
ining the mandatory key values.</t> removeInRFC="false" toc="include" pn="section-6">
<t>If there is an "x5u" parameter verify the "x5u" parameter is a HTTPS URL wi <name slugifiedName="name-validating-the-tnauthlist-a">Validating the TNAu
th a reference to a certificate representing the trusted issuer of authority tok thList Authority Token</name>
ens for the eco-system.</t> <t indent="0" pn="section-6-1">Upon receiving a response to the challenge,
<t>If there is an "x5c" parameter verify the certificate array contains a cert the ACME server <bcp14>MUST</bcp14> perform the following steps to determine th
ificate representing the trusted issuer of authority tokens for the eco-system.< e validity of the response.</t>
/t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6-2"
<t>Verify the TNAuthList Authority Token signature using the public key of the >
certificate referenced by the token's "x5u" or "x5c" parameter.</t> <li pn="section-6-2.1" derivedCounter="1.">Verify that the value of the
<t>Verify that "atc" claim contains a "tktype" identifier with the value "TNAu "atc" claim is a well-formed JSON object containing the mandatory key values.</l
thList".</t> i>
<t>Verify that the "atc" claim "tkvalue" identifier contains the equivalent ba <li pn="section-6-2.2" derivedCounter="2.">If there is an "x5u" paramete
se64url encoded TNAuthList certificate extension string value as the Identifier r, verify the "x5u" parameter is an HTTPS URL with a reference to a certificate
specified in the original challenge.</t> representing the trusted issuer of Authority Tokens for the ecosystem.</li>
<t>Verify that the remaining claims are valid (e.g., verify that token has not <li pn="section-6-2.3" derivedCounter="3.">If there is an "x5c" paramete
expired)</t> r, verify the certificate array contains a certificate representing the trusted
<t>Verify that the "atc" claim "fingerprint" is valid and matches the account issuer of Authority Tokens for the ecosystem.</li>
key of the client making the request</t> <li pn="section-6-2.4" derivedCounter="4.">Verify the TNAuthList Authori
<t>Verify that the "atc" claim "ca" identifier boolean corresponds to the CA b ty Token signature using the public key of the certificate referenced by the tok
oolean in the Basic Constraints extension in the CSR for either CA certificate o en's "x5u" or "x5c" parameter.</li>
r end-entity certificate</t> <li pn="section-6-2.5" derivedCounter="5.">Verify that "atc" claim conta
</list></t> ins a "tktype" identifier with the value "TNAuthList".</li>
<li pn="section-6-2.6" derivedCounter="6.">Verify that the "atc" claim "
<t>If all steps in the token validation process pass, then the ACME server MUST tkvalue" identifier contains the equivalent base64url-encoded TNAuthList certifi
set the challenge object "status" to "valid". If any step of the validation proc cate extension string value as the identifier specified in the original challeng
ess fails, the "status" in the challenge object MUST be set to "invalid".</t> e.</li>
<li pn="section-6-2.7" derivedCounter="7.">Verify that the remaining cla
</section> ims are valid (e.g., verify that token has not expired).</li>
<section anchor="using-acme-issued-certificates-with-json-web-signature"><name>U <li pn="section-6-2.8" derivedCounter="8.">Verify that the "atc" claim "
sing ACME-issued Certificates with JSON Web Signature</name> fingerprint" is valid and matches the account key of the client making the reque
st.</li>
<t>JSON Web Signature (JWS, <xref target="RFC7515"/>) objects can include an "x5 <li pn="section-6-2.9" derivedCounter="9.">Verify that the "atc" claim "
u" header parameter to refer to a certificate that is used to validate the JWS s ca" identifier boolean corresponds to the CA boolean in the Basic Constraints ex
ignature. For example, the STIR PASSporT framework <xref target="RFC8225"/> use tension in the Certificate Signing Request (CSR) for either CA certificate or en
s "x5u" to indicate the STIR certificate used to validate the PASSporT JWS objec d-entity certificate.</li>
t. The URLs used in "x5u" are expected to provide the required certificate in r </ol>
esponse to a GET request, not a POST-as-GET as required for the "certificate" UR <t indent="0" pn="section-6-3">If all steps in the token validation proces
L in the ACME order object. Thus the current mechanism generally requires the A s pass, then the ACME server <bcp14>MUST</bcp14> set the challenge object "statu
CME client to download the certificate and host it on a public URL to make it ac s" to "valid". If any step of the validation process fails, the "status" in the
cessible to relying parties. This section defines an optional mechanism for the challenge object <bcp14>MUST</bcp14> be set to "invalid".</t>
Certificate Authority (CA) to host the certificate directly and provide a URL t </section>
hat the ACME client owner can directly reference in the "x5u" of their signed PA <section anchor="using-acme-issued-certificates-with-json-web-signature" num
SSporTs.</t> bered="true" removeInRFC="false" toc="include" pn="section-7">
<name slugifiedName="name-using-acme-issued-certifica">Using ACME-Issued C
<t>As described in Section 7.4 of <xref target="RFC8555"/> when the certificate ertificates with JSON Web Signature</name>
is ready for making a finalize request, the server will return a 200 (OK) with t <t indent="0" pn="section-7-1">JSON Web Signature (JWS) <xref target="RFC7
he updated order object. In this response, an ACME Server can add a newly defin 515" format="default" sectionFormat="of" derivedContent="RFC7515"/> objects can
ed field called "x5u" that can pass this URL to the ACME client for usage in gen include an "x5u" header parameter to refer to a certificate that is used to vali
erated PASSporTs as a publically available URL for PASSporT validation.</t> date the JWS signature. For example, the STIR PASSporT framework <xref target="
RFC8225" format="default" sectionFormat="of" derivedContent="RFC8225"/> uses "x5
<dl> u" to indicate the STIR certificate used to validate the PASSporT JWS object. T
<dt>x5u (optional, string):</dt> he URLs used in "x5u" are expected to provide the required certificate in respon
<dd> se to a GET request, not a POST-as-GET, as required for the "certificate" URL in
<t>A URL that can be used to reference the certificate in the "x5u" paramete the ACME order object. Thus, the current mechanism generally requires the ACME
r of a JWS object <xref target="RFC7515"/></t> client to download the certificate and host it on a public URL to make it acces
</dd> sible to relying parties. This section defines an optional mechanism for the ce
</dl> rtification authority (CA) to host the certificate directly and provide a URL th
at the ACME client owner can directly reference in the "x5u" of their signed PAS
<t>The publishing of the certificates at the new "x5u" URL should follow the GET SporTs.</t>
request requirement as mentioned above and should be consistent with the timely <t indent="0" pn="section-7-2">As described in <xref target="RFC8555" sect
publication according to the durations of the certificate lifecycle.</t> ion="7.4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.or
g/rfc/rfc8555#section-7.4" derivedContent="RFC8555"/>, when the certificate is r
<t>The following is an example of the use of "x5u" in the response when the cert eady for making a "finalize" request, the server will return a 200 (OK) with the
ificate status is "valid".</t> updated order object. In this response, an ACME server can add a newly defined
field called "x5u" that can pass this URL to the ACME client for usage in gener
<figure><artwork><![CDATA[ ated PASSporTs as a publicly available URL for PASSporT validation.</t>
<dl indent="3" newline="false" spacing="normal" pn="section-7-3">
<dt pn="section-7-3.1">x5u (optional, string):</dt>
<dd pn="section-7-3.2">
<t indent="0" pn="section-7-3.2.1">a URL that can be used to reference
the certificate in the "x5u" parameter of a JWS object <xref target="RFC7515" f
ormat="default" sectionFormat="of" derivedContent="RFC7515"/></t>
</dd>
</dl>
<t indent="0" pn="section-7-4">The publishing of the certificates at the n
ew "x5u" URL should follow the GET request requirement as mentioned above and sh
ould be consistent with the timely publication according to the durations of the
certificate life cycle.</t>
<t indent="0" pn="section-7-5">The following is an example of the use of "
x5u" in the response when the certificate status is "valid".</t>
<sourcecode type="" markers="false" pn="section-7-6">
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: <https://example.com/acme/directory&gt;;rel="index" Link: <https://example.com/acme/directory&gt;;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo Location: https://example.com/acme/order/TOlocE8rfgo
{ {
"status": "valid", "status": "valid",
"expires": "2016-01-20T14:09:07.99Z", "expires": "2016-01-20T14:09:07.99Z",
"notBefore": "2016-01-01T00:00:00Z", "notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z", "notAfter": "2016-01-08T00:00:00Z",
"identifiers": [ "identifiers": [
skipping to change at line 395 skipping to change at line 461
], ],
"authorizations": ["https://sti-ca.com/acme/authz/1234"], "authorizations": ["https://sti-ca.com/acme/authz/1234"],
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize", "finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
"certificate": "https://example.com/acme/cert/mAt3xBGaobw", "certificate": "https://example.com/acme/cert/mAt3xBGaobw",
"x5u": "https://example.com/cert-repo/giJI53km23.pem" "x5u": "https://example.com/cert-repo/giJI53km23.pem"
} }
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="usage-considerations" numbered="true" removeInRFC="false" t
<section anchor="usage-considerations"><name>Usage Considerations</name> oc="include" pn="section-8">
<name slugifiedName="name-usage-considerations">Usage Considerations</name
<section anchor="large-number-of-non-contiguous-tnauthlist-values"><name>Large n >
umber of Non-contiguous TNAuthList values</name> <section anchor="large-number-of-non-contiguous-tnauthlist-values" numbere
d="true" removeInRFC="false" toc="include" pn="section-8.1">
<t>There are many scenarios and reasons to have various combinations of SPCs, TN <name slugifiedName="name-large-number-of-noncontiguo">Large Number of N
s, and TN Ranges. <xref target="RFC8226"/> has provided a somewhat unbounded se oncontiguous TNAuthList Values</name>
t of combinations. It's possible that a complex non-contiguous set of telephone <t indent="0" pn="section-8.1-1">There are many scenarios and reasons to
numbers are being managed by a CSP. Best practice may be simply to split a set have various combinations of SPCs, TNs, and TN ranges. <xref target="RFC8226"
of non-contiguous numbers under management into multiple STI certificates to re format="default" sectionFormat="of" derivedContent="RFC8226"/> has provided a so
present the various contiguous parts of the greater non-contiguous set of TNs, p mewhat unbounded set of combinations. It's possible that a complex noncontiguou
articularly if length of the set of values in identifier object grows to be too s set of telephone numbers are being managed by a CSP. Best practice may be sim
large.</t> ply to split a set of noncontiguous numbers under management into multiple STI c
ertificates to represent the various contiguous parts of the greater noncontiguo
</section> us set of TNs, particularly if the length of the set of values in an identifier
</section> object grows to be too large.</t>
<section anchor="security_considerations"><name>Security Considerations</name> </section>
</section>
<t>The token represented by this document has the credentials to represent the s <section anchor="iana-considerations" numbered="true" removeInRFC="false" to
cope of a telephone number, a block of telephone numbers, or an entire set of te c="include" pn="section-9">
lephone numbers represented by an SPC. The creation, transport, and any storage <name slugifiedName="name-iana-considerations">IANA Considerations</name>
of this token MUST follow the strictest of security best practices beyond the re <t indent="0" pn="section-9-1">Per this document, IANA has added a new ide
commendations of the use of encrypted transport protocols in this document to pr ntifier object type to the "ACME Identifier Types" registry defined in <xref tar
otect it from getting in the hands of bad actors with illegitimate intent to imp get="RFC8555" section="9.7.7" sectionFormat="of" format="default" derivedLink="h
ersonate telephone numbers.</t> ttps://rfc-editor.org/rfc/rfc8555#section-9.7.7" derivedContent="RFC8555"/>.</t>
<table align="center" pn="table-1">
<t>This document inherits the security properties of <xref target="I-D.ietf-acme <thead>
-authority-token"/>. Implementations should follow the best practices identified <tr>
in <xref target="RFC8725"/>.</t> <th align="left" colspan="1" rowspan="1">Label</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
<t>This document only specifies SHA256 for the fingerprint hash. However, the sy </tr>
ntax of the fingerprint object would permit other algorithms if, due to concerns </thead>
about algorithmic agility, a more robust algorithm were required at a future ti <tbody>
me. Future specifications can define new algorithms for the fingerprint object <tr>
as needed.</t> <td align="left" colspan="1" rowspan="1">TNAuthList</td>
<td align="left" colspan="1" rowspan="1">RFC 9448</td>
</section> </tr>
<section anchor="iana-considerations"><name>IANA Considerations</name> </tbody>
</table>
<t>This document requests the addition of a new identifier object type to the "A </section>
CME Identifier Types" registry defined in Section 9.7.7 of <xref target="RFC8555 <section anchor="security_considerations" numbered="true" removeInRFC="false
"/>.</t> " toc="include" pn="section-10">
<name slugifiedName="name-security-considerations">Security Considerations
<figure><artwork><![CDATA[ </name>
+------------+-----------+ <t indent="0" pn="section-10-1">The token represented by this document has
| Label | Reference | the credentials to represent the scope of a telephone number, a block of teleph
+------------+-----------+ one numbers, or an entire set of telephone numbers represented by an SPC. The cr
| TNAuthList | RFCThis | eation, transport, and any storage of this token <bcp14>MUST</bcp14> follow the
+------------+-----------+ strictest of security best practices beyond the recommendations of the use of en
]]></artwork></figure> crypted transport protocols in this document to protect it from getting in the h
ands of bad actors with illegitimate intent to impersonate telephone numbers.</t
</section> >
<section anchor="acknowledgements"><name>Acknowledgements</name> <t indent="0" pn="section-10-2">This document inherits the security proper
ties of <xref target="RFC9447" format="default" sectionFormat="of" derivedConten
<t>We would like to thank Richard Barnes and Russ Housley for valuable contribut t="RFC9447"/>. Implementations should follow the best practices identified in <x
ions to this document.</t> ref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725
"/>.</t>
</section> <t indent="0" pn="section-10-3">This document only specifies SHA256 for th
e fingerprint hash. However, the syntax of the fingerprint object would permit o
ther algorithms if, due to concerns about algorithmic agility, a more robust alg
orithm were required at a future time. Future specifications can define new alg
orithms for the fingerprint object as needed.</t>
</section>
</middle> </middle>
<back> <back>
<references pn="section-11">
<references title='Normative References'> <name slugifiedName="name-references">References</name>
<references pn="section-11.1">
<reference anchor='I-D.ietf-acme-authority-token'> <name slugifiedName="name-normative-references">Normative References</na
<front> me>
<title>ACME Challenges Using an Authority Token</title> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<author fullname='Jon Peterson' initials='J.' surname='Peterson'> 119" quoteTitle="true" derivedAnchor="RFC2119">
<organization>Neustar, Inc.</organization> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often cap
italized. This document defines these words as they should be interpreted in IET
F documents. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
648" quoteTitle="true" derivedAnchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/>
<abstract>
<t indent="0">This document describes the commonly used base 64, b
ase 32, and base 16 encoding schemes. It also discusses the use of line-feeds in
encoded data, use of padding in encoded data, use of non-alphabet characters in
encoded data, use of different encoding alphabets, and canonical encodings. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7
515" quoteTitle="true" derivedAnchor="RFC7515">
<front>
<title>JSON Web Signature (JWS)</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 Signature (JWS) represents content secured
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="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="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="RFC9060" target="https://www.rfc-editor.org/info/rfc9
060" quoteTitle="true" derivedAnchor="RFC9060">
<front>
<title>Secure Telephone Identity Revisited (STIR) Certificate Delega
tion</title>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<date month="September" year="2021"/>
<abstract>
<t indent="0">The Secure Telephone Identity Revisited (STIR) certi
ficate profile provides a way to attest authority over telephone numbers and rel
ated identifiers for the purpose of preventing telephone number spoofing. This s
pecification details how that authority can be delegated from a parent certifica
te to a subordinate certificate. This supports a number of use cases, including
those where service providers grant credentials to enterprises or other customer
s capable of signing calls with STIR.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9060"/>
<seriesInfo name="DOI" value="10.17487/RFC9060"/>
</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="RFC9447" target="https://www.rfc-editor.org/info/rfc9
447" quoteTitle="true" derivedAnchor="RFC9447">
<front>
<title>Automated Certificate Management Environment (ACME) Challenge
s Using an Authority Token</title>
<author initials="J" surname="Peterson" fullname="Jon Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Barnes" fullname="Mary Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Hancock" fullname="David Hancock">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Wendt" fullname="Chris Wendt">
<organization showOnFrontPage="true"/>
</author>
<date year="2023" month="September"/>
</front>
<seriesInfo name="RFC" value="9447"/>
<seriesInfo name="DOI" value="10.17487/RFC9447"/>
</reference>
</references>
<references pn="section-11.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="ATIS-1000080" target="https://access.atis.org/apps/gr
oup_public/download.php/69428/ATIS-1000080.v005.pdf" quoteTitle="true" derivedAn
chor="ATIS-1000080">
<front>
<title>Signature-based Handling of Asserted information using toKENs
(SHAKEN): Governance Model and Certificate Management</title>
<author>
<organization showOnFrontPage="true">ATIS</organization>
</author>
<date year="2022" month="December"/>
</front>
<refcontent>ATIS-1000080.v005</refcontent>
</reference>
<reference anchor="RFC7340" target="https://www.rfc-editor.org/info/rfc7
340" quoteTitle="true" derivedAnchor="RFC7340">
<front>
<title>Secure Telephone Identity Problem Statement and Requirements<
/title>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="September" year="2014"/>
<abstract>
<t indent="0">Over the past decade, Voice over IP (VoIP) systems b
ased on SIP have replaced many traditional telephony deployments. Interworking V
oIP systems with the traditional telephone network has reduced the overall level
of calling party number and Caller ID assurances by granting attackers new and
inexpensive tools to impersonate or obscure calling party numbers when orchestra
ting bulk commercial calling schemes, hacking voicemail boxes, or even circumven
ting multi-factor authentication systems trusted by banks. Despite previous atte
mpts to provide a secure assurance of the origin of SIP communications, we still
lack effective standards for identifying the calling party in a VoIP session. T
his document examines the reasons why providing identity for telephone numbers o
n the Internet has proven so difficult and shows how changes in the last decade
may provide us with new strategies for attaching a secure identity to SIP sessio
ns. It also gives high-level requirements for a solution in this space.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7340"/>
<seriesInfo name="DOI" value="10.17487/RFC7340"/>
</reference>
<reference anchor="RFC8224" target="https://www.rfc-editor.org/info/rfc8
224" quoteTitle="true" derivedAnchor="RFC8224">
<front>
<title>Authenticated Identity Management in the Session Initiation P
rotocol (SIP)</title>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="C. Jennings" initials="C." surname="Jennings"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="C. Wendt" initials="C." surname="Wendt"/>
<date month="February" year="2018"/>
<abstract>
<t indent="0">The baseline security mechanisms in the Session Init
iation Protocol (SIP) are inadequate for cryptographically assuring the identity
of the end users that originate SIP requests, especially in an interdomain cont
ext. This document defines a mechanism for securely identifying originators of S
IP requests. It does so by defining a SIP header field for conveying a signature
used for validating the identity and for conveying a reference to the credentia
ls of the signer.</t>
<t indent="0">This document obsoletes RFC 4474.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8224"/>
<seriesInfo name="DOI" value="10.17487/RFC8224"/>
</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"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<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 signed
to protect the integrity of the identity of the originator and to verify the as
sertion of the identity information at the destination. The cryptographic signat
ure is defined with the intention that it can confidently verify the originating
persona even when the signature is sent to the destination party over an insecu
re channel. PASSporT is particularly useful for many personal-communications app
lications over IP networks and other multi-hop interconnection scenarios where t
he originating and destination parties may not have a direct trusted relationshi
p.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8225"/>
<seriesInfo name="DOI" value="10.17487/RFC8225"/>
</reference>
</references>
</references>
<section anchor="acknowledgements" numbered="false" removeInRFC="false" toc=
"include" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.a-1">We would like to thank <contact fu
llname="Richard Barnes"/> and <contact fullname="Russ Housley"/> for valuable co
ntributions to this document.</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="C." surname="Wendt" fullname="Chris Wendt">
<organization showOnFrontPage="true">Somos Inc.</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>chris-ietf@chriswendt.net</email>
</address>
</author> </author>
<author fullname='Mary Barnes' initials='M.' surname='Barnes'> <author initials="D." surname="Hancock" fullname="David Hancock">
<organization>Neustar, Inc.</organization> <organization showOnFrontPage="true">Somos Inc.</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>davidhancock.ietf@gmail.com</email>
</address>
</author> </author>
<author fullname='David Hancock' initials='D.' surname='Hancock'> <author initials="M." surname="Barnes" fullname="Mary Barnes">
<organization>Comcast</organization> <organization showOnFrontPage="true">Neustar Inc.</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>mary.ietf.barnes@gmail.com</email>
</address>
</author> </author>
<author fullname='Chris Wendt' initials='C.' surname='Wendt'> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization>Somos</organization> <organization showOnFrontPage="true">Neustar Inc.</organization>
<address>
<postal>
<extaddr>Suite 570</extaddr>
<street>1800 Sutter St</street>
<city>Concord</city>
<region>CA</region>
<code>94520</code>
<country>United States of America</country>
</postal>
<email>jon.peterson@neustar.biz</email>
</address>
</author> </author>
<date day='24' month='October' year='2022'/> </section>
<abstract>
<t> Some proposed extensions to the Automated Certificate Management
Environment (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
Authority Token challenge for ACME which supports subtype claims for
different identifiers or namespaces that can be defined separately
for specific applications.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-acme-authority-token-09'/
>
<format target='https://www.ietf.org/archive/id/draft-ietf-acme-authority-tok
en-09.txt' type='TXT'/>
</reference>
<reference anchor='RFC4648' target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/
></author>
<date month='October' year='2006'/>
<abstract><t>This document describes the commonly used base 64, base 32, and bas
e 16 encoding schemes. It also discusses the use of line-feeds in encoded data,
use of padding in encoded data, use of non-alphabet characters in encoded data,
use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK
]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor='RFC7231' target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author fullname='R. Fielding' initials='R.' role='editor' surname='Fielding'><o
rganization/></author>
<author fullname='J. Reschke' initials='J.' role='editor' surname='Reschke'><org
anization/></author>
<date month='June' year='2014'/>
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application
- level protocol for distributed, collaborative, hypertext information systems.
This document defines the semantics of HTTP/1.1 messages, as expressed by reque
st methods, request header fields, response status codes, and response header fi
elds, along with the payload of messages (metadata and body content) and mechani
sms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>
<reference anchor='RFC7515' target='https://www.rfc-editor.org/info/rfc7515'>
<front>
<title>JSON Web Signature (JWS)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho
r>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></a
uthor>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/><
/author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Signature (JWS) represents content secured with digital si
gnatures or Message Authentication Codes (MACs) using JSON-based data structures
. Cryptographic algorithms and identifiers for use with this specification are
described in the separate JSON Web Algorithms (JWA) specification and an IANA re
gistry defined by that specification. Related encryption capabilities are descr
ibed 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/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho
r>
<author fullname='J. Bradley' initials='J.' surname='Bradley'><organization/></a
uthor>
<author fullname='N. Sakimura' initials='N.' surname='Sakimura'><organization/><
/author>
<date month='May' year='2015'/>
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing c
laims 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) structu
re or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the cl
aims 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='RFC8226' target='https://www.rfc-editor.org/info/rfc8226'>
<front>
<title>Secure Telephone Identity Credentials: Certificates</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='S. Turner' initials='S.' surname='Turner'><organization/></aut
hor>
<date month='February' year='2018'/>
<abstract><t>In order to prevent the impersonation of telephone numbers on the I
nternet, some kind of credential system needs to exist that cryptographically as
serts authority over telephone numbers. This document describes the use of cert
ificates in establishing authority over telephone numbers, as a component of a b
roader architecture for managing telephone numbers as identities in protocols li
ke SIP.</t></abstract>
</front>
<seriesInfo name='RFC' value='8226'/>
<seriesInfo name='DOI' value='10.17487/RFC8226'/>
</reference>
<reference anchor='RFC8555' target='https://www.rfc-editor.org/info/rfc8555'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author fullname='R. Barnes' initials='R.' surname='Barnes'><organization/></aut
hor>
<author fullname='J. Hoffman-Andrews' initials='J.' surname='Hoffman-Andrews'><o
rganization/></author>
<author fullname='D. McCarney' initials='D.' surname='McCarney'><organization/><
/author>
<author fullname='J. Kasten' initials='J.' surname='Kasten'><organization/></aut
hor>
<date month='March' year='2019'/>
<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used
for a number of purposes, the most significant of which is the authentication of
domain names. Thus, certification authorities (CAs) in the Web PKI are trusted
to verify that an applicant for a certificate legitimately represents the domai
n name(s) in the certificate. As of this writing, this verification is done thr
ough a collection of ad hoc mechanisms. This document describes a protocol that
a CA and an applicant can use to automate the process of verification and certi
ficate issuance. The protocol also provides facilities for other certificate ma
nagement 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/rfc8725'>
<front>
<title>JSON Web Token Best Current Practices</title>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></a
uthor>
<author fullname='D. Hardt' initials='D.' surname='Hardt'><organization/></autho
r>
<author fullname='M. Jones' initials='M.' surname='Jones'><organization/></autho
r>
<date month='February' year='2020'/>
<abstract><t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based securi
ty 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 format in numerou
s protocols and applications, both in the area of digital identity and in other
application areas. This Best Current Practices document updates RFC 7519 to pro
vide actionable guidance leading to secure implementation and deployment 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='RFC9060' target='https://www.rfc-editor.org/info/rfc9060'>
<front>
<title>Secure Telephone Identity Revisited (STIR) Certificate Delegation</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<date month='September' year='2021'/>
<abstract><t>The Secure Telephone Identity Revisited (STIR) certificate profile
provides a way to attest authority over telephone numbers and related identifier
s for the purpose of preventing telephone number spoofing. This specification de
tails how that authority can be delegated from a parent certificate to a subordi
nate certificate. This supports a number of use cases, including those where ser
vice providers grant credentials to enterprises or other customers capable of si
gning calls with STIR.</t></abstract>
</front>
<seriesInfo name='RFC' value='9060'/>
<seriesInfo name='DOI' value='10.17487/RFC9060'/>
</reference>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a
uthor>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="ATIS-1000080" >
<front>
<title>Signature-based Handling of Asserted information using toKENs (SHAKEN
) Governance Model and Certificate Management &lt;https://access.atis.org/apps/g
roup_public/download.php/32237/ATIS-1000080.pdf&gt;</title>
<author >
<organization>ATIS/SIP Forum NNI Task Group</organization>
</author>
<date year="2017" month="July"/>
</front>
</reference>
<reference anchor='RFC7340' target='https://www.rfc-editor.org/info/rfc7340'>
<front>
<title>Secure Telephone Identity Problem Statement and Requirements</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organizat
ion/></author>
<author fullname='H. Tschofenig' initials='H.' surname='Tschofenig'><organizatio
n/></author>
<date month='September' year='2014'/>
<abstract><t>Over the past decade, Voice over IP (VoIP) systems based on SIP hav
e replaced many traditional telephony deployments. Interworking VoIP systems wi
th the traditional telephone network has reduced the overall level of calling pa
rty number and Caller ID assurances by granting attackers new and inexpensive to
ols to impersonate or obscure calling party numbers when orchestrating bulk comm
ercial calling schemes, hacking voicemail boxes, or even circumventing multi-fac
tor authentication systems trusted by banks. Despite previous attempts to provi
de a secure assurance of the origin of SIP communications, we still lack effecti
ve standards for identifying the calling party in a VoIP session. This document
examines the reasons why providing identity for telephone numbers on the Intern
et has proven so difficult and shows how changes in the last decade may provide
us with new strategies for attaching a secure identity to SIP sessions. It also
gives high-level requirements for a solution in this space.</t></abstract>
</front>
<seriesInfo name='RFC' value='7340'/>
<seriesInfo name='DOI' value='10.17487/RFC7340'/>
</reference>
<reference anchor='RFC8224' target='https://www.rfc-editor.org/info/rfc8224'>
<front>
<title>Authenticated Identity Management in the Session Initiation Protocol (SIP
)</title>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/><
/author>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/><
/author>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho
r>
<date month='February' year='2018'/>
<abstract><t>The baseline security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of the end use
rs that originate SIP requests, especially in an interdomain context. This docu
ment defines a mechanism for securely identifying originators of SIP requests.
It does so by defining a SIP header field for conveying a signature used for val
idating the identity and for conveying a reference to the credentials of the sig
ner.</t><t>This document obsoletes RFC 4474.</t></abstract>
</front>
<seriesInfo name='RFC' value='8224'/>
<seriesInfo name='DOI' value='10.17487/RFC8224'/>
</reference>
<reference anchor='RFC8225' target='https://www.rfc-editor.org/info/rfc8225'>
<front>
<title>PASSporT: Personal Assertion Token</title>
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho
r>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/><
/author>
<date month='February' year='2018'/>
<abstract><t>This document defines a method for creating and validating a token
that cryptographically verifies an originating identity or, more generally, a UR
I or telephone number representing the originator of personal communications. T
he Personal Assertion Token, PASSporT, is cryptographically signed to protect th
e integrity of the identity of the originator and to verify the assertion of the
identity information at the destination. The cryptographic signature is define
d with the intention that it can confidently verify the originating persona even
when the signature is sent to the destination party over an insecure channel.
PASSporT is particularly useful for many personal-communications applications ov
er IP networks and other multi-hop interconnection scenarios where the originati
ng and destination parties may not have a direct trusted relationship.</t></abst
ract>
</front>
<seriesInfo name='RFC' value='8225'/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/>
</reference>
</references>
</back> </back>
<!-- ##markdown-source:
H4sIAMF8jmMAA7U823bbyJHv/IpezkOshKRISrIk7G5OKEq2ZVsXi7Q9Mzk5
c5pAk2wLBBg0IJp2nJMP2f25fMlWVXcDjQslTzKrM4lBoC/V1XWv6u52u61U
pqHw2PR6lKXLt1KlbJ3EcxkKFs/ZaHx1wfBDnMh0y6bxvYhafDZLxIOnPzr9
8ME0CWI/4isYNkj4PO1Kkc673F+JLrdjdVNs2E0jfBNC9+5g2PJ5KhZxsvWY
SoNWS64Tj6VJptJhv3/aH7Z4Ijh8E37rXmw3cRJ4DEctfk2ml3etlkp5FPzC
wzgCCLZCtdbSY39OY7/DVJykiZgreNqu8OEvrZaGyWuxbovBn4yUx8Y99lFE
QUpv9FLGy0Qq522cLGDCeBUrdhn5PXonVlyGHvOxKa36T/S4wU69SOiOfpxF
KS7y/aQ053mPveKRH/v3zqzn/EEGpfc07zhe+Vyl7qQBtlzqhj2ae4Efen68
enTaqx4740kEaCpmveLJ1n1Lc14L2Ame1Fa7gsY0YW9GPZ6cl6Z93WO3IhWJ
iqNWPu/rOCq9bZzXTPspjnpr0/ZPkW7Tm8kv2ETBJovUY4OTfp9NshRasUkK
TzIV7Oi4j218oEJEJCAsCTpsPGLs9PBoqL85MLeiOFnxVD4IIBF22T3v7SRn
bHD3Ynz4/PDEPB4PDwb28WhwVDyemseT4fC5fTw6sg1Ojof28bT/vO+1ZDR3
oRhNLyfdQR/+TvoeYdmw8UQuIp5miejOuBJEOEEoowUxs1IiSeFlPhhgO1P4
NY3fXFwr9mzyagQPe+xl/CCSCGhJsKs4ECGDYdgYesu5RCYFAon4QqxElLL/
WqbpWnn7+9z3hVI9GFf1YOP2+Xqt9hdJnK1/WWezUPr7QbyJwpgHvfVyvX8w
HB4c77sr6a2D+R9pNTlLMkN9PJJfCGCP1r4/ubxlL+IkW7Hr60s25eqevcSZ
qEcAEHps2B8cd/vHBuMHh/0C44fFI6C51e12GZ8BzXA/bbWmS2BzEGAZrS4Q
cwk0zbgrFtOlQGkXAw7FTrxcRA8yiSN6foaycq8qSRlsA43F87EQz4aovsBP
HwQebRNM6hfTKOr5IQYkTEUo1kuQdOw2iUEAADvAbjKVrdcg6thE+EAMeast
uwwAHoTgGcjKPbv9AIMjyPWaAzbbokAtTdxraXStZBCEotX6AbgyTeIg8xHM
VuvrV0PI374xiVhbCR9kklQrAtksFOd0RgUJkmMN1orQwKhAgCLtscuUiYjP
QtyDYCVhKNgn5ANGC5GC1gubg2/mc+HTNz9GsEKGdMwSoeIsAeJkobwXsLcg
QCKSOKAHDMYJ/4rmhrGQkBHnCxGJRMOL7aRSWQV21WNfvz4qFAAT4nMKGkBp
jWmgha0C9OgJQkAT9AlwSt3W7ko+VokycppwUWCXzPP1sgfJ4We6lEnA1jzJ
6a6gw5nYxjAwTlWQMQ5eNHk2Hu31qmwhXY7I3xbUVKX0ggwsccEOPIk42v3S
VOmSpyDe18InUMMQEBMEsGBlNg8tAGwNBLMCNQA7RJARXaIQgN3YLKW/ZJIY
YS5Nv0gATEiilvKQ96gJD5We1ucR46BKgEOKbbEsDL8WEkQv/IR9IdZE8BSu
E/QLUCFsUQDqyocVrdaktQjTHQuPYsCqCcyIa4oM0Sc0AajSVUyTc/8e0KFU
7EuSFxsJNpcMQ7EAIoJVxzgpbEKHPcTSJ03JltCJXiEJqQ2MAr96jE2XQonS
MsG+gj2EYVGCgCZht6PJBOTIVGkEorz89s1CjPiYwQA8SaTeUL3/gH2wtWIY
T2XQjCuG0toOcIjbysZ2qR2NvQgWbSnDhUijF3CzzpJ1DOAiiNijJA0NPViq
MmoVtrpJvNHKm0Q8NoPVWwFfsWxdapZaSBE7A10D+qOFMIxtelsK0aLKGRbZ
FGZV9Wk6MK4fZsT7HCR38gA7mIt1M/Wzye14D7bSEfzX2Womkg5D+QrGcUoj
518j+qrwa/Ulm4VgK6oacwPikVaVn8iZwQufydCSO3cGKhgBVp8rLr1QR3eB
cZVu10I16jGwL4B8qSnQSkk+GPsHSAZVzVQkoADiMF5sEWTBjN2vWPvq/WTa
7uh/2fUNPd9dvHt/eXdxjs9g2Lx9mz/YFpNXN+/fnhdPRc/xzdXVxfW57gxv
WeXV1eintmao9s3t9PLmevS2rcmihMiEqAKYRKJUWSeCdLzKkUvLPBvfssEh
rPY/YLnDweAUCFf/OBkcH5LAEpGejPhE/wQUg5xYrwVYxjAIECFw4hoILkSl
BjyxBGOLLUUiCHdEq5HYdLUwyqVfovegoMJW69LyEKnxDtoQtDnHJU4hLRlk
iZHJIAs0O4RSawKtlPRsHGcuafx5Eq/g9XjUQzHkAJaIv2YoYZFNQEsrHLgA
lsH/hYGe0TK9BsdpE88+AcTKiGUcFCx8UBHrGHVwGucCAH1Tx8BDGJFKkUhr
w5E0h/1y5cjIlRFOjxz2AjBgENfq1kSxjtdZyLVFbmSBFTVGxdPIRlBUUNhD
+7cqqAogOrZPBa9axNB6aa0oLwAabAyGFYqedjFeW+/OAw+zJrHoLJn4blYa
DpQdaJ8GOWdhEUFPs7HGi21owKA9TgTwjCJxWRnDTgi4hg5gfgIWtbRHx+f5
YZaEoEL9ONCaDxQIQOlap/VmZa60VH+EcFFHdOugI7g5gFLtNVlOINukpIVe
T26u2UcxKzwyd9BhPih6hagREQ8NIFl5ZvcN2GELplxAH0H1oMuCPMyNEecq
rcl1b2Cpl8ahUXM8nV/cFfMkWUjG/QgMj898tdZ+jmVqTUJmqH/+438c6fHP
f/yvYUpD9Vp7OXC4bL+JM2gZxvE9bsk8DsN4ozqt1t+dvxZrO+O3Pfbnr20k
1bbnUmanTVQJL1+cHERD3uv1+EM0PD6/Pmh/+0t5wNYGxSDhx/SyazG0ViEz
nswkOBnJlqFiBwOrsjGAQt0REcbmGYjeOqN911Jvb2Bb9tH43S9GeDWd3u4P
eoPWq1ilnt0PiqeMtfHQnQI+PJT+obHX9z+BcfSHT4p8MHBu22iECeQKQGAO
/rOv5B+3ebiA1+2LyfDoebuj391LbNq2zrwzq4YPyD7dFw838zfL6/fP+5uF
7RjFkS+w69GPrwdvD8KL+6uXx+nd8/Wo3/fDkW0G0z86fr7+NrT/ttehRfAt
hgualvCrSQQIJCePHPL0TIDwIeiH/eGg28f/pv2+R//9XCwxHc2Bz0rtTpx2
BcjKsju2ffX85x/Tl5+mP2/fR7fiDcKwuRgdTu/Ds2B5IA6PDhft1rcKsd5E
QEO+kA+ak2ANMqjTV6ewQBVYiqh10N4SpDArfiLReqck/XKd3hv0Djsu75Lp
Vti0KIULW1cr91UG9K0wzjPfardmRVIYObzuGbmmRiEiZ9tcqel1PbPWkw9b
3dmtava0rASLEqSgcm3t0nLZ+7u3VkC3Sw1U2wgso29c4aatLDDTsiRSta92
PBcXRnPP4mBLEhPDTuAy014Ee0ybHQptsNIuWx6n5qb1Y9yNjH0n1iHfdq+R
3zx29dMoe7hZ8/hSbjdT8UV+uT962LTexr6Jk+3kNFrS/mB4cGhkBbrJGbJR
e61DD0T3bfF5LQF+Q/TDGtGDMGtgomEjE1VZqGm0Klc3M7WJCTp/j2oCDWSF
AEBg4DCPCDto/4VQhKxN8qINZiKw4hfxqBQrcLuft69x+A8uZV8WRlTJ9qsI
gqo1p8mqU6NHEA6JtYkTMQe9B9RSixzl5BzPkO/LTK8aWNdKiMJWrWu83Okw
LbTOQ+CtSZG3JCZr5gxHJRa7UOhE3PC6XsS336UbseFXQ0KP6shdetLVlbtZ
bJeyLCvM7N168im8mx0+vPsw/vThp9F2+/5jqelTSrNMp/in1ZBeXq492/mY
Zf0UZZPzy8ns48uT1dXi4vgVsM677Yf3b5+fbL/MD37mm7XS41YpeJcs67Ob
N0+JsbcyuveKrEFtTSpeiW4AksdP42T7x/9MRPjfbRkF4nP7t5BXBU1DQ2NM
oJhpkDKPCBZU+Hq8gm2sWCkITIsv+PceNwoAKvbBvLIteOo73yg1mmtSlwLy
lz2LtzgpKOZJeiFg99fJh1/OjrcX29FhZVLsfBnKZP75zZsfR+pVuvryZnh6
++lkZOkApGFNnn1cishGzbXR4tr81gUvvIOSR49aGB3REvopNGCCCA3RZMc+
Mf66g2IdE+VlFFMbRPJ3xZ1RMoJJJdG8sQaQkV24AFfeLkHqYX9cj9+YwnEz
Ec5AInDyErkDUlhGLj60B2685WLxNULBID9fYU4Uw8kULKJwLqwZrSrFCkeI
ItROQFCkmzi5J+CQiXRGYISIMHuloarkD3o6klKKXYOm1/oEZsw1iU4sAubd
fB8guhwTAtgJikWefuywWQYGJ8dMhV4LoCeGEZOiueqxyzlt+KPoMBgmlRnV
9ObV6CeK0hLqawPpCEgVGWhi5juXB5orGRYioI0EH9FmfZ4ILlvFaK3NfL9p
mc3wlRaKG/DEYjEa8Ni+Mp09BlMhjHWWBch4LhegN8rpY9heasHWMUh5KZQh
Unc2J/RW8S5gL9exSusx+hpSal0R97kUyY0SbbnDb5q/2Q3ipRCHTmUY97xk
i7iWSE1uVp30GXr7Iun91s563QT5Fx31wup494s6uPoY/3XaP5omwf3V8Gp6
7m90o4r+aFiVa3dwFcz3+9/hrxtRjEOfv9zeiU+rMZimxw+H16BTH2bD01fL
T5/e3k4Wi4282OVMn/qzxdHrm8HL+dFPbz99+gJdJ+v793M/uOXyNPvw00/v
yqa2pkQ7t3H6ZJFh4Dboa75UzOA8RmSSjZYGc01TVUM6Kr2kuI9Rd0+RtZPs
0Db15xTLm5BIehU/oVqFRYurJoGcVo3zPds94F450SojrKLyi3KHhkqwX5fL
NRDvRsat5QK2FDywQWWguTUmPVCpN9kCtV7VHNK/D5emaiM1TRwWQVmBqseM
L0jHkMuVIhMUs0OfUmmzQ2TY0SNqGLd3vMZtBtFpOlugrcqsIxvj6VViyWaG
XlB4/fAD2LdKtfWQhv6LF7TDUWXiWsINi5OcCNFhD6Rcj2Em3iR8SQ0T8zhC
ePuo/sPCCVGPUFdW6BQjtD8fZW3ULlrXv9JbazClh3TVV2iiHnmStWR/ln4C
08q8XRVYm/ymoBu2fhxig3Lc9RLKixed70HvYSdPZxgC0VZkKY90DuBM5aqS
jTGlIgQr5QCwRW6zPoJr4yyZFSDBllZQvPiuFRw/tQLOskiC3VvK5dnc/mN6
P+GR4rlA/MEY8S6oxYtmGOSvlAea1AvAKZNjdEEuhZzYRkgVJsprtX6vvQ7t
cNyLrfVETJZBbxwY2MB6QGMlAx9+55ZkOX1SKTtzE+6IoKd9Gaeaq5Sd7hWw
kuQ3pn9AkJPAqmCzZxdocihPrjBtzmnlCcGmZKfLqlQKpagayc1l7UxfObD9
qhX5vLSYWRyHAkSdXo3JaApJgihN4NXG2tSFK+eCjXMjdWhRMhPamcUW1XIH
cnDh1ZyH6nuGRcseKwmioD52R/t7VDkUdE3OuZQvpnVWVAAsu8Pk3IxsuIYE
MDbWGEDvDvQLFqGgeiJYZ1Suw7MwNTgEGltghQOAp5FpetncbENlRyUVcQI7
XCTqnfwqWgBZWpLv7ekS7B0zG2Bq7ZaekenvUwkvQeLUE/UqgH4vmVTyok+V
Bykn5eeVfIqnc3PAkW2v/frj1AahyAMo5+pQOXqPx4T2ceu/M5UGBsITo9mJ
UbF5g+eH/dPTo2G/b96isvDaMnjePz05eH54OhzksINs9r5aOdMYyM95tinM
ljcCavSI8vI37j56WNYD+GFHz72DC2/8whtdeCcH3njkHZ57gyPvrO8NT70X
L7zBmXc8sHXF7PzAOxt5Z6fe4NQ7GXgvTryjvnd65p2/8A5H3vmhd3DqHQ+9
i6F3Bl/72PLgxLs4aH/77XwU0GkjHwnQ0q+W61Qg02CitFovctXztOzPixg6
jcrDOCsoRnzDA5mJ4N1dTKbzLCQ/l5En7KjineTNmHGa033DgfueDPb1bE4M
XzvNjaTWejSSjz5z1cPLM+4UZOHKJAWNBJDGVjUqSpZErBM4Afpt28og05YG
nNnyZD1OKXZZdQ0re/U7DOyFOue0lGurX7CaE6whvSRF6Vss9FvbQr9n48mt
znImWpmA8bzSAp8q80jqlyWlE4HE7anUZhm7nSKa0vEwVObbQmeyDFxji6qL
zLZQzIQIoRxRMQ5XqfBDp6vL7UolpnU9gGckHFodHPZOjFNms6oILBGW3Tbj
GWofu8FEQ0muldeay0TV9Qp9NJ4EVukVKpcrt0wzdyi052Gox7oz5AOwkXJi
Sp0iHWxqCpvB3MlBJJR3S8ynxWVFVv5bgvL8QIvKf1FMtlg9HlMNb5b2FSwR
Q5Qoe2wenpvMkmUgwiOhWJO3sdWBTNF2xjMCq2xVKyGoamneaNxzoh3KKFBC
JK+s2lUDVI8Ag9KzpEHDA2cJriQYZ8agnSGZACOD+ZcU3JcXtRMXYMh7wyOy
PUmmaUd4LYWvy2jdKCxIGfFgGvNCKjmSs2zClHBstmOTq4IdlPkr03ytr0VK
6TuCfmVCMYHunCy06VuA3TGfDexGj0lgb9967SJJqHIe3mmBxibOqYFOLgQp
TZF7zI8ILqrg0+INukoTFjNa5vLcyu8AHCyh4RWfpS3UyUFF0skNzMP+Aeui
pJ3JIEB6uaFNPvz8mcjuCP61HZXupHeG0QlHngQlAUoSurJsfHrAJeQBomrI
405PIKnAWwpl0nm6evvJwHynMYxCoDoxFINcl2Rr9QTaxXNmAgWeYUkR8E2l
Pq+mMQmpVBnfWOb+bHq95yTbKtk8fTBGKjdpV3LH81wIdJQJpla60JXPQqmW
JsaQq1alz1uV1P5MpBthXLsqpqx0qcLTY9exizpHiFuEpSZbVGKRlTBiwNX3
s8Ycj06tAYaXOm3kdkWjVutChMYqQWM0xgVYGnemVJcAUU5LsDs61TGKmHlR
w0LecuG7mXq2ahiutF6Dd4rX+WDBFfaywl8OXCb/qqpJMM0NEz9eN7h0rdaZ
8LnOB9ZEc+n0EYiEOHwQtfrkmrOrD6SYsz62E5BsB3qd4TkMHSVGGQZEjRGU
6bXqGONDl92BSiADsCijqSk10mFYQaEjw4R2iYdNNpF7lqwGbi68DHEVkRQT
38o/ULjNUZs99lKfYbNneZRFaTFfSUU+bQDLWkKc045KPwt5gkhjz0Rv0UOY
ruMEVjxaAa37vKNjG/bIHgYOsF7aioGb8TUJiPqEhUkPUuTyfI/Mb56WQCLU
L+xanUNYnUJCmJmQoM3qOtascBZg9iWQc6rPSjEURiRAddz7dBxD9Uo11Oao
lRNQobpLpDEYO5Qrie9UmZrNmHo8G8GqHh6DkRGh0CgPbubDFHCZMRxqtIUP
eocxYd9jYGTg1uH+6hjVdxVbkMykaJWJMlnMNdA3IsIsZMkfcO0aWG3I0+E8
ir5ZJBRSX3Mez+s2ASGhXKAtpqU9FtqJ2uEkOlW1jlNtBeC2s1UMAr6McZPj
KMXmfL6mqn+KysEilAsMGh8VgMjZtGDwpsMyDgX5pbOahR/N2Cja7vpqEpRC
1wg3YTYUPIlKaprP4iytYDIHGbuQY4Qx82qJCaEDNlYnFeUD90EOSAVirjoz
4VA5wQiLXKxP1NgTJfVtCyrQWKUtL3RcoR60qHfin5hP/aAVytN2Tav1fh2X
C7F31mXUS7HJ/gExhHispAswWKnsWVA8zqaVG2k6YqScbm115O/Zh0opUikD
5OY/KJy5EWHYxZkBCa57U6nxLpKXubOsMJarTW8TeYhMIq4Ik+RlUaL2iWZH
I3RCiUEj9/IiVO2cuHRd85zorg+hz1nr0rBKxKooTQUh01VbaL1qBtrfAbQ7
P08SvnVTPf8/wH0oZn/EHc3jiE4oW1+bYD3SKvhOea+hfgLjd6rInlYQ0asQ
k0s7DhqKvFChF3PloImvdEisgUTdkZ2szI4zchiAhybW2C672TuOEhXJoVLy
yZg2l7UgXWHbmKPaoVNZ1bCCBA9PE7eY2A86gNr9I+OjU64QpD1EnagdP0yu
BntPIaaaizDBMzADQfz6S1GOZLpkYC3Ce0sqRvA9NSOlgArc2FRX+YAkdRuP
8q8Gb2dcATGO9VEPic5YsQemyXhyR0xgVLRJTTmZ+ObcFDn8qLW1dCw5OMYH
yMOaSlE8pFrZ5kpeStktG0p5bOUwpV9p4LauHQSlSVkkg96GOed4llFL+nyU
XRVDlcOQbRM2wPAyKqH3yhaRdk0gcexaHcRp9eODrVbDkcJnrz9OOu5Bwr38
9KtPG2cPDRqRYCK2hWQk02euH8ryz9o0jSURMG0hsGBZpWAxNqBrGOztAU5l
p3ONgM5+ariwstIN3lB3F5pGKPLxERzrjdDpINA/Ki991VMg+wJfCms8u9WY
eQawlG8tl2Jy9vIiD1R2iM05BS+7XHXxE1fFOFYRtJ0B27pcxqFZ92wRAZ4Z
C1vX0jqXZhRuR6lA162yRJPCXK9TV3QgUcAChf2kC1a4VSzmjBSIEYGf9AU+
hUkcbm08Ags7bW7EhOnzc9NONrl82QsJBAeKQuPhlSI4BcFUBVaX/oc6NlLc
lEKwNp1Gg0WjPgE48p6FzWG9Vq0Q5yaEY8Ib+e0WPXJcGo//HvcO87O6JmGd
5+kr2fkEmEsfezNymTN7Bqh8as/IKmPxY4zbhLif3bzZKzRttg7ITauQyaU5
J+fET8wx3Yk5CIgnAINAFzc692qYY7r6HLvhO5seMmkzGNY5N+diGZeVKb4g
lJprcVwU6nC6pivtKD2AxMQrTGhE7J6zayFeAfEAB3tmKahjlPme1/LYqNhz
t/LMiixtU1a3wd3vQszRybxCSrgSU2clCHC1dMpTSp6gITssFtVDI2TGYTEh
WfzuSAjLqPoeCIyuURAW41YzvKqI7mLJPR7yfFWq/UCz/VjKBXg0KNXeWPXo
eZAZZ7nJPgzlXPhbPxT5MXvrhEg3Y2W7mjtK9PryNKnNDjTRvNaDOJpVpuWT
Qb86Z1A+4Th+OT8ZvP54pv568m57ubgdy9N3pz8+eX5ox9Gh7z4YOb0JY//i
JJkv4tp5I73M+mmjwXM8bTTsTweHXv/U6x/3Tk93HJDUTZ86IGlaPXZ8qThv
tPOY5OMHmHaejcxrQVQquz5vPG5mOv+KQ5EOXouzkeYMlaMlHz2+BO32V6P0
4PPZSx7PNqY7lcM0d8MeXXDl4v2FfH15dHC/Gh701mJVPZRJWSeyzVDEjUuB
KAoUv+XJIk8oAJsAjXbRh5GLLM5KJYzalSaWS/R9RSuyL30R8UTGypx+5ArZ
FpUgxrEe8FOGierVTEYFT09ux6qjI8HYbXrN7jieNQM94IaV0fHIQ7icAsAb
lJtZNAPXgZKVOubojk+VjuAtrmOr9CmIpiuuxWcwcUpL3HmzEC5xJlCu2EIJ
itiOJ7cwwxlVWeA1FRhxNQd5lKSabrxlCiRAWlxbVJnSzoBLSNxb4sD7ALMl
C1OJAqx6SV05faMNeovefGw0a3KxuaAT2MmOJRP6i+gbRv3n9moIe2mJbmnK
CmTUcIHMIok3yuRX0jhmIVIURaUmNgBapjv29QcbGv2lHBo1SstmRCpnx9wb
iJa2nMG9zKyKnSJiX9tdPIlHt0Q1br2+cyqia+gSsZtCqtF8Cjnrc/z2lqiO
rj7BSwvNnXzkk8UJ8mNeoEILdhOhBD6YDD5dywbt8mDyzCU85daW5wHqsuo0
+g/MimS7JifBAuTcaFa74kl7Evpat1RHaheCblizOhQs4oAmmYFlzlEzKefa
NglqXhsuqRmuuB1O1FFZv4gvAjEj88SoWTyAtBZktmvj9el79pDlcUCbk6nZ
NhV8ls9eaVl0jG5dDUIK4RaXNZkCFOsguIlNINZlj72KN+LBXmCktgDSZ7tF
bmNbtEFwrjGUmpoaCR4ucHVLrNeZd8BGEuZ6RJARGN+ikHbeCOskFnS5WccG
95N4hjdc5E3YRiSOk0hCcp6RA45GGvq/+lcpT6hdcJOjQcvRgatp9UVhEN5F
SFWnP7DL0fWopo7K+C0lXvFmIFsoqw831QWRPqxkrsYgG9+JlqFlptow6AIv
2ty6eUzrEp32jnvHFaeoVykD3PH3h67z5/74w+4+f4P/veUzEeofd7nt/7ff
eh5Hif+N7oclRP+L85RqPNnIv4/iDTheWoFhlUV+GxLeSUrbwaN7difxVqfA
XL5MkvAuA9/sFeijUGj3ErUMeVaU25azTJMbjeEW+OurWmfcv2/9Hy4x4Lbq
WwAA
</rfc> </rfc>
 End of changes. 36 change blocks. 
963 lines changed or deleted 1073 lines changed or added

This html diff was produced by rfcdiff 1.48.