[要約] RFC 8225は、PASSporT（Personal Assertion Token）の仕様を定義しており、電話通話の認証と信頼性を向上させるために設計されています。PASSporTは、通話の発信者の識別情報を含むトークンを提供し、電話詐欺や不正利用の防止に役立ちます。
Internet Engineering Task Force (IETF) C. Wendt
Request for Comments: 8225 Comcast
Category: Standards Track J. Peterson
ISSN: 2070-1721 Neustar Inc.
February 2018
PASSporT: Personal Assertion Token
PASSporT：個人アサーショントークン
Abstract
概要
This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.
このドキュメントでは、発信元のアイデンティティ、またはより一般的には個人的な通信の発信者を表すURIまたは電話番号を暗号で検証するトークンを作成および検証する方法を定義します。個人アサーショントークンであるPASSporTは、発信者のIDの整合性を保護し、宛先でのID情報のアサーションを検証するために暗号で署名されています。暗号署名は、署名が安全でないチャネルを介して宛先パーティに送信された場合でも、発信元のペルソナを確実に検証できるように定義されています。 PASSporTは、発信者と宛先の当事者が直接の信頼関係を持たない可能性がある、IPネットワークを介した多くのパーソナル通信アプリケーションやその他のマルチホップ相互接続シナリオに特に役立ちます。
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/rfc8225.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8225で入手できます。
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 ....................................................4
2. Terminology .....................................................4
3. PASSporT Overview ...............................................5
4. PASSporT Header .................................................6
4.1. "typ" (Type) Header Parameter ..............................6
4.2. "alg" (Algorithm) Header Parameter .........................6
4.3. "x5u" (X.509 URL) Header Parameter .........................6
4.4. Example PASSporT Header ....................................7
5. PASSporT Payload ................................................7
5.1. JWT-Defined Claims .........................................7
5.1.1. "iat" (Issued At) Claim .............................7
5.2. PASSporT-Specific Claims ...................................8
5.2.1. Originating and Destination Identity Claims .........8
5.2.2. "mky" (Media Key) Claim ............................10
6. PASSporT Signature .............................................11
7. Compact Form of PASSporT .......................................12
7.1. Example Compact Form of PASSporT ..........................13
8. Extending PASSporT .............................................13
8.1. "ppt" (PASSporT) Header Parameter .........................13
8.2. Example Extended PASSporT Header ..........................14
8.3. Extended PASSporT Claims ..................................14
9. Deterministic JSON Serialization ...............................15
9.1. Example PASSporT Deterministic JSON Form ..................16
10. Security Considerations .......................................17
10.1. Avoidance of Replay and Cut-and-Paste Attacks ............17
10.2. Solution Considerations ..................................18
11. IANA Considerations ...........................................18
11.1. Media Type Registration ..................................18
11.2. Registrations in "JSON Web Token Claims" .................19
11.3. Registration in "JSON Web Signature and
Encryption Header Parameters" ............................20
11.4. PASSporT Extensions Registry .............................20
12. References ....................................................20
12.1. Normative References .....................................20
12.2. Informative References ...................................22
Appendix A. Example ES256-Based PASSporT JWS Serialization and
Signature .............................................23
A.1. X.509 Private Key in PKCS #8 Format for ES256 Example ......24
A.2. X.509 Public Key for ES256 Example .........................25
Acknowledgments ...................................................25
Authors' Addresses ................................................25
In today's IP-enabled telecommunications world, there is a growing concern about the ability to trust incoming invitations for communications sessions, including video, voice, and messaging [RFC7340]. As an example, modern telephone networks provide the ability to spoof the calling party's telephone number for many legitimate purposes, including providing network features and services on behalf of a legitimate telephone number. However, as we have seen, bad actors have taken advantage of this ability for illegitimate and fraudulent purposes meant to trick telephone users into believing that they are someone they are not. This problem can be extended to many emerging forms of personal communications.
今日のIP対応の電気通信の世界では、ビデオ、音声、メッセージングなどの通信セッションの着信招待を信頼する機能についての懸念が高まっています[RFC7340]。一例として、最新の電話ネットワークは、正当な電話番号に代わってネットワーク機能とサービスを提供することを含め、多くの正当な目的で発呼者の電話番号を偽装する機能を提供します。しかし、これまで見てきたように、悪意のある俳優は、電話ユーザーをだまして自分がそうでない人物であると信じ込ませることを目的とした不正な目的でこの機能を利用しています。この問題は、多くの新しい形態のパーソナルコミュニケーションにまで及ぶ可能性があります。
This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. Through the extensions defined in Section 8 of this document, other information relevant to the personal communications can also be added to the token. The goal of PASSporT is to provide a common framework for signing information related to the originating identity in an extensible way. Additionally, this functionality is independent of any specific call logic for personal-communications signaling, so that the assertion of information related to the originating identity can be implemented in a flexible way and can be used in such applications as end-to-end applications that require different signaling protocols or gateways between different communications systems. It is anticipated that guidance specific to the signaling protocol will be provided in other related documents and specifications to specify how to use and transport PASSporTs; however, this is intentionally out of scope for this document.
このドキュメントでは、発信元のアイデンティティ、またはより一般的には個人的な通信の発信者を表すURIまたは電話番号を暗号で検証するトークンを作成および検証する方法を定義します。このドキュメントのセクション8で定義されている拡張機能により、個人的なコミュニケーションに関連する他の情報もトークンに追加できます。 PASSporTの目標は、元のIDに関連する情報に拡張可能な方法で署名するための共通のフレームワークを提供することです。さらに、この機能はパーソナルコミュニケーションシグナリングの特定の呼び出しロジックとは独立しているため、元のIDに関連する情報のアサーションは柔軟に実装でき、エンドツーエンドアプリケーションなどのアプリケーションで使用できます。異なる通信システム間で異なるシグナリングプロトコルまたはゲートウェイが必要です。シグナリングプロトコルに固有のガイダンスは、PASSporTの使用方法と転送方法を指定する他の関連ドキュメントと仕様で提供されることが予想されます。ただし、これは意図的にこのドキュメントの範囲外です。
[RFC8224] provides details of the use of PASSporT within the SIP [RFC3261] signaling protocol for the signing and verification of telephone numbers and SIP URIs.
[RFC8224]は、電話番号とSIP URIの署名と検証のためのSIP [RFC3261]シグナリングプロトコル内でのPASSporTの使用の詳細を提供します。
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]で説明されているように解釈されます。
"JSON Web Token (JWT)" [RFC7519], "JSON Web Signature (JWS)" [RFC7515], and other related specifications define a standard token format that can be used as a way of encapsulating claimed or asserted information with an associated digital signature using X.509-based certificates. JWT provides a set of claims in JSON format that can conveniently accommodate asserted originating-identity information and that are easily extensible for use in the extension mechanisms defined below. Additionally, JWS provides a path for updating methods and cryptographic algorithms used for the associated digital signatures.
「JSON Web Token（JWT）」[RFC7519]、「JSON Web Signature（JWS）」[RFC7515]、およびその他の関連仕様は、関連するデジタルで主張または表明された情報をカプセル化する方法として使用できる標準のトークン形式を定義しますX.509ベースの証明書を使用した署名。 JWTは、アサートされた元のID情報に便利に対応でき、以下で定義する拡張メカニズムで使用するために簡単に拡張できるJSON形式のクレームのセットを提供します。さらに、JWSは、関連するデジタル署名に使用される更新方法と暗号化アルゴリズムのパスを提供します。
JWS defines the use of JSON data structures in a specified canonical format for signing data corresponding to the JSON Object Signing and Encryption (JOSE) Header, JWS Payload, and JWS Signature. JWT defines a set of claims that are represented by specified JSON objects that can be extended with custom keys for specific applications. The next sections define the header and claims that MUST be minimally used with JWT and JWS for PASSporT.
JWSは、JSONオブジェクト署名および暗号化（JOSE）ヘッダー、JWSペイロード、およびJWS署名に対応するデータに署名するために、指定された正規形式でJSONデータ構造の使用を定義します。 JWTは、特定のアプリケーションのカスタムキーで拡張できる指定されたJSONオブジェクトで表される一連のクレームを定義します。次のセクションでは、PASSporTのJWTおよびJWSで最小限使用する必要があるヘッダーとクレームを定義します。
PASSporT specifically uses this token format and defines claims that convey the identity of the origination and destination of personal communications. The primary value asserted in a PASSporT object is the originating identity representing the identity of the calling party or the initiator of a personal-communications session. The signer of a PASSporT object may or may not correspond to the originating identity. For a given application's use or using protocol of PASSporT, the creation of the PASSporT object is performed by an entity that is authoritative to assert the caller's identity. This authority is represented by the certificate credentials and the signature, and the PASSporT object is created and initiated to the destination(s) per the application's choice of authoritative point(s) in the network. For example, the PASSporT object could be created at a device that has authenticated with a user or at a network entity with an authenticated trust relationship with that device and its user. Destination identities represent the intended destination of the personal communications, i.e., the identity(s) being called by the caller. The destination point or points determined by the application need to have the capability to verify the PASSporT and the digital signature. The PASSporT-associated certificate is used to validate the authority of the originating signer, generally via a certificate chain to the trust anchor for that application.
PASSporTは特にこのトークン形式を使用し、パーソナルコミュニケーションの発信元と宛先のIDを伝えるクレームを定義します。 PASSporTオブジェクトでアサートされる主な値は、発呼者またはパーソナル通信セッションの開始者のIDを表す元のIDです。 PASSporTオブジェクトの署名者は、元のIDに対応する場合と対応しない場合があります。 PASSporTの特定のアプリケーションの使用またはプロトコルを使用する場合、PASSporTオブジェクトの作成は、呼び出し元のIDをアサートする権限を持つエンティティによって実行されます。この認証局は、証明書の資格情報と署名によって表され、PASSporTオブジェクトが作成され、ネットワークでのアプリケーションの権限のあるポイントの選択に従って宛先に送信されます。たとえば、PASSporTオブジェクトは、ユーザーで認証されたデバイス、またはそのデバイスとそのユーザーとの認証された信頼関係を持つネットワークエンティティで作成できます。宛先IDは、パーソナルコミュニケーションの目的の宛先、つまり発信者が呼び出すIDを表します。アプリケーションによって決定された宛先ポイントには、PASSporTとデジタル署名を検証する機能が必要です。 PASSporT関連の証明書は、通常、そのアプリケーションのトラストアンカーへの証明書チェーンを介して、元の署名者の権限を検証するために使用されます。
The JWS token header is a JOSE Header ([RFC7515], Section 4) that defines the type and encryption algorithm used in the token.
JWSトークンヘッダーは、トークンで使用されるタイプと暗号化アルゴリズムを定義するJOSEヘッダー（[RFC7515]、セクション4）です。
The PASSporT header should include, at a minimum, the Header Parameters defined in the next three subsections.
PASSporTヘッダーには、少なくとも次の3つのサブセクションで定義されるヘッダーパラメーターを含める必要があります。
The "typ" (Type) Header Parameter is defined in JWS ([RFC7515], Section 4.1.9) to declare the media type of the complete JWS.
「typ」（タイプ）ヘッダーパラメータはJWS（[RFC7515]、セクション4.1.9）で定義され、完全なJWSのメディアタイプを宣言します。
For the PASSporT, the "typ" header MUST be the string "passport". This signifies that the encoded token is a JWT of type "passport".
PASSporTの場合、「タイプ」ヘッダーは強力な「パスポート」である必要があります。これは、エンコードされたトークンが「パスポート」タイプのJWTであることを示しています。
The "alg" (Algorithm) Header Parameter is defined in JWS ([RFC7515], Section 4.1.1). This definition includes the ability to specify the use of a cryptographic algorithm for the signature part of the JWS. It also refers to a list of defined "alg" values as part of a registry established by JSON Web Algorithms (JWA) ([RFC7518], Section 3.1).
「alg」（アルゴリズム）ヘッダーパラメータはJWSで定義されています（[RFC7515]、セクション4.1.1）。この定義には、JWSの署名部分に暗号化アルゴリズムの使用を指定する機能が含まれています。また、JSON Web Algorithms（JWA）（[RFC7518]、セクション3.1）によって確立されたレジストリの一部として、定義された「alg」値のリストを参照しています。
For the creation and verification of PASSporTs and their digital signatures, implementations MUST support ES256 as defined in JWA ([RFC7518], Section 3.4). Implementations MAY support other algorithms registered in the "JSON Web Signature and Encryption Algorithms" registry created by [RFC7518]. The contents of that registry may be updated in the future, depending on cryptographic strength requirements guided by current security best practices. The mandatory-to-support algorithm for PASSporTs may likewise be updated in future updates to this document.
PASSporTとそのデジタル署名の作成と検証のために、実装はJWAで定義されたES256をサポートする必要があります（[RFC7518]、セクション3.4）。 [RFC7518]によって作成された「JSON Web Signature and Encryption Algorithms」レジストリに登録されている他のアルゴリズムを実装がサポートする場合があります。そのレジストリの内容は、現在のセキュリティのベストプラクティスによって導かれる暗号強度の要件に応じて、将来更新される可能性があります。 PASSporTのサポートに必須のアルゴリズムも、このドキュメントの将来の更新で更新される可能性があります。
Implementations of PASSporT digital signatures using ES256 as defined above SHOULD use the deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) if or when supported for the reasons stated in [RFC6979].
上記で定義されたES256を使用したPASSporTデジタル署名の実装は、[RFC6979]で述べられている理由でサポートされている場合、またはサポートされている場合、確定的楕円曲線デジタル署名アルゴリズム（ECDSA）を使用する必要があります。
As defined in JWS ([RFC7515], Section 4.1.5), the "x5u" Header Parameter defines a URI [RFC3986] referring to the resource for the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS. Generally, as defined in JWS ([RFC7515], Section 4.1.5), this would correspond to an HTTPS or DNSSEC resource using integrity protection.
JWS（[RFC7515]、セクション4.1.5）で定義されているように、「x5u」ヘッダーパラメーターは、使用されるキーに対応するX.509公開キー証明書または証明書チェーン[RFC5280]のリソースを参照するURI [RFC3986]を定義しますJWSにデジタル署名します。一般に、JWS（[RFC7515]、セクション4.1.5）で定義されているように、これは整合性保護を使用するHTTPSまたはDNSSECリソースに対応します。
An example of the header would be the following, including the specified passport type, ES256 algorithm, and a URI referencing the network location of the certificate needed to validate the PASSporT signature.
ヘッダーの例は次のようになります。これには、指定されたパスポートタイプ、ES256アルゴリズム、およびPASSporT署名の検証に必要な証明書のネットワークロケーションを参照するURIが含まれます。
{
"typ":"passport",
"alg":"ES256",
"x5u":"https://cert.example.org/passport.cer"
}
The token claims consist of the information that needs to be verified at the destination party. These claims follow the definition of a JWT claim ([RFC7519], Section 4) and are encoded as defined by the JWS Payload ([RFC7515], Section 3).
トークンクレームは、宛先パーティで検証する必要がある情報で構成されています。これらのクレームは、JWTクレーム（[RFC7519]、セクション4）の定義に従い、JWSペイロード（[RFC7515]、セクション3）の定義に従ってエンコードされます。
PASSporT defines the use of a standard JWT-defined claim as well as custom claims corresponding to the two parties associated with personal communications -- the originator and destination, as detailed below.
PASSporTは、標準のJWTで定義されたクレームと、パーソナルコミュニケーションに関連する2つのパーティ（発信者と宛先）に対応するカスタムクレームの使用を定義します。
For PASSporT, any claim names MUST use the ASCII character set. Any claim values can contain characters that are outside the ASCII range, consistent with the rules of creating a JWT Claims Set as defined in [RFC7519], Section 7.1.
PASSporTの場合、クレーム名にはASCII文字セットを使用する必要があります。 [RFC7519]のセクション7.1で定義されているJWTクレームセットを作成するルールに準拠して、クレーム値にはASCII範囲外の文字を含めることができます。
The JSON claim MUST include the "iat" (Issued At) claim ([RFC7519], Section 4.1.6). As defined, the "iat" claim should be set to the date and time of issuance of the JWT and MUST indicate the date and time of the origination of the personal communications. The time value should be of the NumericDate format as defined in [RFC7519], Section 2. This is included for securing the token against replay and cut-and-paste attacks, as explained further in Section 10 ("Security Considerations").
JSONクレームには、「iat」（発行された）クレーム（[RFC7519]、セクション4.1.6）を含める必要があります。定義されているように、「iat」クレームはJWTの発行日時に設定する必要があり、パーソナルコミュニケーションの開始日時を示さなければなりません（MUST）。時間値は、[RFC7519]のセクション2で定義されているNumericDate形式である必要があります。これは、セクション10（「セキュリティの考慮事項」）で詳しく説明されているように、リプレイ攻撃とカットアンドペースト攻撃からトークンを保護するために含まれています。
The originating identity and the destination identity are represented by two claims that are required for PASSporT -- the "orig" and "dest" claims. Both "orig" and "dest" MUST contain claim values that are identity claim JSON objects where the child claim name represents an identity type and the claim value is the identity string, both defined in subsequent subsections. Currently, these identities can be represented as either telephone numbers or Uniform Resource Indicators (URIs).
発信元IDと宛先IDは、PASSporTに必要な2つのクレーム、「orig」クレームと「dest」クレームで表されます。 "orig"と "dest"の両方に、IDクレームのJSONオブジェクトであるクレーム値を含める必要があります。子クレーム名はIDタイプを表し、クレーム値はID文字列であり、両方とも後続のサブセクションで定義されます。現在、これらのIDは、電話番号またはUniform Resource Indicator（URI）のいずれかで表すことができます。
The "orig" claim is a JSON object with the claim name of "orig" and a claim value that is a JSON object representing the asserted identity of any type (currently either "tn" or "uri") of the originator of the personal-communications signaling. There MUST be exactly one "orig" claim with exactly one identity claim object in a PASSporT object.
「orig」クレームは、「orig」のクレーム名と、個人の発信者の任意のタイプ（現在は「tn」または「uri」）のアサートされたIDを表すJSONオブジェクトであるクレーム値を持つJSONオブジェクトです。 -通信シグナリング。 PASSporTオブジェクトには、1つの「orig」クレームと1つのIDクレームオブジェクトが必ず存在する必要があります。
Note: As explained in Section 3, the originating identity represents the calling party and may or may not correspond to the authoritative signer of the token.
注：セクション3で説明したように、元のIDは発呼者を表し、トークンの信頼できる署名者に対応する場合と対応しない場合があります。
The "dest" claim is a JSON object with the claim name of "dest" and MUST have at least one identity claim object. The "dest" claim value is an array containing one or more identity claim JSON objects representing the destination identities of any type (currently "tn" or "uri"). If the "dest" claim value array contains both "tn" and "uri" claim names, the JSON object should list the "tn" array first and the "uri" array second. Within the "tn" and "uri" arrays, the identity strings should be put in lexicographical order, including the scheme-specific portion of the URI characters.
「dest」クレームは、クレーム名が「dest」のJSONオブジェクトであり、少なくとも1つのIDクレームオブジェクトが必要です。 「dest」クレーム値は、任意のタイプ（現在「tn」または「uri」）の宛先IDを表す1つ以上のIDクレームJSONオブジェクトを含む配列です。 「dest」クレーム値配列に「tn」と「uri」クレーム名の両方が含まれる場合、JSONオブジェクトは「tn」配列を最初に、「uri」配列を2番目にリストする必要があります。 「tn」および「uri」配列内では、ID文字列は、URI文字のスキーマ固有の部分を含めて、辞書式順序で配置する必要があります。
Note: As explained in Section 3, the destination identity represents the called party and may or may not correspond to the authoritative party verifying the token signature.
注：セクション3で説明したように、宛先IDは着信側を表し、トークン署名を検証する権限のある当事者に対応する場合と対応しない場合があります。
If the originating or destination identity is a telephone number, the claim name representing the identity MUST be "tn".
発信元または宛先のIDが電話番号の場合、IDを表すクレーム名は「tn」でなければなりません。
The claim value for the "tn" claim is the telephone number and MUST be canonicalized according to the procedures specified in [RFC8224], Section 8.3.
「tn」クレームのクレーム値は電話番号であり、[RFC8224]、セクション8.3で指定された手順に従って正規化する必要があります。
If any of the originating or destination identities is in the form of a URI as defined in [RFC3986], the claim name representing the identity MUST be "uri", and the claim value is the URI form of the identity.
発信元または宛先のIDのいずれかが[RFC3986]で定義されているURIの形式である場合、IDを表すクレーム名は「uri」である必要があり、クレーム値はIDのURI形式です。
We recognize that in the future there may be other standard mechanisms for representing identities. The "orig" and "dest" claims currently support "tn" and "uri" but could be extended in the future to allow for other identity types with new IANA-registered unique types to represent these forms.
将来的には、アイデンティティを表すための他の標準的なメカニズムが存在する可能性があることを認識しています。 "orig"および "dest"クレームは現在 "tn"および "uri"をサポートしていますが、将来拡張して、新しいIANA登録の一意のタイプを持つ他のIDタイプがこれらのフォームを表すことができるようにする可能性があります。
The following is an example of a single originator with telephone number identity +12155551212, to a single destination with URI identity "sip:alice@example.com":
以下は、電話番号ID +12155551212の単一の発信者から、URI ID「sip：alice@example.com」の単一の宛先への例です。
{
"dest":{"uri":["sip:alice@example.com"]},
"iat":1443208345,
"orig":{"tn":"12155551212"}
}
The following is an example of a single originator with telephone number identity +12155551212, to multiple destination identities with telephone number identity +12125551212 and two URI identities -- "sip:alice@example.com" and "sip:bob@example.com":
以下は、電話番号ID +12155551212を持つ単一の発信者から、電話番号ID +12125551212および2つのURI ID-"sip：alice@example.com"および "sip：bob@example.com"を持つ複数の宛先IDの例です。 "：
{
"dest":{
"tn":["12125551212"],
"uri":["sip:alice@example.com",
"sip:bob@example.net"]
},
"iat":1443208345,
"orig":{"tn":"12155551212"}
}
Some protocols that use PASSporT may also want to protect media security keys delivered within their signaling in order to bind those keys to the identities established in the signaling layers. The "mky" claim is an optional PASSporT claim defining the assertion of media key fingerprints carried in the Session Description Protocol (SDP) [RFC4566] via the "a=fingerprint" attribute ([RFC4572], Section 5). This claim can support either a single fingerprint or multiple fingerprints appearing in a single SDP body corresponding to one or more media streams offered as defined in [RFC8122].
PASSporTを使用する一部のプロトコルでは、シグナリング内で配信されるメディアセキュリティキーを保護して、それらのキーをシグナリングレイヤで確立されたIDにバインドすることもできます。 「mky」クレームは、オプションのPASSporTクレームであり、「a = fingerprint」属性を介してセッション記述プロトコル（SDP）[RFC4566]で伝達されるメディアキーフィンガープリントのアサーションを定義します（[RFC4572]、セクション5）。この主張は、[RFC8122]で定義されているように提供される1つ以上のメディアストリームに対応する単一のSDP本文に表示される単一の指紋または複数の指紋をサポートできます。
The "mky" claim MUST be formatted as a JSON object with an array that includes the "alg" and "dig" claims with the corresponding algorithm and hexadecimal values. If there is more than one fingerprint value associated with different media streams in SDP, the fingerprint values MUST be constructed as a JSON array denoted by square brackets ("[" and "]"). For the "dig" claim, the claim value MUST be the hash of the hexadecimal value without any colons.
「mky」クレームは、対応するアルゴリズムと16進値を持つ「alg」クレームと「dig」クレームを含む配列を持つJSONオブジェクトとしてフォーマットする必要があります。 SDPの異なるメディアストリームに関連付けられた複数のフィンガープリント値がある場合、フィンガープリント値は角かっこ（ "["および "]"）で表されるJSON配列として構築する必要があります。 「dig」クレームの場合、クレーム値は、コロンなしの16進値のハッシュでなければなりません。
The "mky" claim is a JSON object with a claim name of "mky" and a claim value of a JSON array denoted by brackets. The "mky" claim value JSON array MUST be constructed as follows:
"mky"クレームは、クレーム名が "mky"で、JSON配列のクレーム値が角かっこで示されているJSONオブジェクトです。 「mky」クレーム値のJSON配列は、次のように構築する必要があります。
1. Take each "a=fingerprint" line carried in the SDP.
1. SDPで運ばれる各「a = fingerprint」行を取り上げます。
2. Sort the lines based on the UTF-8 [RFC3629] encoding of the concatenation of the "alg" and "dig" claim value strings.
2. 「alg」および「dig」クレーム値文字列の連結のUTF-8 [RFC3629]エンコーディングに基づいて行をソートします。
3. Encode the array in the order of the sorted lines, where each "mky" array element is a JSON object with two elements corresponding to the "alg" and "dig" objects, with "alg" first and "dig" second.
3. 並べ替えられた行の順序で配列をエンコードします。各「mky」配列要素は、「alg」オブジェクトと「dig」オブジェクトに対応する2つの要素を持つJSONオブジェクトで、「alg」が最初、「dig」が2番目です。
An example claim with the "mky" claim is as follows:
「mky」クレームを使用したクレームの例は次のとおりです。
For an SDP offer that includes the following fingerprint values,
以下のフィンガープリント値を含むSDPオファーの場合、
a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:
5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1
a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65
:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
the PASSporT Payload object would be:
PASSporT Payloadオブジェクトは次のようになります。
{
"dest":{"uri":["sip:alice@example.com"]},
"iat":1443208345,
"mky":[
{
"alg":"sha-256",
"dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
F17A03A27DF9B07F4619B2"
},
{
"alg":"sha-256",
"dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
AB3E4B652E7D463F5442CD54F1"
}
],
"orig":{"tn":"12155551212"}
}
The signature of the PASSporT is created as specified by JWS ([RFC7515], Section 5.1, Steps 1 through 6). PASSporT MUST use the JWS Protected Header. For the JWS Payload and the JWS Protected Header, however, the lexicographic ordering and whitespace rules described in Sections 4 and 5 of this document, and the JSON serialization rules in Section 9 of this document, MUST be followed.
PASSporTの署名は、JWS（[RFC7515]、セクション5.1、ステップ1〜6）の指定に従って作成されます。 PASSporTはJWS保護ヘッダーを使用する必要があります。ただし、JWSペイロードとJWS保護ヘッダーの場合、このドキュメントのセクション4と5で説明されている辞書式順序と空白のルール、およびこのドキュメントのセクション9のJSONシリアル化ルールに従う必要があります。
Appendix A of this document has a detailed example of how to follow the steps to create the JWS Signature.
このドキュメントの付録Aには、JWSシグネチャを作成する手順に従う方法の詳細な例があります。
Step 7 of the JSON serialization procedure in [RFC7515], Section 5.1 is not supported for PASSporT.
[RFC7515]のJSONシリアル化手順のステップ7、セクション5.1はPASSporTではサポートされていません。
[RFC7515], Section 5.1, Step 8 describes the method to create the final JWS Compact Serialization form of the PASSporT.
[RFC7515]、セクション5.1、ステップ8では、PASSporTの最終的なJWS Compact Serializationフォームを作成する方法について説明しています。
For a using protocol of PASSporT, the PASSporT claims as well as the PASSporT header may include redundant or default information that could be reconstructed at the destination based on information provided in the signaling protocol transporting the PASSporT object. In this case, it may be advantageous to have a more compact form of PASSporT to save the transmission of the bytes needed to represent the header and claims.
PASSporTのプロトコルを使用する場合、PASSporTクレームとPASSporTヘッダーには、PASSporTオブジェクトを転送するシグナリングプロトコルで提供される情報に基づいて宛先で再構築できる冗長またはデフォルトの情報が含まれる場合があります。この場合、ヘッダーとクレームを表すために必要なバイトの送信を節約するために、よりコンパクトな形式のPASSporTを用意すると有利な場合があります。
This specification defines the compact form of the PASSporT, in the spirit of the form defined in [RFC7515], Appendix F, with the use of two periods ("..") to represent the header and claim objects being removed, followed by the PASSporT signature as defined in Section 6, and the need for the destination to reconstruct the header and claim objects in order to verify the signature.
この仕様は、[RFC7515]の付録Fで定義されている形式の精神に基づいて、PASSporTのコンパクトな形式を定義しています。2つのピリオド（ ".."）を使用して、削除されるヘッダーとクレームオブジェクトを表し、その後にセクション6で定義されているPASSporT署名、および署名を検証するために宛先がヘッダーとクレームオブジェクトを再構築する必要性。
In order to construct the compact form of the PASSporT string, the procedure described in Section 6 MUST be used, with the exception of [RFC7515], Section 5.1, Step 8. This step would be replaced by the following construction of the compact form of PASSporT, ".." || BASE64URL(JWS Signature).
PASSporT文字列のコンパクトな形式を構築するには、セクション6で説明されている手順を使用する必要があります。ただし、[RFC7515]、セクション5.1、ステップ8を除きます。このステップは、以下のコンパクトな形式の構造に置き換えられます。 PASSporT、「..」|| BASE64URL（JWS署名）。
The using protocol of the compact form of PASSporT MUST be accompanied by a specification for how the header and claims objects can be reconstructed from information in the signaling protocol being used.
PASSporTのコンパクト形式の使用プロトコルは、使用されているシグナリングプロトコルの情報からヘッダーオブジェクトとクレームオブジェクトを再構築する方法の仕様を伴う必要があります。
Note that the full form of the PASSporT, containing the entire header, payload, and signature, should also use the lexicographic ordering and whitespace serialization rules, particularly in the case where some using protocols or interworking between protocols may require switching between full and compact forms and maintaining the integrity of the signature.
ヘッダー、ペイロード、および署名全体を含むPASSporTの完全な形式は、辞書使用順序と空白のシリアル化ルールも使用する必要があることに注意してください。特に、プロトコルの使用やプロトコル間の相互作用により、完全な形式とコンパクトな形式の切り替えが必要になる場合があります。署名の整合性を維持します。
The compact form of the following example token (with line breaks between periods used for readability purposes only)
次のトークン例のコンパクトな形式（読みやすさのみを目的として使用されるピリオド間の改行付き）
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 . eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0 . rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN CpTzO3QfPOlckGaS6hEck7w
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9。 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0。 rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN CpTzO3QfPOlckGaS6hEck7w
would be as follows:
次のようになります：
..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN CpTzO3QfPOlckGaS6hEck7w
..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN CpTzO3QfPOlckGaS6hEck7w
PASSporT includes the bare-minimum set of claims needed to securely assert the originating identity and support the secure properties discussed in various parts of this document. JWT supports a straightforward way to add additional asserted or signed information by simply adding new claims. PASSporT can be extended beyond the defined base set of claims to represent other information requiring assertion or validation beyond the originating identity itself as needed.
PASSporTには、元のIDを安全にアサートし、このドキュメントのさまざまな部分で説明されている安全なプロパティをサポートするために必要な最小限の一連のクレームが含まれています。 JWTは、新しいクレームを追加するだけで、アサートまたは署名された情報を追加する簡単な方法をサポートします。 PASSporTは、定義されたクレームの基本セットを超えて拡張され、必要に応じて、元のID自体を超えてアサーションまたは検証を必要とする他の情報を表すことができます。
Any using protocol can extend the payload of PASSporT with additional JWT claims. JWT claims are managed by the "JSON Web Token Claims" IANA registry as defined in [RFC7519], Section 10.1. Implementations of PASSporT MUST support the baseline claims defined in Section 5.2 and MAY support extended claims. If it is necessary for an extension to PASSporT to require that a relying party support a particular extended claim or set of claims in the PASSporT object, it can do so by specifying a "ppt" element for the PASSporT JOSE Header. All values of "ppt" need to be defined in a specification that associates the new value of the "ppt" element with the required claims and behaviors. Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt".
任意の使用プロトコルは、追加のJWTクレームでPASSporTのペイロードを拡張できます。 JWTクレームは、[RFC7519]、セクション10.1で定義されている「JSON Web Token Claims」IANAレジストリによって管理されます。 PASSporTの実装は、セクション5.2で定義されたベースラインクレームをサポートする必要があり、拡張クレームをサポートする場合があります。証明書利用者がPASSporTオブジェクトの特定の拡張されたクレームまたはクレームのセットをサポートすることをPASSporTの拡張で要求する必要がある場合は、PASSporT JOSEヘッダーの "ppt"要素を指定することで可能になります。 「ppt」のすべての値は、「ppt」要素の新しい値を必要なクレームと動作に関連付ける仕様で定義する必要があります。証明書利用者は、サポートされていない「ppt」を含むPASSporTオブジェクトの検証に失敗する必要があります。
Using protocols MUST explicitly define how they carry each claim and the rules for how the header and payload objects are constructed beyond the lexicographical and serialization rules defined in this document.
プロトコルを使用して、各クレームの伝達方法と、ヘッダーおよびペイロードオブジェクトがこのドキュメントで定義されている辞書式およびシリアル化ルールを超えて構築される方法に関するルールを明示的に定義する必要があります。
Using protocols that carry the compact form of PASSporT (Section 7) instead of the full form MUST use only mandatory extensions signaled with "ppt" -- if a using protocol were to add additional optional claims to a PASSporT object it carried in compact form, relying parties would have no way to reconstruct the token. Moreover, using protocols that support the compact form of PASSporT MUST have some field to signal "ppt" to relying parties, as the compact form of PASSporT omits the JOSE Header.
完全な形式ではなくコンパクトな形式のPASSporT（セクション7）を運ぶプロトコルを使用する場合は、「ppt」で通知される必須の拡張のみを使用する必要があります-プロトコルを使用して、コンパクトな形式で運ぶPASSporTオブジェクトにオプションのクレームを追加する場合、依存パーティはトークンを再構築する方法がありません。さらに、PASSporTのコンパクトな形式がJOSEヘッダーを省略しているため、PASSporTのコンパクトな形式をサポートするプロトコルを使用するには、依存者に "ppt"を通知するフィールドが必要です。
An example header with a PASSporT extension type of "foo" is as follows:
PASSporT拡張タイプが「foo」のヘッダーの例は次のとおりです。
{
"alg":"ES256",
"ppt":"foo",
"typ":"passport",
"x5u":"https://tel.example.org/passport.cer"
}
Specifications that define extensions to the PASSporT mechanism MUST explicitly specify what claims they include beyond the base set of claims from this document, the order in which they will appear, and any further information necessary to implement the extension. All extensions MUST include the baseline PASSporT claim elements specified in Section 5; claims may only be appended to the claims object specified; they can never be removed or reordered. Specifying new claims follows the baseline JWT procedures ([RFC7519], Section 10.1). Understanding an extension or new claims defined by the extension on the destination verification of the PASSporT is optional. The creator of a PASSporT object cannot assume that destination systems will understand any given extension. Verification of PASSporTs by destination systems that do support an extension may then trigger appropriate application-level behavior in the presence of an extension; authors of extensions should provide appropriate extension-specific guidance to application developers on this point.
PASSporTメカニズムの拡張を定義する仕様では、このドキュメントの基本的なクレームセット以外にどのクレームが含まれるか、それらが表示される順序、および拡張機能の実装に必要な詳細情報を明示的に指定する必要があります。すべての拡張には、セクション5で指定されたベースラインPASSporTクレーム要素を含める必要があります。クレームは、指定されたクレームオブジェクトにのみ追加できます。削除したり並べ替えたりすることはできません。新しいクレームの指定は、ベースラインのJWT手順に従います（[RFC7519]、セクション10.1）。 PASSporTの宛先検証で拡張または拡張によって定義された新しいクレームを理解することはオプションです。 PASSporTオブジェクトの作成者は、宛先システムが特定の拡張機能を理解するとは想定できません。拡張機能をサポートする宛先システムによるPASSporTの検証は、拡張機能が存在する場合に適切なアプリケーションレベルの動作をトリガーする場合があります。拡張機能の作成者は、この点に関してアプリケーション開発者に適切な拡張機能固有のガイダンスを提供する必要があります。
An example set of extended claims, extending the first example in Section 5.2.1.4 using "bar" as the newly defined claim, would be as follows:
新しく定義されたクレームとして「bar」を使用してセクション5.2.1.4の最初の例を拡張した拡張クレームの例セットは、次のようになります。
{
"bar":"beyond all recognition"
"dest":{"uri":["sip:alice@example.com"]},
"iat":1443208345,
"orig":{"tn":"12155551212"}
}
JSON objects can include spaces and line breaks, and key value pairs can occur in any order. It is therefore a non-deterministic string format. In order to make the digital signature verification work deterministically, the JSON representation of the JWS Protected Header object and JWS Payload object MUST be computed as follows.
JSONオブジェクトにはスペースと改行を含めることができ、キーと値のペアは任意の順序で発生できます。したがって、これは非決定的な文字列形式です。デジタル署名検証を確定的に機能させるには、JWS保護ヘッダーオブジェクトとJWSペイロードオブジェクトのJSON表現を次のように計算する必要があります。
The JSON object MUST follow the following rules. These rules are based on the thumbprint of a JSON Web Key (JWK) as defined in Section 3 Step 1 of [RFC7638].
JSONオブジェクトは、次の規則に従う必要があります。これらのルールは、[RFC7638]のセクション3ステップ1で定義されているJSON Webキー（JWK）のサムプリントに基づいています。
1. The JSON object MUST contain no whitespace or line breaks before or after any syntactic elements.
1. JSONオブジェクトには、構文要素の前後に空白や改行を含めないでください。
2. JSON objects MUST have the keys ordered lexicographically by the Unicode [UNICODE] code points of the member names.
2. JSONオブジェクトは、メンバー名のUnicode [UNICODE]コードポイントによって辞書順に並べられたキーを持つ必要があります。
3. JSON value literals MUST be lowercase.
3. JSON値リテラルは小文字でなければなりません。
4. JSON numbers are to be encoded as integers unless the field is defined to be encoded otherwise.
4. JSON番号は、フィールドが別の方法でエンコードされるように定義されていない限り、整数としてエンコードされます。
5. Encoding rules MUST be applied recursively to member values and array values.
5. エンコーディングルールは、メンバー値と配列値に再帰的に適用する必要があります。
Note: For any PASSporT extension claims, member names within the scope of a JSON object MUST NOT be equal to other member names; otherwise, serialization will not be deterministic.
注：PASSporT拡張機能のクレームの場合、JSONオブジェクトのスコープ内のメンバー名は他のメンバー名と同じであってはなりません（MUST NOT）。それ以外の場合、シリアル化は確定的ではありません。
This section demonstrates the deterministic JSON serialization for the example PASSporT Payload shown in Section 5.2.1.4.
このセクションでは、セクション5.2.1.4に示すPASSporTペイロードの例の確定的なJSONシリアル化について説明します。
The initial JSON object is shown here:
最初のJSONオブジェクトを次に示します。
{
"dest":{"uri":["sip:alice@example.com"]},
"orig":{"tn":"12155551212"}
"iat":1443208345,
"mky":[
{
"alg":"sha-256",
"dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
F17A03A27DF9B07F4619B2"
},
{
"alg":"sha-256",
"dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
AB3E4B652E7D463F5442CD54F1"
}
],
}
The parent members of the JSON object are as follows:
JSONオブジェクトの親メンバーは次のとおりです。
o "dest"
o 「目的地」
o "orig"
o 「元の」
o "iat"
o "男の子"
o "mky"
o 「mky」
Their lexicographic order is:
それらの辞書式順序は次のとおりです。
o "dest"
o 「目的地」
o "iat"
o "男の子"
o "mky"
o 「mky」
o "orig" The final constructed deterministic JSON serialization representation, with whitespace and line breaks removed (with line breaks used for display purposes only), is:
o "orig"空白と改行が削除された（表示目的でのみ改行が使用される）、最終的に構築された確定的なJSONシリアル化表現は次のとおりです。
{"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky":
[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5
4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5
40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
"orig":{"tn":"12155551212"}}
There are a number of security considerations regarding the use of the token for the avoidance of replay and cut-and-paste attacks. PASSporTs SHOULD only be sent with application-level protocol information (e.g., for SIP, an INVITE as defined in [RFC3261]) corresponding to the required fields in the token. A unique set of token claims and token signature is constructed using the originating identity being asserted with the "orig" claim along with the following two claims:
リプレイ攻撃とカットアンドペースト攻撃を回避するためのトークンの使用に関しては、セキュリティに関する考慮事項がいくつかあります。トークンは、トークンの必須フィールドに対応するアプリケーションレベルのプロトコル情報（たとえば、SIPの場合、[RFC3261]で定義されているINVITE）でのみ送信する必要があります（SHOULD）。トークンクレームとトークン署名の一意のセットは、 "orig"クレームと次の2つのクレームでアサートされる元のIDを使用して構築されます。
o The "iat" claim should correspond to a date/time that the message was originated. It should also be within a relative time that is reasonable for clock drift and transmission time characteristics associated with the application using the PASSporT. Therefore, validation of the token should consider date and time correlation, which could be influenced by usage specific to the signaling protocol and by network time differences.
o 「iat」クレームは、メッセージが発信された日時に対応している必要があります。また、PASSporTを使用するアプリケーションに関連するクロックドリフトおよび伝送時間特性にとって妥当な相対時間内でなければなりません。したがって、トークンの検証では、日付と時刻の相関を考慮する必要があります。これは、シグナリングプロトコルに固有の使用法やネットワークの時間差によって影響を受ける可能性があります。
o The "dest" claim is included to further restrict the use of a valid PASSporT being sent as a replay attack to other destination parties. The verification of the PASSporT at the destination should verify that the "dest" claim matches the destination party as the intended recipient of the message.
o 「dest」クレームは、他の宛先パーティへのリプレイ攻撃として送信される有効なPASSporTの使用をさらに制限するために含まれています。宛先でのPASSporTの検証では、「dest」クレームがメッセージの意図された受信者として宛先当事者と一致することを検証する必要があります。
The use of PASSporTs based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT:
デジタル署名および関連する証明書の検証に基づいてPASSporTを使用するには、認証と認証、または署名されているIDを証明するための署名者の評判を考慮する必要があります。 PASSporTを使用する場合は、以下の考慮事項を認識する必要があります。
o The use of this token should not, in its own right, be considered a full solution for absolute non-repudiation of the identity being asserted.
o このトークンの使用は、それ自体では、アサートされるIDの絶対的な否認防止の完全なソリューションと見なされるべきではありません。
o In many applications, the signer and the end user represented by the asserted identity may not be one and the same. For example, when a service provider signs and validates the token on behalf of the user consuming the service, the provider MUST have an authenticated and secure relationship with the end user or the device initiating and terminating the communications signaling.
o 多くのアプリケーションでは、アサートされたIDによって表される署名者とエンドユーザーは、同一ではない場合があります。たとえば、サービスプロバイダーは、サービスを利用するユーザーに代わってトークンに署名して検証する場合、エンドユーザーまたは通信シグナリングを開始および終了するデバイスとの認証された安全な関係を持っている必要があります。
o Applications that use PASSporT should ensure that the verification of the signature includes a means for verifying that the signer is authoritative through the use of an application-specific or service-specific set of common trust anchors for the application.
o PASSporTを使用するアプリケーションでは、アプリケーションの共通トラストアンカーのアプリケーション固有またはサービス固有のセットを使用して、署名の検証に署名者が信頼できることを検証する手段が含まれていることを確認する必要があります。
This section registers the "application/passport" media type (see [RFC2046] for the definition of "media type") in the "Media Types" registry in the manner described in [RFC6838], to indicate that the content is a PASSporT-defined JWT.
このセクションは、「アプリケーション/パスポート」メディアタイプ（「メディアタイプ」の定義については[RFC2046]を参照）を[RFC6838]で説明されている方法で「メディアタイプ」レジストリに登録し、コンテンツがPASSporT-定義されたJWT。
o Type name: application
o タイプ名：アプリケーション
o Subtype name: passport
o サブタイプ名：パスポート
o Required parameters: N/A
o 必須パラメーター：なし
o Optional parameters: N/A
o オプションのパラメーター：N / A
o Encoding considerations: 8bit; application/passport values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period (".") characters.
o エンコードに関する考慮事項：8ビット。 application / passport値は、ピリオド（ "。"）文字で区切られた、base64urlでエンコードされた一連の値（空の文字列の場合もあります）としてエンコードされます。
o Security considerations: See the Security Considerations section of [RFC7515].
o セキュリティに関する考慮事項：[RFC7515]のセキュリティに関する考慮事項のセクションを参照してください。
o Interoperability considerations: N/A
o 相互運用性に関する考慮事項：N / A
o Published specification: RFC 8225
o 公開された仕様：RFC 8225
o Applications that use this media type: Secure Telephone Identity Revisited (STIR) and other applications that require identity-related assertion
o このメディアタイプを使用するアプリケーション：Secure Telephone Identity Revisited（STIR）およびID関連のアサーションを必要とするその他のアプリケーション
o Fragment identifier considerations: N/A
o フラグメント識別子の考慮事項：なし
o Additional information:
o 追加情報：
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
o Person & email address to contact for further information: Chris Wendt, chris-ietf@chriswendt.net
o 詳細について連絡する人とメールアドレス：Chris Wendt、chris-ietf @ chriswendt.net
o Intended usage: COMMON
o 使用目的：COMMON
o Restrictions on usage: none
o 使用上の制限：なし
o Author: Chris Wendt <chris-ietf@chriswendt.net>
o 作成者：Chris Wendt <chris-ietf@chriswendt.net>
o Change Controller: IESG
o コントローラーの変更：IESG
o Provisional registration? No
o 仮登録？番号
Claim Name: "orig" Claim Description: Originating Identity String Change Controller: IESG Reference: Section 5.2.1 of RFC 8225
クレーム名：「orig」クレームの説明：元のID文字列変更コントローラー：IESGリファレンス：RFC 8225のセクション5.2.1
Claim Name: "dest" Claim Description: Destination Identity String Change Controller: IESG Reference: Section 5.2.1 of RFC 8225
クレーム名：「dest」クレームの説明：宛先ID文字列変更コントローラー：IESGリファレンス：RFC 8225のセクション5.2.1
Claim Name: "mky" Claim Description: Media Key Fingerprint String Change Controller: IESG Reference: Section 5.2.2 of RFC 8225
クレーム名：「mky」クレームの説明：メディアキーフィンガープリント文字列変更コントローラー：IESGリファレンス：RFC 8225のセクション5.2.2
11.3. Registration in "JSON Web Signature and Encryption Header Parameters"
11.3. 「JSON Web Signature and Encryption Header Parameters」への登録
Header Parameter Name: "ppt" Header Parameter Description: PASSporT extension identifier Header Parameter Usage Location(s): JWS Change Controller: IESG Reference: Section 8.1 of RFC 8225
ヘッダーパラメーター名：「ppt」ヘッダーパラメーターの説明：PASSporT拡張識別子ヘッダーパラメーター使用場所：JWS変更コントローラー：IESGリファレンス：RFC 8225のセクション8.1
The IANA has created a new PASSporT Type registry for "ppt" parameter values. That parameter and its values are defined in Section 8.1. New registry entries must contain the name of the "ppt" parameter value and the specification in which the value is described. The policy for this registry is Specification Required [RFC8126].
IANAは、「ppt」パラメータ値用の新しいPASSporT Typeレジストリを作成しました。そのパラメーターとその値はセクション8.1で定義されています。新しいレジストリエントリには、「ppt」パラメータ値の名前と、その値が記述されている仕様が含まれている必要があります。このレジストリのポリシーは、Specification Required [RFC8126]です。
[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>。
[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>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[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>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/RFC4572, July 2006, <https://www.rfc-editor.org/info/rfc4572>.
[RFC4572] Lennox、J。、「Session Description Protocol（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 4572、DOI 10.17487 / RFC4572、2006年7月、<https：// www .rfc-editor.org / info / rfc4572>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：//www.rfc- editor.org/info/rfc6838>。
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979]ポルノ、T。、「デジタル署名アルゴリズム（DSA）と楕円曲線デジタル署名アルゴリズム（ECDSA）の決定論的使用法」、RFC 6979、DOI 10.17487 / RFC6979、2013年8月、<https：//www.rfc- editor.org/info/rfc6979>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<https://www.rfc-editor.org/info/rfc7518>。
[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>。
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.
[RFC7638]ジョーンズ、M。およびN.崎村、「JSON Web Key（JWK）Thumbprint」、RFC 7638、DOI 10.17487 / RFC7638、2015年9月、<https://www.rfc-editor.org/info/rfc7638> 。
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, <https://www.rfc-editor.org/info/rfc8122>.
[RFC8122] Lennox、J。およびC. Holmberg、「セッション記述プロトコル（SDP）のトランスポート層セキュリティ（TLS）プロトコルを介した接続指向のメディアトランスポート」、RFC 8122、DOI 10.17487 / RFC8122、2017年3月、<https ：//www.rfc-editor.org/info/rfc8122>。
[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>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[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：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[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>。
[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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
Appendix A. Example ES256-Based PASSporT JWS Serialization and Signature
付録A. ES256ベースのPASSporT JWSシリアル化と署名の例
For PASSporT, there will always be a JWS with the following members:
PASSporTの場合、次のメンバーを持つJWSが常に存在します。
o "protected", with the value BASE64URL(UTF8(JWS Protected Header))
o 「保護」、値BASE64URL（UTF8（JWS Protected Header））
o "payload", with the value BASE64URL(JWS Payload)
o 「ペイロード」、値BASE64URL（JWS Payload）
o "signature", with the value BASE64URL(JWS Signature)
o 「署名」、値BASE64URL（JWS Signature）
This example will follow the steps in JWS ([RFC7515], Section 5.1, Steps 1-6 and 8); it incorporates the additional serialization steps required for PASSporT.
この例は、JWSの手順（[RFC7515]、セクション5.1、手順1〜6および8）に従います。 PASSporTに必要な追加のシリアル化手順が組み込まれています。
Step 1 for JWS references the JWS Payload. An example PASSporT Payload is as follows:
JWSのステップ1はJWSペイロードを参照します。 PASSporTペイロードの例は次のとおりです。
{
"dest":{"uri":["sip:alice@example.com"]}
"iat":1471375418,
"orig":{"tn":"12155551212"}
}
This would be serialized to the following form (with line break used for display purposes only):
これは次の形式にシリアライズされます（改行は表示目的でのみ使用されます）：
{"dest":{"uri":["sip:alice@example.com"]},"iat":1471375418,
"orig":{"tn":"12155551212"}}
Step 2 computes the BASE64URL(JWS Payload), producing this value (with line break used for display purposes only):
ステップ2はBASE64URL（JWS Payload）を計算し、この値を生成します（改行は表示目的でのみ使用されます）。
eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19
For Step 3, an example PASSporT Protected Header constructed as a JOSE Header is as follows:
ステップ3の場合、JOSEヘッダーとして構築されたPASSporT保護ヘッダーの例は次のとおりです。
{
"alg":"ES256",
"typ":"passport",
"x5u":"https://cert.example.org/passport.cer"
}
This would be serialized to the following form (with line break used
for display purposes only):
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org
/passport.cer"}
Step 4 performs the BASE64URL(UTF8(JWS Protected Header)) operation and encoding, producing this value (with line break used for display purposes only):
ステップ4は、BASE64URL（UTF8（JWS Protected Header））操作とエンコードを実行して、この値を生成します（表示目的でのみ改行が使用されます）。
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
Steps 5 and 6 perform the computation of the digital signature of the PASSporT Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || "." || BASE64URL(JWS Payload)), using ES256 as the algorithm and the BASE64URL(JWS Signature).
手順5および6では、アルゴリズムとしてES256を使用して、PASSporT署名入力ASCII（BASE64URL（UTF8（JWS Protected Header））|| "。" || BASE64URL（JWS Payload））のデジタル署名の計算を実行し、BASE64URL（ JWS署名）。
VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb a7UWYRM47ZbNFdOJquE35cw
VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb a7UWYRM47ZbNFdOJquE35cw
Step 8 describes how to create the final PASSporT, concatenating the values in the order Header.Payload.Signature with period (".") characters. For the above example values, this would produce the following (with line breaks between periods used for readability purposes only):
手順8では、最終的なPASSporTを作成する方法を説明し、値をピリオド（ "。"）文字でHeader.Payload.Signatureの順序で連結します。上記の例の値の場合、これにより以下が生成されます（読みやすさのみを目的として使用されるピリオド間の改行）。
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9 . eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19 . VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb a7UWYRM47ZbNFdOJquE35cw
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9。 eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI 6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19。 VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb a7UWYRM47ZbNFdOJquE35cw
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY-----
Acknowledgments
謝辞
Particular thanks to members of the ATIS and SIP Forum NNI Task Group, including Jim McEachern, Martin Dolly, Richard Shockey, John Barnhill, Christer Holmberg, Victor Pascual Avila, Mary Barnes, and Eric Burger, for their review, ideas, and contributions. Thanks also to Henning Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark Miller, Ted Hardie, Dave Crocker, Robert Sparks, and Jim Schaad for valuable feedback on the technical and security aspects of the document. Additional thanks to Harsha Bellur for assistance in coding the example tokens.
ATISおよびSIPフォーラムのNNIタスクグループのメンバーに特に感謝します。彼らのレビュー、アイデア、および貢献に対して、Jim McEachern、Martin Dolly、Richard Shockey、John Barnhill、Christer Holmberg、Victor Pascual Avila、Mary Barnes、およびEric Burgerが含まれます。また、ドキュメントの技術面とセキュリティ面に関する貴重なフィードバックを提供してくれたヘニングシュルズリンネ、ラスハウズリー、アランジョンストン、リチャードバーンズ、マークミラー、テッドハーディ、デイブクロッカー、ロバートスパークス、ジムシャードにも感謝します。サンプルトークンのコーディングを支援してくれたHarsha Bellurに感謝します。
Authors' Addresses
著者のアドレス
Chris Wendt Comcast One Comcast Center Philadelphia, PA 19103 United States of America
クリスウェントコムキャストワンコムキャストセンターフィラデルフィア、PA 19103アメリカ合衆国
Email: chris-ietf@chriswendt.net
Jon Peterson Neustar Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar Inc. 1800 Sutter St. Suite 570 Concord、CA 94520アメリカ合衆国
Email: jon.peterson@neustar.biz