[要約] RFC 8226は、セキュアな電話番号の身元情報の認証に関する仕様書であり、証明書の使用方法を定義しています。その目的は、電話番号の所有者の身元情報を確実に認証し、通信のセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8226 Neustar
Category: Standards Track S. Turner
ISSN: 2070-1721 sn3rd
February 2018
Secure Telephone Identity Credentials: Certificates
安全な電話ID資格：証明書
Abstract
概要
In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.
インターネット上での電話番号のなりすましを防ぐために、電話番号に対する権限を暗号で主張するある種の資格情報システムが存在する必要があります。このドキュメントでは、SIPなどのプロトコルでIDとして電話番号を管理するための広範なアーキテクチャのコンポーネントとして、電話番号に対する権限を確立する際の証明書の使用について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8226.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8226で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Authority for Telephone Numbers in Certificates .................4
4. Certificate Usage with STIR .....................................5
5. Enrollment and Authorization Using the TN Authorization List ....6
5.1. Constraints on Signing PASSporTs ...........................8
5.2. Certificate Extension Scope and Structure ..................8
6. Provisioning Private Keying Material ............................9
7. Acquiring Credentials to Verify Signatures ......................9
8. JWT Claim Constraints Syntax ...................................10
9. TN Authorization List Syntax ...................................12
10. Certificate Freshness and Revocation ..........................14
10.1. Acquiring the TN List by Reference .......................15
11. IANA Considerations ...........................................16
11.1. ASN.1 Registrations ......................................16
11.2. Media Type Registrations .................................16
12. Security Considerations .......................................17
13. References ....................................................18
13.1. Normative References .....................................18
13.2. Informative References ...................................20
Appendix A. ASN.1 Module ..........................................21
Acknowledgments ...................................................24
Authors' Addresses ................................................24
The Secure Telephone Identity Revisited (STIR) problem statement [RFC7340] identifies the primary enabler of robocalling, vishing (voicemail hacking), swatting, and related attacks as the capability to impersonate a calling party number. The starkest examples of these attacks are cases where automated callees on the Public Switched Telephone Network (PSTN) rely on the calling number as a security measure -- for example, to access a voicemail system. Robocallers use impersonation as a means of obscuring identity. While robocallers can, in the ordinary PSTN, block (that is, withhold) their caller identity, callees are less likely to pick up calls from blocked identities; therefore, appearing to call from some number, any number, is preferable. Robocallers, however, prefer not to call from a number that can trace back to the robocaller, and therefore they impersonate numbers that are not assigned to them.
Secure Telephone Identity Revisited（STIR）problem statement [RFC7340]は、発呼者番号を偽装する機能として、ロボコール、ビッシング（ボイスメールハッキング）、スワッティング、および関連する攻撃の主要なイネーブラーを特定しています。これらの攻撃の最も明白な例は、公衆交換電話網（PSTN）の自動呼び出し先がセキュリティ手段として、たとえばボイスメールシステムにアクセスするために、発信者番号に依存している場合です。ロボコーラーは、身元を隠す手段として偽装を使用します。ロボ発信者は通常のPSTNで発信者IDをブロック（つまり、差し控える）できますが、着信者はブロックされたIDからのコールをピックアップする可能性が低くなります。したがって、ある番号、任意の番号から電話をかけているように見えることが好ましいです。ただし、Robocallerは、Robocallerまでさかのぼれる番号から電話をかけたくないため、割り当てられていない番号を偽装します。
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. With these credentials, parties can assert that they are in fact authorized to use telephony numbers (TNs), and thus they distinguish themselves from impersonators unable to present such credentials. For that reason, the STIR threat model [RFC7375] stipulates that "The design of the credential system envisioned as a solution to these threats must, for example, limit the scope of the credentials issued to carriers or national authorities to those numbers that fall under their purview." This document describes credential systems for telephone numbers based on [X.509] version 3 certificates in accordance with [RFC5280]. While telephone numbers have long been part of the X.509 standard (X.509 supports arbitrary naming attributes to be included in a certificate; the telephoneNumber attribute was defined in the 1988 [X.520] specification), this document provides ways to determine authority more aligned with telephone network requirements, including extending X.509 with a Telephony Number Authorization List certificate extension, which binds certificates to asserted authority for particular telephone numbers or, potentially, telephone number blocks or ranges.
なりすましを防ぐためのシステムの最も重要なコンポーネントの1つは、電話番号を制御する関係者を識別する資格情報の実装です。これらの資格情報を使用すると、当事者は実際にテレフォニー番号（TN）の使用が許可されていることを主張できるため、そのような資格情報を提示できないなりすましと区別されます。そのため、STIR脅威モデル[RFC7375]は、「これらの脅威に対するソリューションとして想定される資格情報システムの設計は、たとえば、キャリアや国家当局に発行される資格情報の範囲を、該当する数に制限する必要があります。彼らの権限。」このドキュメントは、[RFC5280]に準拠した[X.509]バージョン3証明書に基づく電話番号の資格情報システムについて説明します。電話番号は長い間X.509標準の一部でしたが（X.509は証明書に含める任意のネーミング属性をサポートします。telephoneNumber属性は1988 [X.520]仕様で定義されました）、このドキュメントでは、特定の電話番号、または場合によっては電話番号のブロックまたは範囲のアサートされた権限に証明書をバインドするテレフォニー番号認証リスト証明書拡張機能を使用したX.509の拡張を含む、電話ネットワーク要件にさらに整合した権限。
In the STIR in-band architecture specified in [RFC8224], two basic types of entities need access to these credentials: authentication services and verification services (or verifiers). An authentication service must be operated by an entity enrolled with the certification authority (CA) (see Section 5), whereas a verifier need only trust the trust anchor of the authority and also have a means to access and validate the public keys associated with these certificates. Although the guidance in this document is written with the STIR in-band architecture in mind, the credential system described in this document could be useful for other protocols that want to make use of certificates to assert authority over telephone numbers on the Internet.
[RFC8224]で指定されているSTIRインバンドアーキテクチャでは、2つの基本的なタイプのエンティティがこれらの資格情報にアクセスする必要があります：認証サービスと検証サービス（または検証者）。認証サービスは、証明機関（CA）に登録されたエンティティ（セクション5を参照）が運用する必要があります。一方、検証者は、認証局のトラストアンカーのみを信頼し、これらに関連付けられた公開鍵にアクセスして検証する手段を持っている必要があります。証明書。このドキュメントのガイダンスはSTIRインバンドアーキテクチャを念頭に置いて書かれていますが、このドキュメントで説明する資格情報システムは、インターネット上の電話番号を介して権限を主張するために証明書を利用したい他のプロトコルに役立つ可能性があります。
This document specifies only the credential syntax and semantics necessary to support this architecture. It does not assume any particular CA or deployment environment. We anticipate that some deployment experience will be necessary to determine optimal operational models.
このドキュメントでは、このアーキテクチャをサポートするために必要な資格情報の構文とセマンティクスのみを指定しています。特定の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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
At a high level, this specification details two non-exclusive approaches that can be employed to determine authority over telephone numbers with certificates.
大まかに言えば、この仕様では、証明書を使用して電話番号に対する権限を決定するために使用できる2つの非排他的なアプローチについて詳しく説明しています。
The first approach is to leverage the existing subject of the certificate to ascertain that the holder of the certificate is authorized to claim authority over a telephone number. The subject might be represented as a domain name in the subjectAltName, such as an "example.net" where that domain is known to relying parties as a carrier, or represented with other identifiers related to the operation of the telephone network, including Service Provider Codes (SPCs) such as Operating Company Numbers (OCNs) or Service Provider Identifiers (SPIDs) via the TN Authorization List specified in this document. A relying party could then employ an external data set or service that determines whether or not a specific telephone number is under the authority of the carrier identified as the subject of the certificate and use that to ascertain whether or not the carrier should have authority over a telephone number. Potentially, a certificate extension to convey the URI of such an information service trusted by the issuer of the certificate could be developed (though this specification does not propose one). Alternatively, some relying parties could form bilateral or multilateral trust relationships with peer carriers, trusting one another's assertions just as telephone carriers in the Signaling System 7 (SS7) network today rely on transitive trust when displaying the calling party telephone number received through SS7 signaling.
最初のアプローチは、証明書の既存のサブジェクトを活用して、証明書の所有者が電話番号で権限を要求する権限を持っていることを確認することです。サブジェクトは、「example.net」などのsubjectAltNameのドメイン名として表すことができます。このドメインは、キャリアとして信頼者に知られているか、サービスプロバイダーを含む電話ネットワークの操作に関連する他の識別子で表されます。このドキュメントで指定されているTN承認リストを介した運営会社番号（OCN）やサービスプロバイダー識別子（SPID）などのコード（SPC）。依拠当事者は、特定の電話番号が証明書の対象として識別されたキャリアの権限下にあるかどうかを決定する外部データセットまたはサービスを使用し、それを使用してキャリアが権限を持つべきかどうかを確認できます。電話番号。潜在的に、証明書の発行者によって信頼されているそのような情報サービスのURIを伝える証明書拡張が開発される可能性があります（この仕様では提案されていません）。または、一部の証明書利用者は、ピアキャリアと双方向または多国間の信頼関係を形成し、今日のSignaling System 7（SS7）ネットワークの電話キャリアがSS7シグナリングを通じて受信した発呼者の電話番号を表示するときに推移的な信頼に依存しているように、互いの主張を信頼することができます。
The second approach is to extend the syntax of certificates to include a new attribute, defined here as the TN Authorization List, which contains a list of telephone numbers defining the scope of authority of the certificate. Relying parties, if they trust the issuer of the certificate as a source of authoritative information on telephone numbers, could therefore use the TN Authorization List instead of the subject of the certificate to make a decision about whether or not the signer has authority over a particular telephone number. The TN Authorization List could be provided in one of two ways: as a literal value in the certificate or as a network service that allows relying parties to query in real time to determine that a telephone number is in the scope of a certificate. Using the TN Authorization List rather than the certificate subject makes sense when, for example, for privacy reasons the certificate owner would prefer not to be identified, or in cases where the holder of the certificate does not participate in the sort of traditional carrier infrastructure that the first approach assumes.
2番目の方法は、証明書の構文を拡張して、ここでTN Authorization Listとして定義される新しい属性を含めることです。これには、証明書の権限の範囲を定義する電話番号のリストが含まれます。したがって、証明書利用者が電話番号の信頼できる情報源として信頼できる場合、証明書利用者は、証明書の件名の代わりにTN承認リストを使用して、署名者が特定の権限を持つかどうかを決定できます。電話番号。 TN承認リストは、証明書内のリテラル値として、または証明書利用者がリアルタイムでクエリを実行して電話番号が証明書の範囲内にあることを確認できるネットワークサービスとして提供されます。証明書の所有者ではなくTN承認リストを使用することは、たとえば、プライバシー上の理由から、証明書の所有者を特定したくない場合や、証明書の所有者が、次のような従来のキャリアインフラストラクチャに参加していない場合に役立ちます。最初のアプローチは想定しています。
The first approach requires little change to existing Public Key Infrastructure (PKI) certificates; for the second approach, we must define an appropriate enrollment and authorization process. For the purposes of STIR, the over-the-wire format specified in [RFC8224] accommodates either of these approaches: the methods for canonicalizing, for signing, for identifying and accessing the certificate, and so on remain the same; it is only the verifier behavior and authorization decision that will change, depending on the approach to telephone number authority taken by the certificate. For that reason, the two approaches are not mutually exclusive, and in fact a certificate issued to a traditional telephone network service provider could contain a TN Authorization List or not, were it supported by the CA issuing the credential. Regardless of which approach is used, certificates that assert authority over telephone numbers are subject to the ordinary operational procedures that govern certificate use per [RFC5280]. This means that verification services must be mindful of the need to ensure that they trust the trust anchor that issued the certificate and that they have some means to determine the freshness of the certificate (see Section 10).
最初のアプローチでは、既存の公開鍵基盤（PKI）証明書にほとんど変更を加える必要はありません。 2番目のアプローチでは、適切な登録および承認プロセスを定義する必要があります。 STIRの目的のために、[RFC8224]で指定されたover-the-wire形式はこれらのアプローチのいずれかに対応します。正規化、署名、証明書の識別とアクセスなどの方法は同じままです。証明書が取る電話番号認証局へのアプローチに応じて変化するのは、検証者の動作と承認の決定のみです。そのため、2つのアプローチは相互に排他的ではなく、実際には、従来の電話ネットワークサービスプロバイダーに発行された証明書は、資格情報を発行するCAによってサポートされていれば、TN承認リストを含むことも含まないこともできました。使用されるアプローチに関係なく、電話番号に対する権限を主張する証明書は、[RFC5280]に従って証明書の使用を管理する通常の運用手順に従います。つまり、検証サービスは、証明書を発行したトラストアンカーを信頼し、証明書の鮮度を判断するための何らかの手段を備えていることを確認する必要があることに注意する必要があります（セクション10を参照）。
[RFC8224], Section 7.4 requires that all credential systems used by STIR explain how they address the requirements enumerated below. Certificates as described in this document address the STIR requirements as follows:
[RFC8224]、セクション7.4では、STIRで使用されるすべての認証情報システムが、以下に列挙されている要件にどのように対処するかを説明する必要があります。このドキュメントで説明されている証明書は、次のようにSTIR要件に対応しています。
1. The URI [RFC3986] schemes permitted in the SIP Identity header "info" parameter, as well as any special procedures required to dereference the URIs: while normative text is given below in Section 7, this mechanism permits the HTTP [RFC7230], CID (Content-ID) [RFC2392], and SIP URI schemes to appear in the "info" parameter.
1. SIP Identityヘッダーの "info"パラメータで許可されているURI [RFC3986]スキーム、およびURIを逆参照するために必要な特別な手順：標準のテキストはセクション7で後述されていますが、このメカニズムはHTTP [RFC7230]、CID（ Content-ID）[RFC2392]、および「info」パラメータに表示されるSIP URIスキーム。
2. Procedures required to extract keying material from the resources designated by the URI: implementations perform no special procedures beyond dereferencing the "info" URI. See Section 7.
2. URIで指定されたリソースからキー情報を抽出するために必要な手順：実装は、「info」URIを逆参照する以外に特別な手順を実行しません。セクション7を参照してください。
3. Procedures used by the verification service to determine the scope of the credential: this specification effectively proposes two methods, as outlined in Section 3: one where the subject (or, more properly, subjectAltName) of the certificate indicates the scope of authority through a domain name, and relying parties either trust the subject entirely or have some direct means of determining whether or not a number falls under a subject's authority; and another where an extension to the certificate as described in Section 9 identifies the scope of authority of the certificate.
3. 検証サービスが資格のスコープを決定するために使用する手順：この仕様は、セクション3で概説されているように、2つの方法を効果的に提案します。証明書のサブジェクト（より正確には、subjectAltName）がドメインを介した権限のスコープを示す名前、および証明書利用者は、サブジェクトを完全に信頼するか、または番号がサブジェクトの権限に該当するかどうかを判断する直接的な手段を持っています。もう1つは、セクション9で説明されている証明書の拡張により、証明書の権限の範囲を識別します。
4. The cryptographic algorithms required to validate the credentials: for this specification, that means the signature algorithms used to sign certificates. This specification REQUIRES that implementations support both the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve (see [DSS]) and RSA PKCS #1 v1.5 ("PKCS" stands for "Public-Key Cryptography Standards") (see [RFC8017], Section 8.2) for certificate signatures. Implementers are advised that the latter algorithm is mandated only as a transitional mechanism, due to its widespread use in existing PKIs, but we anticipate that this mechanism will eventually be deprecated.
4. 資格情報を検証するために必要な暗号化アルゴリズム：この仕様では、証明書の署名に使用される署名アルゴリズムを意味します。この仕様では、実装がP-256曲線（[DSS]を参照）で楕円曲線デジタル署名アルゴリズム（ECDSA）とRSA PKCS＃1 v1.5（「PKCS」は「公開鍵暗号規格」を表す）の両方をサポートする必要があります。 （証明書の署名については、[RFC8017]、セクション8.2をご覧ください）。実装者は、後者のアルゴリズムは既存のPKIで広く使用されているため、移行メカニズムとしてのみ義務付けられることをお勧めしますが、このメカニズムは最終的に非推奨になると予想しています。
5. Finally, note that all certificates compliant with this specification:
5. 最後に、この仕様に準拠するすべての証明書に注意してください。
* MUST provide cryptographic keying material sufficient to generate the ECDSA using P-256 and SHA-256 signatures necessary to support the ES256 hashed signatures required by PASSporT [RFC8225], which in turn follows the JSON Web Token (JWT) [RFC7519].
* JSON Web Token（JWT）[RFC7519]に続くPASSporT [RFC8225]で必要なES256ハッシュ署名をサポートするために必要なP-256およびSHA-256署名を使用してECDSAを生成するのに十分な暗号化キーイング資料を提供する必要があります。
* MUST support both ECDSA with P-256 and RSA PKCS #1 v1.5 for certificate signature verification.
* 証明書の署名の検証には、P-256を使用するECDSAとRSA PKCS＃1 v1.5の両方をサポートする必要があります。
This document also includes additional certificate-related requirements:
このドキュメントには、証明書関連の追加要件も含まれています。
o See Section 5.1 for requirements related to the JWT Claim Constraints certificate extension.
o JWT Claim Constraints証明書拡張に関連する要件については、セクション5.1を参照してください。
o See Section 7 for requirements related to relying parties acquiring credentials.
o 証明書を取得する依拠当事者に関連する要件については、セクション7を参照してください。
o See Sections 10 and 10.1 for requirements related to certificate freshness and the Authority Information Access (AIA) certificate extension.
o 証明書の鮮度と機関情報アクセス（AIA）証明書の拡張に関連する要件については、セクション10と10.1を参照してください。
This document covers three models for enrollment when using the TN Authorization List extension.
このドキュメントでは、TN承認リスト拡張機能を使用する場合の登録の3つのモデルについて説明します。
The first enrollment model is one where the CA acts in concert with national numbering authorities to issue credentials to those parties to whom numbers are assigned. In the United States, for example, telephone number blocks are assigned to Local Exchange Carriers (LECs) by the North American Numbering Plan Administration (NANPA), who is in turn directed by the national regulator. LECs may also receive numbers in smaller allocations, through number pooling, or via an individual assignment through number portability. LECs assign numbers to customers, who may be private individuals or organizations -- and organizations take responsibility for assigning numbers within their own enterprise. This model requires top-down adoption of the model from regulators through to carriers. Assignees of E.164 numbering resources participating in this enrollment model should take appropriate steps to establish trust anchors.
最初の登録モデルは、CAが国内の番号付与機関と協力して、番号が割り当てられている関係者に資格情報を発行するモデルです。たとえば、米国では、電話番号ブロックは、北米の番号計画管理局（NANPA）によって地域交換事業者（LEC）に割り当てられます。 LECは、番号プールを通じて、または番号ポータビリティによる個別の割り当てを通じて、より小さな割り当てで番号を受け取ることもできます。 LECは、個人または組織である可能性のある顧客に番号を割り当てます。組織は、自社内で番号を割り当てる責任があります。このモデルでは、規制当局からキャリアまで、モデルをトップダウンで採用する必要があります。この登録モデルに参加しているE.164番号付けリソースの担当者は、トラストアンカーを確立するために適切な手順を実行する必要があります。
The second enrollment model is a bottom-up approach where a CA requires that an entity prove control by means of some sort of test that, as with certification authorities for web PKI, might either be (1) automated or (2) a manual administrative process. As an example of an automated process, an authority might send a text message to a telephone number containing a URL (which might be dereferenced by the recipient) as a means of verifying that a user has control of a terminal corresponding to that number. Checks of this form are frequently used in commercial systems today to validate telephone numbers provided by users. This is comparable to existing enrollment systems used by some certificate authorities for issuing S/MIME credentials for email by verifying that the party applying for a credential receives mail at the email address in question.
2番目の登録モデルはボトムアップアプローチであり、Web PKIの証明機関と同様に、（1）自動または（2）手動管理のいずれかであるようなテストによってエンティティが制御を証明することをCAに要求します処理する。自動化されたプロセスの例として、当局は、ユーザーがその番号に対応する端末の制御権を持っていることを確認する手段として、URL（受信者によって逆参照される）を含む電話番号にテキストメッセージを送信する場合があります。このフォームのチェックは、ユーザーが提供する電話番号を検証するために、今日の商用システムで頻繁に使用されています。これは、資格情報を申請する当事者が問題の電子メールアドレスでメールを受信することを確認することにより、電子メールのS / MIME資格情報を発行するために一部の認証局が使用する既存の登録システムに相当します。
The third enrollment model is delegation: that is, the holder of a certificate (assigned by either of the two methods above) might delegate some or all of their authority to another party. In some cases, multiple levels of delegation could occur: a LEC, for example, might delegate authority to a customer organization for a block of 100 numbers used by an IP PBX, and the organization might in turn delegate authority for a particular number to an individual employee. This is analogous to delegation of organizational identities in traditional hierarchical PKIs who use the name constraints extension [RFC5280]; the root CA delegates names in sales to the sales department CA, names in development to the development CA, etc. As lengthy certificate delegation chains are brittle, however, and can cause delays in the verification process, this document considers optimizations to reduce the complexity of verification.
3番目の登録モデルは委任です。つまり、（上記の2つの方法のいずれかによって割り当てられた）証明書の所有者は、その権限の一部またはすべてを別の当事者に委任する可能性があります。場合によっては、複数のレベルの委任が発生する可能性があります。たとえば、LECは、IP PBXが使用する100の番号のブロックに対する顧客組織に権限を委任し、組織は特定の番号に対する権限を次に委任する場合があります。個々の従業員。これは、名前制約拡張[RFC5280]を使用する従来の階層型PKIにおける組織IDの委任に類似しています。ルートCAは、販売の名前を販売部門のCAに委任し、開発の名前を開発CAに委任します。ただし、長い証明書委任チェーンは壊れやすく、検証プロセスに遅延を引き起こす可能性があるため、このドキュメントでは最適化を検討して複雑さを軽減します検証の。
Future work might explore methods of partial delegation, where certificate holders delegate only part of their authority. For example, individual assignees may want to delegate to a service authority for text messages associated with their telephone number but not for other functions.
将来の作業では、証明書の所有者が権限の一部のみを委任する、部分的な委任の方法を調査する可能性があります。たとえば、個々の担当者は、電話番号に関連付けられたテキストメッセージのサービス権限を他の機能に委任したくない場合があります。
The public key in the certificate is used to validate the signature on a JWT [RFC7519] that conforms to the conventions specified in PASSporT [RFC8225]. This specification supports constraints on the JWT claims, thereby allowing the CA to grant different permissions to certificate holders -- for example, those enrolled from proof-of-possession versus delegation. A Certificate Policy (CP) and a Certification Practice Statement (CPS) [RFC3647] are produced as part of the normal PKI bootstrapping process (i.e., the CP is written first, and then the CA says how it conforms to the CP in the CPS). A CA that wishes to place constraints on the JWT claims MUST include the JWT Claim Constraints certificate extension in issued certificates. See Section 8 for information about the certificate extension.
証明書の公開鍵は、PASSporT [RFC8225]で指定された規則に準拠するJWT [RFC7519]の署名を検証するために使用されます。この仕様はJWTクレームの制約をサポートしているため、CAは証明書所有者にさまざまなアクセス許可（たとえば、所有証明と委任から登録されたアクセス許可）を付与できます。証明書ポリシー（CP）と証明書実践ステートメント（CPS）[RFC3647]は、通常のPKIブートストラッププロセスの一部として生成されます（つまり、CPが最初に記述され、次にCAがCPSのCPに準拠する方法を述べます） ）。 JWTクレームに制約を課したいCAは、発行された証明書にJWTクレーム制約証明書拡張を含める必要があります。証明書の拡張については、セクション8を参照してください。
This specification places no limits on the number of telephone numbers that can be associated with any given certificate. Some service providers may be assigned millions of numbers and may wish to have a single certificate that can be applied to signing for any one of those numbers. Others may wish to compartmentalize authority over subsets of the numbers they control.
この仕様では、任意の証明書に関連付けることができる電話番号の数に制限はありません。一部のサービスプロバイダーには数百万の番号が割り当てられている場合があり、それらの番号のいずれかに署名するために適用できる単一の証明書が必要になる場合があります。他の人は、自分が管理する数のサブセットに対して権限を区分化したいと思うかもしれません。
Moreover, service providers may wish to have multiple certificates with the same scope of authority. For example, a service provider with several regional gateway systems may want each system to be capable of signing for each of their numbers but not want to have each system share the same private key.
さらに、サービスプロバイダーは、同じ権限範囲を持つ複数の証明書を必要とする場合があります。たとえば、複数のリージョナルゲートウェイシステムを備えたサービスプロバイダーは、各システムがそれぞれの番号に署名できるようにしたいが、各システムが同じ秘密鍵を共有することを望まない場合があります。
The set of telephone numbers for which a particular certificate is valid is expressed in the certificate through a certificate extension; the certificate's extensibility mechanism is defined in [RFC5280], but the TN Authorization List extension is specified in this document.
特定の証明書が有効である電話番号のセットは、証明書拡張を介して証明書で表現されます。証明書の拡張メカニズムは[RFC5280]で定義されていますが、TN Authorization List拡張はこのドキュメントで指定されています。
The subjects of certificates containing the TN Authorization List extension are typically the administrative entities to whom numbers are assigned or delegated. For example, a LEC might hold a certificate for a range of telephone numbers. In some cases, the organization or individual issued such a certificate may not want to associate themselves with a certificate; for example, a private individual with a certificate for a single telephone number might not want to distribute that certificate publicly if every verifier immediately knew their name. The certification authorities issuing certificates with the TN Authorization List extensions may, in accordance with their policies, obscure the identity of the subject, though mechanisms for doing so are outside the scope of this document.
TN承認リスト拡張を含む証明書のサブジェクトは、通常、番号が割り当てられるか委任される管理エンティティです。たとえば、LECはある範囲の電話番号の証明書を保持している場合があります。場合によっては、そのような証明書を発行した組織または個人は、自分自身を証明書に関連付けたくない場合があります。たとえば、単一の電話番号の証明書を持つ個人が、すべての検証者がすぐに名前を知っている場合、その証明書を公に配布したくない場合があります。 TN Authorization List拡張で証明書を発行する証明機関は、ポリシーに従って、サブジェクトのIDを不明瞭にする場合がありますが、そのためのメカニズムはこのドキュメントの範囲外です。
In order for authentication services to sign calls via the procedures described in [RFC8224], they must hold a private key corresponding to a certificate with authority over the calling number. [RFC8224] does not require that any particular entity in a SIP deployment architecture sign requests, only that it be an entity with an appropriate private key; the authentication service role may be instantiated by any entity in a SIP network. For a certificate granting authority only over a particular number that has been issued to an end user, for example, an end-user device might hold the private key and generate the signature. In the case of a service provider with authority over large blocks of numbers, an intermediary might hold the private key and sign calls.
認証サービスが[RFC8224]で説明されている手順で通話に署名するためには、認証サービスが、呼び出し番号に対する権限を持つ証明書に対応する秘密鍵を保持している必要があります。 [RFC8224]は、SIPデプロイメントアーキテクチャの特定のエンティティが要求に署名することを要求しません。適切な秘密鍵を持つエンティティであることだけを要求します。認証サービスの役割は、SIPネットワーク内の任意のエンティティによってインスタンス化される場合があります。たとえば、エンドユーザーに発行された特定の番号に対してのみ証明書を付与する機関の場合、エンドユーザーのデバイスは秘密鍵を保持し、署名を生成します。大きな数のブロックに対する権限を持つサービスプロバイダーの場合、仲介者が秘密鍵を保持し、通話に署名する場合があります。
The specification RECOMMENDS distribution of private keys through PKCS #8 objects signed by a trusted entity -- for example, through the Cryptographic Message Syntax (CMS) package specified in [RFC5958].
仕様では、信頼できるエンティティによって署名されたPKCS＃8オブジェクトを使用した秘密鍵の配布を推奨しています。たとえば、[RFC5958]で指定されている暗号メッセージ構文（CMS）パッケージを使用しています。
This specification documents multiple ways that a verifier can gain access to the credentials needed to verify a request. As the validity of certificates does not depend on the method of their acquisition, there is no need to standardize any single mechanism for this purpose. All entities that comply with [RFC8224] necessarily support SIP, and consequently SIP itself can serve as a way to deliver certificates. [RFC8224] provides an "info" parameter of the Identity header; this parameter contains a URI for the credential used to generate the Identity header. [RFC8224] also requires that documents that define credential systems list the URI schemes that may be present in the "info" parameter. For implementations compliant with this specification, three URI schemes are REQUIRED: the CID URI, the SIP URI, and the HTTP URI.
この仕様は、検証者が要求の検証に必要な資格情報にアクセスできる複数の方法を文書化しています。証明書の有効性は取得方法に依存しないため、この目的のために単一のメカニズムを標準化する必要はありません。 [RFC8224]に準拠するすべてのエンティティはSIPをサポートする必要があるため、SIP自体が証明書を配信する方法として機能できます。 [RFC8224]は、Identityヘッダーの「info」パラメーターを提供します。このパラメーターには、Identityヘッダーの生成に使用される資格情報のURIが含まれています。 [RFC8224]では、資格情報システムを定義するドキュメントに、「info」パラメータに存在する可能性のあるURIスキームをリストすることも必要です。この仕様に準拠した実装では、CID URI、SIP URI、およびHTTP URIの3つのURIスキームが必要です。
The simplest way for a verifier to acquire the certificate needed to verify a signature is for the certificate to be conveyed in a SIP request along with the signature itself. In SIP, for example, a certificate could be carried in a multipart MIME body [RFC2046], and the URI in the Identity header "info" parameter could specify that body with a CID URI [RFC2392]. However, in many environments this is not feasible due to message size restrictions or lack of necessary support for multipart MIME.
検証者が署名を検証するために必要な証明書を取得する最も簡単な方法は、証明書を署名自体と一緒にSIPリクエストで伝達することです。たとえば、SIPでは、証明書はマルチパートMIMEボディ[RFC2046]で運ぶことができ、Identityヘッダーの "info"パラメータのURIは、CID URI [RFC2392]でそのボディを指定できます。ただし、多くの環境では、メッセージサイズの制限やマルチパートMIMEのサポートが不足しているため、これは実行できません。
The Identity header "info" parameter in a SIP request may contain a URI that the verifier dereferences. Implementations of this specification are REQUIRED to support the use of SIP for this function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and HTTPS.
SIPリクエストのIdentityヘッダーの「info」パラメーターには、検証者が逆参照するURIが含まれている場合があります。この仕様の実装は、この機能（SUBSCRIBE / NOTIFYメカニズムを介して）、およびHTTPとHTTPSでのSIPの使用をサポートするために必要です。
Note well that as an optimization, a verifier may have access to a service, a cache, or other local store that grants access to certificates for a particular telephone number. However, there may be multiple valid certificates that can sign a call setup request for a telephone number, and as a consequence, there needs to be some discriminator that the signer uses to identify their credentials. The Identity header "info" parameter itself can serve as such a discriminator, provided implementations use that parameter as a key when accessing certificates from caches or other sources.
最適化として、検証者は特定の電話番号の証明書へのアクセスを許可するサービス、キャッシュ、またはその他のローカルストアにアクセスできることに注意してください。ただし、電話番号のコールセットアップリクエストに署名できる有効な証明書が複数ある場合があり、その結果、署名者が資格情報を識別するために使用する識別子が必要になります。 Identityヘッダーの「info」パラメーター自体は、キャッシュまたは他のソースから証明書にアクセスするときに、実装がそのパラメーターをキーとして使用するという条件で、そのような識別子として機能できます。
Certificate subjects are limited to specific values for PASSporT claims with the JWT Claim Constraints certificate extension; issuers permit all claims by omitting the JWT Claim Constraints certificate extension from the certificate's extension field [RFC5280]. The extension is non-critical, applicable only to end-entity certificates, and defined with ASN.1 [X.680] [X.681] [X.682] [X.683] later in this section. The syntax of the claims is given in PASSporT; specifying new claims follows the procedures in [RFC8225], Section 8.3.
証明書のサブジェクトは、JWTクレーム制約証明書拡張を使用したPASSporTクレームの特定の値に制限されます。発行者は、証明書の拡張フィールド[RFC5280]からJWTクレーム制約証明書拡張を省略することにより、すべてのクレームを許可します。拡張は重要ではなく、エンドエンティティ証明書にのみ適用可能であり、このセクションの後半でASN.1 [X.680] [X.681] [X.682] [X.683]で定義されます。クレームの構文はPASSporTで提供されます。新しい申し立ての指定は、[RFC8225]のセクション8.3の手順に従います。
This certificate extension is optional, but if present, it constrains the claims that authentication services may include in the PASSporT objects they sign. Constraints are applied by issuers and enforced by verifiers when validating PASSporT claims as follows:
この証明書拡張はオプションですが、存在する場合、認証サービスが署名するPASSporTオブジェクトに含めることができるという主張を制限します。次のようにPASSporTクレームを検証するときに、制約は発行者によって適用され、検証者によって適用されます。
1. mustInclude indicates claims that MUST appear in the PASSporT in addition to iat, orig, and dest. The baseline claims of PASSporT ("iat", "orig", and "dest") are considered to be permitted by default and SHOULD NOT be included. If mustInclude is absent, iat, orig, and dest MUST appear in the PASSporT.
1. mustIncludeは、iat、orig、destに加えてPASSporTに表示する必要があるクレームを示します。 PASSporTのベースラインクレーム（「iat」、「orig」、および「dest」）は、デフォルトで許可されていると見なされ、含まれるべきではありません（SHOULD NOT）。 mustIncludeが存在しない場合、iat、orig、およびdestはPASSporTに出現する必要があります。
2. permittedValues indicates that if the claim name is present, the claim MUST contain one of the listed values.
2. allowedValuesは、クレーム名が存在する場合、クレームにリストされた値の1つが含まれている必要があることを示します。
Consider two examples with a PASSporT claim called "confidence" with values "low", "medium", and "high":
PASSporTクレームが「信頼」と呼ばれ、値が「低」、「中」、「高」の2つの例を考えてみます。
o If a CA issues to an authentication service a certificate that contains the mustInclude JWTClaimName "confidence", then an authentication service MUST include the "confidence" claim in all PASSporTs it generates; a verification service will treat as invalid any PASSporT it receives with a PASSporT claim that does not include the "confidence" claim.
o CAが認証サービスにmustInclude JWTClaimName "confidence"を含む証明書を発行する場合、認証サービスは、生成するすべてのPASSporTに "confidence"クレームを含める必要があります。検証サービスは、「信頼性」クレームを含まないPASSporTクレームで受け取ったPASSporTを無効として扱います。
o If a CA issues to an authentication service a certificate that contains the permittedValues JWTClaimName "confidence" and a permitted "high" value, then an authentication service will treat as invalid any PASSporT it receives with a PASSporT claim that does not include the "confidence" claim with a "high" value.
o CAがauthenticationValues JWTClaimNameの「confidence」と許可された「high」の値を含む証明書を認証サービスに発行すると、認証サービスは、「confidence」を含まないPASSporTクレームで受け取ったPASSporTを無効として扱います。 「高い」値で主張します。
The JWT Claim Constraints certificate extension is identified by the following object identifier (OID), which is defined under the id-pe OID arc defined in [RFC5280] and managed by IANA (see Section 11):
JWT Claim Constraints証明書拡張は、[RFC5280]で定義され、IANAによって管理されるid-pe OIDアークの下で定義される次のオブジェクト識別子（OID）によって識別されます（セクション11を参照）。
id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 }
The JWT Claim Constraints certificate extension has the following syntax:
JWT Claim Constraints証明書拡張の構文は次のとおりです。
JWTClaimConstraints ::= SEQUENCE {
mustInclude [0] JWTClaimNames OPTIONAL,
-- The listed claim names MUST appear in the PASSporT
-- in addition to iat, orig, and dest. If absent, iat, orig,
-- and dest MUST appear in the PASSporT.
permittedValues [1] JWTClaimPermittedValuesList OPTIONAL }
-- If the claim name is present, the claim MUST contain one of
-- the listed values.
( WITH COMPONENTS { ..., mustInclude PRESENT } |
WITH COMPONENTS { ..., permittedValues PRESENT } )
JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF
JWTClaimPermittedValues
JWTClaimPermittedValues ::= SEQUENCE {
claim JWTClaimName,
permitted SEQUENCE SIZE (1..MAX) OF UTF8String }
JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName
JWTClaimName ::= IA5String
The subjects of certificates containing the TN Authorization List extension are the administrative entities to whom numbers are assigned or delegated. When a verifier is validating a caller's identity, local policy always determines the circumstances under which any particular subject may be trusted, but the purpose of the TN Authorization List extension in particular is to allow a verifier to ascertain when the CA has designated that the subject has authority over a particular telephone number or number range. The non-critical TN Authorization List certificate extension is included in the certificate's extension field [RFC5280]. The extension is defined with ASN.1 [X.680] [X.681] [X.682] [X.683]. The syntax and semantics of the extension are as follows.
TN承認リスト拡張を含む証明書のサブジェクトは、番号が割り当てられるか委任される管理エンティティです。検証者が発信者のIDを検証しているとき、ローカルポリシーは常に特定のサブジェクトが信頼できる状況を決定しますが、特にTN承認リスト拡張の目的は、CAがサブジェクトを指定したことを検証者が確認できるようにすることです。特定の電話番号または番号範囲に対する権限を持っています。重要でないTN承認リスト証明書の拡張は、証明書の拡張フィールド[RFC5280]に含まれています。拡張子はASN.1 [X.680] [X.681] [X.682] [X.683]で定義されています。拡張の構文とセマンティクスは次のとおりです。
The subjects of certificates containing the TN Authorization List extension are the administrative entities to whom numbers are assigned or delegated. In an end-entity certificate, the TN Authorization List indicates the TNs that it has authorized. In a CA certificate, the TN Authorization List limits the set of TNs for certification paths that include this certificate.
TN承認リスト拡張を含む証明書のサブジェクトは、番号が割り当てられるか委任される管理エンティティです。エンドエンティティ証明書では、TN承認リストは、それが承認したTNを示します。 CA証明書では、TN承認リストによって、この証明書を含む証明書パスのTNのセットが制限されます。
The TN Authorization List certificate extension is identified by the following object identifier (OID), which is defined under the id-pe OID arc defined in [RFC5280] and managed by IANA (see Section 11):
TN Authorization List証明書拡張機能は、[RFC5280]で定義されているid-pe OIDアークの下で定義され、IANAによって管理される次のオブジェクト識別子（OID）によって識別されます（セクション11を参照）。
id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
The TN Authorization List certificate extension has the following syntax:
TN Authorization List証明書拡張の構文は次のとおりです。
TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
TNEntry ::= CHOICE {
spc [0] ServiceProviderCode,
range [1] TelephoneNumberRange,
one [2] TelephoneNumber
}
ServiceProviderCode ::= IA5String
-- SPCs may be OCNs, various SPIDs, or other SP identifiers
-- from the telephone network.
TelephoneNumberRange ::= SEQUENCE {
start TelephoneNumber,
count INTEGER (2..MAX),
...
}
TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*"))
The TN Authorization List certificate extension indicates the authorized phone numbers for the call setup signer. It indicates one or more blocks of telephone number entries that have been authorized for use by the call setup signer. There are three ways to identify the block:
TN Authorization List証明書拡張機能は、コールセットアップ署名者の許可された電話番号を示します。これは、コールセットアップ署名者による使用が許可されている電話番号エントリの1つ以上のブロックを示します。ブロックを識別する方法は3つあります。
1. SPCs as described in this document are a generic term for the identifiers used to designate service providers in telephone networks today. In North American context, these would include OCNs as specified in [ATIS-0300251], related SPIDs, or other similar identifiers for service providers. SPCs can be used to indirectly name all of the telephone numbers associated with that identifier for a service provider.
1. このドキュメントで説明されているSPCは、今日の電話ネットワークでサービスプロバイダーを指定するために使用される識別子の総称です。北米のコンテキストでは、これらには[ATIS-0300251]で指定されているOCN、関連するSPID、またはサービスプロバイダー向けの他の同様の識別子が含まれます。 SPCを使用すると、サービスプロバイダーの識別子に関連付けられているすべての電話番号を間接的に指定できます。
2. Telephone numbers can be listed in a range (in the TelephoneNumberRange format), which consists of a starting telephone number and then an integer count of numbers within the range, where the valid boundaries of ranges may vary according to national policies. The count field is only applicable to start fields whose values do not include "*" or "#" (i.e., a TelephoneNumber that does not include "*" or "#"). count MUST NOT make the number increase in length (i.e., a TelephoneNumberRange with TelephoneNumber=10 and count=91 is invalid); formally, given the inputs count and TelephoneNumber of length D, TelephoneNumber + count MUST be less than 10^D.
2. 電話番号は、範囲（TelephoneNumberRange形式）でリストできます。これは、開始電話番号と、その範囲内の整数の数で構成されます。範囲の有効な境界は、国の方針に従って異なる場合があります。カウントフィールドは、値に「*」または「＃」を含まない開始フィールド（つまり、「*」または「＃」を含まないTelephoneNumber）にのみ適用できます。 countは数を長くすることはできません（つまり、TelephoneNumber = 10およびcount = 91のTelephoneNumberRangeは無効です）。形式的には、入力カウントと長さDのTelephoneNumberを指定すると、TelephoneNumber + countは10 ^ D未満でなければなりません。
3. A single telephone number can be listed (as a TelephoneNumber).
3. 単一の電話番号を（TelephoneNumberとして）リストできます。
Note that because large-scale service providers may want to associate many numbers, possibly millions of numbers, with a particular certificate, optimizations are required for those cases to prevent the certificate size from becoming unmanageable. In these cases, the TN Authorization List may be given by reference rather than by value, through the presence of a separate certificate extension that permits verifiers to either (1) securely download the list of numbers associated with a certificate or (2) verify that a single number is under the authority of this certificate. For more on this optimization, see Section 10.1.
大規模なサービスプロバイダーは特定の証明書に多数の、場合によっては数百万の番号を関連付けたい場合があるため、証明書のサイズが管理できなくなるのを防ぐために、それらの場合には最適化が必要です。これらの場合、TN Authorization Listは、検証者が（1）証明書に関連付けられた番号のリストを安全にダウンロードするか、または（2）検証することを許可する個別の証明書拡張の存在を通じて、値ではなく参照によって与えられます。単一の番号がこの証明書の権限下にあります。この最適化の詳細については、セクション10.1を参照してください。
Regardless of which of the approaches in Section 3 is followed for using certificates, a certificate verification mechanism is required. However, the traditional problem of certificate freshness gains a new wrinkle when using the TN Authorization List extension with telephone numbers or number ranges (as opposed to SPCs), because verifiers must establish not only that a certificate remains valid but also that the certificate's scope contains the telephone number that the verifier is validating. Dynamic changes to number assignments can occur due to number portability, for example. So, even if a verifier has a valid cached certificate for a telephone number (or a range containing the number), the verifier must determine that the entity that created the PASSporT, which includes a digital signature, is still a proper authority for that number.
証明書を使用するためにセクション3のどのアプローチに従うかに関係なく、証明書検証メカニズムが必要です。ただし、検証者は証明書が有効なままであるだけでなく、証明書のスコープに含まれていることも確認する必要があるため、電話番号または番号範囲（SPCではなく）でTN Authorization List内線を使用すると、証明書の鮮度の従来の問題に新たな問題が生じます。検証者が検証している電話番号たとえば、番号の移植性が原因で、番号の割り当てが動的に変更されることがあります。したがって、検証者が電話番号（または番号を含む範囲）の有効なキャッシュ証明書を持っている場合でも、検証者は、デジタル署名を含むPASSporTを作成したエンティティがその番号に対する適切な権限であることを確認する必要があります。 。
To verify the status of such a certificate, the verifier needs to acquire the certificate if necessary (via the methods described in Section 7) and then would need to either:
そのような証明書のステータスを確認するには、検証者は必要に応じて（セクション7で説明されている方法で）証明書を取得する必要があり、次のいずれかを行う必要があります。
a. Rely on short-lived certificates and not check the certificate's status, or
a. 有効期間が短い証明書に依存し、証明書のステータスをチェックしない、または
b. Rely on status information from the authority (e.g., the Online Certificate Status Protocol (OCSP)).
b. 機関からのステータス情報に依存します（オンライン証明書ステータスプロトコル（OCSP）など）。
The trade-off between short-lived certificates and using status information is that the former's burden is on the front end (i.e., enrollment) and the latter's burden is on the back end (i.e., verification). Both impact call setup time, but some approaches to generating a short-lived certificate, like requiring one for each call, would incur a greater operational cost than acquiring status information. This document makes no particular recommendation for a means of determining certificate freshness for STIR, as this requires further study and implementation experience. Acquiring online status information for certificates has the potential to disclose private information [RFC7258] if proper precautions are not taken. Future specifications that define certificate freshness mechanisms for STIR MUST note any such risks and provide countermeasures where possible.
有効期間が短い証明書とステータス情報の使用との間のトレードオフは、前者の負担はフロントエンド（つまり、登録）にあり、後者の負担はバックエンド（つまり、検証）にあることです。どちらも通話のセットアップ時間に影響しますが、有効期間の短い証明書を生成するためのいくつかのアプローチ（通話ごとに証明書を要求するなど）は、ステータス情報を取得するよりも運用コストが高くなります。このドキュメントでは、STIRの証明書の鮮度を判断する方法について特に推奨していません。これには、さらに調査と実装の経験が必要だからです。証明書のオンラインステータス情報を取得すると、適切な予防策が講じられていない場合、個人情報[RFC7258]が開示される可能性があります。 STIRの証明書の新しさのメカニズムを定義する将来の仕様では、そのようなリスクに注意し、可能な場合は対策を提供する必要があります。
One alternative to checking certificate status for a particular telephone number is simply acquiring the TN Authorization List by reference, that is, through dereferencing a URL in the certificate, rather than including the value of the TN Authorization List in the certificate itself.
特定の電話番号の証明書ステータスを確認する1つの方法は、TN承認リストの値を証明書自体に含めるのではなく、参照によって、つまり証明書内のURLを逆参照することで、単にTN承認リストを取得することです。
Acquiring a list of the telephone numbers associated with a certificate or its subject lends itself to an application-layer query/response interaction outside of certificate status, one that could be initiated through a separate URI included in the certificate. The AIA extension (see [RFC5280]) supports such a mechanism: it designates an OID to identify the accessMethod and an accessLocation, which would most likely be a URI. A verifier would then follow the URI to ascertain whether the TNs in the list are authorized for use by the caller. As with the certificate extension defined in Section 9, a URI dereferenced from an end-entity certificate will indicate the TNs that the caller has been authorized. Verifiers MUST support the AIA extension, and the dereferenced URI from a CA certificate limits the set of TNs for certification paths that include this certificate.
証明書またはそのサブジェクトに関連付けられている電話番号のリストを取得すると、証明書のステータス以外のアプリケーション層のクエリ/応答のやり取りに役立ちます。これは、証明書に含まれる別のURIから開始できます。 AIA拡張機能（[RFC5280]を参照）は、このようなメカニズムをサポートしています。これは、OIDを指定してaccessMethodとaccessLocationを識別します。次に、検証者はURIに従って、リスト内のTNが呼び出し元による使用を許可されているかどうかを確認します。セクション9で定義された証明書拡張と同様に、エンドエンティティ証明書から逆参照されたURIは、呼び出し元が承認されたTNを示します。検証者はAIA拡張をサポートする必要があり、CA証明書から逆参照されたURIは、この証明書を含む証明書パスのTNのセットを制限します。
HTTPS is the most obvious candidate for a protocol to be used for fetching the list of telephone numbers associated with a particular certificate. This document defines a new AIA accessMethod, called "id-ad-stirTNList", which uses the following AIA OID:
HTTPSは、特定の証明書に関連付けられている電話番号のリストを取得するために使用されるプロトコルの最も明白な候補です。このドキュメントでは、次のAIA OIDを使用する「id-ad-stirTNList」と呼ばれる新しいAIA accessMethodを定義します。
id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
When the "id-ad-stirTNList" accessMethod is used, the accessLocation MUST be an HTTPS URI. Dereferencing the URI will return the complete DER-encoded TN Authorization List (see Section 9) for the certificate with a Content-Type of application/tnauthlist (see Section 11.2).
「id-ad-stirTNList」accessMethodを使用する場合、accessLocationはHTTPS URIである必要があります。 URIを逆参照すると、Content-Typeがapplication / tnauthlist（セクション11.2を参照）の証明書について、DERエンコードされた完全なTN承認リスト（セクション9を参照）が返されます。
Delivering the entire list of telephone numbers associated with a particular certificate will divulge to STIR verifiers information about telephone numbers other than the one associated with the particular call that the verifier is checking. In some environments, where STIR verifiers handle a high volume of calls, maintaining an up-to-date and complete cache for the numbers associated with crucial certificate holders could give an important boost to performance.
特定の証明書に関連付けられている電話番号のリスト全体を配信すると、検証者がチェックしている特定の呼び出しに関連付けられている電話番号以外の電話番号に関する情報がSTIR検証者に漏らされます。 STIRベリファイアが大量の呼び出しを処理する一部の環境では、重要な証明書保持者に関連付けられた番号の最新の完全なキャッシュを維持することで、パフォーマンスを大幅に向上させることができます。
This document makes use of object identifiers for the TN certificate extension defined in Section 9, the "TN List by reference" AIA access descriptor defined in Section 10.1, and the ASN.1 module identifier defined in Appendix A. Therefore, per this document, IANA has made the following assignments, as shown on <https://www.iana.org/assignments/smi-numbers>:
このドキュメントでは、セクション9で定義されたTN証明書拡張のオブジェクト識別子、セクション10.1で定義された「参照によるTNリスト」AIAアクセス記述子、および付録Aで定義されたASN.1モジュール識別子を使用します。したがって、このドキュメントによれば、 IANAは、<https://www.iana.org/assignments/smi-numbers>に示されているように、次の割り当てを行いました。
o TN Authorization List certificate extension in the "SMI Security for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry:
o "SMI Security for PKIX Certificate Extension"（1.3.6.1.5.5.7.1）レジストリのTN Authorization List証明書拡張：
26 id-pe-TNAuthList
26 pe-TNAuthList
o JWT Claim Constraints certificate extension in the "SMI Security for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry:
o "SMI Security for PKIX Certificate Extension"（1.3.6.1.5.5.7.1）レジストリのJWT Claim Constraints証明書拡張：
27 id-pe-JWTClaimConstraints
27 id-pe-JWTClaimConstraints
o TN List by reference access descriptor in the "SMI Security for PKIX Access Descriptor" (1.3.6.1.5.5.7.48) registry:
o "SMI Security for PKIX Access Descriptor"（1.3.6.1.5.5.7.48）レジストリの参照アクセス記述子によるTNリスト：
14 id-ad-stirTNList
14 id-ad-stirTNList
o The TN ASN.1 module in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:
o "SMI Security for PKIX Module Identifier"（1.3.6.1.5.5.7.0）レジストリのTN ASN.1モジュール：
89 id-mod-tn-module
89 id-mod-tn-module
Type name: application
Subtype name: tnauthlist
Required parameters: None
Optional parameters: None
Encoding considerations: Binary
Security considerations: See Section 12 of RFC 8226
Interoperability considerations:
The TN Authorization List inside this media type MUST be
DER-encoded TNAuthorizationList.
Published specification: RFC 8226
Applications that use this media type:
Issuers and relying parties of secure telephone identity
certificates, to limit the subject's authority to a
particular telephone number or telephone number range.
Fragment identifier considerations: None
Additional information:
Deprecated alias names for this type: None
Magic number(s): None
File extension(s): None
Macintosh File Type Code(s): None
Person & email address to contact for further information:
Jon Peterson <jon.peterson@team.neustar>
Intended usage: COMMON
Restrictions on usage: None
Author: Sean Turner <sean@sn3rd.com>
Change controller: The IESG <iesg@ietf.org>
This document is entirely about security. For further information on certificate security and practices, see [RFC5280], in particular its Security Considerations section.
このドキュメントは完全にセキュリティに関するものです。証明書のセキュリティと実践の詳細については、[RFC5280]、特にセキュリティに関する考慮事項のセクションを参照してください。
If a certification authority issues a certificate attesting authority over many telephone numbers, the TNAuthList element can divulge to relying parties extraneous telephone numbers associated with the certificate that have no bearing on any given call in progress. The potential privacy risk can be exacerbated by the use of AIA, as described in Section 10.1, to link many thousands of numbers to a single certificate. Even an SPC in a certificate can be used to link a certificate to a particular carrier and, with access to industry databases, potentially the set of numbers associated with that SPC. While these practices may not cause concern in some environments, in other scenarios alternative approaches could minimize the data revealed to relying parties. For example, a service provider with authority over a large block of numbers could generate short-lived certificates for individual TNs that are not so easily linked to the service provider or any other numbers that the service provider controls. Optimizations to facilitate acquiring short-lived certificates are a potential area of future work for STIR.
証明機関が多くの電話番号に対して証明書証明機関を発行する場合、TNAuthList要素は、進行中の特定の通話に影響を与えない、証明書に関連付けられた無関係の電話番号に依存する可能性があります。セクション10.1で説明されているように、AIAを使用して何千もの番号を単一の証明書にリンクすると、潜在的なプライバシーリスクが悪化する可能性があります。証明書内のSPCを使用して、証明書を特定のキャリアにリンクし、業界データベースにアクセスして、そのSPCに関連付けられた一連の番号を潜在的にリンクすることができます。これらのプラクティスは一部の環境では問題を引き起こさない可能性がありますが、他のシナリオでは、代替のアプローチにより、証明書利用者に公開されるデータを最小限に抑えることができます。たとえば、番号の大きなブロックに対する権限を持つサービスプロバイダーは、サービスプロバイダーやサービスプロバイダーが制御するその他の番号に簡単にリンクされない個々のTNの有効期間が短い証明書を生成する可能性があります。有効期間が短い証明書の取得を容易にするための最適化は、STIRの将来の作業の潜在的な領域です。
The TN Authorization List returned through a dereferenced URI is served over HTTPS; the TN Authorization List is therefore protected in transit. But, the TN Authorization List served is not a signed object and therefore the server is trusted to faithfully return the TN Authorization List provided to it by the list generator.
逆参照されたURIを通じて返されるTN承認リストは、HTTPS経由で提供されます。したがって、TN認可リストは転送中に保護されます。ただし、提供されるTN承認リストは署名されたオブジェクトではないため、サーバーは、リストジェネレーターによって提供されたTN承認リストを忠実に返すことが信頼されています。
[ATIS-0300251] ATIS Recommendation 0300251, "Codes for Identification of Service Providers for Information Exchange", 2007.
[ATIS-0300251] ATIS勧告0300251、「情報交換のためのサービスプロバイダーの識別コード」、2007年。
[DSS] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[DSS]米国国立標準技術研究所、米国商務省、「デジタル署名標準（DSS）」、NIST FIPS PUB 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<http：// nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, <https://www.rfc-editor.org/info/rfc2392>.
[RFC2392] Levinson、E。、「Content-ID and Message-ID Uniform Resource Locators」、RFC 2392、DOI 10.17487 / RFC2392、1998年8月、<https://www.rfc-editor.org/info/rfc2392>。
[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.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、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、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<https：// www。 rfc-editor.org/info/rfc5912>。
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/info/rfc5958>.
[RFC5958]ターナー、S。、「非対称キーパッケージ」、RFC 5958、DOI 10.17487 / RFC5958、2010年8月、<https://www.rfc-editor.org/info/rfc5958>。
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing"、RFC 7230、DOI 10.17487 / RFC7230、June 2014、<https：/ /www.rfc-editor.org/info/rfc7230>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https://www.rfc-editor.org/info/rfc7258 >。
[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>.
[RFC7519]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https://www.rfc-editor.org / info / rfc7519>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J。、およびA. Rusch、「PKCS＃1：RSA Cryptography Specifications Version 2.2」、RFC 8017、DOI 10.17487 / RFC8017、2016年11月、< https://www.rfc-editor.org/info/rfc8017>。
[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、「Session Initiation Protocol（SIP）における認証されたID管理」、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>。
[X.509] International Telecommunication Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO/IEC 9594-8, October 2016, <https://www.itu.int/rec/T-REC-X.509>.
[X.509] International Telecommunication Union、「Information technology-Open Systems Interconnection-The Directory：Public-key and attribute certificate frameworks」、ITU-T Recommendation X.509、ISO / IEC 9594-8、2016年10月、<https： //www.itu.int/rec/T-REC-X.509>。
[X.680] International Telecommunication Union, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680>.
[X.680] International Telecommunication Union、「Information Technology-Abstract Syntax Notation One（ASN.1）：Specification of basic notation」、ITU-T Recommendation X.680、ISO / IEC 8824-1、2015年8月、<https： //www.itu.int/rec/T-REC-X.680>。
[X.681] International Telecommunication Union, "Information Technology - Abstract Syntax Notation One (ASN.1): Information object specification", ITU-T Recommendation X.681, ISO/IEC 8824-2, August 2015, <https://www.itu.int/rec/T-REC-X.681>.
[X.681]国際電気通信連合、「情報技術-抽象構文記法1（ASN.1）：情報オブジェクト仕様」、ITU-T勧告X.681、ISO / IEC 8824-2、2015年8月、<https：/ /www.itu.int/rec/T-REC-X.681>。
[X.682] International Telecommunication Union, "Information Technology - Abstract Syntax Notation One (ASN.1): Constraint specification", ITU-T Recommendation X.682, ISO/IEC 8824-3, August 2015, <https://www.itu.int/rec/T-REC-X.682>.
[X.682] International Telecommunication Union、「Information Technology-Abstract Syntax Notation One（ASN.1）：Constraint specification」、ITU-T Recommendation X.682、ISO / IEC 8824-3、2015年8月、<https：// www.itu.int/rec/T-REC-X.682>。
[X.683] International Telecommunication Union, "Information Technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications", ITU-T Recommendation X.683, ISO/IEC 8824-4, August 2015, <https://www.itu.int/rec/T-REC-X.683>.
[X.683]国際電気通信連合、「情報技術-抽象構文記法1（ASN.1）：ASN.1仕様のパラメーター化」、ITU-T勧告X.683、ISO / IEC 8824-4、2015年8月、< https://www.itu.int/rec/T-REC-X.683>。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https://www.rfc-editor.org / info / rfc2046>。
[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.、and S. Wu、 "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework"、RFC 3647、DOI 10.17487 / RFC3647、2003年11月、<https://www.rfc-editor.org/info/rfc3647>。
[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、「Secure Telephone Identity Problem Statement and Requirements」、RFC 7340、DOI 10.17487 / RFC7340、2014年9月、<https：//www.rfc-editor。 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 Threat Model」、RFC 7375、DOI 10.17487 / RFC7375、2014年10月、<https://www.rfc-editor.org/info/rfc7375>。
[X.520] International Telecommunication Union, "Information technology - Open Systems Interconnection - The Directory: Selected attribute types", ITU-T Recommendation X.520, ISO/IEC 9594-6, October 2016, <https://www.itu.int/rec/T-REC-X.520>.
[X.520] International Telecommunication Union、「Information technology-Open Systems Interconnection-The Directory：Selected attribute types」、ITU-T Recommendation X.520、ISO / IEC 9594-6、2016年10月、<https：// www。 itu.int/rec/T-REC-X.520>。
This appendix provides the normative ASN.1 [X.680] definitions for the structures described in this specification using ASN.1, as defined in [X.680], [X.681], [X.682], and [X.683].
この付録では、[X.680]、[X.681]、[X.682]、および[Xで定義されている、ASN.1を使用してこの仕様で説明されている構造の規範的なASN.1 [X.680]定義を提供します。 .683]。
The modules defined in this document are compatible with the most current ASN.1 specifications published in 2015 (see [X.680], [X.681], [X.682], and [X.683]). None of the newly defined tokens in the 2008 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-OID-IRI, TIME, TIME-OF-DAY) are currently used in any of the ASN.1 specifications referred to here.
このドキュメントで定義されているモジュールは、2015年に公開された最新のASN.1仕様と互換性があります（[X.680]、[X.681]、[X.682]、および[X.683]を参照）。 2008 ASN.1で新しく定義されたトークン（DATE、DATE-TIME、DURATION、NOT-A-NUMBER、OID-IRI、RELATIVE-OID-IRI、TIME、TIME-OF-DAY）のいずれも現在使用されていないここで参照されるASN.1仕様の
This ASN.1 module imports ASN.1 from [RFC5912].
このASN.1モジュールは、[RFC5912]からASN.1をインポートします。
TN-Module-2016
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(89) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
輸入
id-ad, id-pe
FROM PKIX1Explicit-2009 -- From RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }
EXTENSION
FROM PKIX-CommonTypes-2009 -- From RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) }
;
；
-- -- JWT Claim Constraints Certificate Extension --
--JWTクレーム制約証明書拡張-
ext-jwtClaimConstraints EXTENSION ::= {
SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints
}
id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 }
JWTClaimConstraints ::= SEQUENCE {
mustInclude [0] JWTClaimNames OPTIONAL,
-- The listed claim names MUST appear in the PASSporT
-- in addition to iat, orig, and dest. If absent, iat, orig,
-- and dest MUST appear in the PASSporT.
permittedValues [1] JWTClaimPermittedValuesList OPTIONAL }
-- If the claim name is present, the claim MUST contain one of
-- the listed values.
( WITH COMPONENTS { ..., mustInclude PRESENT } |
WITH COMPONENTS { ..., permittedValues PRESENT } )
JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of
JWTClaimPermittedValues
JWTClaimPermittedValues ::= SEQUENCE {
claim JWTClaimName,
permitted SEQUENCE SIZE (1..MAX) OF UTF8String }
JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName
JWTClaimName ::= IA5String
-- -- Telephony Number Authorization List Certificate Extension --
--テレフォニー番号認証リスト証明書拡張-
ext-tnAuthList EXTENSION ::= {
SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList
}
id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
TNEntry ::= CHOICE {
spc [0] ServiceProviderCode,
range [1] TelephoneNumberRange,
one [2] TelephoneNumber
}
ServiceProviderCode ::= IA5String
-- SPCs may be OCNs, various SPIDs, or other SP identifiers
-- from the telephone network.
TelephoneNumberRange ::= SEQUENCE {
start TelephoneNumber,
count INTEGER (2..MAX),
...
}
TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*"))
-- TN Access Descriptor
-TNアクセス記述子
id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
END
終わり
Acknowledgments
謝辞
Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave Crocker, Tony Rutkowski, John Braunberger, Eric Rescorla, and Martin Thomson provided key input to the discussions leading to this document. Russ Housley provided some direct assistance and text surrounding the ASN.1 module.
Anders Kristensen、Russ Housley、Brian Rosen、Cullen Jennings、Dave Crocker、Tony Rutkowski、John Braunberger、Eric Rescorla、Martin Thomsonは、このドキュメントに至る議論に重要な情報を提供しました。 Russ Housleyは、ASN.1モジュールに関するいくつかの直接的な支援とテキストを提供しました。
Authors' Addresses
著者のアドレス
Jon Peterson Neustar, Inc.
Jon Peterson Neustar、Inc.
Email: jon.peterson@neustar.biz
Sean Turner sn3rd
ショーンターナーsn3rd
Email: sean@sn3rd.com