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" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2.
6.0) -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-acme-authority-token-tnauthlist-13" c <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
ategory="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> -ietf-acme-authority-token-tnauthlist-13" number="9448" submissionType="IETF" ca
<front> tegory="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" u
<title abbrev="ACME TNAuthList Auth Token">TNAuthList profile of ACME Author pdates="" obsoletes="" xml:lang="en" version="3">
ity Token</title>
<!-- xml2rfc v2v3 conversion 3.16.0 -->
<front>
<title abbrev="ACME TNAuthList Authority Token">TNAuthList Profile of Automa
ted Certificate Management Environment (ACME) Authority Token</title>
<seriesInfo name="RFC" value="9448"/>
<author initials="C." surname="Wendt" fullname="Chris Wendt"> <author initials="C." surname="Wendt" fullname="Chris Wendt">
<organization>Somos Inc.</organization> <organization>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>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>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>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 year="2023" month="September"/>
<date year="2023"/>
<area>sec</area> <area>sec</area>
<workgroup>acme</workgroup>
<keyword>STIR</keyword> <keyword>STIR</keyword>
<abstract> <abstract>
<t>This document defines a profile of the Automated Certificate Management
<t>This document defines a profile of the Automated Certificate Management Envir Environment (ACME) Authority Token for the automated and authorized creation of
onment (ACME) Authority Token for the automated and authorized creation of certi certificates for Voice over IP (VoIP) telephone providers to support Secure Tel
ficates for VoIP Telephone Providers to support Secure Telephony Identity (STI) ephone Identity (STI) using the TNAuthList defined by STI certificates.</t>
using the TNAuthList defined by STI certificates.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC8555"/> describes a mechanism for automating certifica
<t><xref target="RFC8555"/> is a mechanism for automating certificate management te management on the Internet. It enables administrative entities to prove effec
on the Internet. It enables administrative entities to prove effective control tive control over resources like domain names, and it automates the process of g
over resources like domain names, and automates the process of generating and is enerating and issuing certificates. <xref target="RFC9447"/> extends ACME to pro
suing certificates. <xref target="I-D.ietf-acme-authority-token"/> extends ACME vide a general method of extending the authority and authorization of entities t
to provide a general method of extending the authority and authorization of enti o control a resource via a third party Token Authority beyond the certification
ties to control a resource via a third party Token Authority beyond the Certific authority (CA).</t>
ation Authority (CA).</t> <t>This document is a profile document using the Authority Token mechanism
defined in <xref target="RFC9447"/>. It is a profile that specifically address
<t>This document is a profile document using the Authority Token mechanism defin es the Secure Telephone Identity Revisited (STIR) problem statement described in
ed in <xref target="I-D.ietf-acme-authority-token"/>. It is a profile that spec <xref target="RFC7340"/>, which identifies the need for Internet credentials th
ifically addresses the STIR problem statement <xref target="RFC7340"/> which ide at can attest authority for the originator of VoIP calls in order to detect impe
ntifies the need for Internet credentials that can attest authority for the orig rsonation, which is currently an enabler for common attacks associated with ille
inator of VoIP calls in order to detect impersonation, which is currently an ena gal robocalling, voicemail hacking, and swatting. These credentials are used to
bler for common attacks associated with illegal robocalling, voicemail hacking, sign Personal Assertion Tokens (PASSporTs) <xref target="RFC8225"/>, which can
and swatting. These credentials are used to sign PASSporTs <xref target="RFC822 be carried in using protocols such as SIP <xref target="RFC8224"/>. Currently,
5"/>, which can be carried in using protocols such as SIP <xref target="RFC8224" the only defined credentials for this purpose are the certificates specified in
/>. Currently, the only defined credentials for this purpose are the certificat <xref target="RFC8226"/> using the TNAuthList. This document defines the use of
es specified in <xref target="RFC8226"/> using the TNAuthList. This document de the TNAuthList Authority Token in the ACME challenge to prove the authoritative
fines the use of the TNAuthList Authority Token in the ACME challenge to proof t use of the contents of the TNAuthList, including a Service Provider Code (SPC),
he authoritative use of the contents of the TNAuthList, including a Service Prov a telephone number, or a set of telephone numbers or telephone number blocks.</
ider Token (SPC), a Telephone Number, or a set of telephone numbers or telephone t>
number blocks.</t> <t>This document also describes the ability for a telephone authority to a
uthorize the creation of CA types of certificates for delegation, as defined in
<t>This document also describes the ability for a telephone authority to authori <xref target="RFC9060"/>.</t>
ze the creation of CA types of certificates for delegation as defined in <xref t </section>
arget="RFC9060"/>.</t> <section anchor="terminology">
<name>Requirements Language</name>
</section> <t>
<section anchor="terminology"><name>Terminology</name> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this do RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
cument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xr "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown be interpreted as
here.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section anchor="acme-new-order-identifiers-for-tnauthlist"><name>ACME new-order </section>
identifiers for TNAuthList</name> <section anchor="acme-new-order-identifiers-for-tnauthlist">
<name>ACME New-Order Identifiers for TNAuthList</name>
<t>In <xref target="RFC8555"/>, Section 7 defines the procedure that an ACME cli <t><xref target="RFC8555" section="7" sectionFormat="of" /> defines the pr
ent uses to order a new certificate from a CA. The new-order request contains an ocedure that an ACME client uses to order a new certificate from a CA. The new-o
identifier field that specifies the identifier objects the order corresponds to rder request contains an identifier field that specifies the identifier objects
. This draft defines a new type of identifier object called TNAuthList. A TNAut the order corresponds to. This document defines a new type of identifier object
hList identifier contains the identity information to be populated in the TN Aut called TNAuthList. A TNAuthList identifier contains the identity information to
horization List of the new certificate. For the TNAuthList identifier, the new-o be populated in the TNAuthList of the new certificate. For the TNAuthList ident
rder request includes a type set to the string "TNAuthList". The value of the TN ifier, the new-order request includes a type set to the string "TNAuthList". The
AuthList identifier MUST be set to the details of the TNAuthList requested.</t> value of the TNAuthList identifier <bcp14>MUST</bcp14> be set to the details of
the TNAuthList requested.</t>
<t>The format of the string that represents the TNAuthList MUST be constructed u <t>The string that represents the TNAuthList <bcp14>MUST</bcp14> be
sing base64url encoding, as per <xref target="RFC8555"/> base64url encoding desc constructed using base64url encoding, as described in
ribed in Section 5 of <xref target="RFC4648"/> according to the profile specifie <xref target="RFC4648" section="5" sectionFormat="of" /> and as defined in <x
d in JSON Web Signature in Section 2 of <xref target="RFC7515"/>. The base64url ref target="RFC7515" section="2" sectionFormat="of">JSON Web Signature</xref>.
encoding MUST NOT include any padding characters and the TNAuthList ASN.1 object The base64url encoding <bcp14>MUST NOT</bcp14> include any padding charact
MUST encoded using DER encoding rules.</t> ers, and the TNAuthList ASN.1 object <bcp14>MUST</bcp14> be encoded using DER en
coding rules.</t>
<t>An example of an ACME order object “identifiers” field containing a TNAuthLis <t>An example of an ACME order object "identifiers" field containing a TNA
t certificate would look as follows,</t> uthList certificate is as follows:</t>
<sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
"identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}] "identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}]
]]></artwork></figure> ]]></sourcecode>
<t>where the "value" object string represents the arbitrary length of the
<t>where the "value" object string represents the arbitrary length base64url enc base64url-encoded string.</t>
oded string.</t> <t>A full new-order request would look as follows:</t>
<sourcecode type=""><![CDATA[
<t>A full new-order request would look as follows,</t>
<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>On receiving a valid new-order request, the ACME server creates an auth
<t>On receiving a valid new-order request, the ACME server creates an authorizat orization object (<xref target="RFC8555" section="7.1.4" sectionFormat="comma" /
ion object, <xref target="RFC8555"/> Section 7.1.4, containing the challenge tha >), containing the challenge that the ACME client must satisfy to demonstrate au
t the ACME client must satisfy to demonstrate authority for the identifiers spec thority for the identifiers specified by the new order (in this case, the TNAuth
ified by the new order (in this case, the TNAuthList identifier). The CA adds th List identifier). The CA adds the authorization object URL to the "authorization
e authorization object URL to the "authorizations" field of the order object, an s" field of the order object and returns the order object to the ACME client in
d returns the order object to the ACME client in the body of a 201 (Created) res the body of a 201 (Created) response.</t>
ponse.</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
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">
<section anchor="tnauthlist-identifier-authorization"><name>TNAuthList Identifie <name>TNAuthList Identifier Authorization</name>
r Authorization</name> <t>On receiving the new-order response, the ACME client queries the refere
nced authorization object to obtain the challenges for the identifier contained
<t>On receiving the new-order response, the ACME client queries the referenced a in the new-order request, as shown in the following example request and response
uthorization object to obtain the challenges for the identifier contained in the .</t>
new-order request as shown in the following example request and response.</t> <sourcecode type=""><![CDATA[
<figure><artwork><![CDATA[
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=""><![CDATA[
<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>;rel="index" Link: <https://example.com/acme/some-directory>;rel="index"
{ {
"status": "pending", "status": "pending",
"expires": "2022-01-08T00:00:00Z", "expires": "2022-01-08T00:00:00Z",
"identifier": { "identifier": {
"type":"TNAuthList", "type":"TNAuthList",
skipping to change at line 193 skipping to change at line 180
"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>When processing a certificate order containing an identifier of type "T
<t>When processing a certificate order containing an identifier of type "TNAuthL NAuthList", a CA uses the Authority Token challenge type of "tkauth-01" with a "
ist", a CA uses the Authority Token challenge type of "tkauth-01" with a "tkauth tkauth-type" of "atc" in <xref target="RFC9447"/> to verify that the requesting
-type" of "atc" in <xref target="I-D.ietf-acme-authority-token"/> to verify that ACME client has authenticated and authorized control over the requested resource
the requesting ACME client has authenticated and authorized control over the re s represented by the "TNAuthList" value.</t>
quested resources represented by the "TNAuthList" value.</t> <t>The challenge "token-authority" parameter is only used in cases where t
he VoIP telephone network requires the CA to identify the Token Authority. This
<t>The challenge "token-authority" parameter is only used in cases where the VoI is currently not the case for the Signature-based Handling of Asserted informati
P telephone network requires the CA to identify the Token Authority. This is cur on using toKENs (SHAKEN) <xref target="ATIS-1000080"/> certificate framework gov
rently not the case for the SHAKEN <xref target="ATIS-1000080"/> certificate fra ernance but may be used by other frameworks. If a "token-authority" parameter is
mework governance, but may be used by other frameworks. If a "token-authority" p present, then the ACME client <bcp14>MAY</bcp14> use the "token-authority" valu
arameter is present, then the ACME client MAY use the "token-authority" value to e to identify the URL representing the Token Authority that will provide the TNA
identify the URL representing the Token Authority that will provide the TNAuthL uthList Authority Token response to the challenge. If the "token-authority" para
ist Authority Token response to the challenge. If the "token-authority" paramete meter is not present, then the ACME client <bcp14>MUST</bcp14> identify the Toke
r is not present, then the ACME client MUST identify the Token Authority based o n Authority based on locally configured information or local policies.</t>
n locally configured information or local policies.</t> <t>The ACME client responds to the challenge by posting the TNAuthList Aut
hority Token to the challenge URL identified in the returned ACME authorization
<t>The ACME client responds to the challenge by posting the TNAuthList Authority object, an example of which follows:</t>
Token to the challenge URL identified in the returned ACME authorization object <sourcecode type=""><![CDATA[
, an example of which follows.</t>
<figure><artwork><![CDATA[
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>The "tkauth" field is defined as a new field in the challenge object sp
<t>The "tkauth" field is defined as a new field in the challenge object specific ecific to the tkauth-01 challenge type that should contain the TNAuthList Author
to the tkauth-01 challenge type that should contain the TNAuthList Authority To ity Token defined in the next section.</t>
ken defined in the next section.</t> </section>
<section anchor="tnauthlist-authority-token">
</section> <name>TNAuthList Authority Token</name>
<section anchor="tnauthlist-authority-token"><name>TNAuthList Authority Token</n <t>The TNAuthList Authority Token is a profile instance of the ACME Author
ame> ity Token defined in <xref target="RFC9447"/>.</t>
<t>The TNAuthList Authority Token protected header <bcp14>MUST</bcp14> comply wi
<t>The Telephone Number Authority List Authority Token (TNAuthList Authority Tok th "Request Authentication" (<xref target="RFC8555" section="6.2" sectionFormat=
en) is a profile instance of the ACME Authority Token defined in <xref target="I "of"/>).</t>
-D.ietf-acme-authority-token"/>.</t> <t>The TNAuthList Authority Token Payload <bcp14>MUST</bcp14> include the
mandatory claims "exp", "jti", and "atc" and <bcp14>MAY</bcp14> include the opti
<t>The TNAuthList Authority Token Protected header MUST comply with the Authorit onal claims defined for the Authority Token detailed in the next subsections.</t
y Token Protected header as defined in <xref target="I-D.ietf-acme-authority-tok >
en"/>.</t> <section anchor="iss-claim">
<name>"iss" Claim</name>
<t>The TNAuthList Authority Token Payload MUST include the mandatory claims "exp <t>The "iss" claim is an optional claim defined in <xref target="RFC7519
", "jti", and "atc", and MAY include the optional claims defined for the Authori " section="4.1.1" sectionFormat="comma" />. It can be used as a URL identifying
ty Token detailed in the next subsections.</t> the Token Authority that issued the TNAuthList Authority Token beyond the "x5u"
or other header claims that identify the location of the certificate or certifi
<section anchor="iss-claim"><name>"iss" claim</name> cate chain of the Token Authority used to validate the TNAuthList Authority Toke
n.</t>
<t>The "iss" claim is an optional claim defined in <xref target="RFC7519"/> Sect </section>
ion 4.1.1. It can be used as a URL identifying the Token Authority that issued <section anchor="exp-claim">
the TNAuthList Authority Token beyond the "x5u" or other Header claims that iden <name>"exp" Claim</name>
tify the location of the certificate or certificate chain of the Token Authority <t>The "exp" claim, defined in <xref target="RFC7519" section="4.1.4" se
used to validate the TNAuthList Authority Token.</t> ctionFormat="comma" />, <bcp14>MUST</bcp14> be included and contains the DateTim
e value of the ending date and time that the TNAuthList Authority Token expires.
</section> </t>
<section anchor="exp-claim"><name>"exp" claim</name> </section>
<section anchor="jti-claim">
<t>The "exp" claim, defined in <xref target="RFC7519"/> Section 4.1.4, MUST be i <name>"jti" Claim</name>
ncluded and contains the DateTime value of the ending date and time that the TNA <t>The "jti" claim, defined in <xref target="RFC7519" section="4.1.7" se
uthList Authority Token expires.</t> ctionFormat="comma" />, <bcp14>MUST</bcp14> be included and contains a unique id
entifier for this TNAuthList Authority Token transaction.</t>
</section> </section>
<section anchor="jti-claim"><name>"jti" claim</name> <section anchor="atc-claim">
<name>"atc" Claim</name>
<t>The "jti" claim, defined in <xref target="RFC7519"/> Section 4.1.7, MUST be i <t>The "atc" claim <bcp14>MUST</bcp14> be included and is defined in <xr
ncluded and contains a unique identifier for this TNAuthList Authority Token tra ef target="RFC9447"/>. It contains a JSON object with the following elements:</
nsaction.</t> t>
<ul spacing="normal">
</section> <li>a "tktype" key with a string value equal to "TNAuthList" to repres
<section anchor="atc-claim"><name>"atc" claim</name> ent a TNAuthList profile of the Authority Token <xref target="RFC9447"/> defined
by this document. "tktype" is a required key and <bcp14>MUST</bcp14> be include
<t>The "atc" claim MUST be included and is defined in <xref target="I-D.ietf-acm d.</li>
e-authority-token"/>. It contains a JSON object with the following elements:</t <li>a "tkvalue" key with a string value equal to the base64url encodin
> g of the TNAuthList certificate extension ASN.1 object using DER encoding rules.
"tkvalue" is a required key and <bcp14>MUST</bcp14> be included.</li>
<t><list style="symbols"> <li>a "ca" key with a boolean value set to either true when the reques
<t>a "tktype" key with a string value equal to "TNAuthList" to represent a TNA ted certificate is allowed to be a CA cert for delegation uses or false when the
uthList profile of the authority token <xref target="I-D.ietf-acme-authority-tok requested certificate is not intended to be a CA cert, only an end-entity certi
en"/> defined by this document. "tktype" is a required key and MUST be included. ficate. "ca" is an optional key; if not included, the "ca" value is considered f
</t> alse by default.</li>
<t>a "tkvalue" key with a string value equal to the base64url encoding of the <li>a "fingerprint" key constructed as defined in <xref target="RFC855
TN Authorization List certificate extension ASN.1 object using DER encoding rule 5" section="8.1" sectionFormat="comma" />, corresponding to the computation of t
s. "tkvalue" is a required key and MUST be included.</t> he "Thumbprint" step using the ACME account key credentials. "fingerprint" is a
<t>a "ca" key with a boolean value set to either true when the requested certi required key and <bcp14>MUST</bcp14> be included.</li>
ficate is allowed to be a CA cert for delegation uses or false when the requeste </ul>
d certificate is not intended to be a CA cert, only an end-entity certificate. " <t>An example of the TNAuthList Authority Token is as follows:</t>
ca" is an optional key, if not included the "ca" value is considered false by de <sourcecode type=""><![CDATA[
fault.</t>
<t>a "fingerprint" key is constructed as defined in <xref target="RFC8555"/> S
ection 8.1 corresponding to the computation of the "Thumbprint" step using the A
CME account key credentials. "fingerprint" is a required key and MUST be include
d.</t>
</list></t>
<t>An example of the TNAuthList Authority Token is as follows:</t>
<figure><artwork><![CDATA[
{ {
"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">
<section anchor="acquiring-the-token-from-the-token-authority"><name>Acquiring t <name>Acquiring the Token from the Token Authority</name>
he token from the Token Authority</name> <t>Following <xref target="RFC9447" section="5" sectionFormat="comma" />
, the Authority Token should be acquired using a RESTful HTTP POST transaction a
<t>Following <xref target="I-D.ietf-acme-authority-token"/> Section 5, the autho s follows:</t>
rity token should be acquired using a RESTful HTTP POST transaction as follows:< <sourcecode type=""><![CDATA[
/t>
<figure><artwork><![CDATA[
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>The request will pass the account identifier as a string in the reque
<t>The request will pass the account id as a string in the request parameter "id st parameter "id". This string will be managed as an identifier specific to the
". This string will be managed as an identifier specific to the Token Authority Token Authority's relationship with a Communications Service Provider (CSP). Th
's relationship with a communications service provider (CSP). There is assumed t ere is assumed to also be a corresponding authentication procedure that can be v
o also be a corresponding authentication procedure that can be verified for the erified for the success of this transaction, for example, an HTTP authorization
success of this transaction. For example, an HTTP authorization header containin header containing valid authorization credentials, as defined in <xref target="R
g a valid authorization credentials as defined in <xref target="RFC7231"/> Secti FC9110" section="11.6.2" sectionFormat="comma" />.</t>
on 14.8.</t> <t>The body of the POST request <bcp14>MUST</bcp14> contain a JSON objec
t with key value pairs corresponding to values that are requested as the content
<t>The body of the POST request MUST contain a JSON object with key value pairs of the claims in the issued token. As an example, the body <bcp14>SHOULD</bcp14
corresponding to values that are requested as the content of the claims in the i > contain a JSON object as follows:</t>
ssued token. As an example, the body SHOULD contain a JSON object as follows:</t <sourcecode type=""><![CDATA[
>
<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>If successful, the response to the POST request returns a 200 (OK) wi
<t>The response to the POST request if successful returns a 200 OK with a JSON b th a JSON body that contains, at a minimum, the TNAuthList Authority Token as a
ody that contains, at a minimum, the TNAuthList Authority Token as a JSON object JSON object with a key of "token" and the base64url-encoded string representing
with a key of "token" and the base64url encoded string representing the atc tok the atc token. JSON is easily extensible, so users of this specification may wan
en. JSON is easily extensible, so users of this specification may want to pass o t to pass other pieces of information relevant to a specific application.</t>
ther pieces of information relevant to a specific application.</t> <t>An example of a successful response would be as follows:</t>
<sourcecode type=""><![CDATA[
<t>An example successful response would be as follows:</t>
<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>If the request is not successful, the response should indicate the er
<t>If the request is not successful, the response should indicate the error cond ror condition. Specifically, for the case that the authorization credentials ar
ition. Specifically, for the case that the authorization credentials are invali e invalid or if the account identifier provided does not exist, the response cod
d or if the Account ID provided does not exist, the response code MUST be 403 - e <bcp14>MUST</bcp14> be 403 (Forbidden). Other 4xx and 5xx responses <bcp14>MUS
Forbidden. Other 4xx and 5xx responses MUST follow standard <xref target="RFC723 T</bcp14> follow standard HTTP error condition conventions <xref target="RFC9110
1"/> HTTP error condition conventions.</t> "/>.</t>
</section>
</section> <section anchor="token-authority-responsibilities">
<section anchor="token-authority-responsibilities"><name>Token Authority Respons <name>Token Authority Responsibilities</name>
ibilities</name> <t>When creating the TNAuthList Authority Token, the Token Authority <bc
p14>MUST</bcp14> validate that the information contained in the ASN.1 TNAuthList
<t>When creating the TNAuthList Authority Token, the Token Authority MUST valida accurately represents the service provider code (SPC) or telephone number (TN)
te that the information contained in the ASN.1 TNAuthList accurately represents resources the requesting party is authorized to represent based on their pre-est
the service provider code (SPC) or telephone number (TN) resources the requestin ablished, verified, and secure relationship between the Token Authority and the
g party is authorized to represent based on their pre-established and verified s requesting party. Note that the fingerprint in the token request is not meant to
ecure relationship between the Token Authority and the requesting party. Note th be verified by the Token Authority but rather is meant to be signed as part of
at the fingerprint in the token request is not meant to be verified by the Token the token so that the party that requests the token can, as part of the challeng
Authority, but rather is meant to be signed as part of the token so that the pa e response, allow the ACME server to validate that the token requested and used
rty that requests the token can, as part of the challenge response, allow the AC came from the same party that controls the ACME client.</t>
ME server to validate the token requested and used came from the same party that </section>
controls the ACME client.</t> <section anchor="scope-of-the-tnauthlist">
<name>Scope of the TNAuthList</name>
</section> <t>Because this specification specifically involves the TNAuthList defin
<section anchor="scope-of-the-tnauthlist"><name>Scope of the TNAuthList</name> ed in <xref target="RFC8226"/>, which involves SPC, telephone number ranges, and
individual telephone numbers, the client may also request an Authority Token wi
<t>Because this specification specifically involves the TNAuthList defined in <x th some subset of its own authority as the TNAuthList provided in the "tkvalue"
ref target="RFC8226"/> which involves SPC, TNBlock, and individual TNs, the clie element in the "atc" JSON object. Generally, the scope of authority representing
nt may also request an Authority Token with some subset of its own authority as a CSP is represented by a particular SPC (e.g., in North America, an operating
the TNAuthList provided in the "tkvalue" element in the "atc" JSON object. Gener company number (OCN) or service provider identifier (SPID)). Based on number all
ally, the scope of authority representing a communications service provider is r ocations, that provider is also generally associated
epresented by a particular SPC (e.g. in North America, an operating company numb with a particular set of different telephone number ranges and/or telepho
er (OCN) or service provider identifier (SPID)). That provider is also generally ne numbers. The TNAuthList can be constructed to define a limited scope of the
associated, based on number allocations, with a particular set of different TN TelephoneNumberRanges or TelephoneNumbers (<xref target="RFC8226" sectionFormat=
Blocks and/or TNs. TNAuthList can be constructed to define a limited scope of th "comma" section="9"/>) either associated with an SPC or with the scope of teleph
e TNBlocks or TNs either associated with an SPC or with the scope of TN Blocks o one number ranges or telephone numbers the client has authority over.</t>
r TNs the client has authority over.</t> <t>As recommended in the Security Considerations section in <xref target
="RFC9447"/>, an Authority Token can either have a scope that attests all of the
<t>As recommended in <xref target="I-D.ietf-acme-authority-token"/> security con resources that a client is eligible to receive certificates for or potentially
siderations, an Authority Token can either have a scope that attests all of the a more limited scope that is intended to capture only those resources for which
resources which a client is eligible to receive certificates for, or potentially a client will receive a certificate from a particular certification authority.
a more limited scope that is intended to capture only those resources for which Any certification authority that sees an Authority Token can learn information a
a client will receive a certificate from a particular certification authority. bout the resources a client can claim. In cases where this incurs a privacy ris
Any certification authority that sees an Authority Token can learn information k, Authority Token scopes should be limited to only the resources that will be a
about the resources a client can claim. In cases where this incurs a privacy ri ttested by the requested ACME certificate.</t>
sk, Authority Token scopes should be limited to only the resources that will be </section>
attested by the requested ACME certificate.</t> </section>
<section anchor="validating-the-tnauthlist-authority-token">
</section> <name>Validating the TNAuthList Authority Token</name>
</section> <t>Upon receiving a response to the challenge, the ACME server <bcp14>MUST
<section anchor="validating-the-tnauthlist-authority-token"><name>Validating the </bcp14> perform the following steps to determine the validity of the response.<
TNAuthList Authority Token</name> /t>
<ol spacing="normal" type="1">
<t>Upon receiving a response to the challenge, the ACME server MUST perform the <li>Verify that the value of the "atc" claim is a well-formed JSON objec
following steps to determine the validity of the response.</t> t containing the mandatory key values.</li>
<li>If there is an "x5u" parameter, verify the "x5u" parameter is an HTT
<t><list style="symbols"> PS URL with a reference to a certificate representing the trusted issuer of Auth
<t>Verify that the value of the "atc" claim is a well-formed JSON object conta ority Tokens for the ecosystem.</li>
ining the mandatory key values.</t> <li>If there is an "x5c" parameter, verify the certificate array contain
<t>If there is an "x5u" parameter verify the "x5u" parameter is a HTTPS URL wi s a certificate representing the trusted issuer of Authority Tokens for the ecos
th a reference to a certificate representing the trusted issuer of authority tok ystem.</li>
ens for the eco-system.</t> <li>Verify the TNAuthList Authority Token signature using the public key
<t>If there is an "x5c" parameter verify the certificate array contains a cert of the certificate referenced by the token's "x5u" or "x5c" parameter.</li>
ificate representing the trusted issuer of authority tokens for the eco-system.< <li>Verify that "atc" claim contains a "tktype" identifier with the valu
/t> e "TNAuthList".</li>
<t>Verify the TNAuthList Authority Token signature using the public key of the <li>Verify that the "atc" claim "tkvalue" identifier contains the equiva
certificate referenced by the token's "x5u" or "x5c" parameter.</t> lent base64url-encoded TNAuthList certificate extension string value as the iden
<t>Verify that "atc" claim contains a "tktype" identifier with the value "TNAu tifier specified in the original challenge.</li>
thList".</t> <li>Verify that the remaining claims are valid (e.g., verify that token
<t>Verify that the "atc" claim "tkvalue" identifier contains the equivalent ba has not expired).</li>
se64url encoded TNAuthList certificate extension string value as the Identifier <li>Verify that the "atc" claim "fingerprint" is valid and matches the a
specified in the original challenge.</t> ccount key of the client making the request.</li>
<t>Verify that the remaining claims are valid (e.g., verify that token has not <li>Verify that the "atc" claim "ca" identifier boolean corresponds to t
expired)</t> he CA boolean in the Basic Constraints extension in the Certificate Signing Requ
<t>Verify that the "atc" claim "fingerprint" is valid and matches the account est (CSR) for either CA certificate or end-entity certificate.</li>
key of the client making the request</t> </ol>
<t>Verify that the "atc" claim "ca" identifier boolean corresponds to the CA b <t>If all steps in the token validation process pass, then the ACME server
oolean in the Basic Constraints extension in the CSR for either CA certificate o <bcp14>MUST</bcp14> set the challenge object "status" to "valid". If any step o
r end-entity certificate</t> f the validation process fails, the "status" in the challenge object <bcp14>MUST
</list></t> </bcp14> be set to "invalid".</t>
</section>
<t>If all steps in the token validation process pass, then the ACME server MUST <section anchor="using-acme-issued-certificates-with-json-web-signature">
set the challenge object "status" to "valid". If any step of the validation proc <name>Using ACME-Issued Certificates with JSON Web Signature</name>
ess fails, the "status" in the challenge object MUST be set to "invalid".</t> <t>JSON Web Signature (JWS) <xref target="RFC7515"/> objects can include a
n "x5u" header parameter to refer to a certificate that is used to validate the
</section> JWS signature. For example, the STIR PASSporT framework <xref target="RFC8225"/
<section anchor="using-acme-issued-certificates-with-json-web-signature"><name>U > uses "x5u" to indicate the STIR certificate used to validate the PASSporT JWS
sing ACME-issued Certificates with JSON Web Signature</name> object. The URLs used in "x5u" are expected to provide the required certificate
in response to a GET request, not a POST-as-GET, as required for the "certifica
<t>JSON Web Signature (JWS, <xref target="RFC7515"/>) objects can include an "x5 te" URL in the ACME order object. Thus, the current mechanism generally require
u" header parameter to refer to a certificate that is used to validate the JWS s s the ACME client to download the certificate and host it on a public URL to mak
ignature. For example, the STIR PASSporT framework <xref target="RFC8225"/> use e it accessible to relying parties. This section defines an optional mechanism
s "x5u" to indicate the STIR certificate used to validate the PASSporT JWS objec for the certification authority (CA) to host the certificate directly and provid
t. The URLs used in "x5u" are expected to provide the required certificate in r e a URL that the ACME client owner can directly reference in the "x5u" of their
esponse to a GET request, not a POST-as-GET as required for the "certificate" UR signed PASSporTs.</t>
L in the ACME order object. Thus the current mechanism generally requires the A <t>As described in <xref target="RFC8555" section="7.4" sectionFormat="of"
CME client to download the certificate and host it on a public URL to make it ac />, when the certificate is ready for making a "finalize" request, the server wi
cessible to relying parties. This section defines an optional mechanism for the ll return a 200 (OK) with the updated order object. In this response, an ACME s
Certificate Authority (CA) to host the certificate directly and provide a URL t erver can add a newly defined field called "x5u" that can pass this URL to the A
hat the ACME client owner can directly reference in the "x5u" of their signed PA CME client for usage in generated PASSporTs as a publicly available URL for PASS
SSporTs.</t> porT validation.</t>
<dl>
<t>As described in Section 7.4 of <xref target="RFC8555"/> when the certificate <dt>x5u (optional, string):</dt>
is ready for making a finalize request, the server will return a 200 (OK) with t <dd>
he updated order object. In this response, an ACME Server can add a newly defin <t>a URL that can be used to reference the certificate in the "x5u" pa
ed field called "x5u" that can pass this URL to the ACME client for usage in gen rameter of a JWS object <xref target="RFC7515"/></t>
erated PASSporTs as a publically available URL for PASSporT validation.</t> </dd>
</dl>
<dl> <t>The publishing of the certificates at the new "x5u" URL should follow t
<dt>x5u (optional, string):</dt> he GET request requirement as mentioned above and should be consistent with the
<dd> timely publication according to the durations of the certificate life cycle.</t>
<t>A URL that can be used to reference the certificate in the "x5u" paramete <t>The following is an example of the use of "x5u" in the response when th
r of a JWS object <xref target="RFC7515"/></t> e certificate status is "valid".</t>
</dd> <sourcecode type=""><![CDATA[
</dl>
<t>The publishing of the certificates at the new "x5u" URL should follow the GET
request requirement as mentioned above and should be consistent with the timely
publication according to the durations of the certificate lifecycle.</t>
<t>The following is an example of the use of "x5u" in the response when the cert
ificate status is "valid".</t>
<figure><artwork><![CDATA[
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>;rel="index" Link: <https://example.com/acme/directory>;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",
skipping to change at line 395 skipping to change at line 347
], ],
"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">
<section anchor="usage-considerations"><name>Usage Considerations</name> <name>Usage Considerations</name>
<section anchor="large-number-of-non-contiguous-tnauthlist-values">
<section anchor="large-number-of-non-contiguous-tnauthlist-values"><name>Large n <name>Large Number of Noncontiguous TNAuthList Values</name>
umber of Non-contiguous TNAuthList values</name> <t>There are many scenarios and reasons to have various combinations of
SPCs, TNs, and TN ranges. <xref target="RFC8226"/> has provided a somewhat unbo
<t>There are many scenarios and reasons to have various combinations of SPCs, TN unded set of combinations. It's possible that a complex noncontiguous set of te
s, and TN Ranges. <xref target="RFC8226"/> has provided a somewhat unbounded se lephone numbers are being managed by a CSP. Best practice may be simply to spli
t of combinations. It's possible that a complex non-contiguous set of telephone t a set of noncontiguous numbers under management into multiple STI certificates
numbers are being managed by a CSP. Best practice may be simply to split a set to represent the various contiguous parts of the greater noncontiguous set of T
of non-contiguous numbers under management into multiple STI certificates to re Ns, particularly if the length of the set of values in an identifier object grow
present the various contiguous parts of the greater non-contiguous set of TNs, p s to be too large.</t>
articularly if length of the set of values in identifier object grows to be too </section>
large.</t> </section>
</section>
</section>
<section anchor="security_considerations"><name>Security Considerations</name>
<t>The token represented by this document has the credentials to represent the s
cope of a telephone number, a block of telephone numbers, or an entire set of te
lephone numbers represented by an SPC. The creation, transport, and any storage
of this token MUST follow the strictest of security best practices beyond the re
commendations of the use of encrypted transport protocols in this document to pr
otect it from getting in the hands of bad actors with illegitimate intent to imp
ersonate telephone numbers.</t>
<t>This document inherits the security properties of <xref target="I-D.ietf-acme
-authority-token"/>. Implementations should follow the best practices identified
in <xref target="RFC8725"/>.</t>
<t>This document only specifies SHA256 for the fingerprint hash. However, the sy
ntax of the fingerprint object would permit other algorithms if, due to concerns
about algorithmic agility, a more robust algorithm were required at a future ti
me. Future specifications can define new algorithms for the fingerprint object
as needed.</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document requests the addition of a new identifier object type to the "A
CME Identifier Types" registry defined in Section 9.7.7 of <xref target="RFC8555
"/>.</t>
<figure><artwork><![CDATA[
+------------+-----------+
| Label | Reference |
+------------+-----------+
| TNAuthList | RFCThis |
+------------+-----------+
]]></artwork></figure>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank Richard Barnes and Russ Housley for valuable contribut
ions to this document.</t>
</section> <section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>Per this document, IANA has added a new identifier object type to the "
ACME Identifier Types" registry defined in <xref target="RFC8555" section="9.7.7
" sectionFormat="of" />.</t>
<table>
<thead>
<tr>
<th>Label</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>TNAuthList</td>
<td>RFC 9448</td>
</tr>
</tbody>
</table>
</section>
<section anchor="security_considerations">
<name>Security Considerations</name>
<t>The token represented by this document has the credentials to represent
the scope of a telephone number, a block of telephone numbers, or an entire set
of telephone numbers represented by an SPC. The creation, transport, and any st
orage of this token <bcp14>MUST</bcp14> follow the strictest of security best pr
actices beyond the recommendations of the use of encrypted transport protocols i
n this document to protect it from getting in the hands of bad actors with illeg
itimate intent to impersonate telephone numbers.</t>
<t>This document inherits the security properties of <xref target="RFC9447
"/>. Implementations should follow the best practices identified in <xref target
="RFC8725"/>.</t>
<t>This document only specifies SHA256 for the fingerprint hash. However,
the syntax of the fingerprint object would permit other algorithms if, due to co
ncerns about algorithmic agility, a more robust algorithm were required at a fut
ure time. Future specifications can define new algorithms for the fingerprint o
bject as needed.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title='Normative References'> <reference anchor='RFC9447' target='https://www.rfc-editor.org/info/rfc9447'>
<reference anchor='I-D.ietf-acme-authority-token'>
<front>
<title>ACME Challenges Using an Authority Token</title>
<author fullname='Jon Peterson' initials='J.' surname='Peterson'>
<organization>Neustar, Inc.</organization>
</author>
<author fullname='Mary Barnes' initials='M.' surname='Barnes'>
<organization>Neustar, Inc.</organization>
</author>
<author fullname='David Hancock' initials='D.' surname='Hancock'>
<organization>Comcast</organization>
</author>
<author fullname='Chris Wendt' initials='C.' surname='Wendt'>
<organization>Somos</organization>
</author>
<date day='24' month='October' year='2022'/>
<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> <front>
<title>PASSporT: Personal Assertion Token</title> <title>Automated Certificate Management Environment (ACME) Challenges Using an A
<author fullname='C. Wendt' initials='C.' surname='Wendt'><organization/></autho uthority Token</title>
r> <author initials='J' surname='Peterson' fullname='Jon Peterson'>
<author fullname='J. Peterson' initials='J.' surname='Peterson'><organization/>< <organization />
/author> </author>
<date month='February' year='2018'/> <author initials='M' surname='Barnes' fullname='Mary Barnes'>
<abstract><t>This document defines a method for creating and validating a token <organization />
that cryptographically verifies an originating identity or, more generally, a UR </author>
I or telephone number representing the originator of personal communications. T <author initials='D' surname='Hancock' fullname='David Hancock'>
he Personal Assertion Token, PASSporT, is cryptographically signed to protect th <organization />
e integrity of the identity of the originator and to verify the assertion of the </author>
identity information at the destination. The cryptographic signature is define <author initials='C' surname='Wendt' fullname='Chris Wendt'>
d with the intention that it can confidently verify the originating persona even <organization />
when the signature is sent to the destination party over an insecure channel. </author>
PASSporT is particularly useful for many personal-communications applications ov <date year='2023' month='August'/>
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> </front>
<seriesInfo name='RFC' value='8225'/> <seriesInfo name="RFC" value="9447"/>
<seriesInfo name='DOI' value='10.17487/RFC8225'/> <seriesInfo name="DOI" value="10.17487/RFC9447"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
515.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
226.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
555.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
725.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
060.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="ATIS-1000080" target="https://access.atis.org/apps/gr
oup_public/download.php/69428/ATIS-1000080.v005.pdf">
<front>
<title>Signature-based Handling of Asserted information using toKENs
(SHAKEN): Governance Model and Certificate Management</title>
<author>
<organization>ATIS</organization>
</author>
<date year="2022" month="December"/>
</front>
<refcontent>ATIS-1000080.v005</refcontent>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
225.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="Richard Barnes"/> and <contac
t fullname="Russ Housley"/> for valuable contributions to this document.</t>
</section>
</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. 
946 lines changed or deleted 462 lines changed or added

This html diff was produced by rfcdiff 1.48.