[要約] RFC 9448は、VoIP電話プロバイダーがSTI証明書をサポートするために、ACME Authority Tokenのプロファイルを定義しています。目的は、自動化されたかつ認可された証明書の作成を可能にすることです。
Internet Engineering Task Force (IETF) C. Wendt
Request for Comments: 9448 D. Hancock
Category: Standards Track Somos Inc.
ISSN: 2070-1721 M. Barnes
J. Peterson
Neustar Inc.
September 2023
This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates.
このドキュメントでは、STI証明書で定義されたTNAUTHLISTを使用して安全な電話ID（STI）をサポートするために、Voice over IP（VOIP）電話プロバイダーの自動化され承認された証明書の作成のための自動化された証明書管理環境（ACME）機関トークンのプロファイルを定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9448.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9448で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. ACME New-Order Identifiers for TNAuthList
4. TNAuthList Identifier Authorization
5. TNAuthList Authority Token
5.1. "iss" Claim
5.2. "exp" Claim
5.3. "jti" Claim
5.4. "atc" Claim
5.5. Acquiring the Token from the Token Authority
5.6. Token Authority Responsibilities
5.7. Scope of the TNAuthList
6. Validating the TNAuthList Authority Token
7. Using ACME-Issued Certificates with JSON Web Signature
8. Usage Considerations
8.1. Large Number of Noncontiguous TNAuthList Values
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
[RFC8555] describes a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources like domain names, and it automates the process of generating and issuing certificates. [RFC9447] extends ACME to provide a general method of extending the authority and authorization of entities to control a resource via a third party Token Authority beyond the certification authority (CA).
[RFC8555]は、インターネット上の証明書管理を自動化するためのメカニズムを説明しています。これにより、管理エンティティはドメイン名などのリソースを効果的に制御できることを証明し、証明書を生成および発行するプロセスを自動化できます。[RFC9447]は、ACMEを拡張して、認証当局（CA）を超えてサードパーティのトークン当局を介してリソースを制御する権限と承認を拡張する一般的な方法を提供します。
This document is a profile document using the Authority Token mechanism defined in [RFC9447]. It is a profile that specifically addresses the Secure Telephone Identity Revisited (STIR) problem statement described in [RFC7340], which identifies the need for Internet credentials that can attest authority for the originator of VoIP calls in order to detect impersonation, which is currently an enabler for common attacks associated with illegal robocalling, voicemail hacking, and swatting. These credentials are used to sign Personal Assertion Tokens (PASSporTs) [RFC8225], which can be carried in using protocols such as SIP [RFC8224]. Currently, the only defined credentials for this purpose are the certificates specified in [RFC8226] using the TNAuthList. This document defines the use of the TNAuthList Authority Token in the ACME challenge to prove the authoritative use of the contents of the TNAuthList, including a Service Provider Code (SPC), a telephone number, or a set of telephone numbers or telephone number blocks.
このドキュメントは、[RFC9447]で定義されている機関トークンメカニズムを使用したプロファイルドキュメントです。これは、[RFC7340]に記載されている安全な電話IDの再検討（STIR）問題ステートメントに特に対処するプロファイルであり、現在、Impersonationを検出するためにVoIPコールの発信者の権限を証明できるインターネット資格情報の必要性を特定します。違法なロボコール、ボイスメールのハッキング、およびスワットに関連する一般的な攻撃のイネーブラー。これらの資格情報は、個人的なアサーショントークン（パスポート）[RFC8225]に署名するために使用されます。これは、SIP [RFC8224]などのプロトコルを使用して実行できます。現在、この目的のための唯一の定義された資格情報は、TNAUTHLISTを使用して[RFC8226]で指定された証明書です。このドキュメントでは、ACMEチャレンジでのTNAuthList Authority Tokenの使用を定義して、サービスプロバイダーコード（SPC）、電話番号、または電話番号または電話番号ブロックを含むTNAuthListの内容の権威ある使用を証明します。
This document also describes the ability for a telephone authority to authorize the creation of CA types of certificates for delegation, as defined in [RFC9060].
このドキュメントでは、[RFC9060]で定義されているように、電話局が委任のCAタイプの証明書の作成を承認する能力についても説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Section 7 of [RFC8555] defines the procedure that an ACME client uses to order a new certificate from a CA. The new-order request contains an identifier field that specifies the identifier objects the order corresponds to. This 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 includes a type set to the string "TNAuthList". The value of the TNAuthList identifier MUST be set to the details of the TNAuthList requested.
[RFC8555]のセクション7では、ACMEクライアントがCAから新しい証明書を注文するために使用する手順を定義します。新しい注文要求には、順序が対応する識別子オブジェクトを指定する識別子フィールドが含まれています。このドキュメントでは、TNAuthListと呼ばれる新しいタイプの識別子オブジェクトを定義します。TNAUTHLIST識別子には、新しい証明書のTNAUTHLISTに入力されるID情報が含まれています。TNAUTHLIST識別子の場合、新しい注文要求には、文字列「TNAUTHLIST」に設定されたタイプが含まれています。TNAUTHLIST識別子の値は、要求されたTNAuthListの詳細に設定する必要があります。
The string that represents the TNAuthList MUST be constructed using base64url encoding, as described in Section 5 of [RFC4648] and as defined in Section 2 of JSON Web Signature [RFC7515]. The base64url encoding MUST NOT include any padding characters, and the TNAuthList ASN.1 object MUST be encoded using DER encoding rules.
TNAUTHLISTを表す文字列は、[RFC4648]のセクション5で説明されているように、JSON Web署名[RFC7515]のセクション2で定義されているように、base64urlエンコードを使用して構築する必要があります。base64urlエンコードにはパディング文字を含めるべきではなく、TNAUTHLIST ASN.1オブジェクトはDERエンコードルールを使用してエンコードする必要があります。
An example of an ACME order object "identifiers" field containing a TNAuthList certificate is as follows:
TNAUTHLIST証明書を含むACME ORDERオブジェクト「識別子」フィールドの例は次のとおりです。
"identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3"}]
where the "value" object string represents the arbitrary length of the base64url-encoded string.
ここで、「値」オブジェクト文字列は、base64urlエンコード文字列の任意の長さを表します。
A full new-order request would look as follows:
完全な新しい注文のリクエストは次のように見えます。
POST /acme/new-order HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "5XJ1L3lEkMG7tR6pA00clA",
"url": "https://example.com/acme/new-order"
}),
"payload": base64url({
"identifiers": [{"type":"TNAuthList","value":"F83n...n27DN3"}],
"notBefore": "2021-01-01T00:00:00Z",
"notAfter": "2021-01-08T00:00:00Z"
}),
"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
On receiving a valid new-order request, the ACME server creates an authorization object ([RFC8555], Section 7.1.4), containing the challenge that the ACME client must satisfy to demonstrate authority for the identifiers specified by the new order (in this case, the TNAuthList identifier). The CA adds the authorization object URL to the "authorizations" field of the order object and returns the order object to the ACME client in the body of a 201 (Created) response.
有効な新しい注文要求を受信すると、ACMEサーバーはACMEクライアントが新しい注文で指定された識別子の権限を実証するために満たさなければならないという課題を含む、認証オブジェクト（[RFC8555]、セクション7.1.4）を作成します（これでケース、TNAUTHLIST識別子）。CAは、承認オブジェクトURLをOrderオブジェクトの「承認」フィールドに追加し、201（作成）応答の本文でOrderオブジェクトをACMEクライアントに返します。
HTTP/1.1 201 Created
Content-Type: application/json
Replay-Nonce: MYAuvOpaoIiywTezizk5vw
Location: https://example.com/acme/order/1234
{
"status": "pending",
"expires": "2022-01-08T00:00:00Z",
"notBefore": "2022-01-01T00:00:00Z",
"notAfter": "2022-01-08T00:00:00Z",
"identifiers":[{"type":"TNAuthList",
"value":"F83n2a...avn27DN3"}],
"authorizations": [
"https://example.com/acme/authz/1234"
],
"finalize": "https://example.com/acme/order/1234/finalize"
}
On receiving the new-order response, the ACME client queries the referenced authorization object to obtain the challenges for the identifier contained in the new-order request, as shown in the following example request and response.
次の例のリクエストと応答に示すように、新しい注文の応答を受信すると、ACMEクライアントは参照承認オブジェクトをクエリして、新しい注文要求に含まれる識別子の課題を取得します。
POST /acme/authz/1234 HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": " https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/1234"
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/some-directory>;rel="index"
{
"status": "pending",
"expires": "2022-01-08T00:00:00Z",
"identifier": {
"type":"TNAuthList",
"value":"F83n2a...avn27DN3"
},
"challenges": [
{
"type": "tkauth-01",
"tkauth-type": "atc",
"token-authority": "https://authority.example.org",
"url": "https://example.com/acme/chall/prV_B7yEyA4",
"token": "IlirfxKKXAsHtmzK29Pj8A"
}
]
}
When processing a certificate order containing an identifier of type "TNAuthList", a CA uses the Authority Token challenge type of "tkauth-01" with a "tkauth-type" of "atc" in [RFC9447] to verify that the requesting ACME client has authenticated and authorized control over the requested resources represented by the "TNAuthList" value.
タイプ「TNAUTHLIST」の識別子を含む証明書の注文を処理する場合、CAは[RFC9447]の「TKAUTH-01」の「TKAUTH-01」の「TKAUTH-01」の「TKAUTH-01」の機関の挑戦を使用して、要求するACMEクライアントが確認することを確認します。「TNAUTHLIST」値で表される要求されたリソースを認証および承認した制御を承認しました。
The challenge "token-authority" parameter is only used in cases where the VoIP telephone network requires the CA to identify the Token Authority. This is currently not the case for the Signature-based Handling of Asserted information using toKENs (SHAKEN) [ATIS-1000080] certificate framework governance but may be used by other frameworks. If a "token-authority" parameter is present, then the ACME client MAY use the "token-authority" value to identify the URL representing the Token Authority that will provide the TNAuthList Authority Token response to the challenge. If the "token-authority" parameter is not present, then the ACME client MUST identify the Token Authority based on locally configured information or local policies.
課題の「トークン・オーソリティ」パラメーターは、VoIP電話ネットワークがトークン当局を特定するためにCAが必要とする場合にのみ使用されます。これは現在、トークン（Shaken）[ATIS-1000080]証明書フレームワークガバナンスを使用した主張された情報の署名ベースの処理の場合ではありませんが、他のフレームワークでは使用される場合があります。「トークンの承認」パラメーターが存在する場合、ACMEクライアントは「トークンの承認」値を使用して、TNAUTHLIST Authorityの課題にTNAUTHLIST Authorityの対応を提供するトークン当局を表すURLを識別することができます。「トークン承認」パラメーターが存在しない場合、ACMEクライアントは、ローカルで構成された情報またはローカルポリシーに基づいてトークン当局を特定する必要があります。
The ACME client responds to the challenge by posting the TNAuthList Authority Token to the challenge URL identified in the returned ACME authorization object, an example of which follows:
ACMEクライアントは、TNAUTHLIST Authorityトークンを返されたACME認証オブジェクトで特定したチャレンジURLに投稿することにより、課題に応答します。その例は次のとおりです。
POST /acme/chall/prV_B7yEyA4 HTTP/1.1
Host: boulder.example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg",
"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://boulder.example.com/acme/authz/asdf/0"
}),
"payload": base64url({
"tkauth": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"
}),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
The "tkauth" field is defined as a new field in the challenge object specific to the tkauth-01 challenge type that should contain the TNAuthList Authority Token defined in the next section.
「TKAUTH」フィールドは、次のセクションで定義されているTNAUTHLIST Authorityトークンを含むTKAUTH-01チャレンジタイプに固有のチャレンジオブジェクトの新しいフィールドとして定義されます。
The TNAuthList Authority Token is a profile instance of the ACME Authority Token defined in [RFC9447].
TNAUTHLIST Authority Tokenは、[RFC9447]で定義されているACMEオーソリティトークンのプロファイルインスタンスです。
The TNAuthList Authority Token protected header MUST comply with "Request Authentication" (Section 6.2 of [RFC8555]).
TNAUTHLIST Authorityトークン保護されたヘッダーは、「リクエスト認証」（[RFC8555]のセクション6.2）に準拠する必要があります。
The TNAuthList Authority Token Payload MUST include the mandatory claims "exp", "jti", and "atc" and MAY include the optional claims defined for the Authority Token detailed in the next subsections.
TNAUTHLIST Authorityトークンペイロードには、必須の請求「EXP」、「JTI」、および「ATC」を含める必要があり、次のサブセクションで詳述されている当局のオプションのクレームを含めることができます。
The "iss" claim is an optional claim defined in [RFC7519], Section 4.1.1. It can be used as a URL identifying the Token Authority that issued the TNAuthList Authority Token beyond the "x5u" or other header claims that identify the location of the certificate or certificate chain of the Token Authority used to validate the TNAuthList Authority Token.
「ISS」クレームは、[RFC7519]、セクション4.1.1で定義されているオプションのクレームです。これは、TNAUTHLIST Authority Authority Authority Authority Authority Tokenの検証に使用されるトークン当局の証明書または証明書チェーンを特定する「X5U」またはその他のヘッダークレームを超えてTNAUTHLIST Authority Tokenを発行するトークン当局を識別するURLとして使用できます。
The "exp" claim, defined in [RFC7519], Section 4.1.4, MUST be included and contains the DateTime value of the ending date and time that the TNAuthList Authority Token expires.
[RFC7519]で定義されている「Exp」クレーム、セクション4.1.4には、TNAUTHLIST Authority Tokenが期限切れにする終了日と時間の日付値が含まれている必要があります。
The "jti" claim, defined in [RFC7519], Section 4.1.7, MUST be included and contains a unique identifier for this TNAuthList Authority Token transaction.
[RFC7519]で定義されている「JTI」クレーム、セクション4.1.7には、このTNAUTHLIST Authorityトークントランザクションの一意の識別子が含まれている必要があります。
The "atc" claim MUST be included and is defined in [RFC9447]. It contains a JSON object with the following elements:
「ATC」クレームを含める必要があり、[RFC9447]で定義されています。次の要素を持つJSONオブジェクトが含まれています。
* a "tktype" key with a string value equal to "TNAuthList" to represent a TNAuthList profile of the Authority Token [RFC9447] defined by this document. "tktype" is a required key and MUST be included.
* 「TNAUTHLIST」に等しい文字列値を持つ「TKTYPE」キーは、このドキュメントで定義された機関トークン[RFC9447]のTNAUTHLISTプロファイルを表します。「TKTYPE」は必須キーであり、含める必要があります。
* a "tkvalue" key with a string value equal to the base64url encoding of the TNAuthList certificate extension ASN.1 object using DER encoding rules. "tkvalue" is a required key and MUST be included.
* tnauthList証明書拡張asn.1オブジェクトのbase64urlエンコードに等しい文字列値を持つ「tkvalue」キー。derエンコーディングルールを使用します。「tkvalue」は必須キーであり、含める必要があります。
* a "ca" key with a boolean value set to either true when the requested certificate is allowed to be a CA cert for delegation uses or false when the requested certificate is not intended to be a CA cert, only an end-entity certificate. "ca" is an optional key; if not included, the "ca" value is considered false by default.
* 要求された証明書が委任の使用のCA証明書を許可されている場合、または要求された証明書がCA証明書のみであり、エンドエンティティ証明書のみを意図していない場合、Trueに設定された「CA」キー。「CA」はオプションのキーです。含まれていない場合、「CA」値はデフォルトでfalseと見なされます。
* a "fingerprint" key constructed as defined in [RFC8555], Section 8.1, corresponding to the computation of the "Thumbprint" step using the ACME account key credentials. "fingerprint" is a required key and MUST be included.
* [RFC8555]で定義されているように構築された「指紋」キー、セクション8.1。「指紋」は必須キーであり、含める必要があります。
An example of the TNAuthList Authority Token is as follows:
TnauthList Authorityトークンの例は次のとおりです。
{
"protected": base64url({
"typ":"JWT",
"alg":"ES256",
"x5u":"https://authority.example.org/cert"
}),
"payload": base64url({
"iss":"https://authority.example.org",
"exp":1640995200,
"jti":"id6098364921",
"atc":{"tktype":"TNAuthList",
"tkvalue":"F83n2a...avn27DN3",
"ca":false,
"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"}
}),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
Following [RFC9447], Section 5, the Authority Token should be acquired using a RESTful HTTP POST transaction as follows:
[RFC9447]、セクション5に続いて、RESTFUL HTTP Post Transactionを使用して、次のように権限のトークンを取得する必要があります。
POST /at/account/:id/token HTTP/1.1
Host: authority.example.org
Content-Type: application/json
The request will pass the account identifier as a string in the request parameter "id". This string will be managed as an identifier specific to the Token Authority's relationship with a Communications Service Provider (CSP). There is assumed to also be a corresponding authentication procedure that can be verified for the success of this transaction, for example, an HTTP authorization header containing valid authorization credentials, as defined in [RFC9110], Section 11.6.2.
要求は、要求パラメーター「ID」の文字列としてアカウント識別子を渡します。この文字列は、トークン当局と通信サービスプロバイダー（CSP）との関係に固有の識別子として管理されます。[RFC9110]で定義されている有効な承認資格情報を含むHTTP認証ヘッダー、セクション11.6.2など、このトランザクションの成功について検証できる対応する認証手順も想定されています。
The body of the POST request MUST contain a JSON object with key value pairs corresponding to values that are requested as the content of the claims in the issued token. As an example, the body SHOULD contain a JSON object as follows:
POSTリクエストの本文には、発行されたトークンの請求の内容として要求される値に対応するキー値ペアを持つJSONオブジェクトを含める必要があります。例として、ボディは次のようにJSONオブジェクトを含める必要があります。
{
"tktype":"TNAuthList",
"tkvalue":"F83n2a...avn27DN3",
"ca":false,
"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"
}
If successful, the response to the POST request returns a 200 (OK) with a JSON body that contains, at a minimum, the TNAuthList Authority Token as a JSON object with a key of "token" and the base64url-encoded string representing the atc token. JSON is easily extensible, so users of this specification may want to pass other pieces of information relevant to a specific application.
成功した場合、POSTリクエストへの応答は、少なくとも「トークン」のキーとATCを表すbase64URLエンコード文字列を持つJSONオブジェクトとしてTNAUTHLIST Authorityトークンを含むJSONボディを使用して200（OK）を返します。トークン。JSONは簡単に拡張可能であるため、この仕様のユーザーは、特定のアプリケーションに関連する他の情報を渡すことができます。
An example of a successful response would be as follows:
成功した応答の例は次のとおりです。
HTTP/1.1 200 OK
Content-Type: application/json
{"token": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"}
If the request is not successful, the response should indicate the error condition. Specifically, for the case that the authorization credentials are invalid or if the account identifier provided does not exist, the response code MUST be 403 (Forbidden). Other 4xx and 5xx responses MUST follow standard HTTP error condition conventions [RFC9110].
リクエストが成功しない場合、応答はエラー条件を示す必要があります。具体的には、認証資格情報が無効である場合、または提供されたアカウント識別子が存在しない場合、応答コードは403（禁止）でなければなりません。他の4XXおよび5XX応答は、標準のHTTPエラー条件の規則[RFC9110]に従う必要があります。
When creating the TNAuthList Authority Token, the Token Authority MUST validate that the information contained in the ASN.1 TNAuthList accurately represents the service provider code (SPC) or telephone number (TN) resources the requesting party is authorized to represent based on their pre-established, verified, and secure relationship between the Token Authority and the requesting party. Note that the fingerprint in the token request is not meant to be verified by the Token Authority but rather is meant to be signed as part of the token so that the party that requests the token 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 client.
TNAUTHLIST Authority Tokenを作成する場合、トークン当局は、ASN.1 TNAUTHLISTに含まれる情報がサービスプロバイダーコード（SPC）または電話番号（TN）リソースを正確に表していることを検証する必要があります。トークン当局と要求当事者との間に確立され、検証され、安全な関係。トークンリクエストの指紋は、トークン当局によって検証されることを意図しているのではなく、トークンの一部として署名されることを意図しているため、トークンを要求するパーティーがチャレンジ応答の一部としてACMEを許可することができます。トークンが要求され、使用されていることを検証するサーバーは、ACMEクライアントを制御するのと同じパーティーから来たことを検証します。
Because this specification specifically involves the TNAuthList defined in [RFC8226], which involves SPC, telephone number ranges, and individual telephone numbers, the client may also request an Authority Token with some subset of its own authority as the TNAuthList provided in the "tkvalue" element in the "atc" JSON object. Generally, the scope of authority representing a CSP is represented by a particular SPC (e.g., in North America, an operating company number (OCN) or service provider identifier (SPID)). Based on number allocations, that provider is also generally associated with a particular set of different telephone number ranges and/or telephone numbers. The TNAuthList can be constructed to define a limited scope of the TelephoneNumberRanges or TelephoneNumbers ([RFC8226], Section 9) either associated with an SPC or with the scope of telephone number ranges or telephone numbers the client has authority over.
この仕様は、SPC、電話番号、および個々の電話番号を含む[RFC8226]で定義されているTNAUTHLISTを特別に含むため、クライアントは「TKValue」で提供されるTNAUTHLISTとして独自の権限の一部のサブセットとの権限トークンを要求することもできます。「ATC」JSONオブジェクトの要素。一般に、CSPを表す権限の範囲は、特定のSPC（たとえば、北米、運営会社番号（OCN）またはサービスプロバイダー識別子（SPID））で表されます。番号の割り当てに基づいて、そのプロバイダーは一般に、異なる電話番号範囲および/または電話番号の特定のセットにも関連付けられています。TNAUTHLISTは、SPCまたは電話番号の範囲または電話番号の範囲に関連付けられているテレフォンムーバールレンジまたはテレフォンムーバー（[RFC8226]、セクション9）の限られた範囲を定義するために構築できます。
As recommended in the Security Considerations section in [RFC9447], an Authority Token can either have a scope that attests all of the resources that a client is eligible to receive certificates for or potentially a more limited scope that is intended to capture only those resources for which a client will receive a certificate from a particular certification authority. Any certification authority that sees an Authority Token can learn information about the resources a client can claim. In cases where this incurs a privacy risk, Authority Token scopes should be limited to only the resources that will be attested by the requested ACME certificate.
[RFC9447]のセキュリティに関する考慮事項セクションで推奨されているように、当局は、クライアントが証明書を受け取る資格があるすべてのリソースを証明する範囲を持つことができます。クライアントは、特定の認証機関から証明書を受け取ります。トークンがクライアントが請求できるリソースに関する情報を学ぶことができる認定機関。これにプライバシーリスクが発生する場合、当局のトークンスコープは、要求されたACME証明書によって証明されるリソースのみに制限される必要があります。
Upon receiving a response to the challenge, the ACME server MUST perform the following steps to determine the validity of the response.
チャレンジへの応答を受信すると、ACMEサーバーは、応答の有効性を判断するために次の手順を実行する必要があります。
1. Verify that the value of the "atc" claim is a well-formed JSON object containing the mandatory key values.
1. 「ATC」クレームの値が、必須のキー値を含む整形されたJSONオブジェクトであることを確認します。
2. If there is an "x5u" parameter, verify the "x5u" parameter is an HTTPS URL with a reference to a certificate representing the trusted issuer of Authority Tokens for the ecosystem.
2. 「x5u」パラメーターがある場合、「x5u」パラメーターは、エコシステムの権限トークンの信頼できる発行者を表す証明書を参照するHTTPS URLであることを確認します。
3. If there is an "x5c" parameter, verify the certificate array contains a certificate representing the trusted issuer of Authority Tokens for the ecosystem.
3. 「x5c」パラメーターがある場合、証明書配列には、エコシステムの機関トークンの信頼できる発行者を表す証明書が含まれていることを確認します。
4. Verify the TNAuthList Authority Token signature using the public key of the certificate referenced by the token's "x5u" or "x5c" parameter.
4. トークンの「x5u」または「x5c」パラメーターが参照する証明書の公開鍵を使用して、tnauthlist Authority Token署名を確認します。
5. Verify that "atc" claim contains a "tktype" identifier with the value "TNAuthList".
5. 「ATC」クレームには、値「TNAUTHLIST」と「TKTYPE」識別子が含まれていることを確認します。
6. Verify that the "atc" claim "tkvalue" identifier contains the equivalent base64url-encoded TNAuthList certificate extension string value as the identifier specified in the original challenge.
6. 「ATC」クレーム「TKValue」識別子には、元の課題で指定された識別子と同等のbase64URLエンコードされたTNAUTHLIST証明書拡張文字列値が含まれていることを確認します。
7. Verify that the remaining claims are valid (e.g., verify that token has not expired).
7. 残りのクレームが有効であることを確認します（たとえば、トークンが期限切れになっていないことを確認します）。
8. Verify that the "atc" claim "fingerprint" is valid and matches the account key of the client making the request.
8. 「ATC」クレーム「指紋」が有効であり、リクエストを作成するクライアントのアカウントキーと一致することを確認します。
9. Verify that the "atc" claim "ca" identifier boolean corresponds to the CA boolean in the Basic Constraints extension in the Certificate Signing Request (CSR) for either CA certificate or end-entity certificate.
9. 「ATC」クレーム「CA」識別子ブールンが、CA証明書またはエンドエンティティ証明書のいずれかの証明書署名要求（CSR）の基本的な制約拡張におけるCAブール値に対応していることを確認します。
If all steps in the token validation process pass, then the ACME server MUST set the challenge object "status" to "valid". If any step of the validation process fails, the "status" in the challenge object MUST be set to "invalid".
トークン検証プロセスのすべてのステップがパスする場合、ACMEサーバーはチャレンジオブジェクト「ステータス」を「有効」に設定する必要があります。検証プロセスの任意のステップが失敗した場合、チャレンジオブジェクトの「ステータス」を「無効」に設定する必要があります。
JSON Web Signature (JWS) [RFC7515] objects can include an "x5u" header parameter to refer to a certificate that is used to validate the JWS signature. For example, the STIR PASSporT framework [RFC8225] uses "x5u" to indicate the STIR certificate used to validate the PASSporT JWS 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 "certificate" URL in the ACME order object. Thus, the current mechanism generally requires the ACME client to download the certificate and host it on a public URL to make it accessible to relying parties. This section defines an optional mechanism for the certification authority (CA) to host the certificate directly and provide a URL that the ACME client owner can directly reference in the "x5u" of their signed PASSporTs.
JSON Web Signature（JWS）[RFC7515]オブジェクトには、JWS署名を検証するために使用される証明書を参照する「X5U」ヘッダーパラメーターを含めることができます。たとえば、Stir Passport Framework [RFC8225]は「X5U」を使用して、パスポートJWSオブジェクトの検証に使用されるSTIR証明書を示します。「X5U」で使用されるURLは、ACME Orderオブジェクトの「証明書」URLに必要なように、Get Requestに応じて必要な証明書を提供することが期待されます。したがって、現在のメカニズムでは、一般に、ACMEクライアントは証明書をダウンロードし、公開URLでホストして、依存関係者がアクセスできるようにする必要があります。このセクションでは、認証機関（CA）が証明書を直接ホストし、ACMEクライアントの所有者が署名されたパスポートの「X5U」を直接参照できるURLを提供するオプションのメカニズムを定義します。
As described in Section 7.4 of [RFC8555], when the certificate is ready for making a "finalize" request, the server will return a 200 (OK) with the 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 generated PASSporTs as a publicly available URL for PASSporT validation.
[RFC8555]のセクション7.4で説明されているように、証明書の「ファイナライズ」リクエストの準備ができたら、サーバーは更新された注文オブジェクトで200（OK）を返します。この応答では、ACMEサーバーは、パスポート検証のために公開されているURLとして、生成されたパスポートの使用のためにこのURLをACMEクライアントに渡すことができる「X5U」と呼ばれる新しく定義されたフィールドを追加できます。
x5u (optional, string):
X5U（オプション、文字列）：
a URL that can be used to reference the certificate in the "x5u" parameter of a JWS object [RFC7515]
JWSオブジェクトの「X5U」パラメーター[RFC7515]の証明書を参照するために使用できるURL
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 life cycle.
新しい「X5U」URLでの証明書の公開は、上記のようにGETリクエストの要件に従う必要があり、証明書のライフサイクルの期間に応じてタイムリーな出版物と一致するはずです。
The following is an example of the use of "x5u" in the response when the certificate status is "valid".
以下は、証明書のステータスが「有効」である場合の応答で「x5u」の使用の例です。
HTTP/1.1 200 OK
Content-Type: application/json
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: <https://example.com/acme/directory>;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo
{
"status": "valid",
"expires": "2016-01-20T14:09:07.99Z",
"notBefore": "2016-01-01T00:00:00Z",
"notAfter": "2016-01-08T00:00:00Z",
"identifiers": [
"type":"TNAuthList",
"value":"F83n2a...avn27DN3"
],
"authorizations": ["https://sti-ca.com/acme/authz/1234"],
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
"certificate": "https://example.com/acme/cert/mAt3xBGaobw",
"x5u": "https://example.com/cert-repo/giJI53km23.pem"
}
There are many scenarios and reasons to have various combinations of SPCs, TNs, and TN ranges. [RFC8226] has provided a somewhat unbounded set of combinations. It's possible that a complex noncontiguous set of telephone numbers are being managed by a CSP. Best practice may be simply to split a set of noncontiguous numbers under management into multiple STI certificates to represent the various contiguous parts of the greater noncontiguous set of TNs, particularly if the length of the set of values in an identifier object grows to be too large.
SPC、TNS、およびTNの範囲のさまざまな組み合わせを持つ多くのシナリオと理由があります。[RFC8226]は、やや無制限の組み合わせセットを提供しました。複雑な非連続の電話番号セットがCSPによって管理されている可能性があります。ベストプラクティスは、特に識別子オブジェクトの値のセットの長さが大きすぎるように成長する場合、より大きな非連続的なTNSセットのさまざまな隣接する部分を表すために、管理下の非連続数のセットを複数のSTI証明書に分割することです。。
Per this document, IANA has added a new identifier object type to the "ACME Identifier Types" registry defined in Section 9.7.7 of [RFC8555].
このドキュメントに従って、IANAは[RFC8555]のセクション9.7.7で定義されている「ACME識別子タイプ」レジストリに新しい識別子オブジェクトタイプを追加しました。
+============+===========+
| Label | Reference |
+============+===========+
| TNAuthList | RFC 9448 |
+------------+-----------+
Table 1
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 storage of this token MUST follow the strictest of security best practices beyond the recommendations of the use of encrypted transport protocols in this document to protect it from getting in the hands of bad actors with illegitimate intent to impersonate telephone numbers.
このドキュメントで表されるトークンには、電話番号の範囲、電話番号のブロック、またはSPCで表される電話番号のセット全体を表す資格情報があります。このトークンの作成、輸送、および任意のストレージは、このドキュメントで暗号化された輸送プロトコルの使用に関する推奨事項を超えて、最も厳格なセキュリティベストプラクティスに従う必要があります。。
This document inherits the security properties of [RFC9447]. Implementations should follow the best practices identified in [RFC8725].
このドキュメントは、[RFC9447]のセキュリティプロパティを継承します。実装は、[RFC8725]で特定されたベストプラクティスに従う必要があります。
This document only specifies SHA256 for the fingerprint hash. However, the syntax of the fingerprint object would permit other algorithms if, due to concerns about algorithmic agility, a more robust algorithm were required at a future time. Future specifications can define new algorithms for the fingerprint object as needed.
このドキュメントは、指紋ハッシュのSHA256のみを指定します。ただし、アルゴリズムの俊敏性に関する懸念のために、将来の時期により堅牢なアルゴリズムが必要になった場合、指紋オブジェクトの構文は他のアルゴリズムを許可します。将来の仕様は、必要に応じて、指紋オブジェクトの新しいアルゴリズムを定義できます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9447] Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
"Automated Certificate Management Environment (ACME)
Challenges Using an Authority Token", RFC 9447,
DOI 10.17487/RFC9447, September 2023,
<https://www.rfc-editor.org/info/rfc9447>.
[ATIS-1000080]
ATIS, "Signature-based Handling of Asserted information
using toKENs (SHAKEN): Governance Model and Certificate
Management", ATIS-1000080.v005, December 2022,
<https://access.atis.org/apps/group_public/
download.php/69428/ATIS-1000080.v005.pdf>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
We would like to thank Richard Barnes and Russ Housley for valuable contributions to this document.
この文書への貴重な貢献をしてくれたリチャード・バーンズとラス・ヒューズリーに感謝します。
Chris Wendt
Somos Inc.
United States of America
Email: chris-ietf@chriswendt.net
David Hancock
Somos Inc.
United States of America
Email: davidhancock.ietf@gmail.com
Mary Barnes
Neustar Inc.
United States of America
Email: mary.ietf.barnes@gmail.com
Jon Peterson
Neustar Inc.
Suite 570
1800 Sutter St
Concord, CA 94520
United States of America
Email: jon.peterson@neustar.biz