RFC 9578 - Privacy Pass Issuance Protocols 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9578.html
タイトル : RFC 9578 - プライバシーパス発行プロトコル
翻訳編集 : 自動生成

[要約] この文書は、プライバシーパスのトークンのための2つのメッセージ発行プロトコルのバリアントを指定しています。1つは発行者の秘密鍵を使用してプライベートに検証可能なトークンを生成し、もう1つは発行者の公開鍵を使用して公開に検証可能なトークンを生成します。文書内の「発行プロトコル」と「発行プロトコル」のインスタンスは、プライバシーパスの発行プロトコルの2つのバリアントを指すために交換可能に使用されます。

Internet Engineering Task Force (IETF)                           S. Celi
Request for Comments: 9578                                Brave Software
Category: Standards Track                                    A. Davidson
ISSN: 2070-1721                  NOVA LINCS, Universidade NOVA de Lisboa
                                                               S. Valdez
                                                              Google LLC
                                                              C. A. Wood
                                                              Cloudflare
                                                               June 2024

Privacy Pass Issuance Protocols

プライバシーパス発行プロトコル

Abstract

概要

This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol.

このドキュメントは、プライバシーパストークンの2メッセージ発行プロトコルの2つのバリエーションを指定します。1つは、発行者の秘密鍵を使用して個人的に検証可能なトークンと、発行者の公開キーを使用して公開されているトークンを生成するものを作成します。このドキュメントのテキストにおける「発行プロトコル」と「発行プロトコル」のインスタンスは、プライバシーパス発行プロトコルの2つのバリアントを参照するために交換可能に使用されます。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9578.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9578で取得できます。

Copyright Notice

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

   1.  Introduction
   2.  Terminology
   3.  Protocol Overview
   4.  Configuration
   5.  Issuance Protocol for Privately Verifiable Tokens
     5.1.  Client-to-Issuer Request
     5.2.  Issuer-to-Client Response
     5.3.  Finalization
     5.4.  Token Verification
     5.5.  Issuer Configuration
   6.  Issuance Protocol for Publicly Verifiable Tokens
     6.1.  Client-to-Issuer Request
     6.2.  Issuer-to-Client Response
     6.3.  Finalization
     6.4.  Token Verification
     6.5.  Issuer Configuration
   7.  Security Considerations
   8.  IANA Considerations
     8.1.  Well-Known "private-token-issuer-directory" URI
     8.2.  Privacy Pass Token Types
       8.2.1.  Token Type VOPRF(P-384, SHA-384)
       8.2.2.  Token Type Blind RSA (2048-bit)
     8.3.  Media Types
       8.3.1.  "application/private-token-issuer-directory" Media Type
       8.3.2.  "application/private-token-request" Media Type
       8.3.3.  "application/private-token-response" Media Type
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Appendix A.  Test Vectors
     A.1.  Issuance Protocol 1 - VOPRF(P-384, SHA-384)
     A.2.  Issuance Protocol 2 - Blind RSA (2048-bit)
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The Privacy Pass protocol provides a privacy-preserving authorization mechanism. In essence, the protocol allows Clients to provide cryptographic tokens that prove nothing other than that they have been created by a given server in the past [ARCHITECTURE].

プライバシーパスプロトコルは、プライバシーを提供する許可メカニズムを提供します。本質的に、このプロトコルにより、クライアントは、過去に特定のサーバーによって作成されたこと以外に何もないことを証明する暗号化トークンを提供できます[アーキテクチャ]。

This document describes two issuance protocols for Privacy Pass, each of which is built on [HTTP]. It specifies two variants: one that is privately verifiable using the Issuer Private Key based on the Oblivious Pseudorandom Function (OPRF) as defined in [OPRF] and one that is publicly verifiable using the Issuer Public Key based on the blind RSA signature scheme [BLINDRSA]. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol.

このドキュメントでは、プライバシーパスのための2つの発行プロトコルについて説明します。それぞれが[http]上に構築されています。2つのバリエーションを指定します。1つは[OPRF]で定義されている忘却の擬似ランダム関数（OPRF）に基づいた発行者の秘密鍵を使用して個人的に検証可能なものと、ブラインドRSA署名スキームに基づく発行者公開鍵を使用して公開されているもの[ブラインドルサ]。このドキュメントのテキストにおける「発行プロトコル」と「発行プロトコル」のインスタンスは、プライバシーパス発行プロトコルの2つのバリアントを参照するために交換可能に使用されます。

This document does not cover the Privacy Pass architecture, which includes (1) choices that are necessary for deployment and (2) application-specific choices for protecting Client privacy. This information is covered in [ARCHITECTURE].

このドキュメントでは、（1）展開に必要な選択肢と（2）クライアントのプライバシーを保護するためのアプリケーション固有の選択肢を含むプライバシーパスアーキテクチャをカバーしていません。この情報は[アーキテクチャ]でカバーされています。

2. Terminology

2. 用語

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.

「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

This document uses the terms "Origin", "Client", "Issuer", and "Token" as defined in Section 2 of [ARCHITECTURE]. Moreover, the following additional terms are used throughout this document.

このドキュメントでは、[アーキテクチャ]のセクション2で定義されている「Origin」、「クライアント」、「発行者」、「トークン」という用語を使用します。さらに、このドキュメント全体で次の追加用語が使用されています。

Issuer Public Key:

発行者の公開キー：

The public key (from a private-public key pair) used by the Issuer for issuing and verifying tokens.

トークンの発行と検証に発行者が使用する公開鍵（プライベート公開キーペアから）。

Issuer Private Key:

発行者の秘密鍵：

The private key (from a private-public key pair) used by the Issuer for issuing and verifying tokens.

トークンの発行と検証に発行者が使用する秘密鍵（プライベート公開キーペアから）。

Unless otherwise specified, this document encodes protocol messages in TLS notation ([TLS13], Section 3). Moreover, all constants are in network byte order.

特に指定されていない限り、このドキュメントはTLS表記（[TLS13]、セクション3）のプロトコルメッセージをエンコードします。さらに、すべての定数はネットワークバイトの順序です。

3. Protocol Overview

3. プロトコルの概要

The issuance protocols defined in this document embody the core of Privacy Pass. Clients receive TokenChallenge inputs from the redemption protocol ([AUTHSCHEME], Section 2.1) and use the issuance protocols to produce corresponding token values ([AUTHSCHEME], Section 2.2). The issuance protocol describes how Clients and Issuers interact to compute a token using a one-round protocol consisting of a TokenRequest from the Client and a TokenResponse from the Issuer. This interaction is shown below.

このドキュメントで定義されている発行プロトコルは、プライバシーパスのコアを具体化しています。クライアントは、redいプロトコル（[authscheme]、セクション2.1）からtokenchallenge入力を受け取り、発行プロトコルを使用して対応するトークン値（[authscheme]、セクション2.2）を生成します。発行プロトコルは、クライアントからのトークンプロトコルを使用して、クライアントからのトークンレクエストと発行者からのtokenResponseで構成される1ラウンドプロトコルを使用して、クライアントと発行者がどのように対話してトークンを計算するかについて説明します。この相互作用を以下に示します。

   +--------+            +--------+         +----------+ +--------+
   | Origin |            | Client |         | Attester | | Issuer |
   +---+----+            +---+----+         +----+-----+ +---+----+
       |                     |                   |           |
       |<----- Request ------+                   |           |
       +-- TokenChallenge -->|                   |           |
       |                     |<== Attestation ==>|           |
       |                     |                   |           |
       |                     +--------- TokenRequest ------->|
       |                     |<-------- TokenResponse -------+
       |<-- Request+Token ---+                   |           |
       |                     |                   |           |

Figure 1: Issuance Overview

図1：発行の概要

The TokenChallenge inputs to the issuance protocols described in this document can be interactive or non-interactive and can be per Origin or across Origins.

このドキュメントで説明されている発行プロトコルへのTokenChallenge入力は、インタラクティブまたは非インタラクティブであり、起源またはオリジンごとに存在する場合があります。

The issuance protocols defined in this document are compatible with any deployment model defined in Section 4 of [ARCHITECTURE]. The details of attestation are outside the scope of the issuance protocol; see Section 4 of [ARCHITECTURE] for information about how attestation can be implemented in each of the relevant deployment models.

このドキュメントで定義されている発行プロトコルは、[アーキテクチャ]のセクション4で定義されている任意の展開モデルと互換性があります。証明の詳細は、発行プロトコルの範囲外です。関連する各展開モデルでどのように実装できるかについては、[アーキテクチャ]のセクション4を参照してください。

This document describes two variants of the issuance protocol: one that is privately verifiable (Section 5) using the Issuer Private Key based on the OPRF [OPRF] and one that is publicly verifiable (Section 6) using the Issuer Public Key based on the blind RSA signature scheme [BLINDRSA].

このドキュメントでは、発行プロトコルの2つのバリエーションについて説明します。OPRF[OPRF]に基づいた発行者の秘密鍵を使用して個人的に検証可能なもの（セクション5）と、ブラインドに基づく発行者公開鍵を使用して、公開されているもの（セクション6）を使用します（セクション5）RSA署名スキーム[BlindRSA]。

4. Configuration

4. 構成

Issuers MUST provide two parameters for configuration:

発行者は、構成に2つのパラメーターを提供する必要があります。

Issuer Request URL:

発行者リクエストURL：

A token request URL for generating access tokens. For example, an Issuer Request URL might be <https://issuer.example.net/request>.

アクセストークンを生成するためのトークンリクエストURL。たとえば、発行者要求URLは<https://issuer.example.net/request>になる場合があります。

Issuer Public Key values:

発行者の公開鍵の値：

A list of Issuer Public Keys for the issuance protocol.

発行プロトコルの発行者パブリックキーのリスト。

The Issuer parameters can be obtained from an Issuer via a directory object, which is a JSON object ([RFC8259], Section 4) whose values are other JSON values ([RFC8259], Section 3) for the parameters. The contents of this JSON object are defined in Table 1.

発行者パラメーターは、パラメーターの他のJSON値（[RFC8259]、セクション3）であるJSONオブジェクト（[RFC8259]、セクション4）であるディレクトリオブジェクト（[RFC8259]、セクション4）を介して発行者から取得できます。このJSONオブジェクトの内容は、表1に定義されています。

       +====================+======================================+
       | Field Name         | Value                                |
       +====================+======================================+
       | issuer-request-uri | Issuer Request URL value (as an      |
       |                    | absolute URL or as a URL relative to |
       |                    | the directory object) as a percent-  |
       |                    | encoded URL string, represented as a |
       |                    | JSON string ([RFC8259], Section 7)   |
       +--------------------+--------------------------------------+
       | token-keys         | List of Issuer Public Key values,    |
       |                    | each represented as JSON objects     |
       |                    | ([RFC8259], Section 4)               |
       +--------------------+--------------------------------------+

Table 1: Issuer Directory Object Description

表1：発行者ディレクトリオブジェクトの説明

Each "token-keys" JSON object contains the fields and corresponding raw values defined in Table 2.

各「トークンキー」JSONオブジェクトには、表2に定義されているフィールドと対応する生値が含まれています。

   +============+=====================================================+
   | Field Name | Value                                               |
   +============+=====================================================+
   | token-type | Integer value of the token type, as defined in      |
   |            | Section 8.2, represented as a JSON number           |
   |            | ([RFC8259], Section 6)                              |
   +------------+-----------------------------------------------------+
   | token-key  | The base64url public key, encoded per [RFC4648],    |
   |            | for use with the issuance protocol as determined by |
   |            | the token-type field, including padding,            |
   |            | represented as a JSON string ([RFC8259], Section 7) |
   +------------+-----------------------------------------------------+

Table 2: Issuer "token-keys" Object Description

表2：発行者の「トークンキー」オブジェクト説明

Each "token-keys" JSON object may also contain the optional field "not-before". The value of this field is the UNIX timestamp (number of seconds since January 1, 1970, UTC -- see Section 4.2.1 of [TIMESTAMP]) at which the key can be used. If this field is present, Clients SHOULD NOT use a token key before this timestamp, as doing so can lead to issuance failures. The purpose of this field is to assist in scheduled key rotations.

各「トークンキー」JSONオブジェクトには、オプションのフィールド「前に」も含まれている場合があります。このフィールドの値は、キーを使用できるUNIXタイムスタンプです（1970年1月1日以降、UTC -[Timestamp]のセクション4.2.1を参照）。このフィールドが存在する場合、クライアントはこのタイムスタンプの前にトークンキーを使用してはなりません。このフィールドの目的は、スケジュールされたキーローテーションを支援することです。

Beyond staging keys with the "not-before" value, Issuers MAY advertise multiple "token-keys" for the same token-type to facilitate key rotation. In this case, Issuers indicate their preference for which token key to use based on the order of keys in the list, with preference given to keys earlier in the list. Clients SHOULD use the first key in the "token-keys" list that either does not have a "not-before" value or has a "not-before" value in the past, since the first such key is the most likely to be valid in the given time window. Origins can attempt to use any key in the "token-keys" list to verify tokens, starting with the most preferred key in the list. Trial verifications like this can help deal with Client clock skew.

「以前に」値を持つキーをステージングするだけで、発行者は、キーローテーションを容易にするために、同じトークンタイプの複数の「トークンキー」を宣伝する場合があります。この場合、発行者は、リスト内のキーの順序に基づいて使用するトークンキーの好みを示し、リストの早い段階でキーを好みます。クライアントは、「トークンキー」リストの最初のキーを使用する必要があります。これは、最初のそのようなキーは最も可能性が高いため、「トークンキー」リストに「以前に」値を持たないか、過去に「前にない」値を持っています。指定された時間ウィンドウで有効です。Originsは、「トークンキー」リストの任意のキーを使用して、リストの最も好ましいキーから始めて、トークンを検証しようとします。このような試行検証は、クライアントの時計のスキューに対処するのに役立ちます。

Altogether, the Issuer's directory could look like the following (with the "token-key" fields abbreviated):

