[要約] RFC 9447は、ACMEの拡張機能の一つであるAuthority Token Challengeを定義し、特定のポリシーに基づいてトークンを発行する外部機関を利用して証明資格を行うことを可能にする。目的は、異なる識別子や名前空間のために個別に定義されたsubtype claimsをサポートすることである。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 9447 M. Barnes
Category: Standards Track Neustar
ISSN: 2070-1721 D. Hancock
C. Wendt
Somos
September 2023
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 that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications.
自動化された証明書管理環境（ACME）の提案された拡張機能の中には、特定のポリシーに従ってトークンを発行する外部当局に相談することにより、証明書の適格性を証明することに依存しています。このドキュメントは、特定のアプリケーションに対して個別に定義できるさまざまな識別子または名前空間のサブタイプのクレームをサポートする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/rfc9447.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9447で取得できます。
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 Authority Token Challenge
3.1. Token Type Requirements
3.2. Authority Token Scope
3.3. Binding Challenges
4. Authority Token Challenge tkauth-type Registration
5. Acquiring a Token
5.1. Basic REST Interface
6. IANA Considerations
6.1. ACME Validation Method Registration
6.2. JSON Web Token Claim Registration
6.3. Creation of ACME Authority Token Challenge Types Registry
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
ACME [RFC8555] is a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources, like domain names, and automates the process of issuing certificates that attest control or ownership of those resources.
ACME [RFC8555]は、インターネット上の証明書管理を自動化するためのメカニズムです。これにより、管理エンティティはドメイン名などのリソースに対する効果的な制御を証明し、それらのリソースの管理または所有権を証明する証明書を発行するプロセスを自動化できます。
In some cases, proving effective control over an identifier requires an attestation from a third party who has authority over the resource, for example, an external policy administrator for a namespace other than the DNS application ACME was originally designed to support. In order to automate the process of issuing certificates for those resources, this specification defines a generic Authority Token Challenge that ACME servers can issue in order to require clients to return an Authority Token that authorizes a given issuance. The challenge contains a type indication that tells the client what sort of token it needs to acquire. It is expected that the Authority Token Challenge will be usable for a variety of identifier types. In particular, this document describes an architecture for Authority Tokens, defines a JSON Web Token (JWT) [RFC7519] Authority Token format along with a protocol for token acquisition, and shows how to integrate these tokens into an ACME challenge.
場合によっては、識別子に対する効果的な制御を証明するには、リソースに対する権限を持つ第三者からの証明が必要です。たとえば、DNSアプリケーション以外の名前空間の外部ポリシー管理者は、元々サポートするように設計されていました。これらのリソースの証明書を発行するプロセスを自動化するために、この仕様は、ACMEサーバーが特定の発行を承認する権限トークンを返すようクライアントに要求するために発行できる一般的な機関のトークンチャレンジを定義します。課題には、クライアントにどのようなトークンを獲得する必要があるかを伝えるタイプの表示が含まれています。Authority Token Challengeは、さまざまな識別子タイプで使用可能になると予想されます。特に、このドキュメントでは、権威のトークンのアーキテクチャについて説明し、JSON Webトークン（JWT）[RFC7519] Authority Token形式とトークン獲得のプロトコルを定義し、これらのトークンをACMEチャレンジに統合する方法を示しています。
As a concrete example, [RFC9448] provides a mechanism that allows service providers to acquire certificates corresponding to a Service Provider Code (SPC) as defined in [RFC8226] by consulting an external authority responsible for those codes. Furthermore, Communications Service Providers (CSPs) can delegate authority over numbers to their customers, and those CSPs who support ACME can then help customers to acquire certificates for those numbering resources with ACME. This can permit number acquisition flows compatible with those shown in [RFC8396].
具体的な例として、[RFC9448]は、[RFC8226]で定義されているサービスプロバイダーコード（SPC）に対応する証明書を取得できるメカニズムを提供し、これらのコードの責任者の外部当局に相談します。さらに、通信サービスプロバイダー（CSP）は顧客に数値を委任することができます。また、ACMEをサポートするCSPは、ACMEを使用したリソースの番号付けの証明書を取得するのに役立ちます。これにより、[RFC8396]に示されているものと互換性のある数の取得フローが可能になります。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Proving that a device on the Internet has effective control over a non-Internet resource is not as straightforward as proving control over Internet resources, like a DNS zone or a web page. Provided that the issuer of identifiers in a namespace, or someone acting on the issuer's behalf, can implement a service that grants Authority Tokens to the people to whom it has issued identifiers, a generic token could be used as a response to an ACME challenge. This specification, therefore, defines an Authority Token issued by an authority over a namespace to an ACME client for delivery to an ACME server in response to a challenge. Authority over a hierarchical namespace can also be delegated so that delegates of a root authority can themselves act as Token Authorities for certain types of names.
インターネット上のデバイスが非インターネットリソースを効果的に制御することは、DNSゾーンやWebページなどのインターネットリソースの制御を証明するほど簡単ではありません。名前空間の識別子の発行者、または発行者に代わって行動する人は、識別子を発行した人々に当局を付与するサービスを実装できますが、一般的なトークンはACMEチャレンジへの応答として使用できます。したがって、この仕様は、チャレンジに応じてACMEサーバーに配信するために、ACMEクライアントへの名前空間を介して当局によって発行されたトークンを定義します。階層的な名前空間をめぐる機関は、ルート当局の代表者自身が特定の種類の名前のトークン当局として行動できるように委任することもできます。
This architecture assumes a trust relationship between certification authorities (CAs) and Token Authorities, i.e., that CAs are willing to accept the attestation of Token Authorities for particular types of identifiers as sufficient proof to issue a credential. It furthermore assumes that ACME clients have a relationship with Token Authorities, which permits them to authenticate and authorize the issuance of Authority Tokens to the proper entities. This ACME challenge has no applicability to identifiers or authorities where those pre-associations cannot be assumed.
このアーキテクチャは、認証当局（CAS）とトークン当局の間の信頼関係を想定しています。つまり、CASは、資格を発行するのに十分な証拠として、特定のタイプの識別子に対するトークン当局の証明を受け入れることをいとわないことを想定しています。さらに、ACMEクライアントはトークン当局と関係があると想定しており、これにより、当局のトークンの発行を適切なエンティティに認証および承認することができます。このACMEの課題には、これらの事前分類を想定できない識別子または当局への適用性はありません。
The ACME Authority Token Challenge type, "tkauth-01", is here specified for use with the "TNAuthList" (Telephone Number Authentication List) ACME Identifier Type described in [RFC9448]; in order to use the "tkauth-01" Validation Method with an ACME Identifier Type other than "TNAuthList", that identifier type would need to be listed in a new registration in the ACME Validation Methods registry maintained by IANA. "tkauth-01" furthermore supports different token subtypes. The token subtype is determined by a new ACME challenge field, tkauth-type. An IANA registry is used to manage the values of tkauth-type (see Section 6.3). Additionally, this challenge type also has a new "token-authority" field to designate a location where a token can be acquired.
ACME Authority Token Challenge Type「TKAUTH-01」は、[RFC9448]で説明されている「TNAUTHLIST」（電話番号認証リスト）ACME識別子タイプで使用するために指定されています。「TNAUTHLIST」以外のACME識別子タイプを使用して「TKAUTH-01」検証方法を使用するには、INAが管理するACME検証方法レジストリの新しい登録にその識別子タイプをリストする必要があります。「Tkauth-01」はさらに、さまざまなトークンサブタイプをサポートしています。トークンサブタイプは、新しいACMEチャレンジフィールドTKAUTHタイプによって決定されます。IANAレジストリは、TKAUTHタイプの値を管理するために使用されます（セクション6.3を参照）。さらに、このチャレンジタイプには、トークンを取得できる場所を指定するための新しい「トークンの承認」フィールドもあります。
IANA will maintain a registry of tkauth-types under a policy of Specification Required. In order to register a new tkauth-type, specifications must address the following requirements; in cases where a tkauth-type admits of its own subtypes, subtypes inherit these requirements.
IANAは、必要な仕様ポリシーの下でTKAUTHタイプのレジストリを維持します。新しいTKAUTHタイプを登録するには、仕様が次の要件に対処する必要があります。TKAUTHタイプが独自のサブタイプを認めている場合、サブタイプはこれらの要件を継承します。
While Authority Token types do not need to be specific to a namespace, every token must carry enough information for a CA to determine the name for which certificate issuance is authorized. Some types of Authority Token types might be reusable for a number of different namespaces; others might be specific to a particular type of name. Therefore, in defining tkauth-types, future specifications must indicate how a token conveys to the CA the name(s) that the Token Authority is attesting that the ACME client controls.
権限のトークンタイプは名前空間に固有のものである必要はありませんが、すべてのトークンは、証明書の発行が許可される名前を決定するためにCAに十分な情報を運ぶ必要があります。いくつかのタイプの機関トークンタイプは、さまざまな名前空間で再利用可能になる場合があります。その他は、特定のタイプの名前に固有の場合があります。したがって、TKAUTHタイプを定義する際に、将来の仕様は、トークンがACMEクライアントが制御することを証明しているという名前をトークンがCAに伝える方法を示す必要があります。
While nothing precludes use cases where an ACME client is itself a Token Authority, an ACME client will typically need a protocol to request and retrieve an Authority Token. The Token Authority will require certain information from an ACME client in order to ascertain that it is an authorized entity to request a certificate for a particular name. The protocols used to request an Authority Token MUST convey to the Token Authority the identifier type and value that will be used in the ACME challenge, as well as the binding (see Section 3.3), and those MUST be reflected in the Authority Token. A baseline mechanism for how the Token Authority authenticates and authorizes ACME clients to receive Authority Tokens is given in Section 5.
ACMEクライアント自体がトークン当局であるユースケースを排除するものはありませんが、ACMEクライアントは通常、機関のトークンを要求および取得するためにプロトコルを必要とします。トークン当局は、特定の名前の証明書を要求するのが承認されたエンティティであることを確認するために、ACMEクライアントからの特定の情報を要求します。トークンを要求するために使用されるプロトコルは、ACMEチャレンジで使用される識別子の種類と値、および結合（セクション3.3を参照）を識別子の種類と値をトークン当局に伝えなければならず、それらは当局のトークンに反映されなければなりません。Token AuthorityがACMEクライアントが権限トークンを受け取ることを認証および承認する方法のベースラインメカニズムをセクション5に示します。
Because the assignment of resources can change over time, demonstrations of authority must be regularly refreshed. Definitions of a tkauth-type MUST specify how they manage the freshness of authority assignments. Typically, a CA will expect a regular refreshing of the token.
リソースの割り当ては時間とともに変化する可能性があるため、権限のデモンストレーションは定期的に更新する必要があります。TKAUTHタイプの定義は、権限の課題の新鮮さをどのように管理するかを指定する必要があります。通常、CAはトークンの定期的なリフレッシュを期待します。
An Authority Token is used to answer a challenge from an ACME server, upon a request for the issuance of a certificate. It could be that the Authority Token is requested from the Token Authority after a challenge has been received, or it could be that the Authority Token was acquired prior to the initial ACME client request. A Token Authority could grant an Authority Token that has the exact same scope as the requested certificate to a client; alternatively, an Authority Token could attest to all of the resources that the client is eligible to receive certificates for, which could be a superset of the scope of the requested certificate.
証明書の発行を要求すると、ACMEサーバーからの課題に答えるために、当局のトークンが使用されます。チャレンジが受け取られた後、トークン当局からトークンが要求されているか、最初のACMEクライアントのリクエストの前にトークンが取得された可能性があります。トークン当局は、クライアントに要求された証明書とまったく同じ範囲を持つ当局のトークンを付与することができます。あるいは、トークンがクライアントが証明書を受け取る資格があるすべてのリソースを証明することができます。これは、要求された証明書の範囲のスーパーセットである可能性があります。
For example, imagine a case where a Token Authority for DNS names knows that a client is eligible to receive certificates for "example.com" and "example.net". The client asks an ACME server for a certificate for "example.com", and the server directs the client to acquire an Authority Token from the Token Authority. When the client sends an acquisition request (see Section 5) to the Token Authority, the Token Authority could issue a token scoped just to "example.com" or a token that attests the client is eligible to receive certificates for both "example.com" or "example.net". The advantage of the latter is that if, at a later time (but one within the expiry of the token), the client wanted to acquire a certificate for "example.net", it would not have to return to the Token Authority, as the Token effectively pre-authorized the issuance of that certificate.
たとえば、DNS名のトークン当局が、クライアントが「embles.com」および「emble.net」の証明書を受け取る資格があることを知っているケースを想像してください。クライアントは、ACMEサーバーに「Example.com」の証明書を要求し、サーバーはクライアントにトークン当局から機関のトークンを取得するよう指示します。クライアントが取得要求（セクション5を参照）をトークン当局に送信すると、トークン当局は「Example.com」だけにスコープされたトークンを発行することができます。"または" embles.net "。後者の利点は、後の時間（ただし、トークンの有効期限内にあるもの）で、クライアントが「example.net」の証明書を取得したい場合、トークン当局に戻る必要がないことです。トークンは、その証明書の発行を効果的に許可しました。
Applications of the Authority Token to different identifier types might require different scopes, so registrations of tkauth-types should be clear about if and how a scope greater than that of the requested certificate would be conveyed in a token.
さまざまな識別子タイプへの機関トークンのアプリケーションは、異なるスコープが必要になる場合があるため、TKAUTHタイプの登録は、要求された証明書のスコープよりも大きなスコープがトークンで伝達されるかどうか、どのようにスコープをどのように登録するかを明確にする必要があります。
Applications that use the Authority Token need a way to correlate tokens issued by a Token Authority with the proper ACME client to prevent replay or cut-and-paste attacks using a token issued for a different purpose. To mitigate this, Authority Tokens contain a binding signed by a Token Authority; an ACME server can use the binding to determine that a Token presented by a client was in fact granted by the Token Authority based on a request from the client and not from some other entity. It is RECOMMENDED that the ACME account fingerprint be used for this purpose.
当局を使用するアプリケーショントークンは、トークン当局によって発行されたトークンを適切なACMEクライアントと相関させる方法が必要です。これを緩和するために、当局のトークンにはトークン当局によって署名された拘束力が含まれています。ACMEサーバーは、バインディングを使用して、クライアントによって提示されたトークンが実際に他のエンティティからではなく、クライアントからの要求に基づいてトークン当局によって付与されたことを判断できます。ACMEアカウントの指紋をこの目的に使用することをお勧めします。
Creating a binding from an Authority Token to a particular ACME account entails that the Token could be reused up until its expiry for multiple challenges issued by an ACME server. This might be a desirable property when using short-lived certificates, for example, in any cases where the ACME server issues challenges more frequently that an Authority Token can or should issue tokens or in cases where the Authority Token scope (see Section 3.2) is broad, so certificates with a more narrow scope may periodically be issued.
当局のトークンから特定のACMEアカウントへのバインディングを作成するには、ACMEサーバーが発行する複数の課題に対して有効期限が切れるまでトークンを再利用できることが必要です。たとえば、ACMEサーバーの発行が、当局がトークンを発行または発行するか、当局のトークンスコープ（セクション3.2を参照）が可能な場合（セクション3.2を参照）、たとえば、短命の証明書を使用する場合、これは望ましいプロパティである可能性があります。したがって、より狭い範囲の証明書が定期的に発行される場合があります。
For some identifier types, it may be more appropriate to bind the Authority Token to a nonce specific to the challenge rather than to an ACME account fingerprint. Any specification of the use of the nonce or other factors for this purpose is left to the identifier type profile for the Authority Token.
一部の識別子タイプの場合、ACMEアカウントの指紋ではなく、課題に固有のNonCEに機関のトークンをバインドする方が適切かもしれません。この目的のためのNonCEまたはその他の要因の使用の仕様は、機関トークンの識別子タイププロファイルに任されています。
Note that the fingerprint value in the client's JWT is reflected in the Authority Token returned by the Token Authority; the Token Authority has no requirement to validate that fingerprint. Were a fingerprint to be captured by an attacker that had its own account with the Token Authority, it could replay that fingerprint in its own JWT in order to receive an Authority Token with that fingerprint. However, were the attacker to present that Authority Token to an ACME service, the service would see the fingerprint does not match the attacker's ACME account fingerprint. So unless an attacker can compromise a target ACME account or gain similar privileges, the binding would be secure.
クライアントのJWTの指紋値は、トークン当局によって返されたトークンに反映されていることに注意してください。トークン当局には、その指紋を検証するための要件はありません。トークン当局に独自のアカウントを持っている攻撃者によってキャプチャされる指紋であった場合、その指紋を使用して機関のトークンを受け取るために、独自のJWTでその指紋を再生できます。ただし、その権限トークンをACMEサービスに提示する攻撃者は、このサービスは、指紋が攻撃者のACMEアカウントの指紋と一致しないことを確認します。したがって、攻撃者がターゲットACMEアカウントを侵害したり、同様の特権を取得したりしない限り、拘束力は安全になります。
This document specifies a tkauth-type of "atc", which contains a standard JWT [RFC7519] using a signature string defined by a JSON Web Signature (JWS) [RFC7515]. The "atc" tkauth-type MAY be used for any number of different ACME Identifier Types in the ACME challenge.
このドキュメントは、JSON Web署名（JWS）[RFC7515]で定義された署名文字列を使用して、標準JWT [RFC7519]を使用して「ATC」のTKAUTHタイプを指定します。「ATC」TKAUTHタイプは、ACMEチャレンジで任意の数の異なるACME識別子タイプに使用できます。
A new JWT claim, "atc", is defined below and lists the identifier type used in this Authority Token. The "atc" tkauth-type is restricted to the JWTs; if a non-JWT format is desired for the ACME Authority Token Challenge, a different tkauth-type should be specified and registered in the "ACME Authority Token Challenge Types" registry defined in Section 6.3.
新しいJWTクレーム「ATC」を以下に定義し、この権限トークンで使用される識別子タイプをリストします。「ATC」TKAUTHタイプはJWTSに制限されています。ACME Authority Token Challengeに非JWT形式が必要な場合、セクション6.3で定義されているレジストリ「ACME Authority Token Challenge Types」に別のTKAUTHタイプを指定および登録する必要があります。
For this ACME Authority Token usage of a JWT, it is OPTIONAL for the payload of the JWT to contain an "iss", indicating the Token Authority that generated the token if the "x5u" or "x5c" element in the header does not already convey that information; typically, this will be the same location that appeared in the "token-authority" field of the ACME challenge, when present. In order to satisfy the requirement for replay prevention, the JWT MUST contain a "jti" element and an "exp" claim; the "exp" claim manages token freshness. In addition to helping to manage replay, the "jti" provides a convenient way to reliably track when the same "atc" Authority Token is being used for multiple challenges over time within its set lifetime.
このACME AuthorityのトークンのJWTの使用については、JWTのペイロードが「ISS」を含めることはオプションであり、ヘッダーの「X5U」または「X5C」要素がまだそうではない場合にトークン当局を示しています。その情報を伝えます。通常、これは、ACMEチャレンジの「トークンアソート」フィールドに表示される場所と同じ場所になります。リプレイ防止の要件を満たすために、JWTには「JTI」要素と「EXP」クレームを含める必要があります。「Exp」クレームはトークンの新鮮さを管理します。リプレイの管理を支援することに加えて、「JTI」は、同じ「ATC」機関のトークンがセットの寿命以内に複数の課題に使用されている場合、確実に追跡する便利な方法を提供します。
The JWT payload MUST also contain a new JWT claim, "atc", for Authority Token Challenge, which contains three mandatory elements in a JSON map: the ATC identifier type ("tktype"), the identifier value ("tkvalue"), and the binding ("fingerprint"). The use of "tktype" is restricted to the values in the "ACME Identifier Types" registry, as defined by [RFC8555]. The identifier type and value are those given in the ACME challenge and conveyed to the Token Authority by the ACME client. For the purposes of the "atc" tkauth-type, the binding "fingerprint" is assumed to be a fingerprint of the ACME credential for the account used to request the certificate, but the specification of how the binding is generated is left to the identifier type profile for the Authority Token (see Section 3.3). The "tkvalue" indicates the scope of the authority that the token and its semantics are outside the scope of this document, as they will be specified by the "tkvalue" identifier in a separate specification.
JWTペイロードには、JSONマップに3つの必須要素を含むAuthority Token Challengeの新しいJWTクレーム「ATC」も含まれている必要があります。ATC識別子タイプ（「TKTYPE」）、識別子値（「TKValue」）、およびバインディング（「指紋」）。[TKTYPE]の使用は、[RFC8555]で定義されているように、「ACME識別子タイプ」レジストリの値に制限されています。識別子の種類と値は、ACMEチャレンジで与えられたものであり、ACMEクライアントによってトークン当局に伝えられたものです。「ATC」TKAUTHタイプの目的のために、バインディング「指紋」は証明書を要求するために使用されるアカウントのACME資格情報の指紋であると想定されていますが、バインディングの生成方法の仕様は識別子に残されています機関トークンのタイププロファイル（セクション3.3を参照）。「TkValue」は、トークンとそのセマンティクスがこのドキュメントの範囲外であるという権限の範囲を示しています。
Following the example of [RFC9448], the "tktype" identifier type could be the TNAuthList (as defined in [RFC8226]), which would be the value for the "tkvalue" element that the Token Authority is attesting. Practically speaking, that scope may comprise a list of Service Provider Code elements, telephone number range elements, and/ or individual telephone numbers. So for example:
[RFC9448]の例に従って、「TKTYPE」識別子タイプは、トークン当局が証明している「TKValue」要素の価値となるTNAUTHLIST（[RFC8226]で定義されている）である可能性があります。実際に言えば、その範囲は、サービスプロバイダーのコード要素、電話番号の範囲要素、および/または個々の電話番号のリストを構成する場合があります。したがって、例：
{
"protected": base64url({
"typ":"JWT",
"alg":"ES256",
"x5u":"https://authority.example.org/cert"
}),
"payload": base64url({
"iss":"https://authority.example.org/authz",
"exp":1300819380,
"jti":"id6098364921",
"atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==",
"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"
}
Optionally, the "atc" claim may contain a fourth boolean element, "ca". If set to "true", the "ca" element indicates that the Token Authority is granting permission to issue a certification authority certificate rather than an end-entity certificate for the names in question. This permits subordinate delegations from the issued certificate (using [RFC9115] or similar mechanisms). If the "ca" element is absent, the Token Authority is explicitly withholding permission. The "atc" object in the example above would then look like:
オプションで、「ATC」クレームには、4番目のブール要素「CA」が含まれる場合があります。「true」に設定されている場合、「CA」要素は、トークン当局が、問題の名前のエンドエンティティ証明書ではなく、認証機関証明書を発行する許可を与えていることを示します。これにより、発行された証明書（[RFC9115]または同様のメカニズムを使用）から下位代表団が許可されます。「CA」要素がない場合、トークン当局は明示的に許可を差し控えています。上記の例の「ATC」オブジェクトは次のようになります。
"atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==",
"ca":true,"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:
71:D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} }
Specifications of "tktype" identifier types may define additional optional "atc" elements.
「TKTYPE」識別子タイプの仕様は、追加のオプションの「ATC」要素を定義する場合があります。
The acquisition of an Authority Token requires a network interface, apart from potential use cases where the entity that acts as an ACME client itself also acts as a Token Authority trusted by the ACME server. Implementations compliant with this specification MUST support an HTTPS interface for Authority Token acquisition as described below, though other interfaces MAY be supported as well.
機関のトークンの取得には、ACMEクライアント自体として機能するエンティティがACMEサーバーによって信頼されるトークン当局としても機能する潜在的なユースケースとは別に、ネットワークインターフェイスが必要です。この仕様に準拠した実装は、以下に説明するように、権限のトークン取得のためのHTTPSインターフェイスをサポートする必要がありますが、他のインターフェイスもサポートされる場合があります。
In order to request an Authority Token from a Token Authority, a client sends a HTTPS POST request [RFC9110]. This specification assumes that Token Authority URIs are known to clients through preexisting business relationships and that the credentials and related authentication and authorization for Authority Token acquisition are encompassed in that relationship. Different services may organize their web resources in domain-specific ways, but the resource locator should specify the account of the client, an identifier for the service provider, and finally a locator for the token.
トークン当局から当局のトークンを要求するために、クライアントはHTTPSの投稿要求[RFC9110]を送信します。この仕様は、トークンの権限URIが既存のビジネス関係を通じてクライアントに知られていること、および当局の取得の資格と関連する認証と認証がその関係に含まれていることを前提としています。さまざまなサービスがドメイン固有の方法でWebリソースを整理する場合がありますが、リソースロケーターは、クライアントのアカウント、サービスプロバイダーの識別子、そして最後にトークンのロケーターを指定する必要があります。
POST /at/account/:id/token HTTP/1.1
Host: authority.example.com
Content-Type: application/json
Note that ":id" here is a placeholder for an actual account identifier. The body of the POST request MUST contain the Authority Token Challenge element (the key "atc", colon, and its value) that the client is requesting the Token Authority generate. In this way, the client proposes the scope of the Authority Token it would like to receive from the Token Authority.
「：ID」は、実際のアカウント識別子のプレースホルダーであることに注意してください。POSTリクエストの本文には、クライアントがトークン当局に生成する要求している権限トークンチャレンジ要素（キー「ATC」、コロン、およびその価値）を含める必要があります。このようにして、クライアントは、トークン当局から受け取りたい当局のトークンの範囲を提案します。
In common use cases, the "tkvalue" in this request is asking that the Token Authority issue a token that attests the entire scope of authority to which the client is entitled. The client may also request an Authority Token with some subset of its own authority via the "tkvalue" element in the Authority Token Challenge object. The way that "tkvalue" is defined will necessarily be specific to the identifier type. For the TNAuthList identifier type, for example, an object requesting an Authority Token could request authority for only a single telephone number in a way that is defined in the TNAuthList specification.
一般的なユースケースでは、このリクエストの「tkValue」は、トークン当局がクライアントの権利を有する権限の範囲全体を証明するトークンを発行することを求めています。また、クライアントは、オーソリティトークンチャレンジオブジェクトの「TKValue」要素を介して、独自の権限の一部のサブセットを使用して機関のトークンを要求する場合があります。「tkvalue」が定義される方法は、必然的に識別子タイプに固有のものになります。たとえば、TNAUTHLIST識別子タイプの場合、トークンを要求するオブジェクトは、TNAUTHLIST仕様で定義されている方法で単一の電話番号のみの権限を要求できます。
Finally, the JSON object MAY also contain an optional boolean element, "ca", which signifies that the client is requesting that the Token Authority issue an Authority Token with the "ca" flag set, as described in Section 4.
最後に、JSONオブジェクトには、セクション4で説明されているように、クライアントが「CA」フラグセットでトークントークンを発行することをクライアントが要求していることを意味します。
After an HTTPS-level challenge (e.g., a 401 HTTP response code) to verify the identity of the client and subsequently making an authorization decision about whether the client should receive an Authority Token with the requested scope, then in the success case, the Token Authority MUST return a 200 OK with a body of type "application/json" containing the Authority Token.
クライアントのIDを検証し、その後クライアントが要求された範囲で権限のトークンを受け取るべきかどうかについて認定決定を下すために、HTTPSレベルの課題（たとえば、401 HTTP応答コード）の後、その後、クライアントが要求された範囲で、そして成功事例では、トークンはトークン当局は、権限のトークンを含む「アプリケーション/JSON」のタイプの本文で200 OKを返す必要があります。
A full example of "atc" token acquisition using the HTTP interface, with the "tktype" of "TNAuthList", is given in Section 5.5 of [RFC9448].
「TNAUTHLIST」の「TKTYPE」を使用したHTTPインターフェイスを使用した「ATC」トークンの取得の完全な例は、[RFC9448]のセクション5.5に記載されています。
IANA has added a new ACME Validation Method (per [RFC8555]) in the "ACME Validation Methods" subregistry of the "Automated Certificate Management Environment (ACME) Protocol" registry group as follows:
IANAは、「ACME検証方法」に新しいACME検証方法（[RFC8555]ごと）を追加しました。
Label:
ラベル：
tkauth-01
TKAUTH-01
Identifier Type:
識別子タイプ：
TNAuthList
tnauthlist
ACME:
Acme：
Y
y
Reference:
参照：
RFC 9447
RFC 9447
IANA has added a new claim in the "JSON Web Token Claims" registry, as defined in [RFC7519], as follows:
IANAは、[RFC7519]で定義されているように、次のように「JSON Webトークンクレーム」レジストリに新しい主張を追加しました。
Claim name:
クレーム名：
atc
ATC
Claim Description:
クレームの説明：
Authority Token Challenge
オーソリティトークンチャレンジ
Change Controller:
Change Controller：
IETF
IETF
Specification document(s):
仕様文書：
RFC 9447
RFC 9447
IANA has created a new registry for "ACME Authority Token Challenge Types" as used in these challenges, under a policy of Specification Required and following the requirements in Section 3.1, with three columns: Label, Description, and Reference. The initial content of the registry is as follows:
IANAは、これらの課題で使用されている「Acme Authority Authority Token Challengeタイプ」の新しいレジストリを作成しました。必要な仕様のポリシーの下で、セクション3.1の要件に従うこと、ラベル、説明、および参照。レジストリの初期コンテンツは次のとおりです。
Label:
ラベル：
atc (as defined in Section 4)
ATC（セクション4で定義）
Description:
説明：
JSON Web Token (JWT) challenge type
JSON Webトークン（JWT）チャレンジタイプ
Reference:
参照：
RFC 9447
RFC 9447
Per the guidance in [RFC8555], ACME transactions MUST use TLS, and similarly, the HTTPS REST transactions used to request and acquire Authority Tokens MUST use TLS. These measures are intended to prevent the capture of Authority Tokens by eavesdroppers. A preexisting trust relationship between the HTTPS REST client and the Token Authority must also exist in order for the parties to meaningfully authenticate one another. The security considerations of [RFC8555] apply to the use of the mechanism in this specification. Implementations should follow the best practices identified in [RFC8725].
[RFC8555]のガイダンスに従って、ACMEトランザクションはTLSを使用する必要があり、同様に、当局のトークンの要求と取得に使用されるHTTPS RESTトランザクションはTLSを使用する必要があります。これらの措置は、盗聴者による権限のトークンの捕獲を防ぐことを目的としています。HTTPS RESTクライアントとトークン当局との間の既存の信頼関係も、当事者が互いに有意義に認証するために存在する必要があります。[RFC8555]のセキュリティ上の考慮事項は、この仕様におけるメカニズムの使用に適用されます。実装は、[RFC8725]で特定されたベストプラクティスに従う必要があります。
As described in Section 3.2, 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.
セクション3.2で説明されているように、当局のトークンは、クライアントが証明書を受け取る資格があるすべてのリソースを証明する範囲を持つことができます。特定の認定機関からの証明書。トークンがクライアントが請求できるリソースに関する情報を学ぶことができる認定機関。これにプライバシーリスクが発生する場合、当局のトークンスコープは、要求されたACME証明書によって証明されるリソースのみに制限される必要があります。
In cases where a tkauth-type, as defined in Section 4, admits of its own subtypes, the security of features like binding challenges (see Section 3.3) will depend on the subtype specification.
セクション4で定義されているTKAUTHタイプが独自のサブタイプを認めている場合、バインディングチャレンジなどの機能のセキュリティ（セクション3.3を参照）は、サブタイプの仕様に依存します。
The capture of Authority Tokens by an adversary could enable an attacker to acquire a certificate from a CA. Therefore, all Authority Tokens MUST contain a field that identifies to the CA which ACME client requested the token from the Token Authority; here, that is the fingerprint specified in Section 4. All Authority Tokens must specify an expiry (of the token itself as proof for a CA, as opposed to the expiry of the name), and for some applications, it may make sense for that expiry to be quite short. ACME services relying on Authority Tokens SHOULD NOT issue certificates with a longer expiry than the expiry of the Authority Token. Any protocol used to retrieve Authority Tokens from a Token Authority MUST use confidentiality to prevent eavesdroppers from acquiring an Authority Token. The details of this protocol are out of the scope of this specification.
敵による当局のトークンの捕獲により、攻撃者はcaから証明書を取得できるようになります。したがって、すべての機関トークンには、ACMEクライアントがトークン当局からトークンを要求したCAに識別するフィールドを含める必要があります。ここで、それはセクション4で指定された指紋です。すべての権限トークンは、名前の有効期限とは対照的に、CAの証明としてトークン自体の有効期限自体を指定する必要があり、一部のアプリケーションでは、それは意味があるかもしれません。有効期限は非常に短くなります。当局に依存しているACMEサービスは、当局トークンの有効期限よりも長い有効期限を持つ証明書を発行すべきではありません。トークン当局から機関のトークンを取得するために使用されるプロトコルは、盗聴者が当局のトークンを取得するのを防ぐために機密性を使用する必要があります。このプロトコルの詳細は、この仕様の範囲外です。
This document only specifies SHA256 for the fingerprint hash. However, the syntax of the fingerprint object would permit other keys if, due to concerns about algorithmic agility, a more robust algorithm were required at a future time. Future specifications can define new keys 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>.
[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>.
[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>.
[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>.
[RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList Profile of Automated Certificate Management
Environment (ACME) Authority Token", RFC 9448,
DOI 10.17487/RFC9448, September 2023,
<https://www.rfc-editor.org/info/rfc9448>.
[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>.
[RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering,
Distributing, Exposing, and Registering Telephone Numbers
(MODERN): Problem Statement, Use Cases, and Framework",
RFC 8396, DOI 10.17487/RFC8396, July 2018,
<https://www.rfc-editor.org/info/rfc8396>.
[RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T.
Fossati, "An Automatic Certificate Management Environment
(ACME) Profile for Generating Delegated Certificates",
RFC 9115, DOI 10.17487/RFC9115, September 2021,
<https://www.rfc-editor.org/info/rfc9115>.
We would like to Roman Danyliw and Ben Kaduk for contributions to this problem statement and framework.
この問題の声明と枠組みへの貢献については、ローマのダニリウとベン・カドゥクをお願いします。
Jon Peterson
Neustar, Inc.
Email: jon.peterson@team.neustar
Mary Barnes
Neustar, Inc.
Email: mary.ietf.barnes@gmail.com
David Hancock
Somos
Email: davidhancock.ietf@gmail.com
Chris Wendt
Somos
Email: chris-ietf@chriswendt.net