[要約] RFC 9060は、Secure Telephone Identity Revisited (STIR) 証明書委任に関する文書です。この文書の目的は、電話ネットワーク上での通話者IDの信頼性を高めるためのメカニズムを提供することです。利用場面としては、スパムや詐欺の電話を減らし、通話の認証と認可を強化することが挙げられます。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 9060 Neustar
Category: Standards Track September 2021
ISSN: 2070-1721
Secure Telephone Identity Revisited (STIR) Certificate Delegation
安全な電話アイデンティティは証明書の代表団を再検討しました
Abstract
概要
The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.
セキュア電話アイデンティティは、証明書プロファイルを再検討した（かき混ぜる）証明書プロファイルは、電話番号のなりすましを防ぐ目的で、電話番号と関連識別子よりも証明する方法を提供します。この仕様は、その権限を親証明書から下位の証明書に委任できる方法を詳述します。これは、サービスプロバイダーが企業または他の顧客にChakを署名することができる顧客に資格情報を付与するものを含む、多くのユースケースをサポートします。
Status of This Memo
本文書の位置付け
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/rfc9060.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9060で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Motivation
4. Delegation of STIR Certificates
4.1. Scope of Delegation
5. Authentication Service Signing with Delegate Certificates
6. Verification Service Behavior for Delegate Certificate
Signatures
7. Acquiring Multiple Certificates in STIR
8. Certification Authorities and Service Providers
8.1. ACME and Delegation
8.2. Handling Multiple Certificates
9. Alternative Solutions
10. IANA Considerations
11. Privacy Considerations
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Author's Address
The STIR problem statement [RFC7340] reviews the difficulties facing the telephone network that are enabled by impersonation, including various forms of robocalling, voicemail hacking, and swatting [RFC7375]. One of the most important components of a system to prevent impersonation is the implementation of credentials that identify the parties who control telephone numbers. The STIR certificate specification [RFC8226] describes a credential system based on version 3 certificates [X.509] in accordance with [RFC5280] for that purpose. Those credentials can then be used by STIR authentication services [RFC8224] to sign PASSporT objects [RFC8225] carried in SIP [RFC3261] requests.
攪拌問題ステートメント[RFC7340]は、さまざまな形式のロボカール、ボイスメールハッキング、およびSwatting [RFC7375]を含む、偽装によって可能な電話ネットワークに直面する困難を検討します。偽装を防ぐためのシステムの最も重要なコンポーネントの1つは、電話番号を管理する当事者を識別する資格情報の実装です。Stic Certificate Specification [RFC8226]その目的のための[RFC5280]に従って、バージョン3証明書[X.509]に基づく信任状システムについて説明しています。その後、Stic Authentication Services [RFC8224]にSCIP [RFC3261]の要求を搭載している[RFC8224]を照合することで、それらの資格情報を使用できます。
[RFC8226] specifies an extension to X.509 that defines a Telephony Number (TN) Authorization List that may be included by certification authorities (CAs) in certificates. This extension provides additional information that relying parties can use when validating transactions with the certificate. When a SIP request, for example, arrives at a terminating administrative domain, the calling number attested by the SIP request can be compared to the TN Authorization List of the certificate that signed the PASSporT to determine if the caller is authorized to use that calling number.
[RFC8226]証明書の認証局（CAS）によって含まれ得るテレフォニー番号（TN）許可リストを定義するX.509への拡張子を指定します。この拡張機能は、証明書とのトランザクションを検証するときに依存関係者が使用できる追加情報を提供します。たとえば、SIPリクエストが終端管理ドメインに到着すると、SIP要求によって証明された呼び出し番号をパスポートに署名した証明書のTN認証リストと比較して、発信者がその呼び出し番号を使用することを許可されているかどうかを判断できます。。
Initial deployment of [RFC8226] has focused on the use of Service Provider Codes (SPCs) to attest to the scope of authority of a certificate. Typically, these codes are internal telephone network identifiers such as the Operating Company Numbers (OCNs) assigned to carriers in the United States. However, these network identifiers are effectively unavailable to non-carrier entities, and this has raised questions about how such entities might best participate in STIR when needed. Additionally, a carrier may sometimes operate numbers that are formally assigned to another carrier. [RFC8226] gives an overview of a certificate enrollment model based on "delegation", whereby the holder of a certificate might allocate a subset of that certificate's authority to another party. This specification details how delegation of authority works for STIR certificates.
[RFC8226]の初期展開は、証明書の権限の範囲に証明するためのサービスプロバイダーコード（SPC）の使用に焦点を当てています。通常、これらのコードは、米国の担体に割り当てられた事業会社番号（OCN）などの内部電話網識別子です。しかしながら、これらのネットワーク識別子は非キャリアのエンティティにとって効果的に利用できず、そしてこれは必要に応じてどのようにかき混ぜることがどのように関わるかについての質問をしてきた。さらに、キャリアは時々他の搬送波に正式に割り当てられる数を作動させることができる。[RFC8226]「委任」に基づく証明書登録モデルの概要を説明します。これにより、証明書の保有者がその証明書の権限のサブセットを別の当事者に割り当てることがあります。この仕様は、権限の委任が撹拌証明書に対してどのように機能するかを詳述します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This specification also uses the following terms:
この仕様は以下の用語も使用しています。
delegation: The concept of STIR certificate delegation and its terms are defined in [RFC8226].
代表団：攪拌証明書の委任の概念とその条件は[RFC8226]で定義されています。
legitimate spoofing: The practice of selecting an alternative presentation number for a telephone caller legitimately.
正当ななりすまし：統一電話発信者の代替案の表示番号を選択する慣例。
The most pressing need for delegation in STIR arises in a set of use cases where callers want to use a particular calling number, but for whatever reason, their outbound calls will not pass through the authentication service of the service provider that controls that numbering resource.
呼び出し側が特定の呼び出し番号を使用したいユースケースのセットでは、かき混ぜる委任中の委任の必要性が生じているが、それがどのような理由でも、その番号付けリソースを制御するサービスプロバイダの認証サービスを通過することはない。
One example would be an enterprise that places outbound calls through a set of service providers; for each call, a provider is chosen based on a least-cost routing algorithm or similar local policy. The enterprise was assigned a calling number by a particular service provider, but some calls originating from that number will go out through other service providers.
一例は、一連のサービスプロバイダを介して発信コールを配置する企業です。各呼び出しについて、プロバイダは、最小コストルーティングアルゴリズムまたは同様のローカルポリシーに基づいて選択されます。企業には特定のサービスプロバイダによって呼び出し側番号が割り当てられましたが、その番号から発信されたいくつかの呼び出しは他のサービスプロバイダを介して外出されます。
A user might also roam from their usual service provider to a different network or administrative domain for various reasons. Most "legitimate spoofing" examples are of this form, where a user wants to be able to use the main callback number for their business as a calling party number, even when the user is away from the business.
ユーザーは、通常のサービスプロバイダからさまざまなネットワークまたは管理ドメインにローミングされる可能性があります。ユーザが業務から離れている場合でも、ユーザが発呼者番号として自分のビジネスのメインコールバック番号を使用できるようにしたいという点で、最も「正当ななりすまし」の例がこの形式です。
These sorts of use cases could be addressed if the carrier who controls the numbering resource were able to delegate a credential that could be used to sign calls regardless of which network or administrative domain handles the outbound routing for the call. In the absence of something like a delegation mechanism, outbound carriers may be forced to sign calls with credentials that do not cover the originating number in question. Unfortunately, that practice would be difficult to distinguish from malicious spoofing, and if it becomes widespread, it could erode trust in STIR overall.
これらのユニットリソースを制御するキャリアが、どのネットワークまたは管理ドメインを呼び出し側の通話ルーティングを処理するかにかかわらず、コールに署名する可能性がある資格情報を委任できる場合に、これらの種類の使用例を取り上げることができます。委任メカニズムのようなものがない場合、アウトバウンドキャリアは、問題の発信数をカバーしない資格情報との呼び出しに署名することを余儀なくされている可能性があります。残念ながら、悪意のあるスプーフィングと区別するのが難しいだろう、そしてそれが普及しているならば、それは全体的に攪拌して信頼を侵食する可能性があります。
STIR delegate certificates are certificates containing a TNAuthList object that have been signed with the private key of a parent certificate that itself contains a TNAuthList object (either by value or by reference; see Section 4.1). The parent certificate needs to contain a basic constraints extension with the cA boolean set to "true" [RFC5280], indicating that the subject can sign certificates. Every STIR delegate certificate identifies its parent certificate with a standard Authority Key Identifier extension [RFC5280].
Sticle Delegate証明書は、それ自体がTNAuthListオブジェクトが含まれている親証明書の秘密鍵で署名されているTNAuthListオブジェクトを含む証明書です（値または参照ご覧ください。セクション4.1を参照）。親証明書には、CA Booleanが「True」[RFC5280]に設定された基本的な制約拡張機能を含める必要があり、件名が証明書に署名できることを示します。すべてのSTR STARデリゲート証明書は、その親証明書を標準の認証局識別子拡張子[RFC5280]で識別します。
The authority bestowed on the holder of the delegate certificate by the parent certificate is recorded in the delegate certificate's TNAuthList. Because STIR certificates use the TNAuthList object rather than the Subject Name for indicating the scope of their authority, traditional name constraints [RFC5280] are not directly applicable to STIR. In a manner similar to the Resource Public Key Infrastructure (RPKI) [RFC6480] "encompassing" semantics, each delegate certificate MUST have a TNAuthList scope that is equal to or a subset of its parent certificate's scope: it must be "encompassed". For example, a parent certificate with a TNAuthList that attested authority for the numbering range +1-212-555-1000 through 1999 could issue a certificate to one delegate attesting authority for the range +1-212-555-1500 through 1599 and, to another delegate, a certificate for the individual number +1-212-555-1824.
親証明書によって代理証明書の保有者に授与された当局は、Delegate CertificateのTNAuthListに記録されています。攪拌証明書は、権限の範囲を示すための件名ではなくTANUTHLISTオブジェクトを使用するため、従来の名前制約[RFC5280]は直接かき混ぜることはできません。リソース公開鍵インフラストラクチャ（RPKI）[RFC6480]「包含」セマンティクスと同様に、各代理証明書には、親証明書の範囲のサブセットであるTANUTHLISTスコープがある必要があります。それは「包含」する必要があります。たとえば、番号付けの範囲1-212-555-1000から1999年までの権限を証明したTANUTHLISTを持つ親証明書は、1-212-555-1500から1599までの範囲に対して証明書を証明することができ、別の範囲に証明書を発行できます。個人番号1~212-555-1824の証明書、デリゲート。
Delegate certificates MAY also contain a basic constraints extension with the cA boolean set to "true", indicating that they can sign subordinate certificates for further delegates. As only end-entity certificates can actually sign PASSporTs, the holder of a STIR certificate with a "true" cA boolean may create a separate end-entity certificate with either an identical TNAuthList to its parent or a subset of the parent's authority, which would be used to sign PASSporTs.
Delegate証明書には、CA Booleanが「true」に設定された基本的な制約拡張子も含めることができ、それらがさらなる参加者のために従属証明書に署名できることを示しています。エンドエンティティ証明書のみが実際にパスポートに署名できるため、「True」CA Booleanを持つ撹拌証明書の保有者は、その親または親の権限のサブセットに同一のTANUTHLISTを持つ別のエンドエンティティ証明書を作成することができます。パスポートに署名するために使用されます。
The TNAuthList of a STIR certificate may contain one or more SPCs, one or more telephone number ranges, or even a mix of SPCs and telephone number ranges. When delegating from a STIR certificate, a child certificate may inherit from its parent either or both of the above, and this specification explicitly permits SPC-only parent certificates to delegate individual telephone numbers or ranges to a child certificate, as this will be necessary in some operating environments. Depending on the sort of numbering resources that a delegate has been assigned, various syntaxes can be used to capture the delegated resource.
撹拌証明書のTANUTHLISTは、1つ以上のSPC、1つ以上の電話番号の範囲、あるいはSPCと電話番号の範囲の組み合わせでさえ含まれていてもよい。撹拌証明書から委任すると、子証明書がその親から上記のいずれかまたは両方を継承することができ、この仕様はSPC専用の親証明書が個々の電話番号を委任して個々の電話番号を委任し、これが必要になるので子社の証明書に明示的に許可する。いくつかの動作環境。デリゲートが割り当てられている番号付けリソースの種類に応じて、委任リソースをキャプチャするためにさまざまな構文を使用できます。
Some non-carrier entities may be assigned large and complex allocations of telephone numbers, which may be only partially contiguous or entirely disparate. Allocations may also change frequently in minor or significant ways. These resources may be so complex, dynamic, or extensive that listing them in a certificate is prohibitively difficult. Section 10.1 of [RFC8226] describes one potential way to address this: including the TNAuthList (specified in [RFC8226]) in the certificate by reference rather than by value, where a URL in the certificate points to a secure, dynamically updated list of the telephone numbers in the scope of authority of a certificate. For entities that are carriers in all but name, another alternative is the allocation of an SPC; this yields much the same property, as the SPC is effectively a pointer to an external database that dynamically tracks the numbers associated with the SPC. Either of these approaches may make sense for a given deployment. Certification path construction as detailed below treats by-reference TNAuthLists in a certificate as if they had been included by value.
いくつかの非キャリアエンティティには、電話番号の大きく複雑な割り当てが割り当てられ、これは部分的に隣接しているか全体的に異なる場合があります。割り当てはまた、頻繁にまたは重要な方法で頻繁に変化し得る。これらのリソースは、証明書にリストを一覧表示するように複雑で動的、または広範囲になる可能性があります。 [RFC8226]のセクション10.1は、これに対処するための1つの潜在的な方法について説明します。証明書の中のURLがセキュアで動的に更新されたリストを指している値ではなく、証明書のTNAuthList（RFC8226]）を参照してください。証明書の権限の範囲内の電話番号。すべての名前での輸送者であるエンティティの場合、別の代替案はSPCの割り当てです。 SPCは、SPCに関連付けられている番号を動的に追跡する外部データベースへのポインタであるため、これにより、ほとんど同じプロパティが得られます。これらのアプローチのどちらかが、特定の展開に対して理にかなっている可能性があります。以下の認証パス構築下記のように、参照されていたかのように、証明書の参照TNAUTHLISTSを扱います。
Other non-carrier entities may have straightforward telephone number assignments, such as enterprises receiving a set of a thousand blocks from a carrier that may be kept for years or decades. Particular freephone numbers may also have a long-term association with an enterprise and its brand. For these sorts of assignments, assigning an SPC may seem like overkill, and using the TN ranges of the TNAuthList (by value) is sufficient.
他の非キャリアエンティティは、長年または何十年もの間保持され得るキャリアからの千ブロックのセットを受信する企業のような直接的な電話番号割り当てを有することができる。特定のFILE電話番号は、企業とそのブランドとの長期的な関連付けもあります。これらの種類の割り当てのために、SPCを割り当てることはOverkillのように見え、TNAuthListのTN範囲を（値別）で使用することが十分である。
Whichever approach is taken to represent the delegated resource, there are fundamental trade-offs regarding when and where in the architecture a delegation is validated -- that is, when the delegated TNAuthList is checked and determined to be "encompassed" by the TNAuthList of its parent. This might be performed at the time the delegate certificate is issued, at the time that a verification service receives an inbound call, or potentially both. It is generally desirable to offload as much of this as possible to the certification process as verification occurs during call setup; thus, additional network dips could lead to perceptible delay, whereas certification happens outside of call processing as a largely administrative function. Ideally, if a delegate certificate can supply a by-value TN range, then a verification service could ascertain that an attested calling party number is within the scope of the provided certificate without requiring any additional transactions with a service. In practice, verification services may already incorporate network queries into their processing (for example, to dereference the "x5u" field of a PASSporT) that could piggyback any additional information needed by the verification service.
委任リソースを表すためにどのアプローチが取られているか、アーキテクチャ内のどこで、委任が検証されたとき、すなわち委任されたTauthListがそのTNAuthListによって「包含される」と判断されたときに基本的なトレードオフがあります。親。これは、検証サービスが受信呼び出しを受信した時点で、または潜在的に両方を受信する時点で、デリゲート証明書が発行される可能性があります。呼び出し設定中に検証が行われるため、認証プロセスにできるだけ多くのものをオフロードすることが一般に望ましいです。したがって、追加のネットワークDIPは知覚可能な遅延を引き起こす可能性がありますが、認証はコール処理の外で主に管理機能として発生します。理想的には、代理人証明書が副利額のTN範囲を供給できる場合、検証サービスは証明された発呼者番号がサービスとの追加の取引を必要とせずに提供された証明書の範囲内であることを確認することができる。実際には、検証サービスはすでにネットワーククエリをそれらの処理に組み込んでもよい（たとえば、パスポートの「X5U」フィールドを参照するために）検証サービスによって必要とされる追加情報をピギーバックすることができる。
Note that the permission semantics of the TNAuthList [RFC8226] are additive: that is, the scope of a certificate is the superset of all of the SPCs and telephone number ranges enumerated in the TNAuthList. As SPCs themselves are effectively pointers to a set of telephone number ranges, and a telephone number may belong to more than one SPC, this may introduce some redundancy to the set of telephone numbers specified as the scope of a certificate. The presence of one or more SPCs and one or more sets of telephone number ranges are similarly treated additively, even if the telephone number ranges turn out to be redundant to the scope of an SPC.
TNAuthList [RFC8226]の許可セマンティクスは加算詞です。つまり、証明書の範囲は、TNAuthListで列挙されたすべてのSPCと電話番号範囲のスーパーセットです。SPC自体が一連の電話番号範囲を効果的にポインタし、電話番号が複数のSPCに属する可能性があるため、これは証明書の範囲として指定された電話番号のセットにいくつかの冗長性を導入する可能性があります。電話番号範囲がSPCの範囲に対して冗長であることが判明したとしても、1つまたは複数のSPCの存在および1つまたは複数の電話番号範囲が同様に扱われる。
Authentication service behavior varies from [RFC8224] as follows, although the same checks are performed by the authentication service when comparing the calling party number attested in call signaling with the scope of the authority of the signing certificate. Authentication services SHOULD NOT use a delegate certificate without validating that its scope of authority is encompassed by that of its parent certificate, and if that certificate has its own parent, the entire certification path SHOULD be validated.
認証サービスの動作は、次のように[RFC8224]によって異なりますが、呼シグナリングで証明された呼び出し側番号と署名証明書の権限の範囲を比較すると、認証サービスによって実行されます。認証サービスは、その権限の範囲がその親証明書のその親証明書のそれに含まれることを検証せずにデリゲート証明書を使用しないでください。その証明書の親がある場合は、認証パス全体を検証する必要があります。
This delegation architecture does not require that a non-carrier entity act as its own authentication service. That function may be performed by any authentication service that holds the private key corresponding to the delegate certificate, including one run by an outbound service provider, a third party in an enterprise's outbound call path, or in the SIP User Agent itself.
この委任アーキテクチャは、非キャリアエンティティが独自の認証サービスとして機能することを要求していません。その関数は、アウトバウンドサービスプロバイダによる1つの実行、企業の発信コールパス内のサードパーティ、またはSIPユーザエージェント自体を含む、デリゲート証明書に対応する秘密鍵を保持する任意の認証サービスによって実行され得る。
Note that authentication services creating a PASSporT for a call signed with a delegate certificate MUST provide an "x5u" link corresponding to the entire certification path rather than just the delegate certificate used to sign the call, as described in Section 7.
認証サービスを委任している通話のためのパスポートを作成する認証サービスは、セクション7で説明されているように、呼び出しに署名するために使用されるデリゲート証明書ではなく、認証パス全体に対応する「X5U」リンクを提供する必要があります。
The responsibility of a verification service validating PASSporTs signed with delegate certificates, while largely following baseline specifications [RFC8224] and [RFC8225], requires some additional procedures. When the verification service dereferences the "x5u" parameter, it will acquire a certificate list rather than a single certificate. It MUST then validate all of the credentials in the list, identifying the parent certificate for each delegate through its Authority Key Identifier extension.
ベースライン証明書で署名されているパスポートを検証する検証サービスの責任は、基本的な証明書[RFC8224]と[RFC8225]では、いくつかの追加の手順を必要とします。検証サービスが「x5u」パラメータを参照すると、単一の証明書ではなく証明書リストを取得します。その後、リスト内のすべての認証情報を検証し、その権限キー識別子拡張子を介して各デリゲートの親証明書を識別する必要があります。
While relying parties ordinarily have significant latitude in certification path construction when validating a certification path, STIR assumes a more rigid hierarchical subordination model rather than one where relying parties may want to derive their own certification path to particular trust anchors. If the certificates acquired from the "x5u" element of a PASSporT do not lead to an anchor that the verification service trusts, it treats the validation no differently than it would when a non-delegated certificate was issued by an untrusted root; in SIP, it MAY return a 437 "Unsupported Credential" response if the call should be failed for lack of a valid Identity header.
認証経路を検証する際には、当事者が認証経路の建設において著しい寛容性を持ちますが、依拠当事者が特定の信託アンカーへの独自の認証経路を導出することができる人ではなく、より厳格な階層的な劣後モデルを想定しています。パスポートの「x5u」要素から取得した証明書が検証サービスを信頼するアンカーにつながっていない場合は、非委任されていない証明書が信頼されていないルートによって発行された場合とは異なる検証を扱います。SIPでは、有効なIDヘッダーが不足しているためにコールに失敗する必要がある場合は、437の「サポートされていない信任状」の応答を返すことがあります。
PASSporT [RFC8225] uses the "x5u" element to convey the URL where verification services can acquire the certificate used to sign a PASSporT. This value is mirrored by the "info" parameter of the Identity header when a PASSporT is conveyed via SIP. Commonly, this is an HTTPS URI.
Passport [RFC8225]「x5u」要素を使用して、検証サービスがパスポートに署名するために使用される証明書を取得できるURLを伝達します。PassportがSIPを介して伝達されたときに、この値はIDヘッダーの「情報」パラメータによってミラーリングされます。一般的に、これはHTTPS URIです。
When a STIR delegate certificate is used to sign a PASSporT, the "x5u" element in the PASSporT will contain a URI indicating where a certificate list is available. While the baseline JSON Web Signature (JWS) also supports an "x5c" element specifically for certificate chains, in operational practice, certification paths are already being delivered in the STIR environment via the "x5u" element, so this specification RECOMMENDS that implementations continue to use "x5u". "x5c" is OPTIONAL for environments where it is known to be supported. That list will be a concatenation of certificates encoded with Privacy Enhanced Mail (PEM) of the type "application/pem-certificate-chain" defined in [RFC8555]. The certificate path [RFC5280] ordering MUST be ordered from the signer to the trust anchor. The list begins with the certificate used to sign the PASSporT, followed by its parent, and then any subsequent grandparents, great-grandparents, and so on. The key identifier in the Authority Key Identifier extension in the first certificate MUST appear in the Subject Key Identifier extension in the second certificate. The key identifier pairing MUST match in this way throughout the entire chain of certificates. Note that Automatic Certificate Management Environment (ACME) [RFC8555] requires the first element in a pem-certificate-chain to be an end-entity certificate.
Sticle Delegate証明書がパスポートに署名するとき、パスポート内の「x5u」要素には、証明書リストが利用可能な場所を示すURIが含まれます。ベースラインJSON Webシグネチャ（JWS）は、証明書チェーン用の「x5c」要素もサポートしていますが、運用上の実践では、認証パスは既に「X5U」要素を介して攪拌環境で配信されているため、実装は続行することをお勧めします。 "x5u"を使用してください。 "x5c"は、サポートされることが知られている環境ではオプションです。そのリストは、[RFC8555]で定義されている「アプリケーション/ PEM-certificate-chain」の型のプライバシー強化メール（PEM）でエンコードされた証明書の連結です。証明書パス[RFC5280]注文は、署名者から信託アンカーに注文する必要があります。リストは、パスポートに署名するために使用される証明書、その後、その後、その後の祖父母、祖父母などで始まります。最初の証明書のAuthority Key Identifier拡張子のキー識別子は、2番目の証明書の件名識別子拡張子に表示されている必要があります。キー識別子ペアリングは、この方法で証明書のチェーン全体を通して一致する必要があります。自動証明書管理環境（ACME）[RFC8555]には、PEM-CERTITION-CHAINの最初の要素がエンドエンティティ証明書になる必要があります。
Once a telephone service provider has received a CA certificate attesting to their numbering resources, they may delegate resources from it as they see fit. Note that the allocation to a service provider of a certificate with a basic constraints extension with the cA boolean set to "true" does not require that a service provider act as a certification authority itself; serving as a certification authority is a function requiring specialized expertise and infrastructure. Certification authorities are, for example, responsible for maintaining certificate revocation lists and related functions as well as publishing certification practice statements. A third-party certification authority, including the same one that issued the service provider its parent certificate, could act as the CA that issues delegate certificates for the service provider if the necessary business relationships permit it. A service provider might in this case act as a Token Authority (see Section 8.1) granting its customers permissions to receive certificates from the CA.
電話サービスプロバイダーがその番号付けリソースに証明されているCA証明書を受信したら、それらはフィットが見られるようにそれからリソースを委任することができます。 CA Boolean SETが「TRUE」に設定されている基本的な制約拡張子を持つ証明書のサービスプロバイダへの割り当ては、サービスプロバイダーが認証局をそのものとして機能する必要はありません。認証局としての役割は、専門の専門知識とインフラストラクチャを必要とする機能です。認証当局は、たとえば、証明書失効リストの維持および関連機能の責任と認定慣行ステートメントを発行しています。サービスプロバイダーを発行したものと同じものを含むサードパーティの認証局は、必要なビジネス関係がそれを許可した場合にサービスプロバイダーの委任証明書を発行するCAとして機能する可能性があります。この場合、サービスプロバイダは、CAから証明書を受信するための顧客の許可を付与するトークン権限として機能することができます（セクション8.1参照）。
Note that if the same CA that issued the parent certificate is also issuing a delegate certificate, it may be possible to shorten the certification path, which reduces the work required of verification services. The trade-off here is that if the CA simply issued a non-delegate certificate (whose parent is the CA's trust anchor) with the proper TNAuthList value, relying parties might not be able to ascertain which service provider owned those telephone numbers, information that might be used to make an authorization decision on the terminating side. However, some additional object in the certificate outside of the TNAuthList could preserve that information; this is a potential area for future work, and longer certification paths are the only mechanism currently defined.
親証明書を発行したのと同じCAがデリゲート証明書を発行している場合、認証パスを短縮することが可能であり、検証サービスに必要な作業を軽減します。ここでのトレードオフは、CAが単純に代理人の証明書（親がCAの信頼アンカー）を発行した場合、適切なTANUTHLIST値を使用して、どのサービスプロバイダがそれらの電話番号を所有しているかを確認できない可能性があるためです。終端側で承認決定を下すのに使用される可能性があります。ただし、TANUTHLISTの外部の証明書内の追加のオブジェクトはその情報を保存する可能性があります。これは将来の作業の潜在的な領域であり、より長い認証パスは現在定義されている唯一のメカニズムです。
All CAs must detail in their practices and policies a requirement to validate that the "encompassing" of a delegate certificate is done by its parent. Note that this requires that CAs have access to the necessary industry databases to ascertain whether, for example, a particular telephone number is encompassed by an SPC. Alternatively, a CA may acquire an Authority Token (see Section 8.1) that affirms that a delegation is in the proper scope. Exactly what operational practices this entails may vary in different national telephone administrations and are thus left to the Certificate Policy / Certification Practice Statement (CP/CPS) [RFC3647].
すべてのCAは、代理証明書の「包含」がその親によって行われていることを検証するための要件を検証する必要があります。これには、特定の電話番号がSPCによって囲まれているかどうかを確認するためにCASが必要な業界データベースにアクセスできるようにする必要があることに注意してください。あるいは、CAは、委任が適切な範囲内にあることを確認する権限トークン（セクション8.1を参照）を取得することができる。まさにこれが伴う伴う伴奏の扱い方法は、さまざまな国内電話管理によって異なり、したがって証明書ポリシー/認定練習文（CP / CPS）[RFC3647]に残されています。
STIR deployments commonly use ACME [RFC8555] for certificate acquisition, and it is anticipated that delegate certificates will also be acquired through an ACME interface. An entity can acquire a certificate from a particular CA by requesting an Authority Token [ACME-CHAL] from the parent with the desired TNAuthList [ACME-TOKEN] object. Note that if the client intends to do further subdelegation of its own, it should request a token with the "ca" Authority Token flag set.
攪拌展開は、認証取得のためにACME [RFC8555]を使用しており、委任証明書がACMEインタフェースを介して取得されることが予想されます。エンティティは、親からの権限トークン[ACME-CHAL]を、必要なTANUTHLIST [ACME-TOKEN]オブジェクトを要求することによって、特定のCAから証明書を取得できます。クライアントがそれ自身のさらなるサブデレギーを実行することを意図している場合は、「CA」認証トークンフラグを設定してトークンを要求する必要があります。
The entity then presents that Authority Token to a CA to acquire a STIR delegate certificate. ACME returns an "application/pem-certificate-chain" object, and that object would be suitable for publication as an HTTPS resource for retrieval with the PASSporT "x5u" mechanism as discussed in Section 7. If the Certificate Signing Request (CSR) presented to the ACME server is for a certificate with the cA boolean set to "true", then the ACME server makes a policy decision to determine whether or not it is appropriate to issue that certificate to the requesting entity. That policy decision will be reflected by the "ca" flag in the Authority Token.
その後、エンティティはその権限トークンをCAに提示して、Sticle Delegate証明書を取得します。ACMEは、「アプリケーション/ PEM-certification-chain」オブジェクトを返し、そのオブジェクトは、セクション7で説明したように、Passport "x5u"メカニズムを使用して検索するためのHTTPSリソースとしての出版物に適しています7.証明書署名要求（CSR）ACMEサーバには、CA Booleanが「true」に設定されている証明書の場合、ACMEサーバはその証明書を要求元エンティティに発行するのに適したかどうかを判断するためのポリシー決定を行います。そのポリシー決定は、権限トークンの「CA」フラグによって反映されます。
Service providers that want the capability to rapidly age out delegated certificates can rely on the ACME Short-Term, Automatically Renewed (STAR) [RFC8739] mechanism to automate the process of short-term certificate expiry.
委任された証明書を迅速に熟成させる能力が迅速に働くことができるサービスプロバイダーは、短期証明書の満了のプロセスを自動化するために自動的に更新された（STAR）[RFC8739]メカニズムに頼ることができます。
In some deployments, non-carrier entities may receive telephone numbers from several different carriers. This could lead to enterprises needing to maintain a sort of STIR keyring, with different certificates delegated to them from different providers. These certificates are potentially issued by different CAs, which enterprises choose between when signing a call. This could be the case regardless of which syntax is used in the TNAuthList to represent the scope of the delegation (see Section 4.1). As noted in Section 8, if the parent certs use the same CA, it may be possible to shorten the certification path.
いくつかの展開では、非キャリアエンティティはいくつかの異なるキャリアから電話番号を受信することができる。これは、さまざまなプロバイダからのそれらに委任された異なる証明書を持つ、一種のかき混ぜるキーリングを維持する必要がある企業につながる可能性があります。これらの証明書は異なるCAによって発行される可能性があり、その企業は通話に署名するときを選択します。これは、委任の範囲を表すためにTNAuthListでどの構文が使用されているかにかかわらず、（セクション4.1を参照）。セクション8で述べたように、親会社が同じCAを使用すると、認証パスを短縮することが可能であり得る。
For non-carrier entities handling a small number of certificates, this is probably not a significant burden. For cases where it becomes burdensome, a few potential approaches exist. A delegate certificate could be cross-certified with another delegate certificate via an Authority Information Access (AIA) field containing the URL of a Certificate Authority Issuer so that a signer would only need to sign with a single certificate to inherit the privileges of the other certificate(s) with which it has cross-certified. In very complex delegation cases, it might make more sense to establish a bridge CA that cross-certifies with all of the certificates held by the enterprise rather than requiring a mesh of cross-certification between a large number of certificates. Again, this bridge CA function would likely be performed by some existing CA in the STIR ecosystem. These procedures would, however, complicate the fairly straightforward certification path reconstruction approach described in Section 7 and would require further specification.
非キャリアエンティティのために少数の証明書を処理するために、これはおそらく重要な負担ではありません。それが煩わしくなる場合は、いくつかの潜在的なアプローチが存在します。署名者が他の証明書の特権を継承するために単一の証明書と署名する必要があるため、証明書局発行者のURLを含む権限情報アクセス（AIA）フィールドを介して、代理証明書を別の代理証明書と交差させることができます。それが交差認証した。非常に複雑な委任的な訴訟では、多数の証明書の間で交差認証のメッシュを必要とするのではなく、企業によって保持されているすべての証明書を含むブリッジCAを確立することがより理密になるかもしれません。繰り返しになりますが、このブリッジCA機能は、撹拌生態系の既存のCAによって実行される可能性があります。しかしながら、これらの手順は、セクション7に記載されているかなり簡単な認証経路再構成手法を複雑にし、さらなる仕様を必要とするであろう。
At the time this specification was written, STIR was only starting to see deployment. In some future environment, the policies that govern CAs may not permit them to issue intermediate certificates with a TNAuthList object and a cA boolean set to "true" in the basic constraints certificate extension [RFC5280]. Similar problems in the web PKI space motivated the development of TLS subcerts [TLS-CRED], which substitutes a signed "delegated credential" token for a certificate for such environments. A comparable mechanism could be developed for the STIR space, which would allow STIR certificates to sign a data object that contains effectively the same data as the delegate certificate specified here, including a public key that could sign PASSporTs. The TLS subcerts system has further explored leveraging ACME to issue short-lived certificates for temporary delegation as a means of obviating the need for revocation. Specification of a mechanism similar to TLS subcerts for STIR is future work and will be undertaken only if the market requires it.
この仕様が書かれたときに、かき混ぜるだけで展開が始まっていました。いくつかの将来の環境では、CAを支配するポリシーは、それらがTNAUTHLISTオブジェクトと中間証明書を発行することができず、基本的な制約証明書拡張[RFC5280]でCA Booleanを「TRUE」に設定します。 Web PKIスペースでの同様の問題は、そのような環境の証明書の署名付きの「委任信任状」トークンを代入するTLSサブセルション[TLS-CRES]の開発を動作させました。攪拌空間のために同等のメカニズムを開発することができ、これは、パスポートに署名することができる公開鍵を含む公開鍵を含む、ここで指定されたデリゲート証明書と同じデータを含むデータオブジェクトに署名することを可能にするであろう。 TLSサブセルテスシステムは、失効の必要性を回避するための手段として、一時的な委任のための短命の証明書を発行するためにACMEを活用するためにさらに検討されています。かき混ぜるためのTLSサブ事業と同様のメカニズムの仕様は将来の仕事です、そして市場にそれを必要とする場合にのみ行われます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
Any STIR certificate that identifies a narrow range of telephone numbers potentially exposes information about the entities that are placing calls. As such a telephone number range is a necessary superset of the calling party number that is openly signaled during call setup, the privacy risks associated with this mechanism are not substantially greater than baseline STIR. See [RFC8224] for guidance on the use of anonymization mechanisms in STIR.
狭い範囲の電話番号を識別するあらゆる攪拌証明書は、通話をかけるエンティティに関する情報を潜在的に公開します。そのような電話番号の範囲は、呼設定中に公開されている発呼者番号の必要なスーパーセットであり、このメカニズムに関連するプライバシーリスクはベースラインをかき混ぜる以上のものではない。匿名化メカニズムをかき混ぜることについてのガイダンスについては、[RFC8224]を参照してください。
This document is entirely about security. As delegation can allow signing-in scenarios where unauthenticated "legitimate" spoofing would otherwise be used, the hope is that delegation will improve the overall security of the STIR ecosystem. For further information on certificate security and practices, see [RFC5280], particularly its security considerations. Also see the security considerations of [RFC8226] for general guidance on the implications of the use of certificates in STIR and [RFC7375] for the STIR threat model.
この文書は完全にセキュリティについてです。代表団がそうでなければ使用されない「正当な」スプーフィングが使用されるようなサインインシナリオを許可することができるので、希望は委任が撹拌エコシステムの全体的なセキュリティを改善することである。証明書のセキュリティと慣行の詳細については、[RFC5280]、特にそのセキュリティ上の考慮事項を参照してください。また、攪拌中の証明書の使用と[RFC7375]の意味に関する一般的なガイダンスのための[RFC8226]のセキュリティ上の考慮事項を参照してください。
Much of the security of delegation depends on the implementation of the encompassing semantics described in Section 4. When delegating from an SPC-based TNAuthList to a set of telephone number ranges, understanding the encompassing semantics may require access to industry databases that track the numbering assets of service providers associated with a given SPC. In some operating environments, such databases might not exist. How encompassing is policed is therefore a matter outside the scope of this document and specific to operational profiles of STIR.
委任のセキュリティの多くは、セクション4で説明されている包括的な意味論の実装に依存します.SPCベースのTNAUTHLISTからの電話番号範囲に委任される場合は、包括的なセマンティクスを理解する必要がある場合があります。特定のSPCに関連するサービスプロバイダの。いくつかの動作環境では、そのようなデータベースが存在しない可能性があります。したがって、包含がポリシングされることは、この文書の範囲外で、かき混ぜる操作プロファイルに特有の問題です。
The use of by-reference TNAuthLists as described in Section 4 means that the TNAuthList associated with a certificate can change over time; see the security considerations of [RFC3986] for more on the implications of this property. It is considered a useful feature here due to the potential dynamism of large lists of telephone numbers, but this dynamism means that a relying party might at one point accept that a particular telephone number is associated with a certificate but later reject it for the same certificate as the dynamic list changes. Also note that if the HTTPS service housing the by-reference telephone number list is improperly secured, that too can lead to vulnerabilities. Ultimately, the CA that issued a delegated certificate populates the URL in the AIA field and is responsible for making a secure selection. Service providers acting as CAs are directed to the cautionary words about running a CA in Section 8 regarding the obligations this entails for certificate revocation and so on.
セクション4に記載されているような副参照TNAUTHLISSの使用は、証明書に関連付けられているTNAuthListが時間の経過とともに変化する可能性があることを意味します。このプロパティの意味の詳細については、[RFC3986]のセキュリティ上の考慮事項を参照してください。ここでは、電話番号の大規模なリストの潜在的なダイナミズムのためにここでは便利な機能と考えられていますが、このダイナミズムは、特定の電話番号が証明書に関連付けられているが、後で同じ証明書のためにそれを拒絶することを一つのポイントに許可することを意味します。動的リストが変わるにつれて。また、副電話番号リストを収容するHTTPSサービスが不適切に保護されている場合、それもまた脆弱性につながる可能性があります。最終的には、委任された証明書を発行したCAは、AIAフィールドにURLを入力し、安全な選択をする責任があります。 CASとして機能するサービスプロバイダは、証明書の失効に対する義務を伴う義務については、セクション8のCAを実行することについての注意言葉に向けられています。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[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>.
[RFC8224] Peterson、J.、Jennings、C、Rescorla、E.、およびC.Wendt、「セッション開始プロトコル（SIP）」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<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>.
[RFC8225] Wendt、C.およびJ.Peterson、 "Passport：Personal Assertion Token"、RFC 8225、DOI 10.17487 / RFC8225、2018年2月、<https：//www.rfc-editor.org/info/rfc8225>。
[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>.
[RFC8226] Peterson、J.およびS. Turner、「Secure Phereth Identity Credentials：証明書」、RFC 8226、DOI 10.17487 / RFC8226、2018年2月、<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>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D.、およびJ.Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：//www.rfc-editor.org/info/rfc8555>。
[ACME-CHAL] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Challenges Using an Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-06, 12 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-06>.
[Acme-Chal] Peterson、J.、Barnes、M.、Hancock、D.、およびC. Wendt、「権威トークンを使用したACMEの課題」、進行中の作業、インターネットドラフト、ドラフト - IETF-achme-orcirual-トークン06,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-06>。
[ACME-TOKEN] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-tnauthlist-08, 27 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-08>.
[acme-token] Wendt、C.、Hancock、D.、Barnes、M.、およびJ.Peterson、「ACME Authority TokenのTanuthlistプロファイル」、進行中の作業、インターネットドラフト、ドラフト-IETF-ACME-Authority-TOKEN-TNAUTHLIST-08,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-08>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, DOI 10.17487/RFC3647, November 2003, <https://www.rfc-editor.org/info/rfc3647>.
[RFC3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C.、およびS. WU、「インターネットX.509公開鍵インフラストラクチャ証明書ポリシーおよび認証慣行フレームワーク」、RFC 3647、DOI 10.17487 /rfc3647、2003年11月、<https://www.rfc-editor.org/info/rfc3647>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M.およびS. Kent、「安全なインターネットルーティングをサポートするためのインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https：//www.rfc-editor.org/info/rfc6480>。
[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>.
[RFC7340] Peterson、J.、Schulzrinne、H.、H。Tschofenig、「安全な電話アイデンティティーの声明および要件」、RFC 7340、DOI 10.17487 / RFC7340、2014年9月、<https：//www.rfc-編集者。org / info / rfc7340>。
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", RFC 7375, DOI 10.17487/RFC7375, October 2014, <https://www.rfc-editor.org/info/rfc7375>.
[RFC7375] Peterson、J.、「Secure Telephone Identity Model」、RFC 7375、DOI 10.17487 / RFC7375、2014年10月、<https：//www.rfc-editor.org/info/rfc7375>。
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, March 2020, <https://www.rfc-editor.org/info/rfc8739>.
[RFC8739] Sheffer、Y、Lopez、D.、Gonzalez De Dios、O.、Perales、A。、およびT.Fossati、 "自動証明書管理環境の短期、自動的に更新された（スター）証明書のサポート（ACME） "、RFC 8739、DOI 10.17487 / RFC8739、2020年3月、<https://www.rfc-editor.org/info/rfc8739>。
[TLS-CRED] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10>.
[TLS-CRES] Barnes、R.、Iyngar、S.、Sullivan、N.、およびE. Rescorla、「TLSの代表資格情報」、進行中の作業、インターネットドラフト、Draft-IETF-TLS-SUBCERTS-10、2021年1月24日、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10>。
[X.509] ITU-T, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, October 2016, <https://www.itu.int/rec/T-REC-X.509>.
[X.509] ITU-T、「情報技術 - オープンシステムインターコネクション - ディレクトリ：パブリックキーと属性証明書フレームワーク」、ITU-T勧告X.509、2016年10月、<https：//www.itu.int/rec/t-rec-x.509>。
Acknowledgments
謝辞
We would like to thank Ines Robles, Richard Barnes, Chris Wendt, Dave Hancock, Russ Housley, Benjamin Kaduk, and Sean Turner for key input on this document.
私たちは、この文書のキー入力のために、Robles、Richard Barnes、Chris Wendt、Dave Hancock、Russ Ousley、Benjamin Kaduk、Sean Turnerに感謝します。
Author's Address
著者の住所
Jon Peterson Neustar, Inc.
Jon Peterson Neustar、Inc。
Email: jon.peterson@team.neustar