合計で、発行者のディレクトリは次のように見えることがあります（「トークンキー」フィールドが略されています）：

    {
       "issuer-request-uri": "https://issuer.example.net/request",
       "token-keys": [
         {
           "token-type": 2,
           "token-key": "MI...AB",
           "not-before": 1686913811,
         },
         {
           "token-type": 2,
           "token-key": "MI...AQ",
         }
       ]
    }

Clients that use this directory resource before 1686913811 in UNIX time would use the second key in the "token-keys" list, whereas Clients that use this directory after 1686913811 in UNIX time would use the first key in the "token-keys" list.

1686913811以前にUNIX時間にこのディレクトリリソースを使用するクライアントは、「トークンキー」リストの2番目のキーを使用しますが、UNIX時間に1686913811以降にこのディレクトリを使用するクライアントは、「Token-Keys」リストの最初のキーを使用します。

A complete "token-key" value, encoded as it would be in the Issuer directory, would look like the following (line breaks are inserted to fit within the per-line character limits):

発行者ディレクトリにあるようにエンコードされた完全な「トークンキー」値は、次のように見えます（ラインブレークが挿入され、文字ごとの文字制限に収まるように挿入されます）：

   $ echo MIIBUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQE \
    BCDALBglghkgBZQMEAgKiAwIBMAOCAQ8AMIIBCgKCAQEAmKHGAMyeoJt1pj3n7xTtqAPr \
    _DhZAPhJM7Pc8ENR2BzdZwPTTF7KFKms5wt-mL01at0SC-cdBuIj6WYK8Ovz0AyaBuvTv \
    W6SKCh7ZPXEqCGRsq5I0nthREtrYkGo113oMVPVp3sy4VHPgzd8KdzTLGzOrjiUOsSFWb \
    jf21iaVjXJ2VdwdS-8O-430wkucYjGeOJwi8rWx_ZkcHtav0S67Q_SlExJel6nyRzpuuI \
    D9OQm1nxfs1Z4PhWBzt93T2ozTnda3OklF5n0pIXD6bttmTekIw_8Xx2LMis0jfJ1QL99 \
    aA-muXRFN4ZUwORrF7cAcCUD_-56_6fh9s34FmqBGwIDAQAB \
    | sed s/-/+/g | sed s/_/\\//g | openssl base64 -d \
    | openssl asn1parse -dump -inform DER
       0:d=0  hl=4 l= 338 cons: SEQUENCE
       4:d=1  hl=2 l=  61 cons: SEQUENCE
       6:d=2  hl=2 l=   9 prim: OBJECT            :rsassaPss
      17:d=2  hl=2 l=  48 cons: SEQUENCE
      19:d=3  hl=2 l=  13 cons: cont [ 0 ]
      21:d=4  hl=2 l=  11 cons: SEQUENCE
      23:d=5  hl=2 l=   9 prim: OBJECT            :sha384
      34:d=3  hl=2 l=  26 cons: cont [ 1 ]
      36:d=4  hl=2 l=  24 cons: SEQUENCE
      38:d=5  hl=2 l=   9 prim: OBJECT            :mgf1
      49:d=5  hl=2 l=  11 cons: SEQUENCE
      51:d=6  hl=2 l=   9 prim: OBJECT            :sha384
      62:d=3  hl=2 l=   3 cons: cont [ 2 ]
      64:d=4  hl=2 l=   1 prim: INTEGER           :30
      67:d=1  hl=4 l= 271 prim: BIT STRING
      ... truncated public key bytes ...

Issuer directory resources have the media type "application/private-token-issuer-directory" and are located at the well-known location /.well-known/private-token-issuer-directory; see Section 8.1 for the registration information for this well-known URI. This resource is located at a well-known URI because Issuers are defined by an Origin name in TokenChallenge structures; see Section 2.1 of [AUTHSCHEME].

発行者ディレクトリリソースには、メディアタイプの「アプリケーション/プライベートトークン - イッサーディレクトリ」があり、有名な場所/.Well-Known/Private-Token-Issuer-Directoryにあります。この有名なURIの登録情報については、セクション8.1を参照してください。このリソースは、発行者がTokenChallenge構造の原点名で定義されるため、よく知られているURIにあります。[authscheme]のセクション2.1を参照してください。

The Issuer directory and Issuer resources SHOULD be available on the same Origin. If an Issuer wants to service multiple different Issuer directories, they MUST create unique subdomains for each directory so the TokenChallenge defined in Section 2.1 of [AUTHSCHEME] can be differentiated correctly.

発行者ディレクトリと発行者のリソースは、同じ起源で利用できるようにする必要があります。発行者が複数の異なる発行者ディレクトリにサービスを提供したい場合、[authscheme]のセクション2.1で定義されているトークンチャレンジを正しく区別できるように、各ディレクトリの一意のサブドメインを作成する必要があります。

Issuers SHOULD use HTTP cache directives to permit caching of this resource [RFC5861]. The cache lifetime depends on the Issuer's key rotation schedule. Regular rotation of token keys is recommended to minimize the risk of key compromise and any harmful effects that happen due to key compromise.

発行者は、HTTPキャッシュ指令を使用して、このリソースのキャッシュを許可する必要があります[RFC5861]。キャッシュの寿命は、発行者のキーローテーションスケジュールに依存します。主要な妥協のリスクと重要な妥協のために発生する有害な影響を最小限に抑えるために、トークンキーの定期的な回転が推奨されます。

Issuers can control the cache lifetime with the Cache-Control header, as follows:

発行者は、次のように、キャッシュコントロールヘッダーでキャッシュの寿命を制御できます。

     Cache-Control: max-age=86400

Consumers of the Issuer directory resource SHOULD follow the usual HTTP caching semantics [RFC9111] when processing this resource. Long cache lifetimes may result in the use of stale Issuer configuration information, whereas short lifetimes may result in decreased performance. When the use of an Issuer configuration results in token issuance failures, e.g., because the Issuer has invalidated its directory resource before its expiration time and issuance requests using this configuration are unsuccessful, the directory SHOULD be fetched and revalidated. Issuance will continue to fail until the Issuer configuration is updated.

発行者ディレクトリリソースの消費者は、このリソースを処理する際には、通常のHTTPキャッシングセマンティクス[RFC9111]に従う必要があります。長いキャッシュの寿命は、古い発行者構成情報を使用する可能性がありますが、寿命が短いとパフォーマンスが低下する可能性があります。発行者の構成を使用すると、発行者が有効期限を迎える前にディレクトリリソースを無効にしたため、この構成を使用した発行要求が失敗したため、発行者が発行された発行障害をもたらす場合、ディレクトリを取得して修正する必要があります。発行者の構成が更新されるまで、発行は引き続き失敗します。

5. Issuance Protocol for Privately Verifiable Tokens

5. 個人的に検証可能なトークンの発行プロトコル

The privately verifiable issuance protocol allows Clients to produce token values that verify using the Issuer Private Key. This protocol is based on the OPRF [OPRF].

個人的に検証可能な発行プロトコルにより、クライアントは発行者の秘密鍵を使用して検証するトークン値を作成できます。このプロトコルは、OPRF [OPRF]に基づいています。

Issuers provide an Issuer Private Key and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol. See Section 5.5 for information about how these keys are generated.

発行者は、それぞれプロトコルへの入力としてトークンを生産するために使用されるスキーとPKIとそれぞれ示されている発行者の秘密鍵と公開キーを提供します。これらのキーの生成方法については、セクション5.5を参照してください。

Clients provide the following as input to the issuance protocol:

クライアントは、発行プロトコルへの入力として以下を提供します。

Issuer Request URL:

発行者リクエストURL：

A URL identifying the location to which issuance requests are sent. This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL. The value of this parameter depends on the Client configuration and deployment model. For example, in the "Joint Origin and Issuer" deployment model ([ARCHITECTURE], Section 4.3), the Issuer Request URL might correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer.

発行要求が送信される場所を識別するURL。これは、発行者のディレクトリリソースの「発行者レクエスト-URI」値から派生したURLであるか、別のクライアントが構成したURLにすることができます。このパラメーターの値は、クライアントの構成と展開モデルに依存します。たとえば、「共同起源と発行者」の展開モデル（[アーキテクチャ]、セクション4.3）では、発行者要求URLがクライアントの設定されたアテスターに対応する場合があり、アテスターはリクエストを発行者に中継するように構成されています。

Issuer name:

発行者名：

An identifier for the Issuer. This is typically a hostname that can be used to construct HTTP requests to the Issuer.

発行者の識別子。これは通常、発行者にHTTP要求を構築するために使用できるホスト名です。

Issuer Public Key:

発行者の公開キー：

pkI, with a key identifier token_key_id computed as described in Section 5.5.

PKI、セクション5.5で説明されているように、キー識別子token_key_idを計算します。

Challenge value:

チャレンジ値：

challenge -- an opaque byte string. For example, this might be provided by the redemption protocol described in [AUTHSCHEME].

チャレンジ - 不透明なバイト文字列。たとえば、これは[authscheme]に記載されているredいプロトコルによって提供される場合があります。

Given this configuration and these inputs, the two messages exchanged in this protocol are described below. This section uses notation described in [OPRF], Section 4, including SerializeElement and DeserializeElement, SerializeScalar and DeserializeScalar, and DeriveKeyPair.

この構成とこれらの入力を考えると、このプロトコルで交換される2つのメッセージを以下に説明します。このセクションでは、[OPRF]、セクション4に記載されている表記法を使用します。これには、SerializeElementおよびDeserializeElement、SerializeScalarとDeserializecalar、およびDeriveKeypairを含みます。

The constants Ne and Ns are as defined in Section 4.4 ("OPRF(P-384, SHA-384)") of [OPRF]. For this protocol, the constant Nk, which is also equal to Nh as defined in Section 4.4 of [OPRF], is defined by Section 8.2.1.

定数NEとNSは、[OPRF]のセクション4.4（ "OPRF（P-384、SHA-384））で定義されています。このプロトコルの場合、[OPRF]のセクション4.4で定義されているNHにも等しい定数NKは、セクション8.2.1で定義されています。

5.1. Client-to-Issuer Request

5.1. クライアントからイザーへのリクエスト

The Client first creates a context as follows:

クライアントは、最初に次のようにコンテキストを作成します。

   client_context = SetupVOPRFClient("P384-SHA384", pkI)

Here, "P384-SHA384" is the identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite defined in [OPRF]. SetupVOPRFClient is defined in [OPRF], Section 3.2.

ここで、「P384-SHA384」は、[OPRF]で定義されているOPRF（P-384、SHA-384）Ciphersuiteに対応する識別子です。setupvoprfclientは[oprf]、セクション3.2で定義されています。

The Client then creates an issuance request message for a random 32-byte nonce with the input challenge and Issuer key identifier as described below:

次に、クライアントは、以下に説明するように、入力チャレンジと発行者キー識別子を使用して、ランダムな32バイトのノンセの発行要求メッセージを作成します。

   nonce = random(32)
   challenge_digest = SHA256(challenge)
   token_input = concat(0x0001, // token-type field is 2 bytes long
                        nonce,
                        challenge_digest,
                        token_key_id)
   blind, blinded_element = client_context.Blind(token_input)

The Blind function is discussed in Sections 3.3.1 and 3.3.2 of [OPRF]. If the Blind function fails, the Client aborts the protocol. The Client stores the nonce and challenge_digest values locally for use when finalizing the issuance protocol to produce a token (as described in Section 5.3).

盲検機能については、[OPRF]のセクション3.3.1および3.3.2で説明します。ブラインド関数が失敗した場合、クライアントはプロトコルを中止します。クライアントは、発行プロトコルを完成させてトークンを生成するときに使用するためにローカルにNonCEおよびChallenge_Digest値を保存します（セクション5.3で説明します）。

The Client then creates a TokenRequest structured as follows:

次に、クライアントは次のように構造化されたtokenRequestを作成します。

   struct {
     uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */
     uint8_t truncated_token_key_id;
     uint8_t blinded_msg[Ne];
   } TokenRequest;

The structure fields are defined as follows:

構造フィールドは次のように定義されています。

* "token_type" is a 2-octet integer, which matches the type in the challenge.

* 「token_type」は2オクテットの整数であり、チャレンジのタイプに一致します。

* "truncated_token_key_id" is the least significant byte of the token_key_id (Section 5.5) in network byte order (in other words, the last 8 bits of token_key_id). This value is truncated so that Issuers cannot use token_key_id as a way of uniquely identifying Clients; see referenced information from Section 7 for more details.

* 「truncated_token_key_id」は、ネットワークバイトの順序でtoken_key_id（セクション5.5）の最も重要なバイトです（言い換えれば、token_key_idの最後の8ビット）。この値は、発行者がクライアントを一意に識別する方法としてtoken_key_idを使用できないように切り捨てられます。詳細については、セクション7の参照情報を参照してください。

* "blinded_msg" is the Ne-octet blinded message defined above, computed as SerializeElement(blinded_element).

* 「Blinded_msg」は、上記で定義されたNE-OCTETブラインドメッセージで、SerializeElement（blinded_element）として計算されています。

The values token_input and blinded_element are stored locally for use when finalizing the issuance protocol to produce a token (as described in Section 5.3). The Client then generates an HTTP POST request to send to the Issuer Request URL, with the TokenRequest as the content. The media type for this request is "application/ private-token-request". An example request for the Issuer Request URL "https://issuer.example.net/request" is shown below.

値token_inputとblinded_elementは、発行プロトコルを完成させてトークンを生成するときに使用するためにローカルに保存されます（セクション5.3で説明されています）。次に、クライアントは、TokenRequestをコンテンツとして、発行者リクエストURLに送信するHTTP POSTリクエストを生成します。このリクエストのメディアタイプは「アプリケーション/プライベートトークンレクエスト」です。発行者要求のリクエストの例「https://issuer.example.net/request」を以下に示します。

   POST /request HTTP/1.1
   Host: issuer.example.net
   Accept: application/private-token-response
   Content-Type: application/private-token-request
   Content-Length: <Length of TokenRequest>

   <Bytes containing the TokenRequest>

5.2. Issuer-to-Client Response

5.2. 発行者からクライアントへの応答

Upon receipt of the request, the Issuer validates the following conditions:

リクエストを受け取ると、発行者は次の条件を検証します。

* The TokenRequest contains a supported token_type.

* TokenRequestには、サポートされているtoken_typeが含まれています。

* The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of a public key owned by the Issuer.

* tokenRequest.truncated_token_key_idは、発行者が所有する公開鍵の切り捨てられたキーIDに対応しています。

* The TokenRequest.blinded_msg is of the correct size.

* tokenRequest.blinde_msgは正しいサイズです。

If any of these conditions are not met, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the Client.

これらの条件のいずれかが満たされていない場合、発行者はクライアントにHTTP 422（処理不可能なコンテンツ）エラーを返品する必要があります。

If these conditions are met, the Issuer then tries to deserialize TokenRequest.blinded_msg using DeserializeElement ([OPRF], Section 2.1), yielding blinded_element. If this fails, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the Client. Otherwise, if the Issuer is willing to produce a token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows:

これらの条件が満たされている場合、発行者はDeserializeElement（[OPRF]、セクション2.1）を使用してTokenRequest.blinde_msgの脱色を試み、blinded_elementを生成します。これが失敗した場合、発行者はクライアントにHTTP 422（処理できないコンテンツ）エラーを返品する必要があります。それ以外の場合、発行者がクライアントにトークンを生成することをいとわない場合、発行者は次のように盲検化された応答を計算することにより発行フローを完了します。

   server_context = SetupVOPRFServer("P384-SHA384", skI)
   evaluate_element, proof =
     server_context.BlindEvaluate(skI, pkI, blinded_element)

SetupVOPRFServer is defined in [OPRF], Section 3.2, and BlindEvaluate is defined in [OPRF], Section 3.3.2. The Issuer then creates a TokenResponse structured as follows:

SetupVoprfServerは[OPRF]、セクション3.2で定義されており、Vellinevaluateは[OPRF]、セクション3.3.2で定義されています。次に、発行者は次のように構成されたtokenResponseを作成します。

   struct {
      uint8_t evaluate_msg[Ne];
      uint8_t evaluate_proof[Ns+Ns];
   } TokenResponse;

The structure fields are defined as follows:

構造フィールドは次のように定義されています。

* "evaluate_msg" is the Ne-octet evaluated message, computed as SerializeElement(evaluate_element).

* 「evaluate_msg」は、serializeelement（evaluate_element）として計算されたNE-OCTET評価メッセージです。

* "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as concat(SerializeScalar(proof[0]), SerializeScalar(proof[1])).

* 「evaluate_proof」は（ns+ns）-octetシリアル化された証明であり、concat（serializescalar（proof [0]）、serializescalar（form [1]））として計算されたスカラー値のペアです。

The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response".

発行者は、コンテンツがtokenResponseで構成されるステータスコード200でHTTP応答を生成し、コンテンツタイプは「アプリケーション/プライベートトークン応答」として設定されています。

   HTTP/1.1 200 OK
   Content-Type: application/private-token-response
   Content-Length: <Length of TokenResponse>

   <Bytes containing the TokenResponse>

5.3. Finalization

5.3. ファイナライゼーション

Upon receipt, the Client handles the response and, if successful, deserializes the content values TokenResponse.evaluate_msg and TokenResponse.evaluate_proof, yielding evaluated_element and proof. If deserialization of either value fails, the Client aborts the protocol. Otherwise, the Client processes the response as follows:

受領すると、クライアントは応答を処理し、成功した場合、コンテンツ値tokenResponse.evaluate_msgおよびtokenResponse.evaluate_proofを脱必要にし、evaluated_elementと証明を生成します。いずれかの値の降下が失敗した場合、クライアントはプロトコルを中止します。それ以外の場合、クライアントは次のように応答を処理します。

   authenticator = client_context.Finalize(token_input, blind,
                                           evaluated_element,
                                           blinded_element,
                                           proof)

The Finalize function is defined in [OPRF], Section 3.3.2. If this succeeds, the Client then constructs a token as follows:

ファイナライズ関数は、[OPRF]、セクション3.3.2で定義されています。これが成功した場合、クライアントは次のようにトークンを構築します。

   struct {
     uint16_t token_type = 0x0001; /* Type VOPRF(P-384, SHA-384) */
     uint8_t nonce[32];
     uint8_t challenge_digest[32];
     uint8_t token_key_id[32];
     uint8_t authenticator[Nk];
   } Token;

The Token.nonce value is the value that was created according to Section 5.4. If the Finalize function fails, the Client aborts the protocol.

token.nonce値は、セクション5.4に従って作成された値です。ファイナライズ関数が失敗した場合、クライアントはプロトコルを中止します。

5.4. Token Verification

5.4. トークン検証

Verifying a token requires creating a Verifiable Oblivious Pseudorandom Function (VOPRF) context using the Issuer Private Key and Public Key, evaluating the token contents, and comparing the result against the token authenticator value:

トークンを検証するには、発行者の秘密鍵と公開キーを使用して、検証可能な忘却の擬似ランダム関数（VOPRF）コンテキストを作成し、トークンの内容を評価し、結果をトークン認証因子値と比較する必要があります。

   server_context = SetupVOPRFServer("P384-SHA384", skI)
   token_authenticator_input =
     concat(Token.token_type,
            Token.nonce,
            Token.challenge_digest,
            Token.token_key_id)
   token_authenticator =
     server_context.Evaluate(token_authenticator_input)
   valid = (token_authenticator == Token.authenticator)

5.5. Issuer Configuration

5.5. 発行者構成

Issuers are configured with Issuer Private Keys and Public Keys, each denoted skI and pkI, respectively, used to produce tokens. These keys MUST NOT be reused in other protocols. A RECOMMENDED method for generating keys is as follows:

発行者は、それぞれトークンの生産に使用される発行者のプライベートキーとパブリックキーで構成されています。これらのキーは、他のプロトコルで再利用してはなりません。キーを生成するための推奨される方法は次のとおりです。

   seed = random(Ns)
   (skI, pkI) = DeriveKeyPair(seed, "PrivacyPass")

The DeriveKeyPair function is defined in [OPRF], Section 3.2.1. The key identifier for a public key pkI, denoted token_key_id, is computed as follows:

deriveKeypair関数は、[OPRF]、セクション3.2.1で定義されています。token_key_idと表現される公開キーPKIのキー識別子は、次のように計算されます。

   token_key_id = SHA256(SerializeElement(pkI))

Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD ensure that the truncated forms of new key IDs do not collide with other truncated key IDs in rotation. Collisions can cause the Issuer to use the wrong Issuer Private Key for issuance, which will in turn cause the resulting tokens to be invalid. There is no known security consequence of using the wrong Issuer Private Key. A possible exception to this constraint would be a colliding key that is still in use but is in the process of being rotated out, in which case the collision cannot reasonably be avoided; however, this situation is expected to be transient.

クライアントは各tokenRequestでtoken_key_keを切り捨てているため、発行者は、新しいキーIDの切り捨てられた形式が、回転中の他の切り捨てられたキーIDと衝突しないようにする必要があります。衝突により、発行者が発行に誤った発行者の秘密鍵を使用すると、結果のトークンが無効になります。間違った発行者の秘密鍵を使用することのセキュリティの結果は既知のものではありません。この制約の可能性のある例外は、まだ使用されているが、回転する過程にある衝突キーです。その場合、衝突は合理的に回避できません。ただし、この状況は一時的なものになると予想されます。

6. Issuance Protocol for Publicly Verifiable Tokens

6. 公開されているトークンの発行プロトコル

This section describes a variant of the issuance protocol discussed in Section 5 for producing publicly verifiable tokens using the protocol defined in [BLINDRSA]. In particular, this variant of the issuance protocol works for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic blind RSA protocol variants described in Section 5 of [BLINDRSA].

このセクションでは、[lindrsa]で定義されたプロトコルを使用して、公開されているトークンを生成するためにセクション5で説明した発行プロトコルのバリアントについて説明します。特に、発行プロトコルのこのバリアントは、RSABSSA-SHA384-PSS-DETERMINISTICとRSABSSA-SHA384-PSSZERO-DETERMINIST BLINK RSAプロトコルバリエーションで[BlindRSA]のセクション5で説明されています。

The publicly verifiable issuance protocol differs from the protocol defined in Section 5 in that the output tokens are publicly verifiable by anyone with the Issuer Public Key. This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer Public Key, without explicit coordination or permission from the Issuer. This is because the Issuer does not learn the Origin that requested the token during the issuance protocol.

公開可能な発行プロトコルは、発行者の公開キーを持つ人が公開されているという点で、セクション5で定義されているプロトコルとは異なります。これは、発行者の明示的な調整や許可なしに発行者の公開キーを持っている限り、すべてのオリジンが特定の発行者を選択してトークンを生成できることを意味します。これは、発行者が発行プロトコル中にトークンを要求した起源を学習しないためです。

Beyond this difference, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance protocol variant. In particular, Issuers provide an Issuer Private Key and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol. See Section 6.5 for information about how these keys are generated.

この違いを超えて、公開可能な発行プロトコルバリアントは、個人的に検証可能な発行プロトコルバリアントとほぼ同じです。特に、発行者は、それぞれプロトコルへの入力としてトークンを生成するために使用されるスキーとPKIとそれぞれ発行者の秘密鍵と公開キーを提供します。これらのキーの生成方法については、セクション6.5を参照してください。

Clients provide the following as input to the issuance protocol:

クライアントは、発行プロトコルへの入力として以下を提供します。

Issuer Request URL:

発行者リクエストURL：

A URL identifying the location to which issuance requests are sent. This can be a URL derived from the "issuer-request-uri" value in the Issuer's directory resource, or it can be another Client-configured URL. The value of this parameter depends on the Client configuration and deployment model. For example, in the "Split Origin, Attester, Issuer" deployment model ([ARCHITECTURE], Section 4.4), the Issuer Request URL might correspond to the Client's configured Attester, and the Attester is configured to relay requests to the Issuer.

発行要求が送信される場所を識別するURL。これは、発行者のディレクトリリソースの「発行者レクエスト-URI」値から派生したURLであるか、別のクライアントが構成したURLにすることができます。このパラメーターの値は、クライアントの構成と展開モデルに依存します。たとえば、「Split Origin、Attester、Issuer」展開モデル（[アーキテクチャ]、セクション4.4）では、発行者要求URLがクライアントの設定されたAttesterに対応する場合があり、Attesterは発行者にリクエストを中継するように構成されています。

Issuer name:

発行者名：

An identifier for the Issuer. This is typically a hostname that can be used to construct HTTP requests to the Issuer.

発行者の識別子。これは通常、発行者にHTTP要求を構築するために使用できるホスト名です。

Issuer Public Key:

発行者の公開キー：

pkI, with a key identifier token_key_id computed as described in Section 6.5.

PKI、セクション6.5で説明されているように、キー識別子token_key_idを計算します。

Challenge value:

チャレンジ値：

challenge -- an opaque byte string. For example, this might be provided by the redemption protocol described in [AUTHSCHEME].

チャレンジ - 不透明なバイト文字列。たとえば、これは[authscheme]に記載されているredいプロトコルによって提供される場合があります。

Given this configuration and these inputs, the two messages exchanged in this protocol are described below. For this protocol, the constant Nk is defined by Section 8.2.2.

この構成とこれらの入力を考えると、このプロトコルで交換される2つのメッセージを以下に説明します。このプロトコルでは、定数NKはセクション8.2.2で定義されます。

6.1. Client-to-Issuer Request

6.1. クライアントからイザーへのリクエスト

The Client first creates an issuance request message for a random 32-byte nonce using the input challenge and Issuer key identifier as follows:

クライアントは、最初に、入力チャレンジと発行者キー識別子を使用して、ランダムな32バイトのノンセの発行要求メッセージを作成します。

   nonce = random(32)
   challenge_digest = SHA256(challenge)
   token_input = concat(0x0002, // token-type field is 2 bytes long
                        nonce,
                        challenge_digest,
                        token_key_id)
   blinded_msg, blind_inv =
     Blind(pkI, PrepareIdentity(token_input))

The PrepareIdentity and Blind functions are defined in Sections 4.1 and 4.2 of [BLINDRSA], respectively. The Client stores the nonce and challenge_digest values locally for use when finalizing the issuance protocol to produce a token (as described in Section 6.3).

準備および盲目の機能は、それぞれ[lindrsa]のセクション4.1と4.2で定義されています。クライアントは、発行プロトコルを完成させてトークンを生成するときに使用するためにローカルにNonCEおよびChallenge_Digest値を保存します（セクション6.3で説明されています）。

The Client then creates a TokenRequest structured as follows:

次に、クライアントは次のように構造化されたtokenRequestを作成します。

   struct {
     uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */
     uint8_t truncated_token_key_id;
     uint8_t blinded_msg[Nk];
   } TokenRequest;

The structure fields are defined as follows:

構造フィールドは次のように定義されています。

* "token_type" is a 2-octet integer, which matches the type in the challenge.

* 「token_type」は2オクテットの整数であり、チャレンジのタイプに一致します。

* "truncated_token_key_id" is the least significant byte of the token_key_id (Section 6.5) in network byte order (in other words, the last 8 bits of token_key_id). This value is truncated so that Issuers cannot use token_key_id as a way of uniquely identifying Clients; see referenced information from Section 7 for more details.

* 「truncated_token_key_id」は、ネットワークバイトの順序でtoken_key_id（セクション6.5）の最も重要なバイトです（言い換えれば、token_key_idの最後の8ビット）。この値は、発行者がクライアントを一意に識別する方法としてtoken_key_idを使用できないように切り捨てられます。詳細については、セクション7の参照情報を参照してください。

* "blinded_msg" is the Nk-octet request defined above.

* 「Blinded_msg」は、上記で定義されたNK-OCTETリクエストです。

The Client then generates an HTTP POST request to send to the Issuer Request URL, with the TokenRequest as the content. The media type for this request is "application/private-token-request". An example request for the Issuer Request URL "https://issuer.example.net/ request" is shown below.

次に、クライアントは、TokenRequestをコンテンツとして、発行者リクエストURLに送信するHTTP POSTリクエストを生成します。このリクエストのメディアタイプは「アプリケーション/プライベートトークンレクエスト」です。発行者要求のリクエストの例「https://issuer.example.net/リクエスト」を以下に示します。

   POST /request HTTP/1.1
   Host: issuer.example.net
   Accept: application/private-token-response
   Content-Type: application/private-token-request
   Content-Length: <Length of TokenRequest>

   <Bytes containing the TokenRequest>

6.2. Issuer-to-Client Response

6.2. 発行者からクライアントへの応答

Upon receipt of the request, the Issuer validates the following conditions:

リクエストを受け取ると、発行者は次の条件を検証します。

* The TokenRequest contains a supported token_type.

* TokenRequestには、サポートされているtoken_typeが含まれています。

* The TokenRequest.truncated_token_key_id corresponds to the truncated key ID of an Issuer Public Key.

* tokenRequest.truncated_token_key_idは、発行者の公開キーの切り捨てられたキーIDに対応しています。

* The TokenRequest.blinded_msg is of the correct size.

* tokenRequest.blinde_msgは正しいサイズです。

If any of these conditions are not met, the Issuer MUST return an HTTP 422 (Unprocessable Content) error to the Client. Otherwise, if the Issuer is willing to produce a token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows:

これらの条件のいずれかが満たされていない場合、発行者はクライアントにHTTP 422（処理不可能なコンテンツ）エラーを返品する必要があります。それ以外の場合、発行者がクライアントにトークンを生成することをいとわない場合、発行者は次のように盲検化された応答を計算することにより発行フローを完了します。

   blind_sig = BlindSign(skI, TokenRequest.blinded_msg)

The BlindSign function is defined in Section 4.3 of [BLINDRSA]. The result is encoded and transmitted to the Client in the following TokenResponse structure:

ブラインドサイド関数は、[lindrsa]のセクション4.3で定義されています。結果は、次のtokenResponse構造でエンコードされ、クライアントに送信されます。

   struct {
     uint8_t blind_sig[Nk];
   } TokenResponse;

The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response".

   HTTP/1.1 200 OK
   Content-Type: application/private-token-response
   Content-Length: <Length of TokenResponse>

   <Bytes containing the TokenResponse>

6.3. Finalization

6.3. ファイナライゼーション

Upon receipt, the Client handles the response and, if successful, processes the content as follows:

受領すると、クライアントは応答を処理し、成功した場合、次のようにコンテンツを処理します。

   authenticator =
     Finalize(pkI, PrepareIdentity(token_input), blind_sig, blind_inv)

The Finalize function is defined in Section 4.4 of [BLINDRSA]. If this succeeds, the Client then constructs a token as described in [AUTHSCHEME] as follows:

ファイナライズ関数は、[lindrsa]のセクション4.4で定義されています。これが成功した場合、クライアントは次のように[authscheme]に記載されているようにトークンを構築します。

   struct {
     uint16_t token_type = 0x0002; /* Type Blind RSA (2048-bit) */
     uint8_t nonce[32];
     uint8_t challenge_digest[32];
     uint8_t token_key_id[32];
     uint8_t authenticator[Nk];
   } Token;

The Token.nonce value is the value that was sampled according to Section 6.1. If the Finalize function fails, the Client aborts the protocol.

token.nonce値は、セクション6.1に従ってサンプリングされた値です。ファイナライズ関数が失敗した場合、クライアントはプロトコルを中止します。

6.4. Token Verification

6.4. トークン検証

Verifying a token requires checking that Token.authenticator is a valid signature over the remainder of the token input using the Issuer Public Key. The function RSASSA-PSS-VERIFY is defined in Section 8.1.2 of [RFC8017], using SHA-384 as the hash function, MGF1 with SHA-384 as the Probabilistic Signature Scheme (PSS) mask generation function (MGF), and a 48-byte salt length (sLen).

トークンを確認するには、token.authenticatorが発行者の公開キーを使用してトークン入力の残りの署名であることを確認する必要があります。関数rsassa-PSS-verifyは、[RFC8017]のセクション8.1.2で定義されており、SHA-384をハッシュ関数として、MGF1を使用してSHA-384を確率的署名スキーム（PSS）マスク生成関数（MGF）、およびA48バイトの塩の長さ（スレン）。

   token_authenticator_input =
     concat(Token.token_type,
            Token.nonce,
            Token.challenge_digest,
            Token.token_key_id)
   valid = RSASSA-PSS-VERIFY(pkI,
                             token_authenticator_input,
                             Token.authenticator)

6.5. Issuer Configuration

6.5. 発行者構成

Issuers are configured with Issuer Private Keys and Public Keys, each denoted skI and pkI, respectively, used to produce tokens. Each key SHALL be generated securely -- for example, as specified in FIPS 186-5 [DSS]. These keys MUST NOT be reused in other protocols.

発行者は、それぞれトークンの生産に使用される発行者のプライベートキーとパブリックキーで構成されています。各キーは、たとえば、FIPS 186-5 [DSS]で指定されているように、安全に生成されます。これらのキーは、他のプロトコルで再利用してはなりません。

The key identifier for an Issuer Private Key and Public Key (skI, pkI), denoted token_key_id, is computed as SHA256(encoded_key), where encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object [RFC5280] carrying pkI as a DER-encoded RSAPublicKey value [RFC5756] in the subjectPublicKey field. Additionally, (1) the SPKI object MUST use the id-RSASSA-PSS object identifier in the algorithm field within the SPKI object and (2) the parameters field MUST contain an RSASSA-PSS-params value and MUST include the hashAlgorithm, maskGenAlgorithm, and saltLength values. The saltLength MUST match the output size of the hash function associated with the public key and token type.

発行者の秘密鍵と公開キー（Ski、PKI）のキー識別子は、token_key_idと表され、sha256（encoded_key）として計算されます。subjectpublickeyフィールドのrsapublickey値[RFC5756]。さらに、（1）SPKIオブジェクトは、SPKIオブジェクト内のアルゴリズムフィールドにID-RSassa-PSSオブジェクト識別子を使用する必要があり、（2）パラメーターフィールドには、rsassa-PSS-Params値を含む必要があり、ハサルゴリズム、Maskgenalgorithmを含める必要があります。およびsaltlength値。SaltLengthは、公開キーとトークンタイプに関連付けられたハッシュ関数の出力サイズと一致する必要があります。

An example sequence of the SPKI object (in ASN.1 format, with the actual public key bytes truncated) for a 2048-bit key is shown below:

2048ビットキーのSPKIオブジェクトの例（ASN.1形式、実際の公開キーバイトが切り捨てられた）を以下に示します。

   $ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER
       0:d=0  hl=4 l= 338 cons: SEQUENCE
       4:d=1  hl=2 l=  61 cons: SEQUENCE
       6:d=2  hl=2 l=   9 prim: OBJECT            :rsassaPss
      17:d=2  hl=2 l=  48 cons: SEQUENCE
      19:d=3  hl=2 l=  13 cons: cont [ 0 ]
      21:d=4  hl=2 l=  11 cons: SEQUENCE
      23:d=5  hl=2 l=   9 prim: OBJECT            :sha384
      34:d=3  hl=2 l=  26 cons: cont [ 1 ]
      36:d=4  hl=2 l=  24 cons: SEQUENCE
      38:d=5  hl=2 l=   9 prim: OBJECT            :mgf1
      49:d=5  hl=2 l=  11 cons: SEQUENCE
      51:d=6  hl=2 l=   9 prim: OBJECT            :sha384
      62:d=3  hl=2 l=   3 cons: cont [ 2 ]
      64:d=4  hl=2 l=   1 prim: INTEGER           :30
      67:d=1  hl=4 l= 271 prim: BIT STRING
      ... truncated public key bytes ...

7. Security Considerations

7. セキュリティに関する考慮事項

This document outlines how to instantiate the issuance protocol based on the VOPRF defined in [OPRF] and the blind RSA protocol defined in [BLINDRSA]. All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are covered in the architecture document [ARCHITECTURE]. In particular, Sections 4 and 5 of [ARCHITECTURE] discuss relevant privacy considerations influenced by the Privacy Pass deployment models, and Section 6 of [ARCHITECTURE] discusses privacy considerations that apply regardless of deployment model. Notable considerations include those pertaining to Issuer Public Key rotation and consistency -- where consistency is as described in [CONSISTENCY] -- and Issuer selection.

このドキュメントでは、[OPRF]で定義されているVOPRFおよび[BlindRSA]で定義されているブラインドRSAプロトコルに基づいて発行プロトコルをインスタンス化する方法を概説しています。VOPRFおよびブラインドRSAドキュメントで説明されているすべてのセキュリティ上の考慮事項は、プライバシーパスユースケースにも適用されます。マルチクライアントおよびマルチイザーの設定におけるより広範なプライバシーとセキュリティの懸念に関連する考慮事項については、アーキテクチャドキュメント[アーキテクチャ]で説明しています。特に、[アーキテクチャ]のセクション4と5は、プライバシーパス展開モデルの影響を受けた関連するプライバシーに関する考慮事項について説明し、[アーキテクチャ]のセクション6では、展開モデルに関係なく適用されるプライバシーに関する考慮事項について説明します。注目すべき考慮事項には、発行者の公開キーのローテーションと一貫性（一貫性が[一貫性]に記載されているとおり）と発行者の選択に関連するものが含まれます。

8. IANA Considerations

8. IANAの考慮事項

8.1. Well-Known "private-token-issuer-directory" URI

8.1. 有名な「Private-Token-Issuer-Directory」URI

IANA has updated the "Well-Known URIs" registry [WellKnownURIs] with the following values.

IANAは、「よく知られているURIS」レジストリ[よく知られている]レジストリを次の値で更新しました。

   +===============+============+===========+===========+=============+
   | URI Suffix    | Change     | Reference | Status    | Related     |
   |               | Controller |           |           | Information |
   +===============+============+===========+===========+=============+
   | private-      | IETF       | RFC 9578  | permanent | None        |
   | token-issuer- |            |           |           |             |
   | directory     |            |           |           |             |
   +---------------+------------+-----------+-----------+-------------+

Table 3: "private-token-issuer-directory" Well-Known URI

表3：「Private-Token-Issuer-Directory」有名URI

8.2. Privacy Pass Token Types

8.2. プライバシーパストークンタイプ

IANA has updated the "Privacy Pass Token Types" registry [PrivPassTokenTypes] with the entries below.

IANAは、「プライバシーパストークンタイプ」レジストリ[privpasStokentypes]を以下のエントリで更新しました。

8.2.1. Token Type VOPRF(P-384, SHA-384)

8.2.1. トークンタイプVOPRF（P-384、SHA-384）

Value:

値：

0x0001

Name:

名前：

VOPRF(P-384, SHA-384)

VOPRF（P-384、SHA-384）

Token Structure:

トークン構造：

As defined in Section 2.2 of [AUTHSCHEME].

[authscheme]のセクション2.2で定義されているとおり。

Token Key Encoding:

トークンキーエンコーディング：

Serialized using SerializeElement (Section 2.1 of [OPRF]).

SerializeElementを使用してシリアル化（[OPRF]のセクション2.1）。

TokenChallenge Structure:

TokenChallenge構造：

As defined in Section 2.1 of [AUTHSCHEME].

[authscheme]のセクション2.1で定義されているとおり。

Publicly Verifiable:

一般に検証可能：

Public Metadata:

パブリックメタデータ：

Private Metadata:

プライベートメタデータ：

Nk:

Nid:

Change controller:

Change Controller：

IETF

Reference:

参照：

RFC 9578, Section 5

RFC 9578、セクション5

Notes:

ノート：

None

なし

8.2.2. Token Type Blind RSA (2048-bit)

8.2.2. トークンタイプブラインドRSA（2048ビット）

Value:

値：

0x0002

Name:

名前：

Blind RSA (2048-bit)

ブラインドRSA（2048ビット）

Token Structure:

トークン構造：

As defined in Section 2.2 of [AUTHSCHEME].

[authscheme]のセクション2.2で定義されているとおり。

Token Key Encoding:

トークンキーエンコーディング：

Serialized as a DER-encoded SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID [RFC5756].

rsassa-pss oid [rfc5756]を使用して、derエンコードされた件名publickeyinfo（spki）オブジェクトとしてシリアル化されました。

TokenChallenge Structure:

TokenChallenge構造：

As defined in Section 2.1 of [AUTHSCHEME].

[authscheme]のセクション2.1で定義されているとおり。

Publicly Verifiable:

一般に検証可能：

Public Metadata:

パブリックメタデータ：

Private Metadata:

プライベートメタデータ：

Nk:

256

Nid:

Change controller:

Change Controller：

IETF

Reference:

参照：

RFC 9578, Section 6

RFC 9578、セクション6

Notes:

ノート：

The RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384- PSSZERO-Deterministic variants are supported.

RSABSSA-SHA384-PSS-DETERMINISTICおよびRSABSSA-SHA384-PSSZERO-DETERMINISTISISTバリアントがサポートされています。

8.3. Media Types

8.3. メディアタイプ

IANA has added the following entries to the "Media Types" registry [MediaTypes]:

IANAは、「メディアタイプ」レジストリ[メディアタイプ]に次のエントリを追加しました。

* "application/private-token-issuer-directory"

* 「アプリケーション/プライベートトークン - イッサーディレクトリ」

* "application/private-token-request"

* 「アプリケーション/プライベートトークンレクエスト」

* "application/private-token-response"

* 「アプリケーション/プライベートトークン応答」

The templates for these entries are listed below. The reference is this RFC.

これらのエントリのテンプレートを以下に示します。参照はこのRFCです。

8.3.1. "application/private-token-issuer-directory" Media Type

8.3.1. 「アプリケーション/プライベートトークン-Issuer-Directory」メディアタイプ

Type name:

タイプ名：

application

応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務

Subtype name:

サブタイプ名：

private-token-issuer-directory

Private-Token-Issuer-Directory

Required parameters:

必要なパラメーター：

N/A

n/a

Optional parameters:

オプションのパラメーター：

N/A

n/a

Encoding considerations:

考慮事項のエンコード：

binary

バイナリバイナリー二進

Security considerations:

セキュリティ上の考慮事項：

See Section 7 of RFC 9578.

RFC 9578のセクション7を参照してください。

Interoperability considerations:

相互運用性の考慮事項：

N/A

n/a

Published specification:

公開された仕様：

RFC 9578

Applications that use this media type:

このメディアタイプを使用するアプリケーション：

Services that implement the Privacy Pass Issuer role, and Client applications that interact with the Issuer for the purposes of issuing or redeeming tokens.

プライバシーパス発行者の役割を実装するサービス、およびトークンの発行または償還の目的で発行者と対話するクライアントアプリケーション。

Fragment identifier considerations:

フラグメント識別子の考慮事項：

N/A

n/a

Additional information:

追加情報：

Deprecated alias names for this type:

このタイプの非推奨エイリアス名：

N/A

n/a

Magic number(s):

マジックナンバー：

N/A

n/a

File extension(s):

ファイル拡張子：

N/A

n/a

Macintosh file type code(s):

Macintoshファイルタイプコード：

N/A

n/a

Person & email address to contact for further information:

詳細については、連絡先への個人およびメールアドレス：

See the Authors' Addresses section of RFC 9578.

RFC 9578の著者のアドレスセクションを参照してください。

Intended usage:

意図された使用法：

COMMON

一般

Restrictions on usage:

使用に関する制限：

N/A

n/a

Author:

著者：

See the Authors' Addresses section of RFC 9578.

RFC 9578の著者のアドレスセクションを参照してください。

Change controller:

Change Controller：

IETF

8.3.2. "application/private-token-request" Media Type

8.3.2. 「アプリケーション/プライベートトークンリケスト」メディアタイプ

Type name:

タイプ名：

application

応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務

Subtype name:

サブタイプ名：

private-token-request

プライベートトークンリケスト

Required parameters:

必要なパラメーター：

N/A

n/a

Optional parameters:

オプションのパラメーター：

N/A

n/a

Encoding considerations:

考慮事項のエンコード：

binary

バイナリバイナリー二進

Security considerations:

セキュリティ上の考慮事項：

See Section 7 of RFC 9578.

RFC 9578のセクション7を参照してください。

Interoperability considerations:

相互運用性の考慮事項：

N/A

n/a

Published specification:

公開された仕様：

RFC 9578

Applications that use this media type:

このメディアタイプを使用するアプリケーション：

Applications that want to issue or facilitate issuance of Privacy Pass tokens, including Privacy Pass Issuer applications themselves.

プライバシーパス発行者アプリケーション自体を含む、プライバシーのパストークンを発行または促進したいアプリケーション。

Fragment identifier considerations:

フラグメント識別子の考慮事項：

N/A

n/a

Additional information:

追加情報：

Deprecated alias names for this type:

このタイプの非推奨エイリアス名：

N/A

n/a

Magic number(s):

マジックナンバー：

N/A

n/a

File extension(s):

ファイル拡張子：

N/A

n/a

Macintosh file type code(s):

Macintoshファイルタイプコード：

N/A

n/a

Person & email address to contact for further information:

詳細については、連絡先への個人およびメールアドレス：

See the Authors' Addresses section of RFC 9578.

RFC 9578の著者のアドレスセクションを参照してください。

Intended usage:

意図された使用法：

COMMON

一般

Restrictions on usage:

使用に関する制限：

N/A

n/a

Author:

著者：

See the Authors' Addresses section of RFC 9578.

RFC 9578の著者のアドレスセクションを参照してください。

Change controller:

Change Controller：

IETF

8.3.3. "application/private-token-response" Media Type

8.3.3. 「アプリケーション/プライベートトークン応答」メディアタイプ

Type name:

タイプ名：

application

応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務

Subtype name:

サブタイプ名：

private-token-response

プライベートトークン応答

Required parameters:

必要なパラメーター：

N/A

n/a

Optional parameters:

オプションのパラメーター：

N/A

n/a

Encoding considerations:

考慮事項のエンコード：

binary

バイナリバイナリー二進

Security considerations:

セキュリティ上の考慮事項：

See Section 7 of RFC 9578.

RFC 9578のセクション7を参照してください。

Interoperability considerations:

相互運用性の考慮事項：

N/A

n/a

Published specification:

公開された仕様：

RFC 9578

Applications that use this media type:

このメディアタイプを使用するアプリケーション：

Applications that want to issue or facilitate issuance of Privacy Pass tokens, including Privacy Pass Issuer applications themselves.

プライバシーパス発行者アプリケーション自体を含む、プライバシーのパストークンを発行または促進したいアプリケーション。

Fragment identifier considerations:

フラグメント識別子の考慮事項：

N/A

n/a

Additional information:

追加情報：

Deprecated alias names for this type:

このタイプの非推奨エイリアス名：

N/A

n/a

Magic number(s):

マジックナンバー：

N/A

n/a

File extension(s):

ファイル拡張子：

N/A

n/a

Macintosh file type code(s):

Macintoshファイルタイプコード：

N/A

n/a

Person & email address to contact for further information:

詳細については、連絡先への個人およびメールアドレス：

See the Authors' Addresses section of RFC 9578.

RFC 9578の著者のアドレスセクションを参照してください。

Intended usage:

意図された使用法：

COMMON

一般

Restrictions on usage:

使用に関する制限：

N/A

n/a

Author:

著者：

See the Authors' Addresses section of RFC 9578.

RFC 9578の著者のアドレスセクションを参照してください。

Change controller:

Change Controller：

IETF

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

   [ARCHITECTURE]
              Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
              Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
              2024, <https://www.rfc-editor.org/info/rfc9576>.

   [AUTHSCHEME]
              Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
              HTTP Authentication Scheme", RFC 9577,
              DOI 10.17487/RFC9577, June 2024,
              <https://www.rfc-editor.org/info/rfc9577>.

   [BLINDRSA] Denis, F., Jacobs, F., and C. A. Wood, "RSA Blind
              Signatures", RFC 9474, DOI 10.17487/RFC9474, October 2023,
              <https://www.rfc-editor.org/info/rfc9474>.

   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [MediaTypes]
              IANA, "Media Types",
              <https://www.iana.org/assignments/media-types/>.

   [OPRF]     Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
              Wood, "Oblivious Pseudorandom Functions (OPRFs) Using
              Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,
              December 2023, <https://www.rfc-editor.org/info/rfc9497>.

   [PrivPassTokenTypes]
              IANA, "Privacy Pass Token Types",
              <https://www.iana.org/assignments/privacy-pass/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5756]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Updates for RSAES-OAEP and RSASSA-PSS Algorithm
              Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010,
              <https://www.rfc-editor.org/info/rfc5756>.

   [RFC5861]  Nottingham, M., "HTTP Cache-Control Extensions for Stale
              Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
              <https://www.rfc-editor.org/info/rfc5861>.

   [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>.

   [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>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC9111]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Caching", STD 98, RFC 9111,
              DOI 10.17487/RFC9111, June 2022,
              <https://www.rfc-editor.org/info/rfc9111>.

   [TIMESTAMP]
              Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
              Defining Packet Timestamps", RFC 8877,
              DOI 10.17487/RFC8877, September 2020,
              <https://www.rfc-editor.org/info/rfc8877>.

   [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [WellKnownURIs]
              IANA, "Well-Known URIs",
              <https://www.iana.org/assignments/well-known-uris/>.

9.2. Informative References

9.2. 参考引用

   [CONSISTENCY]
              Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
              "Key Consistency and Discovery", Work in Progress,
              Internet-Draft, draft-ietf-privacypass-key-consistency-01,
              10 July 2023, <https://datatracker.ietf.org/doc/html/
              draft-ietf-privacypass-key-consistency-01>.

   [DSS]      National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", NIST FIPS Publication 186-5,
              DOI 10.6028/NIST.FIPS.186-5, February 2023,
              <https://doi.org/10.6028/nist.fips.186-5>.

   [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>.

Appendix A. Test Vectors

付録A. テストベクトル

This section includes test vectors for the two basic issuance protocols specified in this document. Appendix A.1 contains test vectors for token issuance protocol 1 (0x0001), and Appendix A.2 contains test vectors for token issuance protocol 2 (0x0002).

このセクションには、このドキュメントで指定された2つの基本的な発行プロトコルのテストベクトルが含まれています。付録A.1には、トークン発行プロトコル1（0x0001）のテストベクトルが含まれており、付録A.2にはトークン発行プロトコル2（0x0002）のテストベクトルが含まれています。

A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384)

A.1. 発行プロトコル1-VOPRF（P-384、SHA-384）

The test vectors below list the following values:

以下のテストベクトルには、次の値がリストされています。

skI:

The Issuer Private Key, serialized using SerializeScalar ([OPRF], Section 2.1) and represented as a hexadecimal string.

SerializeScalar（[OPRF]、セクション2.1）を使用してシリアル化された発行者の秘密鍵、および16進文字列として表されます。

pkI:

The Issuer Public Key, serialized according to the encoding in Section 8.2.1.

セクション8.2.1のエンコーディングに従ってシリアル化された発行者の公開キー。

token_challenge:

token_challenge：

A randomly generated TokenChallenge structure, represented as a hexadecimal string.

16進列の文字列として表されるランダムに生成されたトークンチャレンジ構造。

nonce:

ノンセ：

The 32-byte Client nonce generated according to Section 5.1, represented as a hexadecimal string.

セクション5.1に従って生成された32バイトのクライアントnonceは、16進文字列として表されます。

blind:

盲目：

The blind used when computing the OPRF blinded message, serialized using SerializeScalar ([OPRF], Section 2.1) and represented as a hexadecimal string.

視覚障害者は、OPRFブラインドメッセージを計算するときに使用され、SerializeScalar（[OPRF]、セクション2.1）を使用してシリアル化され、16進文字列として表されます。

token_request:

token_request：

The TokenRequest message constructed according to Section 5.1, represented as a hexadecimal string.

セクション5.1に従って構築されたTokenRequestメッセージは、16進文字列として表されます。

token_response:

token_response：

The TokenResponse message constructed according to Section 5.2, represented as a hexadecimal string.

セクション5.2に従って構築されたtokenResponseメッセージは、16進文字列として表されます。

token:

トークン：

The output token from the protocol, represented as a hexadecimal string.

プロトコルからの出力トークンは、16進列文字列として表されます。

   // Test vector 1
   skI: 39b0d04d3732459288fc5edb89bb02c2aa42e06709f201d6c518871d5181
   14910bee3c919bed1bbffe3fc1b87d53240a
   pkI: 02d45bf522425cdd2227d3f27d245d9d563008829252172d34e48469290c
   21da1a46d42ca38f7beabdf05c074aee1455bf
   token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc
   daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b3000e6f72696
   7696e2e6578616d706c65
   nonce:
   6aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05fafe73073b8
   blind: 8e7fd80970b8a00b0931b801a2e22d9903d83bd5597c6a4dc1496ed2b1
   7ef820445ef3bd223f3ab2c4f54c5d1c956909
   token_request: 0001f4030ab3e23181d1e213f24315f5775983c678ce22eff9
   427610832ab3900f2cd12d6829a07ec8a6813cf0b5b886f4cc4979
   token_response: 036bb3c5c397d88c3527cf9f08f1fe63687b867e85c930c49
   ee2c222408d4903722a19ff272ac97e3725b947c972784ebfe86eb9ea54336e43
   34ea9660212c0c85fbadfbf491a1ce2446fc3379337fccd45c1059b2bc760110e
   e1ec227d8e01c9f482c00c47ffa0dbe2fb58c32dde2b1dbe69fff920a528e68dd
   9b3c2483848e57c30542b8984fa6bfecd6d71d54d53eda
   token: 00016aa422c41b59d3e44a136dd439df2454e3587ee5f3697798cdc05f
   afe73073b8501370b494089dc462802af545e63809581ee6ef57890a12105c283
   68169514bf260d0792bf7f46c9866a6d37c3032d8714415f87f5f6903d7fb071e
   253be2f4e0a835d76528b8444f73789ee7dc90715b01c17902fd87375c00a7a9d
   3d92540437f470773be20f71e721da3af40edeb

   // Test vector 2
   skI: 39efed331527cc4ddff9722ab5cd35aeafe7c27520b0cfa2eedbdc298dc3
   b12bc8298afcc46558af1e2eeacc5307d865
   pkI: 038017e005904c6146b37109d6c2a72b95a183aaa9ed951b8d8fb1ed9033
   f68033284d175e7df89849475cd67a86bfbf4e
   token_challenge: 0001000e6973737565722e6578616d706c6500000e6f7269
   67696e2e6578616d706c65
   nonce:
   7617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3190c29d665
   blind: 6492ee50072fa18d035d69c4246362dffe2621afb95a10c033bb0109e0
   f705b0437c425553272e0aa5266ec379e7015e
   token_request: 000133033a5fe04a39da1bbfb68ccdeecd1917474dd525462e
   5a90a6ba53b42aaa1486fe443a2e1c7f3fd5ff028a1c7cf1aeac5d
   token_response: 023bf8cd624880d669c5cc6c88b056355c6e8e1bcbf3746cf
   b9ab9248a4c056f23a4876ef998a8b6b281d50f852c6fa868fc4fa135c79ccb5f
   bdf8bf3c926e10c7c12f934a887d86da4a4e5be70f5a169aa75720887bb690536
   92a8f11f9cda7a72f281e4e3568e848225367946c70db09e718e3cba16193987b
   c10bede3ef54c4d036c17cd4015bb113be60d7aa927e0d
   token: 00017617bc802cfdb5d74722ef7418bdbb4f2c88403820e55fe7ec07d3
   190c29d665c994f7d5cdc2fb970b13d4e8eb6e6d8f9dcdaa65851fb091025dfe1
   34bd5a62a116477bc9e1a205cca95d0c92335ca7a3e71063b2ac020bdd231c660
   97f12333ef438d00801bca5ace0fab8eb483dc04cd62578b95b5652921cd2698c
   45ea74f6c8827b4e19f01140fa5bd039866f562

   // Test vector 3
   skI: 2b7709595b62b784f14946ae828f65e6caeba6eefe732c86e9ae50e818c0
   55b3d7ca3a5f2beecaa859a62ff7199d35cc
   pkI: 03a0de1bf3fd0a73384283b648884ba9fa5dee190f9d7ad4292c2fd49d8b
   4d64db674059df67f5bd7e626475c78934ae8d
   token_challenge: 0001000e6973737565722e6578616d706c65000017666f6f
   2e6578616d706c652c6261722e6578616d706c65
   nonce:
   87499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c28aa7d3a9df
   blind: 1f659584626ba15f44f3d887b2e5fe4c27315b185dfbfaea4253ebba30
   610c4d9b73c78714c142360e85a00942c0fcff
   token_request: 0001c8024610a9f3aac21090f3079d6809437a2b94b4403c7e
   645f849bc6c505dade154c258c8ecd4d2bdcf574daca65db671908
   token_response: 03c2ab925d03e7793b4a4df6eb505210139f620359e142449
   1b8143c06a3e5298b25b662c33256411be7277233e1a34570f7a4d142d931e4b5
   ff8829e27aaf7eb2cc7f9ab655477d71c01d5da5aef44dd076b5820b4710ef025
   a9e6c6b50a95af6105c5987c1b834d615008cf6370556ed00c6671e69776c09a9
   2b5ac84804750dd867c78817bdf69f1443002b18ae7a52
   token: 000187499b5930918d2d83ecebf92d25ca0722aa11b80dbbfd950537c2
   8aa7d3a9df1949fd455872478ba87e2e6c513c3261cddbe57220581245e4c9c91
   1dd1c0bb865785bff8f3cfe08cccbb3a7b8e41d23a172871be4828cc54582d87b
   c7cfc5c8bcedc1868ebc845b000c317ed75312274a42b10be6db23bd8a168fd2f
   021c23925d72c4d14cd7588c03845da0d41a326

   // Test vector 4
   skI: 22e237b7b983d77474e4495aff2fc1e10422b1d955192e0fbf2b7b618fba
   625fcb94b599da9113da49c495a48fbf7f7f
   pkI: 028cd68715caa20d19b2b20d017d6a0a42b9f2b0a47db65e5e763e23744f
   e14d74e374bbc93a2ec3970eb53c8aa765ee21
   token_challenge: 0001000e6973737565722e6578616d706c65000000
   nonce:
   02f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a89e820cd43
   blind: af91d1dbcf6b46baecde70eb305b8fe75629199cca19c7f9344b8607b9
   0def27bc53e0345ade32c9fd0a1efda056d1c0
   token_request: 0001a503632ebb003ed15b6de4557c047c7f81a58688143331
   2ad3ad7f9416f2dfc940d3f439ad1e8cd677d94ae7c05bc958d134
   token_response: 032018bc3f180d9650e27f72de76a90b47e336ae9cb058548
   d851c7046fa0875d96346c15cb39d8083cc6fb57216544c6a815c37d792769e12
   9c0513ce2034c3286cb212548f4aed1b0f71b28e219a71874a93e53ab2f473282
   71d1e9cbefc197a4f599a6825051fa1c6e55450042f04182b86c9cf12477a9f16
   849396c051fa27012e81a86e6c4a9204a063f1e1722dd7
   token: 000102f0a206752d555a24924f2da5942a1bb4cb2d83ff473aa8b2bc3a
   89e820cd43085cb06952044c7655b412ab7d484c97b97c48c79c568140b8d49a0
   2ca47a9cfb0a5cfb861290c4dbd8fd9b60ee9b1a1a54cf47c98531fe253f1ed6d
   875de5a58f42db12b540b0d11bc5d6b42e6d17c2b73e98631e54d40fd2901ebec
   4268668535b03cbf76f7f15a29d623a64cab0c4

   // Test vector 5
   skI: 46f3d4f562002b85ffcfdb4d06835fb9b2e24372861ecaa11357fd1f29f9
   ed26e44715549ccedeb39257f095110f0159
   pkI: 02fbe9da0b7cabe3ec51c36c8487b10909142b59af030c728a5e87bb3b30
   f54c06415d22e03d9212bd3d9a17d5520d4d0f
   token_challenge: 0001000e6973737565722e6578616d706c65205de58a52fc
   daef25ca3f65448d04e040fb1924e8264acfccfc6c5ad451d582b30000
   nonce:
   9ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e84483c90e89
   blind: 76e0938e824b6cda6c163ff55d0298d539e222ed3984f4e31bbb654a8c
   59671d4e0a7e264ca758cd0f4b533e0f60c5aa
   token_request: 0001e10202bc92ac516c867f39399d71976018db52fcab5403
   f8534a65677ba9e1e7d9b1d01767d137884c86cf5fe698c2f5d8e9
   token_response: 0322ea3856a71533796393229b33d33c02cd714e40d5aa4e0
   71f056276f32f89c09947eca8ff119d940d9d57c2fcbd83d2da494ddeb37dc1f6
   78e5661a8e7bcc96b3477eb89d708b0ce10e0ea1b5ce0001f9332f743c0cc3d47
   48233fea6d3152fae7844821268eb96ba491f60b1a3a848849310a39e9ef59121
   669aa5d5dbb4b4deb532d2f907a01c5b39efaf23985080
   token: 00019ee54942d8a1604452a76856b1bfaf1cd608e1e3fa38acfd9f13e8
   4483c90e89d4380df12a1727f4e2ca1ee0d7abea0d0fb1e9506507a4dd618f9b8
   7e79f9f3521a7c9134d6722925bf622a994041cdb1b082cdf1309af32f0ce00ca
   1dab63e1b603747a8a5c3b46c7c2853de5ec7af8cac7cf3e089cecdc9ed3ff05c
   d24504fe4f6c52d24ac901471267d8b63b61e6b

A.2. Issuance Protocol 2 - Blind RSA (2048-bit)

A.2. 発行プロトコル2-ブラインドRSA（2048ビット）

The test vectors below list the following values:

以下のテストベクトルには、次の値がリストされています。

skI:

The PEM-encoded PKCS #8 RSA Issuer Private Key used for signing tokens, represented as a hexadecimal string.

PEMエンコードされたPKCS＃8 RSA発行者の秘密鍵は、16進の文字列として表されるトークンの署名に使用されます。

pkI:

The Issuer Public Key, serialized according to the encoding in Section 8.2.2.

セクション8.2.2のエンコードに従ってシリアル化された発行者の公開キー。

token_challenge:

token_challenge：

A randomly generated TokenChallenge structure, represented as a hexadecimal string.

16進列の文字列として表されるランダムに生成されたトークンチャレンジ構造。

nonce:

ノンセ：

The 32-byte Client nonce generated according to Section 6.1, represented as a hexadecimal string.

セクション6.1に従って生成された32バイトのクライアントnonceは、16進列として表されます。

blind:

盲目：

The blind used when computing the blind RSA blinded message, represented as a hexadecimal string.

ブラインドは、ヘキサデシメール文字列として表される盲目のRSAブラインドメッセージを計算するときに使用されます。

salt:

塩：

The randomly generated 48-byte salt used when encoding the blinded TokenRequest message, represented as a hexadecimal string.

盲検化されたTokenRequestメッセージをエンコードするときに使用されるランダムに生成された48バイトの塩は、16進数文字列として表されます。

token_request:

token_request：

The TokenRequest message constructed according to Section 6.1, represented as a hexadecimal string.

セクション6.1に従って構築されたTokenRequestメッセージは、16進文字列として表されます。

token_response:

token_response：

The TokenResponse message constructed according to Section 6.2, represented as a hexadecimal string.

セクション6.2に従って構築されたtokenResponseメッセージは、16進列として表されます。

token:

トークン：

The output token from the protocol, represented as a hexadecimal string.

プロトコルからの出力トークンは、16進列文字列として表されます。

   // Test vector 1
   skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
   4945765149424144414e42676b71686b6947397730424151454641415343424b6
   3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
   7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
   57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
   35743561496b3172417643655844644e44503442325055707851436e6969396e6
   b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
   6558563835464f314a752b62397336356d586d34516a755139455961497138337
   1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
   355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
   76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
   72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
   475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
   742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
   b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
   316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
   57266366336444373686c6c784c57535638477342737663386f364750320a6359
   366f777042447763626168474b556b5030456b62395330584c4a5763475347356
   1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
   644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
   f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
   414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
   264556851483856437872793251564d515751696e57684174364d7154340a5342
   5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
   3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
   784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
   a652f376b337946786b68305146333162713630654c393047495369414f0a354b
   4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
   9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
   306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
   e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
   7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
   8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
   77524e3632496f397463392b41434c745542377674476179332b6752775974534
   33262356564386c4969656774546b6561306830754453527841745673330a6e35
   6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
   0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
   77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
   e735170315947763977644a724d6156774a6376497077563676315570660a5674
   4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
   9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
   5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
   97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
   7844733968355272627852614e6673542b7241554837783153594456565159564
   d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
   6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
   2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
   31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
   86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
   77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
   0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
   4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
   0524956415445204b45592d2d2d2d2d0a
   pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
   03040202a11a301806092a864886f70d010108300b0609608648016503040202a
   2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
   25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
   b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
   0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
   53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
   32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
   1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
   e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
   babd612d03cad02db134b7e225a5f0203010001
   token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e
   393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e88000e6f72696
   7696e2e6578616d706c65
   nonce:
   aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd1508d07827f05
   blind: 425421de54c7381864ce36473abfb988c454fe6c27de863de702a6a2ad
   ca153fa2de47bd8fcd62734caa8ce1f920b77d980ab58c32d16dde54873f28ca9
   68e8c125b8363514be68972f553655bcc7f80a284cc327e47e804a47333c5b3cd
   f773312cc7ad9fda748aed0baa7e19c5a2d1dafda718f086d7fc0a4bc02d488e0
   f20812daee335af7177b7a8369bd617066aed7a58f659f295c36b418827f67972
   5b81ca14ea16fb82df21ad76da1ac38dcf24bf6252f8510e2308608ac9197f6cb
   54fdcb19db17837302a2b87d659c5605f35f3709a130f0c3d50e172f0cae36cbc
   9467f9914895a215a9e32443bcafff795273ccf8965a7eaa8c0b2184763e3e5c
   salt: 3d980852fa570c064204feb8d107098db976ef8c2137e8641d234bbd88a
   986fdb306a7af220cfadede08f51e1ef61766
   token_request: 0002086a95be84b63cfed0993bb579194a72a95057e1548ac4
   63a9a5b33b011f2b2011d59487f01862f1d8e4d5ea42e73a660fbc3d010b944a5
   4da3a4e0942f8894c0884589b438cb902e9a34278970f33c16f351f7dae58d273
   c3ab66ef368da36f785e89e24d1d983d5c34311cd21f290f9e89e8646ab0d0a48
   988fcd46230de5e7603cd12cc95c7ec5002e5e26737aa7eb69c626476e6c8d465
   10ee404a3d7daf3a23b7c66735d363ca13676925c6ed0117f60d165ce1f8ba616
   d041b6384baf6da3e2f757cb18e879a4f8595c2dc895ddf1f4279c75768d108b5
   c47f95f94e81e2d8b9c8b74476924ab3b7c45243fc99ac5466e8a3680ad37fa15
   c96010b274094
   token_response: 675d84b751d9e593330ec4b6d7ab69c9a61517e98971f4b73
   6150508174b4335761464f237be2d72bbae4b94dffc6143413f6351f1aa4efde6
   c32d4d6d9392a008290d56d1222f9b77a1336213e01934f7d972f3bf9ea5a5786
   c321352f103b3667e605379a55f0fb925fbb09b8a9f85e7dd4b388a3b49d06fd7
   0ba28f6a780e3bc8f6421554fd6c38b63ef19f84ccfcf14709dd0b4d72213c1f0
   60893854eba0ea1a147e275da320db5e9849882d5f9179efa8a2d8d3b803f9d14
   45ef5c1f660be08883ce9b29a0a992fc035d2938cbb61c440044438dbb8b3ce71
   58a8f9827d230482f622d291406ab236b32b122627ae0fd36bd0d6b7607b8044a
   ce404d44
   token: 0002aa72019d1f951df197021ce63876fe8b0a02dc1c31a12b0a2dd150
   8d07827f055969f643b4cfda5196d4aa86aeb5368834f4f06de46950ed435b3b8
   1bd036d44ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
   71cd2708bc6a21b533d07294b5e900faf5537dd3eb33cee4e08c9670d1e5358fd
   184b0e00c637174f5206b14c7bb0e724ebf6b56271e5aa2ed94c051c4a433d302
   b23bc52460810d489fb050f9de5c868c6c1b06e3849fd087629f704cc724bc0d0
   984d5c339686fcdd75f9a9cdd25f37f855f6f4c584d84f716864f546b696d620c
   5bd41a811498de84ff9740ba3003ba2422d26b91eb745c084758974642a420782
   01543246ddb58030ea8e722376aa82484dca9610a8fb7e018e396165462e17a03
   e40ea7e128c090a911ecc708066cb201833010c1ebd4e910fc8e27a1be467f786
   71836a508257123a45e4e0ae2180a434bd1037713466347a8ebe46439d3da1970

   // Test vector 2
   skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
   4945765149424144414e42676b71686b6947397730424151454641415343424b6
   3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
   7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
   57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
   35743561496b3172417643655844644e44503442325055707851436e6969396e6
   b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
   6558563835464f314a752b62397336356d586d34516a755139455961497138337
   1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
   355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
   76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
   72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
   475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
   742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
   b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
   316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
   57266366336444373686c6c784c57535638477342737663386f364750320a6359
   366f777042447763626168474b556b5030456b62395330584c4a5763475347356
   1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
   644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
   f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
   414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
   264556851483856437872793251564d515751696e57684174364d7154340a5342
   5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
   3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
   784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
   a652f376b337946786b68305146333162713630654c393047495369414f0a354b
   4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
   9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
   306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
   e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
   7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
   8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
   77524e3632496f397463392b41434c745542377674476179332b6752775974534
   33262356564386c4969656774546b6561306830754453527841745673330a6e35
   6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
   0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
   77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
   e735170315947763977644a724d6156774a6376497077563676315570660a5674
   4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
   9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
   5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
   97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
   7844733968355272627852614e6673542b7241554837783153594456565159564
   d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
   6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
   2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
   31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
   86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
   77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
   0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
   4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
   0524956415445204b45592d2d2d2d2d0a
   pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
   03040202a11a301806092a864886f70d010108300b0609608648016503040202a
   2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
   25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
   b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
   0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
   53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
   32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
   1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
   e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
   babd612d03cad02db134b7e225a5f0203010001
   token_challenge: 0002000e6973737565722e6578616d706c6500000e6f7269
   67696e2e6578616d706c65
   nonce:
   98c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873d90e84488d
   blind: 7bb85f89c9b83a0e2b02938b3396f06f8f3df0018a91f1a2cc5416aaa5
   52994d063f634d50bea13bffe8d5e01431e646e2e384549cefd695ac3affff665
   a1ebf0113df2520006bd66e468d37a58266daa8a3a75692535e1fc46d0c1d6fb6
   f37c949808172e20c0b77a48570a1fcb474325bdd23cdbce52b5d6a9e39f7aec7
   3b09004eae8c8bfff2b4b533ea63bcf467a4cd95ccfb0cb4e43bc4992c1fd0be7
   a77a4475dbf8094cf25125ece901abbcea607a9050ad9f8ec3d0d66341f6eab40
   ee9c9c22c0b560b8377f8543d8878c7458885fd285c7556cc88fc6021617075b4
   2c83a86005169a6f13352e789b28fdbbe3d0288e1dd7c801497573893146aea3
   salt: b6b4378421ab0ea677ce3f4036fd0489dee458ad81ea519c3e8bde3fcd5
   ec1505d28e110d7b44dcac5e04ecedd54d11a
   token_request: 00020892d26a271c0104657ba10c0b5cb2827bb209d86e8002
   7f96bfb861e0f40cb897f0fc426498433141ce9bc8b4a95914fefe4e40bdd3802
   a121cb0b59a4ae7e03255275c4abf071d991c82ead402606c0ef912178b0a0f68
   d303e06a966079230592827b84979dbcb5f21ab8904e9908638ddf705c4f8af8a
   053c19a66090726b60c6b4063976e4c66eab33522dd3f9d64828441db4aa82d55
   adcc3d3920592884cd1e5a3f490d5c81f1306705dcc5c61d82373f1dbd7d2ae4b
   2fea0f7339f5d868415f59312766e3074ee4a7305f5f053da82673ee6747a727a
   26d8d10ea1b1a3491d26b0c38b962c02a774ac78932153aae9dcc98a9b1db1f53
   89644682f7727
   token_response: 113a5124c1aef6fc230d9fc42b789226f45ca941aad4da3f4
   8cf37c7744a8d7fd1dcfd71cd39d09e9324760180ea0bade3360efaf7322a1fa1
   5f41247be3857fde8c5c92ec6d67a7ee33be8fdadf8b27bb0db706117448e55bc
   e9927cb6bfb1f87f9edb054181a4558af0c0d3973d7033b9599e674c20cf08a7b
   bcf0da815a2edaab7c4fb80dee4ea2cc53576a9691e857da931c6c592d2c69dd2
   1afda8ea653dd90157adfe80e2375c08e75beb497df8b7b73192fbbd4e80359d9
   bbaecea14e0acebdda92596f71ec1d57e26b6497b3152976bc07a4409148cb843
   89eb207fb8e841106012408c6e19b4f964008b6a909aaab767a661a061c97da16
   43040455
   token: 000298c1345ff38a554b429b428b0f206cfe4f3892f8041995f2c24873
   d90e84488d11e15c91a7c2ad02abd66645802373db1d823bea80f08d452541fb2
   b62b5898bca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
   71cd27083350a206c5e9b7c0898f97611ce0bb8d74d310bb194ab67e094e32ff6
   da90886924b1b9e7b569402c1101d896d2fc3a7371ef77f02310db1dc9f81c853
   5828c2d0e9d9051720d182cd54e1c2c3bf417da2fc7aa72bb70ccc834ef274a2e
   809c9821b3d395d6535423f7428b3f29175d6eb840b4b7685336e57e2b6afeaab
   c0c17ea4f557e8a9cc2f624e245c6ccd7cbdd6c32c97c5c6974e802f688e2d25f
   0aba4215f609f692244517d5d3407e0172273982c001c158f5fcbe1b5d2447c26
   a87e89f5a9e72b498b0c59ce749823d2cf253d3cf6cd4e64fa0e434d95e488789
   247a9ceed756ff4ff33a8d2402c0db381236d331092838b608a42002552092897

   // Test vector 3
   skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
   4945765149424144414e42676b71686b6947397730424151454641415343424b6
   3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
   7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
   57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
   35743561496b3172417643655844644e44503442325055707851436e6969396e6
   b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
   6558563835464f314a752b62397336356d586d34516a755139455961497138337
   1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
   355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
   76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
   72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
   475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
   742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
   b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
   316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
   57266366336444373686c6c784c57535638477342737663386f364750320a6359
   366f777042447763626168474b556b5030456b62395330584c4a5763475347356
   1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
   644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
   f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
   414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
   264556851483856437872793251564d515751696e57684174364d7154340a5342
   5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
   3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
   784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
   a652f376b337946786b68305146333162713630654c393047495369414f0a354b
   4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
   9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
   306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
   e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
   7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
   8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
   77524e3632496f397463392b41434c745542377674476179332b6752775974534
   33262356564386c4969656774546b6561306830754453527841745673330a6e35
   6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
   0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
   77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
   e735170315947763977644a724d6156774a6376497077563676315570660a5674
   4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
   9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
   5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
   97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
   7844733968355272627852614e6673542b7241554837783153594456565159564
   d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
   6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
   2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
   31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
   86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
   77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
   0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
   4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
   0524956415445204b45592d2d2d2d2d0a
   pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
   03040202a11a301806092a864886f70d010108300b0609608648016503040202a
   2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
   25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
   b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
   0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
   53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
   32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
   1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
   e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
   babd612d03cad02db134b7e225a5f0203010001
   token_challenge: 0002000e6973737565722e6578616d706c65000017666f6f
   2e6578616d706c652c6261722e6578616d706c65
   nonce:
   9e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af1592df0e71
   blind: c52cabc5e4e131e0f5860cc4c486c5ee8a5fa8ae59484446121f87b0d8
   ccd037f161a99ebcc57f79d05a2ffc852656ad2d0894fab8d1b0f998e6e678254
   ed5778da98b137371320314d06c24276e35435bccffa49d257687f270f9ce1792
   6a074737546d5415a4bb9e624a6302562b395856632efb6992f6593a4f95fb342
   002efebc3046ca96bbc26edb2f1a1454a24ce7b9a7ec8e44fb9e99c8144d409d8
   cd8a5903c0a3c0acbd9f82573ed1fc4a296e3eaf4867ade30110794678f422d36
   bd103ea4617d2472cf58da3381e52e5be60f4acbf685e280648cef21211a796ec
   d005ecbdaa1046c40950afca4c4e7dd4b8c19e504088489a15667b45895b6e92
   salt: c847b5d0fa9101a1e09954ac9f3eed6600af58936295ad2e54274e13e64
   0d59f732d07530c94c19c20668f03470c77ac
   token_request: 0002080f6bd84fba1822c577c8cd670f1136cca107f84ddd9d
   405d5ed22ad15da975538f031433bad4a2688999732927efe2928d4c132389a12
   2f40b639b083d6fcbbed7a55fb18db536d2dcbaefe6dc0a70730e6565b08a7dfd
   783913a59f37d798de0cfc262c9e90a7ee884a3ec355eacbd44e5f6779fea6a78
   5b05ac352fdd51a116cf2be1d8e38b0bfacd6a3d53a88c99f747cce908f86b335
   62691f540e3e88562092cd17cc2f78ce0fb53312a5f2dc918bdb1dc90d9d65091
   c7ba9080ccc1755cb5437989364dc92f0e8fea18f66d631451feb02a3d68af41d
   e1a3f9be925dda5c4ca0706fc4ca28b3317e939f6573442c6d03be17cd141fa82
   60d382d134c6b
   token_response: 2dd08ce89cf4f62bc236ab7b75266e13c57c750345e328e0b
   ea107537c4cbeea5bfc990716950440628ea2e37dbc5c9c6d84f9a965cbf0cbff
   fb89516b1fd19a90d69cc52a28890bbdcf782f56aefadad85b6e861a74170ce91
   0891c89e4293f37978dbd41cc8b5c68802de3d86d9f0326b9c22b809512245896
   6a6ddd1aeb3828d239c3b359efc9b375390eb19050d5656c2b084304d9bd8a816
   14f631bf82a7e4588413b44a0cb6d94e942fa134790b396cb71e3ed33b557b5bd
   0734e726fa79abdca8694703b81d0e289b749801d4383e0d4f825dcde0dd98c43
   d3ba81c028dd8833a4fc24961f60e118d4421dce5b611d53e9ca96156a52509bf
   a9afeb7e
   token: 00029e7a22bdc5d715682434cebc07eb5fa53f622f776a17a6d91757af
   1592df0e710042eee45ac4dd5acb8f6e65c4d8dd47504f73f7463507ef96a4d72
   27d2774f3ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
   71cd270815b010bbc0d5f55e9c856d2e9ffaefba007d33c2d5452fbeb0b15919b
   973e0dc9180aaeb18242043758d9fb0ac9ac5e04da9ff74ec93644ae6cdb7068e
   a76ce2295b9b95e383ed3a9856e9f618dafdf4cec5d2b53ea4297c2f3990babca
   71e3ccd6c07a437daae7ed27b6b81178fb7ce5fa5dd63781cc64ac1e410f441c0
   34b0a5cc873a2ce875e8b38c92bab563635c4f8f4fa35d1f582ef19edf7da75aa
   11a503a82e32a12bd4da41e0ca7ec7f451caf586f5b910003fcbbb9ff5ffa2408
   c28d6807737d03da651ea9bfafcc2747a6830e19a1d160fcd5c25d2f79dad86a8
   b3de8e926e08ca1addced72977f7b56398ef59c26e725df0a976a08f2a936ca42

   // Test vector 4
   skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
   4945765149424144414e42676b71686b6947397730424151454641415343424b6
   3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
   7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
   57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
   35743561496b3172417643655844644e44503442325055707851436e6969396e6
   b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
   6558563835464f314a752b62397336356d586d34516a755139455961497138337
   1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
   355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
   76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
   72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
   475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
   742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
   b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
   316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
   57266366336444373686c6c784c57535638477342737663386f364750320a6359
   366f777042447763626168474b556b5030456b62395330584c4a5763475347356
   1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
   644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
   f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
   414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
   264556851483856437872793251564d515751696e57684174364d7154340a5342
   5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
   3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
   784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
   a652f376b337946786b68305146333162713630654c393047495369414f0a354b
   4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
   9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
   306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
   e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
   7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
   8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
   77524e3632496f397463392b41434c745542377674476179332b6752775974534
   33262356564386c4969656774546b6561306830754453527841745673330a6e35
   6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
   0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
   77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
   e735170315947763977644a724d6156774a6376497077563676315570660a5674
   4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
   9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
   5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
   97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
   7844733968355272627852614e6673542b7241554837783153594456565159564
   d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
   6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
   2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
   31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
   86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
   77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
   0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
   4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
   0524956415445204b45592d2d2d2d2d0a
   pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
   03040202a11a301806092a864886f70d010108300b0609608648016503040202a
   2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
   25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
   b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
   0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
   53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
   32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
   1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
   e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
   babd612d03cad02db134b7e225a5f0203010001
   token_challenge: 0002000e6973737565722e6578616d706c65000000
   nonce:
   494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c45340bfe8e6
   blind: 097cb17bcedecfe058dff5c4e517d1e36d7ab8f46252b1ac1933ba378c
   32625c0dbc69f5655c2003bf39e75810796cd63675b223cf3162c57108d56e058
   4cfce6cad829e74369ada38a095eb3012c912b31ccde7425f93464e353fb17552
   be3a8df2913daca61543a33ae45058f218c471dfbc12fb304158e29b6ed35bc07
   9e23f1e6173c5dec4545840bbe58e5ad37cbea0a10dca5d9df2781589d27c3410
   8477b52c0d32a1370c17f703941fbb1a007a6794e7de2758709c9bbf80f21eec7
   922b9bb491eb6aac8c1a14764e648e6be4fff0ae913797067aa0826f366c3103e
   103b05653c73b52d7f825a185dccfb806da700db9f53abb848554b7d4f7c28f3
   salt: 49912979f1bf528e5b8228ab1328df74319dce7bdaf45821ceb1100dcf0
   42a2dfe852fc9db59b64a5f6493c282504240
   token_request: 000208244840027ca8c620f8b14caded9a198ba388ccd8541e
   962f68a0071535d958d18494afd0bc11da4da8c8b33864f5a8f623b697cd56348
   594e11a75479048a72c0ed179b070506c09a7eb6ed3582f572df38cf60fcde11a
   52c5ce6d7b23435b60200ad9f66d21f40f323c9aa54307d0b966d4457c37542b6
   6bb183ddeafca914fc74831698b5d52f498ee3d165685f49a8d86e39fe6c4b7ec
   678f5250908d25e5b873c69b422368121aa4210cadd6fc640907d3cb9a7a3e827
   a0e742470f00c2f49dc6c0e8cc9470dbfd73df0ccbb96c10b02af0dd7dee719ec
   a11ff8e1b4929e59f3cf319de9bda29a6d968b43083b5d4242f3448d76ada08b8
   014f70b97e719
   token_response: c2746ff644cffb28a2c19395fa19dfb61fd135daa837844fb
   f9fbe06c253e64e69f53aefddc0fb4833b1b5e58f571134a34f245499c3e73419
   549c2c9111cf94f2f68fea3996d47f71e8d8d6fc5b1c074bf74fa59de4cbf32f5
   f08d45ea45492f0279c3b1a8d852698edbe1651eb8e09eb223a27386c0feb2f6a
   8260235edb36cf433da518100829b63166284b325d87fc941ea3bafe7b6761b70
   82e09397837f74b4f0fc838bce8af7242089dd5561f57735926bcbad219fc9fee
   85ae49a8e8951f63ca194b7ff018c06ee02267e7267bb996432dc76973819da80
   e3e86947b0a4b36d3a972dafaaa3db0e1044b325f02c679996d9bcd3ce51390d5
   4bc10b8c
   token: 0002494dae41fc7e300c2d09990afcd5d5e1fc95305337dc12f78942c4
   5340bfe8e6b741ec1b6fd05f1e95f8982906aec1612896d9ca97d53eef94ad3c9
   fe023f7a4ca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
   71cd2708a55c83dc04292b5d92add1a87b37e54f22f61c58840586f390c50b231
   824423378ddcf50e69dc817d45bfad06c7f2a0ac35d2acd7f26b0bc9954c192b0
   a0ef28a2a5650e390098dd3cb1166a7cb1716d3dd2d19dc5ca3b1ea6206359de0
   002d82bc4fa7e69fb07214b06addcbd2203d1e17f57fc580bcc5a13e0ac15cf94
   2182cc2b5d6eaa737a712704114e357e2ec2f10047463ded02a1a0766dc346dd7
   212b9711e03ac95eb258ac1164104dc9a0d3e738ae742ab5ed8c5139fc07145a7
   88b9f891741ee68f0a66782b7b84a9bb4cb4b3d1b26b67106f397b35b641d882d
   7b0185168946de898ef72349a44a47dbdd6d46e9ba9ba543d5701b65c63d645c2

   // Test vector 5
   skI: 2d2d2d2d2d424547494e2050524956415445204b45592d2d2d2d2d0a4d49
   4945765149424144414e42676b71686b6947397730424151454641415343424b6
   3776767536a41674541416f49424151444c4775317261705831736334420a4f6b
   7a38717957355379356b6f6a41303543554b66717444774e38366a424b5a4f764
   57245526b49314c527876734d6453327961326333616b4745714c756b440a556a
   35743561496b3172417643655844644e44503442325055707851436e6969396e6
   b492b6d67725769744444494871386139793137586e6c5079596f784f530a646f
   6558563835464f314a752b62397336356d586d34516a755139455961497138337
   1724450567a50335758712b524e4d636379323269686763624c766d42390a6a41
   355334475666325a6c74785954736f4c364872377a58696a4e394637486271656
   76f753967654b524d584645352f2b4a3956595a634a734a624c756570480a544f
   72535a4d4948502b5358514d4166414f454a4547426d6d4430683566672f43473
   475676a79486e4e51383733414e4b6a55716d3676574574413872514c620a4530
   742b496c706641674d4241414543676745414c7a4362647a69316a506435384d6
   b562b434c6679665351322b7266486e7266724665502f566344787275690a3270
   316153584a596962653645532b4d622f4d4655646c485067414c7731785134576
   57266366336444373686c6c784c57535638477342737663386f364750320a6359
   366f777042447763626168474b556b5030456b62395330584c4a5763475347356
   1556e484a585237696e7834635a6c666f4c6e7245516536685578734d710a6230
   644878644844424d644766565777674b6f6a4f6a70532f39386d4555793756422
   f3661326c7265676c766a632f326e4b434b7459373744376454716c47460a787a
   414261577538364d435a342f5131334c762b426566627174493973715a5a776a7
   264556851483856437872793251564d515751696e57684174364d7154340a5342
   5354726f6c5a7a7772716a65384d504a393175614e4d6458474c63484c4932367
   3587a76374b53514b42675144766377735055557641395a325a583958350a6d49
   784d54424e6445467a56625550754b4b413179576e31554d444e63556a71682b7
   a652f376b337946786b68305146333162713630654c393047495369414f0a354b
   4f574d39454b6f2b7841513262614b314d664f5931472b386a7a4258557042733
   9346b353353383879586d4b366e796467763730424a385a6835666b55710a5732
   306f5362686b686a5264537a48326b52476972672b5553774b426751445a4a4d6
   e7279324578612f3345713750626f737841504d69596e6b354a415053470a7932
   7a305a375455622b7548514f2f2b78504d376e433075794c494d44396c61544d4
   8776e3673372f4c62476f455031575267706f59482f4231346b2f526e360a6675
   77524e3632496f397463392b41434c745542377674476179332b6752775974534
   33262356564386c4969656774546b6561306830754453527841745673330a6e35
   6b796132513976514b4267464a75467a4f5a742b7467596e576e5155456757385
   0304f494a45484d45345554644f637743784b7248527239334a6a7546320a4533
   77644b6f546969375072774f59496f614a5468706a50634a62626462664b792b6
   e735170315947763977644a724d6156774a6376497077563676315570660a5674
   4c61646d316c6b6c7670717336474e4d386a6e4d30587833616a6d6d6e6665573
   9794758453570684d727a4c4a6c394630396349324c416f4742414e58760a7567
   5658727032627354316f6b6436755361427367704a6a5065774e526433635a4b3
   97a306153503144544131504e6b7065517748672f2b36665361564f487a0a7941
   7844733968355272627852614e6673542b7241554837783153594456565159564
   d68555262546f5a6536472f6a716e544333664e6648563178745a666f740a306c
   6f4d4867776570362b53494d436f6565325a6374755a5633326c6349616639726
   2484f633764416f47416551386b3853494c4e4736444f413331544535500a6d30
   31414a49597737416c5233756f2f524e61432b78596450553354736b75414c787
   86944522f57734c455142436a6b46576d6d4a41576e51554474626e594e0a5363
   77523847324a36466e72454374627479733733574156476f6f465a6e636d504c5
   0386c784c79626c534244454c79615a762f624173506c4d4f39624435630a4a2b
   4e534261612b6f694c6c31776d4361354d43666c633d0a2d2d2d2d2d454e44205
   0524956415445204b45592d2d2d2d2d0a
   pkI: 30820152303d06092a864886f70d01010a3030a00d300b06096086480165
   03040202a11a301806092a864886f70d010108300b0609608648016503040202a
   2030201300382010f003082010a0282010100cb1aed6b6a95f5b1ce013a4cfcab
   25b94b2e64a23034e4250a7eab43c0df3a8c12993af12b111908d4b471bec31d4
   b6c9ad9cdda90612a2ee903523e6de5a224d6b02f09e5c374d0cfe01d8f529c50
   0a78a2f67908fa682b5a2b430c81eaf1af72d7b5e794fc98a3139276879757ce4
   53b526ef9bf6ceb99979b8423b90f4461a22af37aab0cf5733f7597abe44d31c7
   32db68a181c6cbbe607d8c0e52e0655fd9996dc584eca0be87afbcd78a337d17b
   1dba9e828bbd81e291317144e7ff89f55619709b096cbb9ea474cead264c2073f
   e49740c01f00e109106066983d21e5f83f086e2e823c879cd43cef700d2a352a9
   babd612d03cad02db134b7e225a5f0203010001
   token_challenge: 0002000e6973737565722e6578616d706c65208e7acc900e
   393381e8810b7c9e4a68b5163f1f880ab6688a6ffe780923609e880000
   nonce:
   a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f63143cd43a3
   blind: ad7a32e1ac31b91daefd7042cc23d5621ab3e870d87297bbfe1ee8a518
   ffc5b84770d3b77775c485b2d219954834868842d2f11877ac4bceb5da88944cc
   a043a9afa52f9c9998a5dea7ab7c1f82662d0d327e29705a269ad221ae74a7c11
   72ff89c48997a9fda08886d3998bb538868396c0ace71d260cc71f768001939b2
   4d80d88979f0244a3dbc004eadfac81e138d430b9fa51c1aad21b957ff96b3123
   c91c2fff362a386f0f99a3f9fc906ca626fd9107648f87532b44c4fe3856ecae1
   f46d8ebf5d2f46e52034478e5e883015666574dd80bd5c036c4b55ebcc8b66068
   8d23944cc1932d075b559dcdc269fae3511761f71c113634e60d67accc8875fb
   salt: 35c04710ce866d879447b6230ce098a49e81be5c067881cce7bd5f92c1e
   5bd9b3c7d4d795cfad134fdfe916d735a624a
   token_request: 0002083d6495c72529bbc4f5c0b49e94e4561baec1ca638a93
   b2940ea9e37b838db7b1a91ec1f257d49b45c4f75119c2ab9eb5578541ad2b9ba
   c1bd627abc709097f503f83d98fed6dbeb615c3be9bf09cbf8ea25ea8026c1b8b
   a1c704ff516ed87c3d7d85342fd00111d8a80492d4b8fdbb092a282f74f13901e
   5edc1b3b02cfe24c950affe6130fbb57c1482d674db3c6944812ba081c2235a16
   d01eeec0932a8619d85732fc3e36179f0b50377bf9cb7a50ce3abeb3f31ed5f0f
   3deec7aae7290f5397cec61318357d652b029a0fda0f100a78e36c4ef56ba3779
   963e8745fdf4e347763c63d825836878e249833a0f4bd315392cc06ccca2c955e
   921efbc4f941d
   token_response: 8db727000018a98a2fe9fda8bbde5b8e9cedc31efbcaed695
   0eb1e0f8d9af9db632def52f74f07cdab304bbde40519080dd0388fb2b8900528
   b4791d2bca40aa2c2a6d1b92f010c1849bfb781cc813cc204855dd05e8a2dd31e
   a5220981b8ab6b008e153083dc8f594206440d66286fea9c21b56807be8655506
   ab7818bb9c8c69489dda56fe6390a5397268c8b5711f9d2df6f2584740cccf034
   5fd67f93f345426f33c078a0aceb90845df9eef74f6248d06c36d19e191da325b
   721ddc12ea78ed37b0c3b6170590536e3aee7eb0efc7d11a2c9d072a394f12ffa
   67ecf316c49efd8f31723b11fe46740636bd89ad4f7ef96bc38b2cb4916d9dc04
   ba1b2fc6
   token: 0002a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f6
   3143cd43a3bb8a8cf1c59e7a251358ed76fe0ccff61044bc79dd261f16020324d
   22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f
   71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a
   9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26
   e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7c
   c6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81
   a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16b
   a49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273
   c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d658
   5a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23

Acknowledgements

謝辞

The authors of this document would like to acknowledge the helpful feedback and discussions from Benjamin Schwartz, Joseph Salowey, and Tara Whalen.

この文書の著者は、ベンジャミン・シュワルツ、ジョセフ・サロウィー、タラ・ウォーレンからの役立つフィードバックと議論を認めたいと考えています。

Authors' Addresses

著者のアドレス

   Sofía Celi
   Brave Software
   Lisbon
   Portugal
   Email: cherenkov@riseup.net

   Alex Davidson
   NOVA LINCS, Universidade NOVA de Lisboa
   Largo da Torre
   Caparica
   Portugal
   Email: alex.davidson92@gmail.com

   Steven Valdez
   Google LLC
   Email: svaldez@chromium.org

   Christopher A. Wood
   Cloudflare
   101 Townsend St
   San Francisco, CA 94107
   United States of America
   Email: caw@heapingbits.net

RFC 9578 - Privacy Pass Issuance Protocols 日本語訳

Privacy Pass Issuance Protocols

プライバシーパス発行プロトコル

Abstract

概要

Status of This Memo

本文書の位置付け

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

2. Terminology

2. 用語

3. Protocol Overview

3. プロトコルの概要

4. Configuration

4. 構成

5. Issuance Protocol for Privately Verifiable Tokens

5. 個人的に検証可能なトークンの発行プロトコル

5.1. Client-to-Issuer Request

5.1. クライアントからイザーへのリクエスト

5.2. Issuer-to-Client Response

5.2. 発行者からクライアントへの応答

5.3. Finalization

5.3. ファイナライゼーション

5.4. Token Verification

5.4. トークン検証

5.5. Issuer Configuration

5.5. 発行者構成

6. Issuance Protocol for Publicly Verifiable Tokens

6. 公開されているトークンの発行プロトコル

6.1. Client-to-Issuer Request

6.1. クライアントからイザーへのリクエスト

6.2. Issuer-to-Client Response

6.2. 発行者からクライアントへの応答

6.3. Finalization

6.3. ファイナライゼーション

6.4. Token Verification

6.4. トークン検証

6.5. Issuer Configuration

6.5. 発行者構成

7. Security Considerations

7. セキュリティに関する考慮事項

8. IANA Considerations

8. IANAの考慮事項

8.1. Well-Known "private-token-issuer-directory" URI

8.1. 有名な「Private-Token-Issuer-Directory」URI

8.2. Privacy Pass Token Types

8.2. プライバシーパストークンタイプ

8.2.1. Token Type VOPRF(P-384, SHA-384)

8.2.1. トークンタイプVOPRF（P-384、SHA-384）

8.2.2. Token Type Blind RSA (2048-bit)

8.2.2. トークンタイプブラインドRSA（2048ビット）

8.3. Media Types

8.3. メディアタイプ

8.3.1. "application/private-token-issuer-directory" Media Type

8.3.1. 「アプリケーション/プライベートトークン-Issuer-Directory」メディアタイプ

8.3.2. "application/private-token-request" Media Type

8.3.2. 「アプリケーション/プライベートトークンリケスト」メディアタイプ

8.3.3. "application/private-token-response" Media Type

8.3.3. 「アプリケーション/プライベートトークン応答」メディアタイプ

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

9.2. Informative References

9.2. 参考引用

Appendix A. Test Vectors

付録A. テストベクトル

A.1. Issuance Protocol 1 - VOPRF(P-384, SHA-384)

A.1. 発行プロトコル1-VOPRF（P-384、SHA-384）

A.2. Issuance Protocol 2 - Blind RSA (2048-bit)

A.2. 発行プロトコル2-ブラインドRSA（2048ビット）

Acknowledgements

謝辞

Authors' Addresses

著者のアドレス