[要約] この文書は、プライバシーを保護する認証メカニズムに基づく認可のために使用されるプライバシーパスのアーキテクチャと要件を指定しています。プライバシーパスとそのプロトコルの概念モデル、セキュリティとプライバシーの目標、実用的な展開モデル、および各展開モデルに対する推奨事項を説明し、望ましいセキュリティとプライバシーの目標が達成されるよう支援します。
Internet Engineering Task Force (IETF) A. Davidson
Request for Comments: 9576 NOVA LINCS, Universidade NOVA de Lisboa
Category: Informational J. Iyengar
ISSN: 2070-1721 Fastly
C. A. Wood
Cloudflare
June 2024
This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled.
このドキュメントは、プライバシーを提供する認証メカニズムに基づいて許可に使用される構成プロトコルのプライバシーパスアーキテクチャと要件を指定します。プライバシーパスの概念モデルとそのプロトコル、そのセキュリティとプライバシーの目標、実用的な展開モデル、および各展開モデルの推奨事項について説明し、目的のセキュリティとプライバシーの目標が達成されるようにします。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9576.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9576で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Architecture
3.1. Overview
3.2. Use Cases
3.3. Privacy Goals and Threat Model
3.4. Redemption Protocol
3.5. Issuance Protocol
3.5.1. Attester Role
3.5.2. Issuer Role
3.5.3. Issuance Metadata
3.5.4. Future Issuance Protocol Requirements
3.6. Information Flow
3.6.1. Token Challenge Flow
3.6.2. Attestation Flow
3.6.3. Issuance Flow
3.6.4. Token Redemption Flow
4. Deployment Models
4.1. Shared Origin, Attester, Issuer
4.2. Joint Attester and Issuer
4.3. Joint Origin and Issuer
4.4. Split Origin, Attester, Issuer
5. Deployment Considerations
5.1. Discriminatory Treatment
5.2. Centralization
6. Privacy Considerations
6.1. Partitioning by Issuance Metadata
6.2. Partitioning by Issuance Consistency
6.3. Partitioning by Side Channels
7. Security Considerations
7.1. Token Caching
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
Privacy Pass is an architecture for authorization based on privacy-preserving authentication mechanisms. In other words, relying parties authenticate Clients in a privacy-preserving way, i.e., without learning any unique, per-Client information through the authentication protocol, and then make authorization decisions on the basis of that authentication succeeding or failing. Possible authorization decisions might be to provide Clients with read access to a particular resource or write access to a particular resource.
プライバシーパスは、プライバシーを提供する認証メカニズムに基づいた承認のためのアーキテクチャです。言い換えれば、当事者は、クライアントをプライバシーを提供する方法で認証します。つまり、認証プロトコルを介して一意のクライアント情報を学習せずに、成功または失敗のその認証に基づいて認可決定を下します。可能な認可決定は、クライアントに特定のリソースへの読み取りアクセスを提供するか、特定のリソースへの書き込みアクセスを提供することです。
Typical approaches for authorizing Clients, such as through the use of long-term state (cookies), are not privacy friendly, since they allow servers to track Clients across sessions and interactions. Privacy Pass takes a different approach: instead of presenting linkable state-carrying information to servers, e.g., a cookie indicating whether or not the Client is an authorized user or has completed some prior challenge, Clients present unlinkable proofs that attest to this information. These proofs, or tokens, are private in the sense that a given token cannot be linked to the protocol interaction where that token was initially issued.
長期状態（Cookie）の使用など、クライアントを承認するための典型的なアプローチは、セッションやインタラクション全体でクライアントを追跡できるため、プライバシーにやさしくありません。プライバシーパスには別のアプローチが必要です。リンク可能な状態運搬情報をサーバーに提示する代わりに、たとえばクライアントが認定ユーザーであるか、以前の課題を完了したかどうかを示すCookieを提示する代わりに、クライアントはこの情報を証明するリンクできない証明を提示します。これらの証明、またはトークンは、特定のトークンが最初に発行されたプロトコル相互作用にリンクできないという意味で非公開です。
At a high level, the Privacy Pass architecture consists of two protocols: redemption and issuance. The redemption protocol, described in [AUTHSCHEME], runs between Clients and Origins (servers). It allows Origins to challenge Clients to present tokens for consumption. Origins verify the token to authenticate the Client -- without learning any specific information about the Client -- and then make an authorization decision on the basis of the token verifying successfully or not. Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained token or invokes an issuance protocol, e.g., the protocols described in [ISSUANCE], to acquire a token to present as authorization.
高レベルでは、プライバシーパスアーキテクチャは、償還と発行の2つのプロトコルで構成されています。[Authscheme]に記載されている償還プロトコルは、クライアントとOrigins（サーバー）の間で実行されます。オリジンがクライアントに挑戦して消費のためにトークンを提示することを可能にします。Originsは、クライアントに関する特定の情報を学習せずにクライアントを認証するためにトークンを検証し、トークンを正常に検証するかどうかに基づいて承認決定を下します。トークンの種類、たとえば、キャッシュできるかどうかに応じて、クライアントは以前に取得したトークンを提示するか、[発行]に記載されているプロトコルを発行するプロトコルを呼び出し、認証として提示するトークンを取得します。
This document describes requirements for both redemption and issuance protocols and how they interact. It also provides recommendations on how the architecture should be deployed to ensure the privacy of Clients and the security of all participating entities.
このドキュメントは、償還と発行プロトコルの両方の要件とそれらの相互作用について説明しています。また、クライアントのプライバシーとすべての参加エンティティのセキュリティを確保するために、アーキテクチャを展開する方法に関する推奨事項も提供します。
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]で説明されているように解釈されます。
The following terms are used throughout this document:
次の用語は、このドキュメント全体で使用されます。
Client:
クライアント:
An entity that seeks authorization to an Origin. Using terminology from [RFC9334], Clients implement the Remote ATtestation procedureS (RATS) Attester role.
起源への承認を求めるエンティティ。[RFC9334]の用語を使用して、クライアントはリモートの証明手順（RAT）Attesterの役割を実装します。
Token:
トークン：
A cryptographic authentication message used for authorization decisions, produced as output from an issuance mechanism or protocol.
発行メカニズムまたはプロトコルからの出力として生成される認可決定に使用される暗号化認証メッセージ。
Origin:
起源：
An entity that consumes tokens presented by Clients and uses them to make authorization decisions.
クライアントによって提示されたトークンを消費し、それらを使用して許可決定を下すエンティティ。
Token challenge:
トークンチャレンジ：
The mechanism by which Origins request tokens from Clients, often denoted TokenChallenge.
Originsがクライアントにトークンを要求するメカニズムは、多くの場合TokenChallengeを示します。
Token request:
トークンリクエスト：
A message used by Clients to request a token from an Issuer, often denoted TokenRequest.
多くの場合、TokenRequestを示す発行者からトークンを要求するためにクライアントが使用するメッセージ。
Token response:
トークン応答：
A message used by Issuers to send tokens to a Client, often denoted TokenResponse.
多くの場合、トークンをクライアントに送信するために発行者が使用するメッセージ。
Redemption:
償還：
The mechanism by which Clients present tokens to Origins for the purposes of authorization.
クライアントが認可を目的としてトークンを起源に提示するメカニズム。
Issuer:
発行者：
An entity that issues tokens to Clients for properties attested to by the Attester.
Attesterによって証明されたプロパティのためにクライアントにトークンを発行するエンティティ。
Issuance:
発行：
The mechanism by which an Issuer produces tokens for Clients.
発行者がクライアント用のトークンを生産するメカニズム。
Attester:
アテスター：
An entity that attests to properties of Clients for the purposes of token issuance. Using terminology from [RFC9334], Attesters implement the RATS Verifier role.
トークン発行の目的でクライアントのプロパティを証明するエンティティ。[RFC9334]の用語を使用して、ATTESTERSはRATS検証剤の役割を実装します。
Attestation procedure:
証明手順：
The procedure by which an Attester determines whether or not a Client has the specific set of properties that are necessary for token issuance.
Attersterが、クライアントがトークン発行に必要な特定のプロパティセットを持っているかどうかを判断する手順。
The trust relationships between each of the entities in this list are further elaborated upon in Section 3.3.
このリストの各エンティティ間の信頼関係は、セクション3.3でさらに詳しく説明されています。
The Privacy Pass architecture consists of four logical entities -- Client, Origin, Issuer, and Attester -- that work in concert for token redemption and issuance. This section presents an overview of Privacy Pass, a high-level description of the threat model and privacy goals of the architecture, and the goals and requirements of the redemption and issuance protocols. Deployment variations for the Origin, Issuer, and Attester in this architecture, including considerations for implementing these entities, are further discussed in Section 4.
プライバシーパスアーキテクチャは、クライアント、オリジン、発行者、および攻撃者の4つの論理エンティティで構成されています。このセクションでは、プライバシーパスの概要、アーキテクチャの脅威モデルとプライバシー目標の高レベルの説明、および償還および発行プロトコルの目標と要件を示します。これらのエンティティを実装するための考慮事項を含む、このアーキテクチャの起源、発行者、および登録の展開のバリエーションについては、セクション4でさらに説明します。
This section describes the typical interaction flow for Privacy Pass, as shown in Figure 1.
このセクションでは、図1に示すように、プライバシーパスの典型的な相互作用フローについて説明します。
1. A Client interacts with an Origin by sending a request or otherwise interacting with the Origin in a way that triggers a response containing a token challenge. The token challenge indicates a specific Issuer to use.
1. クライアントは、トークンチャレンジを含む応答をトリガーする方法でリクエストを送信するか、その他の方法で起源と対話することにより、起源と対話します。トークンチャレンジは、使用する特定の発行者を示しています。
2. If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of previously issued tokens, it can skip to step 6 and redeem its token; see Section 7.1 for security considerations regarding cached tokens.
2. クライアントがトークンチャレンジを満たすトークンを既に利用できる場合、たとえば、クライアントが以前に発行されたトークンのキャッシュを持っているため、ステップ6にスキップしてトークンを引き換えることができます。キャッシュされたトークンに関するセキュリティ上の考慮事項については、セクション7.1を参照してください。
3. If the Client does not have a token available and decides it wants to obtain one (or more) bound to the token challenge, it then invokes the issuance protocol. As a prerequisite to the issuance protocol, the Client runs the deployment-specific attestation process that is required for the designated Issuer. Client attestation can be done via proof of solving a CAPTCHA, checking device or hardware attestation validity, etc.; see Section 3.5.1 for more details.
3. クライアントが利用可能なトークンを持っておらず、トークンチャレンジにバインドされたもの（またはそれ以上）を取得することを決定した場合、発行プロトコルを呼び出します。発行プロトコルの前提条件として、クライアントは、指定された発行者に必要な展開固有の証明プロセスを実行します。クライアントの証明は、Captchaの解決、デバイスまたはハードウェアの証明の妥当性などを解決する証明を介して行うことができます。詳細については、セクション3.5.1を参照してください。
4. If the attestation process completes successfully, the Client creates a token request to send to the designated Issuer (generally via the Attester, though it is not required to be sent through the Attester). The Attester and Issuer might be functions on the same server, depending on the deployment model (see Section 4). Depending on the attestation process, it is possible for attestation to run alongside the issuance protocol, e.g., where Clients send necessary attestation information to the Attester along with their token request. If the attestation process fails, the Client receives an error and issuance aborts without a token.
4. 証明プロセスが正常に完了した場合、クライアントは指定された発行者に送信するためのトークンリクエストを作成します（一般的には、アテスターを介して送信する必要はありませんが）。Attesterと発行者は、展開モデルに応じて、同じサーバー上の機能である可能性があります（セクション4を参照）。証明プロセスに応じて、たとえば、クライアントがトークンリクエストとともに必要な証明情報をAttesterに送信する発行プロトコルと一緒に実行することが可能です。証明プロセスが失敗した場合、クライアントはトークンなしでエラーを受け取り、発行は中止します。
5. The Issuer generates a token response based on the token request, which is returned to the Client (generally via the Attester). Upon receiving the token response, the Client computes a token from the token challenge and token response. This token can be validated by anyone with the per-Issuer key but cannot be linked to the content of the token request or token response.
5. 発行者は、クライアントに返されるトークン要求に基づいてトークン応答を生成します（通常はAttester経由）。トークンの応答を受信すると、クライアントはトークンチャレンジとトークンの応答からトークンを計算します。このトークンは、発行者のキーを持つ人は誰でも検証できますが、トークン要求またはトークンの応答のコンテンツにリンクすることはできません。
6. If the Client has a token, it includes it in a subsequent request to the Origin, as authorization. This token is sent only once in reaction to a challenge; Clients do not send tokens more than once, even if they receive duplicate or redundant challenges. The Origin validates that the token was generated by the expected Issuer and has not already been redeemed for the corresponding token challenge. If the Client does not have a token, perhaps because issuance failed, the Client does not reply to the Origin's challenge with a new request.
6. クライアントがトークンを持っている場合、許可として、その後のオリジンへの要求にそれを含めます。このトークンは、チャレンジに反応して1回だけ送信されます。クライアントは、重複または冗長な課題を受け取ったとしても、トークンを複数回送信しません。起源は、トークンが予想される発行者によって生成されたことを検証し、対応するトークンチャレンジとまだ引き換えられていない。クライアントがトークンを持っていない場合、おそらく発行が失敗したため、クライアントは新しいリクエストでOriginの課題に返信しません。
+--------+ +--------+ +----------+ +--------+
| Origin | | Client | | Attester | | Issuer |
+---+----+ +---+----+ +----+-----+ +---+----+
| | | |
|<----- Request ------+ | |
+-- TokenChallenge -->| | |
| |<== Attestation ==>| |
| | | |
| +--------- TokenRequest ------->|
| |<-------- TokenResponse -------+
|<-- Request+Token ---+ | |
| | | |
Figure 1: Privacy Pass Redemption and Issuance Protocol Interaction
図1：プライバシーパス償還と発行プロトコルの相互作用
Use cases for Privacy Pass are broad and depend greatly on the deployment model as discussed in Section 4. The initial motivating use case for Privacy Pass [PrivacyPassCloudflare] was to help rate-limit malicious or otherwise abusive traffic from services such as Tor [DMS2004]. The generalized and evolved architecture described in this document also works for this use case. However, for added clarity, some more possible use cases are described below.
プライバシーパスのユースケースは広範であり、セクション4で説明したように展開モデルに大きく依存します。プライバシーパスの最初の動機付けのユースケース[privacypasscloudflare]は、Tor [DMS2004]などのサービスからの悪意のあるまたはその他の虐待的なトラフィックを評価することでした。。このドキュメントで説明されている一般化および進化したアーキテクチャも、このユースケースで機能します。ただし、明確にするために、さらにいくつかの可能なユースケースを以下に説明します。
* Low-quality, anti-fraud signal for open Internet services. Tokens can attest that the Client behind the user agent is likely not a bot attempting to perform some form of automated attack such as credential stuffing. Example attestation procedures for this use case might be solving some form of CAPTCHA or presenting evidence of a valid, unlocked device in good standing.
* オープンインターネットサービス用の低品質のアンチフラード信号。Tokensは、ユーザーエージェントの背後にあるクライアントが、資格詰めなどの自動攻撃を実行しようとするボットではない可能性が高いことを証明できます。このユースケースの例の証明手順は、何らかの形のキャプチャを解決するか、有効でロック解除されたデバイスの証拠を良好な状態で提示することです。
* Privacy-preserving authentication for proprietary services. Tokens can attest that the Client is a valid subscriber for a proprietary service, such as a deployment of Oblivious HTTP [OHTTP].
* 独自のサービスのプライバシー推定認証。トークンは、クライアントが、忘却のHTTP [OHTTP]の展開など、独自のサービスの有効なサブスクライバーであることを証明できます。
The end-to-end flow for Privacy Pass described in Section 3.1 involves three different types of contexts:
セクション3.1で説明されているプライバシーパスのエンドツーエンドフローには、3つの異なるタイプのコンテキストが含まれます。
Redemption context:
償還のコンテキスト：
The interactions and set of information shared between the Client and Origin, i.e., the information that is provided or otherwise available to the Origin during redemption that might be used to identify a Client and construct a token challenge. This context includes all information associated with redemption, such as the timestamp of the event, Client-visible information (including the IP address), and the Origin name.
クライアントと起源の間で共有される情報、つまり、クライアントを識別してトークンチャレンジを構築するために使用される可能性のある償還中に提供される、またはその他の方法で利用可能な情報。このコンテキストには、イベントのタイムスタンプ、クライアント可視情報（IPアドレスを含む）、オリジン名など、償還に関連するすべての情報が含まれます。
Issuance context:
発行コンテキスト：
The interactions and set of information shared between the Client, Attester, and Issuer, i.e., the information that is provided or otherwise available to the Attester and Issuer during issuance that might be used to identify a Client. This context includes all information associated with issuance, such as the timestamp of the event, any Client-visible information (including the IP address), and the Origin name (if revealed during issuance). This does not include the token challenge in its entirety, as that is kept secret from the Issuer during the issuance protocol.
クライアント、アテスター、および発行者の間で共有される情報、つまり、クライアントを識別するために使用される可能性のある発行中に、アテスターと発行者が提供またはその他の方法で利用できる情報。このコンテキストには、イベントのタイムスタンプ、クライアント可視情報（IPアドレスを含む）、およびオリジナル名（発行中に明らかにされた場合）など、発行に関連するすべての情報が含まれます。これには、発行プロトコル中に発行者から秘密にされているため、トークンチャレンジ全体が含まれません。
Attestation context:
証明のコンテキスト：
The interactions and set of information shared between the Client and Attester only, for the purposes of attesting the validity of the Client, that is provided or otherwise available during attestation that might be used to identify the Client. This context includes all information associated with attestation, such as the timestamp of the event and any Client-visible information, including information needed for the attestation procedure to complete.
クライアントの有効性を証明する目的で、クライアントの有効性を証明する目的で、クライアントの妥当性を証明する目的で、クライアントの妥当性を証明する目的で、クライアントの間でのみ共有された情報のセットと、クライアントの識別に使用される可能性のある情報のみとの間で共有されます。このコンテキストには、イベントのタイムスタンプや、認証手順が完了するために必要な情報を含むクライアントに見える情報などの証明に関連するすべての情報が含まれます。
The privacy goals of Privacy Pass assume a threat model in which Origins trust specific Issuers to produce tokens, and Issuers in turn trust one or more Attesters to correctly run the attestation procedure with Clients. This arrangement ensures that tokens that validate for a given Issuer were only issued to a Client that successfully completed attestation with an Attester that the Issuer trusts. Moreover, this arrangement means that if an Origin accepts tokens issued by an Issuer that trusts multiple Attesters, then a Client can use any one of these Attesters to issue and redeem tokens for the Origin. Whether or not these different entities in the architecture collude for learning redemption, issuance, or attestation contexts, as well as the necessary preconditions for context unlinkability, depends on the deployment model; see Section 4 for more details.
プライバシーパスのプライバシー目標は、Originsが特定の発行者を信頼してトークンを生産する脅威モデルを想定しており、発行者は1人以上のアテッターがクライアントとの証明手順を正しく実行することを信頼しています。この取り決めにより、特定の発行者に対して検証するトークンは、発行者が信頼することを避けていることを認めたことに正常に完了したクライアントにのみ発行されることが保証されます。さらに、この取り決めは、原産地が複数のアテスタントを信頼する発行者によって発行されたトークンを受け入れる場合、クライアントはこれらのアテッターのいずれかを使用して、オリジンのトークンを発行および引き換えることができることを意味します。アーキテクチャ内のこれらのさまざまなエンティティが、償還、発行、または証明のコンテキストを学習するために共謀するかどうか、およびコンテキストの非難に必要な前提条件は、展開モデルに依存します。詳細については、セクション4を参照してください。
The mechanisms for establishing trust between each entity in this arrangement are deployment specific. For example, in settings where Clients interact with Issuers through an Attester, Attesters and Issuers might use mutually authenticated TLS to authenticate one another. In settings where Clients do not communicate with Issuers through an Attester, the Attesters might convey this trust via a digital signature that Issuers can verify.
この取り決めで各エンティティ間で信頼を確立するためのメカニズムは、展開固有です。たとえば、クライアントがアテスターを介して発行者とやり取りする設定では、相互に認証されたTLSを使用して相互に認証する場合があります。クライアントがアテスターを介して発行者と通信しない設定では、アッターは、発行者が検証できるデジタル署名を介してこの信頼を伝えるかもしれません。
Clients explicitly trust Attesters to perform attestation correctly and in a way that does not violate their privacy. In particular, this means that Attesters that may be privy to private information about Clients are trusted to not disclose this information to non-colluding parties. Colluding parties are assumed to have access to the same information; see Section 4 for more about different deployment models and non-collusion assumptions. However, Clients assume that Issuers and Origins are malicious.
クライアントは、プライバシーに違反しない方法で、アテアターを明示的に信頼しており、正しく、そして違反しない方法で証明を実行します。特に、これは、クライアントに関する個人情報に違反する可能性のあるエイターズが、この情報を非共謀者に開示しないと信頼されていることを意味します。共謀者は、同じ情報にアクセスできると想定されています。さまざまな展開モデルと非委託の仮定の詳細については、セクション4を参照してください。ただし、クライアントは、発行者と起源が悪意があると想定しています。
Given this threat model, the privacy goals of Privacy Pass are oriented around unlinkability based on redemption, issuance, and attestation contexts, as described below.
この脅威モデルを考えると、プライバシーパスのプライバシー目標は、以下で説明するように、償還、発行、および証明のコンテキストに基づいて、非難に基づいて方向付けられています。
1. Origin-Client unlinkability. This means that given two redemption contexts, the Origin cannot determine if both redemption contexts correspond to the same Client or two different Clients. Informally, this means that a Client in a redemption context is indistinguishable from any other Client that might use the same redemption context. The set of Clients that share the same redemption context is referred to as a redemption anonymity set.
1. 起源の依存性の低い可能性。これは、2つの償還コンテキストを考えると、両方の償還コンテキストが同じクライアントまたは2つの異なるクライアントに対応するかどうかを起源が判断できないことを意味します。非公式には、これは、償還コンテキストのクライアントが、同じ償還のコンテキストを使用する可能性のある他のクライアントと区別できないことを意味します。同じ償還コンテキストを共有するクライアントのセットは、償還匿名セットと呼ばれます。
2. Issuer-Client unlinkability. This is similar to Origin-Client unlinkability in that a Client in an issuance context is indistinguishable from any other Client that might use the same issuance context. The set of Clients that share the same issuance context is referred to as an issuance anonymity set.
2. 発行者クライアントの非難性。これは、発行コンテキスト内のクライアントが同じ発行コンテキストを使用する可能性のある他のクライアントと見分けがつかないという点で、Origin-Clientのリンク可能性に似ています。同じ発行コンテキストを共有するクライアントのセットは、発行匿名性セットと呼ばれます。
3. Attester-Origin unlinkability. This is similar to Origin-Client and Issuer-Client unlinkability. It means that given two attestation contexts, the Attester cannot determine if both contexts correspond to the same Origin or two different Origins. The set of Origins that share the same attestation context is referred to as an attestation anonymity set.
3. astester-originの非難の可能性。これは、Origin-Clientおよび発行者クライアントの非難に似ています。つまり、2つの証明のコンテキストを考えると、Attesterは両方のコンテキストが同じ起源または2つの異なる起源に対応するかどうかを判断できないことを意味します。同じ証明コンテキストを共有する一連の起源は、証明匿名セットと呼ばれます。
4. Redemption context unlinkability. Given two redemption contexts, the Origin cannot determine which issuance and attestation contexts each redemption corresponds to, even with the collaboration of the Issuer and Attester (should these be different parties). This means that any information that may be learned about the Client during the issuance and attestation flows cannot be used by the Origin to compromise Client privacy.
4. 償還のコンテキストの解放可能性。2つの償還のコンテキストを考えると、原点は、発行者と誘惑者のコラボレーションであっても、各償還がどの発行と証明のコンテキストに対応するかを決定することはできません（これらは異なる当事者である場合）。これは、発行および証明フロー中にクライアントについて学習できる情報は、クライアントのプライバシーを妥協するために起源によって使用できないことを意味します。
These unlinkability properties ensure that only the Clients are able to correlate information that might be used to identify them with activity on the Origin. The Attester, Issuer, and Origin only receive the information necessary to perform their respective functions.
これらの非難プロパティにより、クライアントのみが、原点上のアクティビティと識別するために使用される可能性のある情報を相関させることができます。Attester、発行者、および起源は、それぞれの機能を実行するために必要な情報のみを受け取ります。
The manner in which these unlinkability properties are achieved depends on the deployment model, type of attestation, and issuance protocol details. For example, as discussed in Section 4, in some cases it is necessary to use an anonymization service that hides Client IP addresses, such as Tor [DMS2004]. In general, anonymization services ensure that all Clients that use the service are indistinguishable from one another, though in practice there may be small distinguishing features (TLS fingerprints, HTTP headers, etc.). Moreover, Clients generally trust these services to not disclose private Client information (such as IP addresses) to untrusted parties. Failure to use an anonymization service when interacting with Attesters, Issuers, or Origins can allow the set of possible Clients to be partitioned by the Client's IP address and can therefore lead to unlinkability violations. Similarly, malicious Origins may attempt to link two redemption contexts together by using Client-specific Issuer Public Keys. See Sections 5 and 6 for more information.
これらの非難プロパティが達成される方法は、展開モデル、証明の種類、および発行プロトコルの詳細によって異なります。たとえば、セクション4で説明したように、場合によっては、TOR [DMS2004]などのクライアントIPアドレスを隠す匿名化サービスを使用する必要があります。一般に、匿名化サービスは、サービスを使用するすべてのクライアントが互いに区別できないことを保証しますが、実際には、小さな際立った機能（TLS指紋、HTTPヘッダーなど）がある場合があります。さらに、クライアントは一般に、これらのサービスを信頼して、プライベートクライアント情報（IPアドレスなど）を信頼されていない当事者に開示しないことを信頼しています。匿名化サービスを使用しないと、アッター、発行者、またはオリジンとやり取りする場合、可能なクライアントのセットがクライアントのIPアドレスによって分割されるため、非難違反につながる可能性があります。同様に、悪意のある起源は、クライアント固有の発行者パブリックキーを使用して、2つの償還コンテキストを結び付けようとする場合があります。詳細については、セクション5および6を参照してください。
Sections 3.4 and 3.5 describe the functional properties and security requirements of the redemption and issuance protocols in more detail. Section 3.6 describes how information flows between the Issuer, Origin, Client, and Attester through these protocols.
セクション3.4および3.5は、償還および発行プロトコルの機能的特性とセキュリティ要件をより詳細に説明します。セクション3.6では、これらのプロトコルを使用して、発行者、起源、クライアント、および登録者間の情報がどのように流れるかについて説明します。
The Privacy Pass redemption protocol, described in [AUTHSCHEME], is an authorization protocol wherein Clients present tokens to Origins for authorization. Normally, redemption is preceded by a challenge, wherein the Origin challenges Clients for a token with a TokenChallenge ([AUTHSCHEME], Section 2.1) and, if possible, Clients present a valid token ([AUTHSCHEME], Section 2.2) in reaction to the challenge. This interaction is shown below.
[authscheme]に記載されているプライバシーパスredemptionプロトコルは、クライアントが承認のためにトークンを起源に提示する承認プロトコルです。通常、償還の前には課題があります。これにより、OriginはTokenChallenge（[authscheme]、セクション2.1）を使用したトークンにクライアントに挑戦し、可能であれば、クライアントは有効なトークン（[authscheme]、セクション2.2）を提示します。チャレンジ。この相互作用を以下に示します。
+--------+ +--------+
| Origin | | Client |
+---+----+ +---+----+
| |
|<----- Request ------+
+-- TokenChallenge -->|
| | <== Issuance protocol ==>
|<-- Request+Token ---+
| |
Figure 2: Challenge and Redemption Protocol Interaction
図2：課題と償還プロトコルの相互作用
Alternatively, when configured to do so, Clients may opportunistically present token values to Origins without a corresponding TokenChallenge.
あるいは、そうするように構成されている場合、クライアントは、対応するTokenChallengeなしで、日和見的にトークン値を起源に提示する場合があります。
The structure and semantics of the TokenChallenge and token messages depend on the issuance protocol and token type being used; see [AUTHSCHEME] for more information.
TokenChallengeおよびトークンメッセージの構造とセマンティクスは、使用されている発行プロトコルとトークンタイプに依存します。詳細については、[authscheme]を参照してください。
The challenge provides the Client with the information necessary to obtain tokens that the server might subsequently accept in the redemption context. There are a number of ways in which the token may vary based on this challenge, including the following:
この課題は、サーバーがその後償還のコンテキストで受け入れる可能性のあるトークンを取得するために必要な情報をクライアントに提供します。トークンは、以下を含むこの課題に基づいて異なる方法があります。
* Issuance protocol. The challenge identifies the type of issuance protocol required for producing the token. Different issuance protocols have different security properties, e.g., some issuance protocols may produce tokens that are publicly verifiable, whereas others may not have this property.
* 発行プロトコル。この課題は、トークンの生産に必要な発行プロトコルのタイプを特定します。異なる発行プロトコルには異なるセキュリティプロパティがあります。たとえば、一部の発行プロトコルは、公開されているトークンを生成する場合がありますが、他の発行プロトコルはこのプロパティを持っていない場合があります。
* Issuer identity. Token challenges identify which Issuers are trusted for a given issuance protocol. As described in Section 3.3, the choice of Issuer determines the type of Attesters and attestation procedures possible for a token from the specified Issuer, but the Origin does not learn exactly which Attester was used for a given token issuance event.
* 発行者の身元。トークンの課題特定の発行プロトコルに対してどの発行者が信頼されているかを特定します。セクション3.3で説明されているように、発行者の選択により、指定された発行者からのトークンに可能なアテスタントのタイプと認証手順が決定されますが、Originは特定のトークン発行イベントに使用されたアテスターを正確に学習しません。
* Redemption context. Challenges can be bound to a given redemption context, which influences a Client's ability to pre-fetch and cache tokens. For example, an empty redemption context always allows tokens to be issued and redeemed non-interactively, whereas a fresh and random redemption context means that the redeemed token must be issued only after the Client receives the challenge. See Section 2.1.1 of [AUTHSCHEME] for more details.
* 償還のコンテキスト。課題は、特定の償還のコンテキストに縛られる可能性があります。これは、トークンを事前にフェッチしてキャッシュするクライアントの能力に影響を与えます。たとえば、空の償還コンテキストでは常にトークンを発行し、非対話的に償還することができますが、新鮮でランダムな償還のコンテキストは、クライアントがチャレンジを受け取った後にのみ償還されたトークンを発行する必要があることを意味します。詳細については、[authscheme]のセクション2.1.1を参照してください。
* Per-Origin or cross-Origin. Challenges can be constrained to the Origin for which the challenge originated (referred to as per-Origin tokens) or can be used across multiple Origins (referred to as cross-Origin tokens). The set of Origins for which a cross-Origin token is applicable is referred to as the cross-Origin set. Opting into this set is done by explicitly agreeing on the contents of the set. Every Origin in a cross-Origin set, by opting in, agrees to admit tokens for any other Origin in the set. See Section 2.1.1 of [AUTHSCHEME] for more information on how this set is created.
* オリジンごとまたはクロスオリジン。課題は、課題が発生した起源（オリジンごとのトークンと呼ばれる）に制約されるか、複数の起源（クロスオリジントークンと呼ばれる）で使用できます。クロスオリジントークンが適用される起源のセットは、クロスオリジンセットと呼ばれます。このセットへの選択は、セットの内容について明示的に同意することによって行われます。クロスオリジンセットのすべての起源は、オプトインすることにより、セット内の他の起源についてトークンを認めることに同意します。このセットの作成方法の詳細については、[authscheme]のセクション2.1.1を参照してください。
Origins that admit cross-Origin tokens bear some risk of allowing tokens issued for one Origin to be spent in an interaction with another Origin. In particular, cross-Origin tokens issued based on a challenge for one Origin can be redeemed at another Origin in the cross-Origin set, which can make it difficult to regulate token consumption. Depending on the use case, Origins may need to maintain state to track redeemed tokens. For example, Origins that accept cross-Origin tokens across shared redemption contexts SHOULD track which tokens have already been redeemed in those redemption contexts, since these tokens can be issued and then spent multiple times for any such challenge. Note that Clients that redeem the same token to multiple Origins do risk those Origins being able to link Client activity together, which can disincentivize this behavior. See Section 2.1.1 of [AUTHSCHEME] for discussion.
クロスオリジントークンを認める起源は、ある起源に対して発行されたトークンを別の起源との相互作用に費やすことを許可するリスクを負います。特に、1つの起源の課題に基づいて発行されたクロスオリジントークンは、クロスオリジンセットの別の起源で引き換えることができます。これにより、トークン消費の調節が困難になります。ユースケースに応じて、Originsは償還されたトークンを追跡するために状態を維持する必要がある場合があります。たとえば、共有された償還のコンテキスト全体でクロスオリジントークンを受け入れる起源は、これらのトークンを発行し、そのような課題に複数回費やすことができるため、それらの償還のコンテキストですでに引き換えられているトークンを追跡する必要があります。同じトークンを複数の起源に引き換えるクライアントは、クライアントアクティビティを結び付けることができる起源のリスクがあり、この動作を除去できることに注意してください。ディスカッションについては、[authscheme]のセクション2.1.1を参照してください。
How Clients respond to token challenges can have privacy implications. For example, if an Origin allows the Client to choose an Issuer, then the choice of Issuer can reveal information about the Client used to partition anonymity sets; see Section 6.2 for more information about these privacy considerations.
クライアントがトークンの課題にどのように対応するかは、プライバシーに影響を与える可能性があります。たとえば、Originがクライアントが発行者を選択できる場合、発行者の選択は、匿名セットを分割するために使用されるクライアントに関する情報を明らかにすることができます。これらのプライバシーに関する考慮事項の詳細については、セクション6.2を参照してください。
The Privacy Pass issuance protocols, such as those described in [ISSUANCE], are two-message protocols that take as input a TokenChallenge from the redemption protocol ([AUTHSCHEME], Section 2.1) and produce a token ([AUTHSCHEME], Section 2.2), as shown in Figure 1.
[発行]に記載されているようなプライバシーパスの発行プロトコルは、償還プロトコル（[authscheme]、セクション2.1）からトークンチャレンジを入力してトークンを生成し、トークン（[authscheme]、セクション2.2）から入力する2メッセージプロトコルである。、図1に示すように。
The structure and semantics of the TokenRequest and TokenResponse messages depend on the issuance protocol and token type being used; see [ISSUANCE] for more information.
TokenRequestおよびtokenResponseメッセージの構造とセマンティクスは、使用されている発行プロトコルとトークンタイプに依存します。詳細については、[発行]を参照してください。
Clients interact with the Attester and Issuer to produce a token for a challenge. The context in which an Attester vouches for a Client during issuance is referred to as the attestation context. This context includes all information associated with the issuance event, such as the timestamp of the event and Client-visible information, including the IP address or other information specific to the type of attestation done.
クライアントはAttesterと発行者と対話して、挑戦のためにトークンを作成します。Attesterが発行中にクライアントを保証するコンテキストは、証明コンテキストと呼ばれます。このコンテキストには、イベントのタイムスタンプや、IPアドレスや、行われた証明の種類に固有のその他の情報など、発行イベントに関連付けられているすべての情報が含まれます。
Each issuance protocol may be different, e.g., in the number and types of participants, underlying cryptographic constructions used when issuing tokens, and even privacy properties.
各発行プロトコルは、たとえば、参加者の数と種類で、トークンを発行する際に使用される暗号化構造、さらにはプライバシープロパティでさえ異なる場合があります。
Clients initiate the issuance protocol using the token challenge, a randomly generated nonce, and a public key for the Issuer, all of which are the Client's private input to the protocol and ultimately bound to an output token; see Section 2.2 of [AUTHSCHEME] for details. Future specifications may change or extend the Client's input to the issuance protocol to produce tokens with a different structure.
クライアントは、トークンチャレンジ、ランダムに生成されたノンセ、および発行者の公開鍵を使用して発行プロトコルを開始します。これらはすべて、クライアントのプロトコルへのプライベート入力であり、最終的には出力トークンに結合します。詳細については、[authscheme]のセクション2.2を参照してください。将来の仕様は、クライアントの入力を発行プロトコルに変更または拡張して、異なる構造のトークンを生成する場合があります。
Token properties vary based on the issuance protocol. Important properties supported in this architecture are described below.
トークンプロパティは、発行プロトコルによって異なります。このアーキテクチャでサポートされている重要なプロパティを以下に説明します。
1. Public verifiability. This means that the token can be verified using the Issuer Public Key. A token that does not have public verifiability can only be verified using the Issuer secret key.
1. 公共の検証可能性。これは、発行者の公開キーを使用してトークンを検証できることを意味します。公共の検証性を持たないトークンは、発行者のシークレットキーを使用してのみ検証できます。
2. Public metadata. This means that the token can be cryptographically bound to arbitrary public information. See Section 6.1 for privacy considerations regarding public metadata.
2. パブリックメタデータ。これは、トークンを暗号化的にarbitrary意的な公開情報に結びつけることができることを意味します。パブリックメタデータに関するプライバシーに関する考慮事項については、セクション6.1を参照してください。
3. Private metadata. This means that the token can be cryptographically bound to arbitrary private information, i.e., information that the Client does not observe during token issuance or redemption. See Section 6.1 for privacy considerations regarding private metadata.
3. プライベートメタデータ。これは、トークンが任意の個人情報、つまりクライアントがトークン発行または償還中に観察しない情報に暗号化的に結合することができることを意味します。プライベートメタデータに関するプライバシーに関する考慮事項については、セクション6.1を参照してください。
The issuance protocol itself can be any interactive protocol between the Client, Issuer, or other parties that produces a valid token bound to the Client's private input, subject to the following security requirements.
発行プロトコル自体は、クライアント、発行者、またはクライアントのプライベート入力にバインドされた有効なトークンを作成し、以下のセキュリティ要件を条件として、任意のインタラクティブなプロトコルとなる可能性があります。
1. Unconditional input secrecy. The issuance protocol MUST NOT reveal anything about the Client's private input, including the challenge and nonce, to the Attester or Issuer, regardless of the hardness assumptions of the underlying cryptographic protocol(s). This property is sometimes also referred to as blindness.
1. 無条件の入力の秘密。発行プロトコルは、基礎となる暗号化プロトコルの硬度の仮定に関係なく、課題や発行者に、チャレンジや非CEを含むクライアントのプライベート入力について何も明らかにしてはなりません。この特性は、時々失明とも呼ばれます。
2. One-more forgery security. The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens offline or otherwise without interacting with the Issuer directly.
2. 1つの偽造セキュリティ。発行プロトコルは、悪意のあるクライアントまたはアテッター（クライアントとして）を許可してはなりません。
3. Concurrent security. The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients, Attesters, and Issuers.
3. 同時セキュリティ。発行プロトコルは、多くのクライアント、アサイザー、および発行者と同時に同時に実行する必要があります。
See Section 3.5.4 for requirements on new issuance protocol variants and related extensions.
新しい発行プロトコルバリアントおよび関連拡張機能の要件については、セクション3.5.4を参照してください。
In the sections below, we describe the Attester and Issuer roles in more detail.
以下のセクションでは、Attesterと発行者の役割についてさらに詳しく説明します。
In Privacy Pass, attestation is the process by which an Attester bears witness to, confirms, or authenticates a Client so as to verify properties about the Client that are required for issuance. Issuers trust Attesters to perform attestation correctly, i.e., to implement attestation procedures in such a way that those procedures are not subverted or bypassed by malicious Clients.
プライバシーパスでは、Attesterが、発行に必要なクライアントに関するプロパティを確認するために、クライアントを証し、確認、認証するプロセスです。発行者は、アテアターを信頼して、証明を正しく実行すること、つまり、これらの手順が悪意のあるクライアントによって破壊またはバイパスされないように証明手順を実装することを信頼しています。
[RFC9334] describes an architecture for attestation procedures. Using that architecture as a conceptual basis, Clients are RATS Attesters that produce attestation evidence, and Attesters are RATS Verifiers that appraise the validity of attestation evidence.
[RFC9334]は、証明手順のアーキテクチャを説明しています。そのアーキテクチャを概念的根拠として使用すると、クライアントは証拠の証拠を生み出すラットのアテッターであり、証明書の証拠の妥当性を評価するラットの検証因子です。
The type of attestation procedure is a deployment-specific option and outside the scope of the issuance protocol. Example attestation procedures are below.
証明手順のタイプは、展開固有のオプションであり、発行プロトコルの範囲外です。例の実証手順は以下にあります。
* Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be attested to have this capability for the purpose of being ruled out as a bot or otherwise automated Client.
* キャプチャを解く。Captchaの課題を解決するクライアントは、ボットまたはその他の自動化されたクライアントとして除外される目的で、この機能を持つことを証明できます。
* Presenting evidence of Client device validity. Some Clients run on trusted hardware that is capable of producing device-level attestation evidence.
* クライアントデバイスの有効性の証拠を提示します。一部のクライアントは、デバイスレベルの証明の証拠を作成できる信頼できるハードウェアで実行されます。
* Proving properties about Client state. Clients can be associated with state, and the Attester can verify this state. Examples of state include the Client's geographic region and whether the Client has a valid application-layer account.
* クライアント状態に関するプロパティの証明。クライアントは状態に関連付けられ、アテスターはこの状態を検証できます。状態の例には、クライアントの地理的領域と、クライアントが有効なアプリケーション層アカウントを持っているかどうかが含まれます。
Attesters may support different types of attestation procedures.
アッターは、さまざまな種類の証明手順をサポートする場合があります。
Each attestation procedure has different security properties. For example, attesting to having a valid account is different from attesting to running on trusted hardware. Supporting multiple attestation procedures is an important step towards ensuring equitable access for Clients; see Section 5.1.
各証明手順には、セキュリティプロパティが異なります。たとえば、有効なアカウントを持つことを証明することは、信頼できるハードウェアでの実行とは異なる場合があります。複数の証明手順をサポートすることは、クライアントの公平なアクセスを確保するための重要なステップです。セクション5.1を参照してください。
The role of the Attester in the issuance protocol and its impact on privacy depend on the type of attestation procedure, issuance protocol, and deployment model. For instance, increasing the number of required attestation procedures could decrease the overall anonymity set size. As an example, the number of Clients that have solved a CAPTCHA in the past day, that have a valid account, and that are running on a trusted device is less than the number of Clients that have solved a CAPTCHA in the past day. See Section 6.2 for more discussion of how the variety of attestation procedures can negatively impact Client privacy.
発行プロトコルにおけるアテスターの役割とプライバシーへの影響は、証明手順、発行プロトコル、展開モデルの種類に依存します。たとえば、必要な証明手順の数を増やすと、全体的な匿名セットサイズが減少する可能性があります。例として、過去の日にCaptchaを解決し、有効なアカウントを持ち、信頼できるデバイスで実行されているクライアントの数は、過去の日にCaptchaを解決したクライアントの数よりも少ないです。さまざまな証明手順がクライアントのプライバシーにどのように悪影響を与えるかについての詳細については、セクション6.2を参照してください。
Depending on the issuance protocol, the Issuer might learn information about the Origin. To ensure Issuer-Client unlinkability, the Issuer should be unable to link that information to a specific Client. For such issuance protocols where the Attester has access to Client-specific information, such as is the case for attestation procedures that involve Client-specific information (such as application-layer account information) or for deployment models where the Attester learns Client-specific information (such as Client IP addresses), Clients trust the Attester to not share any Client-specific information with the Issuer. In deployments where the Attester does not learn Client-specific information or where the Attester and Issuer are operated by the same entity (such as in the Joint Attester and Issuer model described in Section 4.2), the Client does not need to explicitly trust the Attester in this regard.
発行プロトコルに応じて、発行者は起源に関する情報を学習する場合があります。発行者クライアントの非難性を確保するために、発行者はその情報を特定のクライアントにリンクできないはずです。Attesterがクライアント固有の情報にアクセスできるこのような発行プロトコルについては、クライアント固有の情報（アプリケーションレイヤーアカウント情報など）を含む証明手順、またはAttesterがクライアント固有の情報を学習する展開モデルの場合など、（クライアントIPアドレスなど）、クライアントは、クライアント固有の情報を発行者と共有しないことを避けていると信頼しています。Attesterがクライアント固有の情報を学習しない展開や、Attesterと発行者が同じエンティティ（セクション4.2で説明されている共同Attesterおよび発行者モデルなど）によって運営されている場所では、クライアントはAttesterを明示的に信頼する必要はありません。この点について。
Issuers trust Attesters to correctly and reliably perform attestation. However, certain types of attestation procedures can vary in value over time, e.g., if the attestation procedure is compromised. Broken attestation procedures are considered exceptional events and require configuration changes to address the underlying cause. For example, if an attestation procedure is compromised or subverted because of a zero-day exploit on devices that implement the attestation procedure, then the corresponding attestation procedure should be untrusted until the exploit is patched. Addressing changes in attestation quality is therefore a deployment-specific task. In Split Origin, Attester, and Issuer deployments (see Section 4.4), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched.
発行者は、アテアターを信頼して、正確かつ確実に証明を実行することを信頼しています。ただし、特定のタイプの証明手順は、たとえば、証明手順が妥協された場合、時間の経過とともに価値が異なる場合があります。壊れた証明手順は例外的なイベントと見なされ、根本的な原因に対処するために構成変更が必要です。たとえば、証明手順を実装するデバイスのゼロデイのエクスプロイトのために証明手順が損なわれたり、破壊されたりする場合、エクスプロイトがパッチが適用されるまで、対応する証明手順は信頼されない必要があります。したがって、証明品質の変更に対処することは、展開固有のタスクです。Split Origin、Attester、および発行者の展開（セクション4.4を参照）では、発行者は、妥協点がパッチされるまで、信頼できるセットから侵害されたアテッサーを削除することを選択できます。
From the perspective of an Origin, tokens produced by an Issuer with at least one compromised Attester cannot be trusted, assuming that the Origin does not know which attestation procedure was used for issuance. This is because the Origin cannot distinguish between tokens that were issued via compromised Attesters and tokens that were issued via uncompromised Attesters, absent some distinguishing information in the tokens themselves or from the Issuer. As a result, until the attestation procedure is fixed, the Issuer cannot be trusted by Origins. Moreover, as a consequence, any tokens issued by an Issuer with a compromised Attester may no longer be trusted by Origins, even if those tokens were issued to Clients interacting with an uncompromised Attester.
起源の観点から見ると、少なくとも1人の妥協したアテスターを持つ発行者によって生成されたトークンは、発行にどの証明手順が使用されているかがわからないと仮定して、信頼できません。これは、起源が、妥協したアテッターを介して発行されたトークンと、妥協のないアテッターを介して発行されたトークンを区別できないためです。その結果、証明手順が修正されるまで、発行者はOriginsによって信頼できません。さらに、結果として、発行者が侵害されたアテスターと発行されたトークンは、妥協のない態度と対話するクライアントにそれらのトークンが発行されたとしても、Originsに信頼されなくなる可能性があります。
In Privacy Pass, the Issuer is responsible for completing the issuance protocol for Clients that complete attestation through a trusted Attester. As described in Section 3.5.1, Issuers explicitly trust Attesters to correctly and reliably perform attestation. Origins explicitly trust Issuers to only issue tokens from trusted Attesters. Clients do not explicitly trust Issuers.
プライバシーパスでは、発行者は、信頼できる態度を介して完全に認証されているクライアントの発行プロトコルを完了する責任があります。セクション3.5.1で説明されているように、発行者は、アテアターを明示的に信頼して正しく、確実に証明を実行することを信頼しています。Originsは、信頼できるアテスタントからトークンのみを発行するために発行者を明示的に信頼しています。クライアントは、発行者を明示的に信頼していません。
Depending on the deployment model case, issuance may require some form of Client anonymization service, similar to an IP-hiding proxy, so that Issuers cannot learn information about Clients. This can be provided by an explicit participant in the issuance protocol, or it can be provided via external means, such as through the use of an IP-hiding proxy service like Tor [DMS2004]. In general, Clients SHOULD minimize or remove identifying information where possible when invoking the issuance protocol.
展開モデルのケースに応じて、発行者がクライアントに関する情報を学習できないように、IPハイディングプロキシと同様に、発行が何らかの形のクライアント匿名化サービスを必要とする場合があります。これは、発行プロトコルの明示的な参加者によって提供されるか、TOR [DMS2004]のようなIPハイディングプロキシサービスの使用など、外部手段を介して提供できます。一般に、クライアントは、発行プロトコルを呼び出すときに可能な場合は識別情報を最小化または削除する必要があります。
Issuers are uniquely identifiable by all Clients with a consistent identifier. In a web context, this identifier might be the Issuer hostname. Issuers maintain one or more configurations, including issuance key pairs, for use in the issuance protocol. Each configuration is assumed to have a unique and canonical identifier, sometimes referred to as a key identifier or key ID. Issuers can rotate these configurations as needed to mitigate the risk of compromise; see Section 6.2 for more considerations around configuration rotation. The Issuer Public Key for each active configuration is made available to Origins and Clients for use in the issuance and redemption protocols.
発行者は、一貫した識別子を持つすべてのクライアントが一意に識別できます。Webコンテキストでは、この識別子が発行者のホスト名である可能性があります。発行者は、発行プロトコルで使用するために、発行キーペアを含む1つ以上の構成を維持します。各構成には、キー識別子またはキーIDと呼ばれることもある一意で標準的な識別子があると想定されています。発行者は、必要に応じてこれらの構成を回転させて、妥協のリスクを軽減できます。構成の回転に関する詳細については、セクション6.2を参照してください。各アクティブな構成の発行者の公開キーは、発行および償還プロトコルで使用するためにOriginsとクライアントが利用できるようになります。
Certain instantiations of the issuance protocol may permit public or private metadata to be cryptographically bound to a token. As an example, one trivial way to include public metadata is to assign a unique Issuer Public Key for each value of metadata, such that N keys yield log_2(N) bits of metadata. Metadata may be public or private.
発行プロトコルの特定のインスタンス化により、パブリックまたはプライベートメタデータがトークンに暗号化されていることが許可される場合があります。例として、パブリックメタデータを含める些細な方法の1つは、nキーがメタデータのlog_2（n）ビットを生成するように、メタデータの各値に一意の発行者の公開キーを割り当てることです。メタデータはパブリックまたはプライベートである可能性があります。
Public metadata is metadata that Clients can observe as part of the token issuance flow. Public metadata can be either transparent or opaque. For example, transparent public metadata is a value that either the Client generates itself or the Issuer provides during the issuance flow and that the Client can check for correctness. Opaque public metadata is metadata the Client can see but cannot check for correctness. As an example, the opaque public metadata might be a "fraud detection signal", computed on behalf of the Issuer, during token issuance. Generally speaking, Clients cannot determine if this value is generated in a way that permits tracking.
パブリックメタデータは、クライアントがトークン発行フローの一部として観察できるメタデータです。パブリックメタデータは、透明または不透明です。たとえば、透明なパブリックメタデータは、クライアントがそれ自体を生成するか、発行者が発行フロー中に提供する値であり、クライアントが正しさを確認できる値です。不透明なパブリックメタデータは、クライアントが見ることができるが、正しさを確認することはできないメタデータです。例として、不透明な公共メタデータは、トークン発行中に発行者に代わって計算された「詐欺検出信号」である可能性があります。一般的に言えば、クライアントは、この値が追跡を許可する方法で生成されるかどうかを判断できません。
Private metadata is metadata that Clients cannot observe as part of the token issuance flow. Such instantiations can be built on the private metadata bit construction from Kreuter et al. [KLOR20] or the attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF) from Huang et al. [HIJK21].
プライベートメタデータは、クライアントがトークン発行フローの一部として観察できないメタデータです。このようなインスタンス化は、Kreuter et alからのプライベートメタデータビット構造に基づいて構築できます。[klor20]またはHuang et al。[hijk21]。
Metadata can be arbitrarily long or bounded in length. The amount of permitted metadata may be determined by an application or by the underlying cryptographic protocol. The total amount of metadata bits included in a token is the sum of public and private metadata bits. Every bit of metadata can be used to partition the Client issuance or redemption anonymity sets; see Section 6.1 for more information.
メタデータは、任意に長く、または長さが境界に縛られている場合があります。許可されたメタデータの量は、アプリケーションまたは基礎となる暗号プロトコルによって決定される場合があります。トークンに含まれるメタデータビットの総量は、パブリックおよびプライベートメタデータビットの合計です。すべてのメタデータを使用して、クライアントの発行または償還の匿名性セットを分割できます。詳細については、セクション6.1を参照してください。
The Privacy Pass architecture and ecosystem are both intended to be receptive to extensions that expand the current set of functionalities through new issuance protocols. Each new issuance protocol and extension MUST adhere to the following requirements:
プライバシーパスアーキテクチャとエコシステムはどちらも、新しい発行プロトコルを通じて現在の機能セットを拡張する拡張を受け入れることを目的としています。新しい発行プロトコルと拡張は、次の要件を遵守する必要があります。
1. Include a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on how to use the protocol to mitigate or minimize negative deployment or privacy consequences discussed in Sections 5 and 6, respectively.
1. 拡張機能のプライバシーへの影響、これらの影響が正当化される理由の詳細な分析、およびそれぞれセクション5および6で議論されているネガティブな展開またはプライバシーの結果を緩和または最小化する方法に関するガイドラインを含めます。
2. Adhere to the guidelines specified in Section 3.5.2 for managing Issuer Public Key data.
2. 発行者の公開データを管理するためのセクション3.5.2で指定されたガイドラインを順守します。
3. Clearly specify how to interpret and validate TokenChallenge and token messages that are exchanged during the redemption protocol.
3. 償還プロトコル中に交換されるTokenChallengeおよびトークンメッセージを解釈および検証する方法を明確に指定します。
The end-to-end process of redemption and issuance protocols involves information flowing between the Issuer, Origin, Client, and Attester. That information can have implications on the privacy goals that Privacy Pass aims to provide as outlined in Section 3.3. In this section, we describe the flow of information between each party. How this information affects the privacy goals in particular deployment models is further discussed in Section 4.
償還および発行プロトコルのエンドツーエンドのプロセスには、発行者、起源、クライアント、およびアテスターの間で流れる情報が含まれます。その情報は、プライバシーパスがセクション3.3で概説したとおりに提供することを目的とするプライバシー目標に影響を与えることができます。このセクションでは、各当事者間の情報の流れについて説明します。この情報が特定の展開モデルのプライバシー目標にどのように影響するかについては、セクション4でさらに説明します。
To use Privacy Pass, Origins choose an Issuer from which they are willing to accept tokens. Origins then construct a token challenge using this specified Issuer and information from the redemption context it shares with the Client. This token challenge is then delivered to a Client. The token challenge conveys information about the Issuer and the redemption context, such as whether the Origin desires a per-Origin or cross-Origin token. Any entity that sees the token challenge might learn things about the Client as known to the Origin. This is why input secrecy is a requirement for issuance protocols, as it ensures that the challenge is not directly available to the Issuer.
プライバシーパスを使用するには、Originsがトークンを受け入れる意思のある発行者を選択します。Originsは、この指定された発行者とクライアントと共有する償還コンテキストからの情報を使用して、トークンチャレンジを構築します。このトークンチャレンジは、クライアントに配信されます。トークンチャレンジは、発行者と償還のコンテキストに関する情報を伝えます。トークンチャレンジを見るエンティティは、クライアントについてのことを起源に知られていることを学ぶかもしれません。これが、入力秘密が発行プロトコルの要件である理由です。これは、課題が発行者が直接利用できないことを保証するためです。
Clients interact with the Attester to prove that they meet some required set of properties. In doing so, Clients contribute information to the attestation context, which might include sensitive information such as application-layer identities, IP addresses, and so on. Clients can choose whether or not to contribute this information based on local policy or preference.
クライアントはアテスターと対話して、必要なプロパティのセットを満たしていることを証明します。そうすることで、クライアントは、アプリケーション層のアイデンティティ、IPアドレスなどの機密情報が含まれる場合があることを認証コンテキストに紹介します。クライアントは、ローカルポリシーまたは好みに基づいてこの情報を提供するかどうかを選択できます。
Clients use the issuance protocol to produce a token bound to a token challenge. In doing so, there are several ways in which the issuance protocol contributes information to the attestation or issuance contexts. For example, a token request may contribute information to the attestation or issuance contexts as described below.
クライアントは、発行プロトコルを使用して、トークンチャレンジにバインドされたトークンを作成します。そうすることで、発行プロトコルが証明または発行のコンテキストに情報を提供するいくつかの方法があります。たとえば、トークンリクエストは、以下に説明するように、証明または発行のコンテキストに情報を提供する場合があります。
* Issuance protocol. The type of issuance protocol can contribute information about the Issuer's capabilities to the attestation or issuance contexts, as well as the capabilities of a given Client. For example, if a Client is presented with multiple issuance protocol options, then the choice of which issuance protocol to use can contribute information about the Client's capabilities.
* 発行プロトコル。発行プロトコルの種類は、発行者の能力に関する情報を、特定のクライアントの能力だけでなく、証明または発行のコンテキストにもたらすことができます。たとえば、クライアントに複数の発行プロトコルオプションが提示されている場合、使用する発行プロトコルの選択は、クライアントの機能に関する情報に貢献できます。
* Issuer configuration. Information about the Issuer configuration, such as its identity or the public key used to validate tokens it creates, can be revealed during issuance and contribute to the attestation or issuance contexts.
* 発行者構成。その身元や作成するトークンの検証に使用される公開鍵などの発行者構成に関する情報は、発行中に明らかになり、証明または発行のコンテキストに貢献できます。
* Attestation information. The issuance protocol can contribute information to the attestation or issuance contexts based on what attestation procedure the Issuer uses to trust a token request. In particular, a token request that is validated by a given Attester means that the Client that generated the token request must be capable of completing the designated attestation procedure.
* 証明情報。発行プロトコルは、発行者がトークン要求を信頼するために使用する証明手順に基づいて、証明または発行のコンテキストに情報を提供できます。特に、特定のアテスターによって検証されたトークン要求は、トークン要求を生成したクライアントが指定された証明手順を完了することができなければならないことを意味します。
* Origin information. The issuance protocol can contribute information about the Origin that challenged the Client; see Section 3.6.1. In particular, a token request designated for a specific Issuer might imply that the resulting token is for an Origin that trusts the specified Issuer. However, this is not always true, as some token requests can correspond to cross-Origin tokens, i.e., they are tokens that would be accepted at any Origin that accepts the cross-Origin token.
* 起源情報。発行プロトコルは、クライアントに挑戦した起源に関する情報を提供できます。セクション3.6.1を参照してください。特に、特定の発行者に指定されたトークン要求は、結果のトークンが指定された発行者を信頼する起源であることを暗示する可能性があります。ただし、一部のトークン要求はクロスオリジントークンに対応できるため、これは必ずしも真実ではありません。つまり、クロスオリジントークンを受け入れる原点で受け入れられるトークンです。
Moreover, a token may contribute information to the issuance attestation or contexts as described below.
さらに、トークンは、以下に説明するように、発行またはコンテキストに情報を提供する可能性があります。
* Origin information. The issuance protocol can contribute information about the Origin in how it responds to a token request. For example, if an Issuer learns the Origin during issuance and is also configured to respond in some way on the basis of that information, and the Client interacts with the Issuer transitively through the Attester, that response can reveal information to the Attester.
* 起源情報。発行プロトコルは、トークンリクエストにどのように応答するかについて、起源に関する情報を提供できます。たとえば、発行者が発行中に起源を学習し、その情報に基づいて何らかの方法で応答するように構成されている場合、クライアントはAttesterを介して発行者と交換的に対話することもできます。
* Token. The token produced by the issuance protocol can contain information from the issuance context. In particular, depending on the issuance protocol, tokens can contain public or private metadata, and Issuers can choose that metadata on the basis of information in the issuance context.
* トークン。発行プロトコルによって生成されたトークンには、発行コンテキストからの情報を含めることができます。特に、発行プロトコルに応じて、トークンはパブリックまたはプライベートメタデータを含めることができ、発行者は発行コンテキストの情報に基づいてそのメタデータを選択できます。
Exceptional cases in the issuance protocol, such as when either the Attester or Issuer aborts the protocol, can contribute information to the attestation or issuance contexts. The extent to which information in this context harms the Issuer-Client or Attester-Origin unlinkability goals as discussed in Section 3.3 depends on the deployment model; see Section 4. Clients can choose whether or not to contribute information to these contexts based on local policy or preference.
Attesterまたは発行者のいずれかがプロトコルを中止した場合など、発行プロトコルの例外的なケースは、証明または発行のコンテキストに情報を提供できます。このコンテキストでの情報が、セクション3.3で説明されているように、発行者クライアントまたはアテスターオリジンの非難の目標を損なう程度は、展開モデルに依存します。セクション4を参照してください。クライアントは、ローカルポリシーまたは好みに基づいてこれらのコンテキストに情報を提供するかどうかを選択できます。
Clients send tokens to Origins during the redemption protocol. Any information that is added to the token during issuance can therefore be sent to the Origin. Information can be either (1) explicitly passed in a token or (2) implicit in the way the Client responds to a token challenge. For example, if a Client fails to complete issuance and consequently fails to redeem a token for a token challenge, this can reveal information to the Origin that it might not otherwise have access to. However, an Origin cannot necessarily distinguish between a Client that fails to complete issuance and one that ignores the token challenge altogether.
クライアントは、償還プロトコル中にトークンを起源に送信します。したがって、発行中にトークンに追加された情報は、原点に送信できます。情報は、（1）トークンで明示的に渡されるか、（2）クライアントがトークンチャレンジに応答する方法に暗黙的に渡すことができます。たとえば、クライアントが発行を完了できず、その結果、トークンチャレンジのためにトークンを引き換えることに失敗した場合、これは他の方法ではアクセスできない可能性のある原点に情報を明らかにすることができます。ただし、発行を完了できないクライアントと、トークンチャレンジを完全に無視しているクライアントを必ずしも区別することはできません。
The Origin, Attester, and Issuer portrayed in Figure 1 can be instantiated and deployed in a number of ways. The deployment model directly influences the manner in which attestation, issuance, and redemption contexts are separated to achieve Origin-Client, Issuer-Client, and Attester-Origin unlinkability.
図1に描かれている起源、攻撃者、および発行者は、さまざまな方法でインスタンス化および展開できます。展開モデルは、起源とクライアント、発行者クライアント、およびアテスターオリジンの非難性を実現するために、証明、発行、および償還のコンテキストが分離される方法に直接影響します。
This section covers some expected deployment models and their corresponding security and privacy considerations. Each deployment model is described in terms of the trust relationships and communication patterns between the Client, Attester, Issuer, and Origin. Entities drawn within the same bounding box are assumed to be operated by the same party and are therefore able to collude. Collusion can enable linking of attestation, issuance, and redemption contexts. Entities not drawn within the same bounding box (i.e., operated by separate parties) are assumed to not collude. Mechanisms for enforcing non-collusion are out of scope for this architecture.
このセクションでは、予想される展開モデルとそれに対応するセキュリティおよびプライバシーに関する考慮事項について説明します。各展開モデルは、クライアント、アテスター、発行者、および起源の間の信頼関係とコミュニケーションパターンの観点から説明されています。同じ境界ボックス内で描かれたエンティティは、同じ当事者によって運営されていると想定されているため、共謀することができます。共謀により、認証、発行、および償還のコンテキストのリンクを可能にすることができます。同じ境界ボックス内に描かれていないエンティティ（つまり、別々の当事者によって運営されている）は、共謀しないと想定されています。非委託を強制するためのメカニズムは、このアーキテクチャの範囲外です。
In this model, the Origin, Attester, and Issuer are all operated by the same entity, as shown in Figure 3.
このモデルでは、図3に示すように、起源、Attester、および発行者はすべて同じエンティティによって動作します。
+---------------------------------------------.
+--------+ | +----------+ +--------+ +--------+ |
| Client | | | Attester | | Issuer | | Origin | |
+---+----+ | +-----+----+ +----+---+ +---+----+ |
| `-------|---------------|-------------|------'
|<-------------------------------- TokenChallenge --+
| | | |
|<=== Attestation ===>| | |
| | | |
+----------- TokenRequest ----------->| |
|<---------- TokenResponse -----------+ |
| |
+--------------------- Token ----------------------->
| |
Figure 3: Shared Deployment Model
図3：共有展開モデル
This model represents the initial deployment of Privacy Pass, as described in [PrivacyPassCloudflare]. In this model, the Attester, Issuer, and Origin share the attestation, issuance, and redemption contexts. As a result, attestation mechanisms that can uniquely identify a Client, e.g., requiring that Clients authenticate with some type of application-layer account, are not appropriate, as they could lead to unlinkability violations.
このモデルは、[privacypasscloudflare]に記載されているように、プライバシーパスの初期展開を表します。このモデルでは、Attester、発行者、およびOriginは、証明、発行、および償還のコンテキストを共有しています。その結果、クライアントを一意に識別できる証明メカニズム、たとえば、クライアントが何らかのタイプのアプリケーションレイヤーアカウントで認証することを要求することは、非難違反につながる可能性があるため、適切ではありません。
Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that issuance and redemption events be separated over time, such as through the use of tokens that correspond to token challenges with an empty redemption context (see Section 3.4), or that they be separated over space, such as through the use of an anonymizing service when connecting to the Origin.
Origin-Client、発行者クライアント、およびAttester-Originの非難性には、空の償還コンテキスト（セクション3.4を参照）のトークンチャレンジに対応するトークンの使用など、発行および償還イベントが時間の経過とともに分離される必要があります（セクション3.4を参照）、または原点に接続するときに匿名サービスを使用するなど、スペースを介して分離します。
In this model, the Attester and Issuer are operated by the same entity, separate from the Origin. The Origin trusts the joint Attester and Issuer to perform attestation and issue tokens. Clients interact with the joint Attester and Issuer for attestation and issuance. This arrangement is shown in Figure 4.
このモデルでは、Attesterと発行者は同じエンティティによって動作し、原点とは別のものです。Originは、共同Attesterと発行者を信頼して、証明を実行し、トークンを発行します。クライアントは、ATSETATIONと発行のために、共同Attesterおよび発行者と対話します。この配置を図4に示します。
+------------------------------.
+--------+ | +----------+ +--------+ | +--------+
| Client | | | Attester | | Issuer | | | Origin |
+---+----+ | +-----+----+ +----+---+ | +---+----+
| `-------|---------------|-----' |
|<---------------------------------- TokenChallenge --+
| | | |
|<==== Attestation ====>| | |
| | | |
+------------- TokenRequest ----------->| |
|<----------- TokenResponse ------------+ |
| |
+----------------------- Token ----------------------->
| |
Figure 4: Joint Attester and Issuer Deployment Model
図4：共同攻撃と発行者の展開モデル
This model is useful if an Origin wants to offload attestation and issuance to a trusted entity. In this model, the Attester and Issuer share an attestation and issuance context for the Client, separate from the Origin's redemption context.
このモデルは、オリジンが信頼できるエンティティへの証明と発行をオフロードしたい場合に役立ちます。このモデルでは、Attesterと発行者は、Originの償還コンテキストとは別に、クライアントの証明と発行コンテキストを共有します。
Similar to the shared Origin, Attester, Issuer model, Issuer-Client and Origin-Client unlinkability in this model requires that issuance and redemption events, respectively, be separated over time or space. Attester-Origin unlinkability requires that the Attester and Issuer do not learn the Origin for a particular token request. For this reason, issuance protocols that require the Issuer to learn information about the Origin, such as the issuance protocol described in [RATE-LIMITED], are not appropriate, since they could lead to Attester-Origin unlinkability violations through the Origin name.
共有の起源と同様に、このモデルでのaTtester、発行者モデル、発行者クライアント、および起源とクライアントの非難は、それぞれ発行および償還イベントを時間または空間で分離する必要があります。Attester-Originの非難性には、Attesterと発行者が特定のトークンリクエストの起源を学ばないことが必要です。このため、[レート制限]で説明されている発行プロトコルなど、発行者が原点に関する情報を学習することを必要とする発行プロトコルは、オリジン名を介したアテスターオーリジンリンク率違反につながる可能性があるため、適切ではありません。
In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in Figure 5. The Issuer accepts token requests that come from trusted Attesters. Since the Attester and Issuer are separate entities, this model requires some mechanism by which Issuers establish trust in the Attester (as described in Section 3.3). For example, in settings where the Attester is a Client-trusted service that directly communicates with the Issuer, one way to establish this trust is via mutually authenticated TLS. However, alternative authentication mechanisms are possible. In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below.
このモデルでは、図5に示すように、出身者と発行者は、アテスターとは別の同じエンティティによって運営されています。Attesterと発行者は別々のエンティティであるため、このモデルには、発行者がAttesterに信頼を確立するメカニズムが必要です（セクション3.3で説明されています）。たとえば、Attesterが発行者と直接通信するクライアントに信頼されたサービスである設定では、この信頼を確立する1つの方法は相互に認証されたTLSを介してです。ただし、代替認証メカニズムが可能です。このモデルでは、下の図に示すように、原点と発行者は、アテスターとは別の同じエンティティによって動作します。
+----------------------------.
+--------+ +----------+ | +--------+ +--------+ |
| Client | | Attester | | | Issuer | | Origin | |
+---+----+ +-----+----+ | +----+---+ +---+----+ |
| | `------|-------------|------'
|<-------------------------------- TokenChallenge --+
| | | |
|<=== Attestation ===>| | |
| | | |
+------------ TokenRequest ---------->| |
|<---------- TokenResponse -----------+ |
| |
+--------------------- Token ----------------------->
| |
Figure 5: Joint Origin and Issuer Deployment Model
図5：ジョイント起源と発行者の展開モデル
This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account information, but do not otherwise want to learn information about individual Clients beyond what is observed during the token redemption, such as Client IP addresses.
このモデルは、クライアントを特定することを必要とする起源に役立ちます。たとえば、アプリケーションレイヤーアカウント情報の使用を通じて、クライアントIPアドレスなどのトークン償還中に観察されるものを超えて個々のクライアントに関する情報を学習したくない。
In this model, attestation contexts are separate from Issuer and redemption contexts. As a result, any type of attestation is suitable in this model.
このモデルでは、証明のコンテキストは、発行者と償還のコンテキストとは別のものです。その結果、このモデルではあらゆるタイプの証明が適しています。
Moreover, assuming that there is more than one Origin involved, any type of token challenge is suitable, since no single party will have access to the identifying Client information and unique Origin information. Issuers that produce tokens for a single Origin are not suitable in this model, since an Attester can infer the Origin from a token request, as described in Section 3.6.3. However, since the issuance protocol provides input secrecy, the Attester does not learn details about the corresponding token challenge, such as whether the token challenge is per Origin or across Origins.
さらに、複数の起源が関与していると仮定すると、識別するクライアント情報と一意の起源情報に1人の当事者がアクセスできないため、あらゆる種類のトークンチャレンジが適切です。セクション3.6.3で説明されているように、アテスターはトークン要求から起源を推測できるため、1つの起源のトークンを生成する発行者はこのモデルでは適していません。ただし、発行プロトコルは入力の秘密を提供するため、Attesterは、トークンチャレンジが起源ごとにあるか、起源を越えているかなど、対応するトークンチャレンジに関する詳細を学習しません。
In this model, the Origin, Attester, and Issuer are all operated by different entities. As with the Joint Origin and Issuer model (Section 4.3), the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment depend on the issuance protocol and relationship between the Attester and Issuer; see Section 3.3. This arrangement is shown in Figure 1.
このモデルでは、起源、Attester、および発行者はすべて異なるエンティティによって運営されています。共同起源と発行者モデル（セクション4.3）と同様に、発行者は信頼できるアテッターから生じるトークンリクエストを受け入れ、その信頼施設の詳細は、発行プロトコルと攻撃者と発行者の関係に依存します。セクション3.3を参照してください。この配置を図1に示します。
This is the most general deployment model and is necessary for some types of issuance protocols where the Attester plays a role in token issuance; see [RATE-LIMITED] for one such type of issuance protocol.
これは最も一般的な展開モデルであり、アテスターがトークン発行に役割を果たすいくつかのタイプの発行プロトコルに必要です。このようなタイプの発行プロトコルについては、[レート制限]を参照してください。
In this model, the Attester, Issuer, and Origin have a separate view of the Client: the Attester sees potentially sensitive Client-identifying information, such as account identifiers or IP addresses; the Issuer sees only the information necessary for issuance; and the Origin sees token challenges, corresponding tokens, and Client source information, such as their IP address. As a result, attestation, issuance, and redemption contexts are separate, and therefore any type of token challenge is suitable in this model as long as there is more than a single Origin.
このモデルでは、Attester、発行者、およびOriginはクライアントの個別のビューを持っています。Attesterは、アカウント識別子やIPアドレスなどの潜在的に機密性の高いクライアントを特定する情報を見ています。発行者は、発行に必要な情報のみを見ています。また、Originには、IPアドレスなどのトークンの課題、対応するトークン、およびクライアントソース情報が表示されます。その結果、証明、発行、および償還のコンテキストは別々であるため、1つ以上の起源がある限り、このモデルでは、あらゆるタイプのトークンチャレンジが適切です。
As with the Joint Origin and Issuer model (Section 4.3), and as described in Section 3.6.3, if the Issuer produces tokens for a single Origin, then per-Origin tokens are not appropriate, since the Attester can infer the Origin from a token request.
共同起源と発行者モデル（セクション4.3）、およびセクション3.6.3で説明されているように、発行者が単一の起源に対してトークンを生成する場合、出発者は原点を推測できるため、オーリジンごとのトークンは適切ではありません。トークンリクエスト。
Section 4 discusses deployment models that are possible in practice. Beyond possible implications on security and privacy properties of the resulting system, Privacy Pass deployments can impact the overall ecosystem in two important ways: (1) discriminatory treatment of Clients and the gated access to otherwise open services and (2) centralization. This section describes considerations relevant to these topics.
セクション4では、実際に可能な展開モデルについて説明します。結果として得られるシステムのセキュリティとプライバシーのプロパティに関する可能性のある影響を超えて、プライバシーパスの展開は、2つの重要な方法で全体的なエコシステムに影響を与える可能性があります。このセクションでは、これらのトピックに関連する考慮事項について説明します。
Origins can use tokens as a signal for distinguishing between (1) Clients that are capable of completing attestation with one Attester trusted by the Origin's chosen Issuer and (2) Clients that are not capable of doing the same. A consequence of this is that Privacy Pass could enable discriminatory treatment of Clients based on attestation support. For example, an Origin could only authorize Clients that successfully authenticate with a token, prohibiting access to all other Clients.
Originsは、Originが選択した発行者から信頼されている1人のAttesterと（2）同じことを行うことができないクライアントで証明を完了することができるクライアントを区別するためのシグナルとしてトークンを使用できます。この結果、プライバシーパスにより、認証のサポートに基づいてクライアントの差別的な扱いが可能になる可能性があります。たとえば、Originは、他のすべてのクライアントへのアクセスを禁止するトークンで認証されたクライアントのみを承認できます。
The types of attestation procedures supported for a particular deployment depend greatly on the use case. For example, consider a proprietary deployment of Privacy Pass that authorizes Clients to access a resource such as an anonymization service. In this context, it is reasonable to support specific types of attestation procedures that demonstrate that Clients can access the resource, such as with an account or specific type of device. However, in open deployments of Privacy Pass that are used to safeguard access to otherwise open or publicly accessible resources, diversity in attestation procedures is critically important so as to not discriminate against Clients that choose certain software, hardware, or identity providers.
特定の展開でサポートされる証明手順の種類は、ユースケースに大きく依存します。たとえば、クライアントが匿名化サービスなどのリソースにアクセスすることを許可するプライバシーパスの独自の展開を検討してください。これに関連して、アカウントや特定のタイプのデバイスなど、クライアントがリソースにアクセスできることを示す特定の種類の証明手順をサポートすることが合理的です。ただし、特定のソフトウェア、ハードウェア、またはアイデンティティプロバイダーを選択するクライアントを差別しないために、オープンまたは公開可能なリソースへのアクセスを保護するために使用されるプライバシーパスのオープンな展開では、証明手順の多様性が非常に重要です。
In principle, Issuers should strive to mitigate discriminatory behavior by providing equitable access to all Clients. This can be done by working with a set of Attesters that are suitable for all Clients. In practice, this may require trade-offs in what type of attestation Issuers are willing to trust so as to enable more widespread support. In other words, trusting a variety of Attesters with a diverse set of attestation procedures would presumably increase support among Clients, though most likely at the expense of decreasing the overall value of tokens issued by the Issuer.
原則として、発行者は、すべてのクライアントに公平なアクセスを提供することにより、差別的な行動を軽減するよう努力する必要があります。これは、すべてのクライアントに適した一連のアテッターと協力することで実行できます。実際には、これには、より広範なサポートを可能にするために、どのタイプの証明発行者が信頼することをいとわないかについてのトレードオフが必要になる場合があります。言い換えれば、多様な証明手続きセットでさまざまなアテッターを信頼することは、おそらくクライアント間のサポートを増やすでしょうが、発行者が発行したトークンの全体的な価値を減らすことを犠牲にする可能性が高いでしょう。
For example, to disallow discriminatory behavior between Clients with and without device attestation support, an Issuer may wish to support Attesters that support CAPTCHA-based attestation. This means that the overall attestation value of a Privacy Pass token is bound by the difficulty in spoofing or bypassing either one of these attestation procedures.
たとえば、デバイスの証明サポートの有無にかかわらず、クライアント間の差別的な行動を禁止するために、発行者は、Captchaベースの証明をサポートするアテッターをサポートしたい場合があります。これは、プライバシーパストークンの全体的な証明値が、これらの証明手順のいずれかをスプーフィングまたはバイパスすることの難しさに拘束されることを意味します。
A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization among those participants. [CENTRALIZATION] discusses several ways in which this might be mitigated. For example, a multi-stakeholder governance model could be established to determine what candidate participants are fit to operate as participants in a Privacy Pass deployment. This is precisely the system used to control the Web's trust model.
有意義なプライバシーのためにプライバシーパスの展開に参加者の数を制限した結果は、それらの参加者の間に集中的な集中化を強制することです。[集中化]これが緩和される可能性のあるいくつかの方法について説明します。たとえば、マルチステークホルダーガバナンスモデルを確立して、プライバシーパスの展開の参加者として運営するのに適している候補者の参加者を決定できます。これはまさに、Webの信頼モデルを制御するために使用されるシステムです。
Alternatively, Privacy Pass deployments might mitigate this problem through implementation. For example, rather than centralize the role of attestation in one or a few entities, attestation could be a distributed function performed by a quorum of many parties, provided that neither Issuers nor Origins learn which Attester implementations were chosen. As a result, Clients could have more opportunities to switch between attestation participants.
あるいは、プライバシーパスの展開は、実装を通じてこの問題を軽減する可能性があります。たとえば、1つまたは少数のエンティティにおける証明の役割を集中化するのではなく、発行者もOriginsも、どのアテッターの実装が選択されたかを学習しない限り、多くの当事者によって実行される分散関数である可能性があります。その結果、クライアントは、証明参加者を切り替える機会を増やすことができます。
The previous section discusses the impact of deployment details on Origin-Client, Issuer-Client, and Attester-Origin unlinkability. The value these properties afford to end users depends on the size of anonymity sets in which Clients or Origins are unlinkable. For example, consider two different deployments, one wherein there exists a redemption anonymity set of size two and another wherein there exists a redemption anonymity set of size 2^32. Although Origin-Client unlinkability guarantees that the Origin cannot link any two requests to the same Client based on these contexts, respectively, the smaller these sets become, the higher the probability of determining the "true" Client.
前のセクションでは、展開の詳細が起源とクライアント、発行者クライアント、およびaTter-Originの非難に及ぼす影響について説明します。これらのプロパティがエンドユーザーに提供する価値は、クライアントまたはオリジンがリンクできない匿名セットのサイズに依存します。たとえば、2つの異なる展開を検討します。1つは、サイズ2の償還匿名セットが存在し、もう1つはサイズ2^32の償還匿名セットが存在することを検討します。Origin-Clientの非難は、これらのコンテキストに基づいてそれぞれ2つのリクエストを同じクライアントにリンクすることができないことを保証しますが、これらのセットが小さくなるほど、「真の」クライアントを決定する確率が高くなります。
In practice, there are a number of ways in which the size of anonymity sets may be reduced or partitioned, though they all center around the concept of consistency. In particular, by definition, all Clients in an anonymity set share a consistent view of information needed to run the issuance and redemption protocols. The Issuer Public Key is an example of the type of information needed to run these protocols. When two Clients have inconsistent information, these Clients effectively have different redemption contexts and therefore belong in different anonymity sets.
実際には、匿名セットのサイズを縮小または分割する方法はいくつかありますが、それらはすべて一貫性の概念に集中しています。特に、定義上、匿名セットのすべてのクライアントは、発行および償還プロトコルの実行に必要な情報の一貫したビューを共有します。発行者の公開キーは、これらのプロトコルを実行するために必要な情報の種類の例です。2人のクライアントが一貫性のない情報を持っている場合、これらのクライアントは効果的に異なる償還コンテキストを持っているため、異なる匿名セットに属します。
The following subsections discuss issues that can influence anonymity set size. For each issue, we discuss mitigations or safeguards to protect against the underlying problem.
次のサブセクションでは、匿名のセットサイズに影響を与える可能性のある問題について説明します。各問題について、根本的な問題から保護するための緩和または保護に関する議論について説明します。
Any public or private metadata bits of information can be used to further segment the size of the Client anonymity set. Any Issuer that wanted to track a single Client could add a single metadata bit to Client tokens. For the tracked Client, it would set the bit to 1, and 0 otherwise. Adding additional bits provides an exponential increase in tracking granularity in a manner similar to introducing more Issuers (though with more potential targeting).
パブリックまたはプライベートメタデータの情報を使用して、クライアントの匿名セットのサイズをさらにセグメント化できます。単一のクライアントを追跡したい発行者は、クライアントトークンに単一のメタデータビットを追加できます。追跡されたクライアントの場合、ビットを1に、それ以外の場合は0に設定します。追加のビットを追加すると、より多くの発行者を導入するのと同様の方法で、粒度の追跡が指数関数的に増加します（より潜在的なターゲティングを伴う）。
For this reason, deployments should take the amount of metadata used by an Issuer in creating tokens, together with the bits of information that Issuers may learn about Clients through other means, into account. Since this metadata may be useful for practical deployments of Privacy Pass, Issuers must balance this against the reduction in Client privacy.
このため、展開は、発行者がトークンの作成に使用するメタデータの量と、発行者が他の手段を通じてクライアントについて学習できる情報の断片を考慮に入れる必要があります。このメタデータはプライバシーパスの実際の展開に役立つ可能性があるため、発行者はクライアントのプライバシーの削減とバランスをとる必要があります。
The number of permitted metadata values often depends on deployment-specific details. In general, limiting the amount of metadata permitted helps limit the extent to which metadata can uniquely identify individual Clients. Failure to bound the number of possible metadata values can therefore lead to a reduction in Client privacy. Most token types do not admit any metadata, so this bound is implicitly enforced.
許可されているメタデータ値の数は、多くの場合、展開固有の詳細に依存します。一般に、許可されているメタデータの量を制限することは、メタデータが個々のクライアントを一意に識別できる程度を制限するのに役立ちます。したがって、可能なメタデータ値の数を拘束しないと、クライアントのプライバシーが減少する可能性があります。ほとんどのトークンタイプはメタデータを認めていないため、このバウンドは暗黙的に施行されています。
Anonymity sets can be partitioned by information used for the issuance protocol, including metadata, Issuer configuration (keys), and Issuer selection.
匿名セットは、メタデータ、発行者構成（キー）、発行者の選択を含む発行プロトコルに使用される情報によって分割できます。
Any issuance metadata bits of information can be used to partition the Client anonymity set. For example, any Issuer that wanted to track a single Client could add a single metadata bit to Client tokens. For the tracked Client, it would set the bit to 1, and 0 otherwise. Adding additional bits provides an exponential increase in tracking granularity in a manner similar to introducing more Issuers (though with more potential targeting).
発行メタデータの情報を使用して、クライアントの匿名セットを分割することができます。たとえば、単一のクライアントを追跡したい発行者は、クライアントトークンに単一のメタデータビットを追加できます。追跡されたクライアントの場合、ビットを1に、それ以外の場合は0に設定します。追加のビットを追加すると、より多くの発行者を導入するのと同様の方法で、粒度の追跡が指数関数的に増加します（より潜在的なターゲティングを伴う）。
The number of active Issuer configurations also contributes to anonymity set partitioning. In particular, when an Issuer updates their configuration and the corresponding key pair, any Client that invokes the issuance protocol with this configuration becomes part of a set of Clients that also ran the issuance protocol using the same configuration. Issuer configuration updates, e.g., due to key rotation, are an important part of hedging against long-term private key compromise. In general, key rotations represent a trade-off between Client privacy and Issuer security. Therefore, it is important that key rotations occur on a regular cycle to reduce the harm of an Issuer key compromise.
アクティブな発行者構成の数も、匿名セットのパーティション化に貢献します。特に、発行者が構成と対応するキーペアを更新すると、この構成で発行プロトコルを呼び出すクライアントは、同じ構成を使用して発行プロトコルを実行した一連のクライアントの一部になります。発行者構成の更新は、たとえば、キーローテーションのために、長期的な秘密鍵の妥協に対するヘッジの重要な部分です。一般に、キーローテーションは、クライアントのプライバシーと発行者のセキュリティのトレードオフを表しています。したがって、発行者の重要な妥協の害を減らすために、定期的なサイクルで重要な回転が発生することが重要です。
Lastly, if Clients are willing to issue and redeem tokens from a large number of Issuers for a specific Origin and that Origin accepts tokens from all Issuers, partitioning can occur. As an example, if a Client obtains tokens from many Issuers and an Origin later challenges that Client for a token from each Issuer, the Origin can learn information about the Client. This arrangement might happen if Clients request tokens from different Issuers, each of which has different Attester preferences. Each per-Issuer token that a Client holds essentially corresponds to a bit of information about the Client that the Origin learns. Therefore, there is an exponential loss in privacy relative to the number of Issuers.
最後に、クライアントが特定の起源のために多数の発行者からトークンを発行して引き換えることをいとわない場合、その起源がすべての発行者からトークンを受け入れると、分割が発生する可能性があります。例として、クライアントが多くの発行者からトークンを取得し、その後のオリジンが各発行者からのトークンのクライアントに挑戦する場合、オリジンはクライアントに関する情報を学ぶことができます。クライアントが異なる発行者からトークンを要求する場合、この取り決めが発生する可能性があります。クライアントが保持しているそれぞれの発行者トークンは、本質的に、オリジンが学習するクライアントに関する少しの情報に対応しています。したがって、発行者の数に対するプライバシーの指数関数的な損失があります。
The fundamental problem here is that the number of possible issuance configurations, including the keys in use and the Issuer identities themselves, can partition the Client anonymity set. To mitigate this problem, Clients SHOULD bound the number of active issuance configurations per Origin as well as across Origins. Moreover, Clients SHOULD employ some form of consistency mechanism to ensure that they receive the same configuration information and are not being actively partitioned into smaller anonymity sets. See [CONSISTENCY] for possible consistency mechanisms. Depending on the deployment, the Attester might assist the Client in applying these consistency checks across Clients. Failure to apply a consistency check can allow Client-specific keys to violate Origin-Client unlinkability.
ここでの基本的な問題は、使用中のキーや発行者のアイデンティティ自体を含む可能な発行構成の数が、クライアントの匿名性セットを分割できることです。この問題を軽減するために、クライアントは、起源と起源全体で、アクティブな発行構成の数を削除する必要があります。さらに、クライアントは何らかの形の一貫性メカニズムを採用して、同じ構成情報を受け取り、より小さな匿名セットに積極的に分割されていないことを確認する必要があります。可能な一貫性メカニズムについては[一貫性]を参照してください。展開に応じて、アテスターはクライアントがクライアントにこれらの一貫性チェックを適用するのを支援する可能性があります。一貫性チェックを適用しないと、クライアント固有のキーが起源とクライアントの非難に違反することができます。
Side-channel attacks, such as those based on timing correlation, could be used to reduce anonymity set size. In particular, for interactive tokens that are bound to a Client-specific redemption context, the anonymity set of Clients during the issuance protocol consists of those Clients that started issuance between the time of the Origin's challenge and the corresponding token redemption. Depending on the number of Clients using a particular Issuer during that time window, the set can be small. Applications should take such side channels into consideration before choosing a particular deployment model and type of token challenge and redemption context.
タイミング相関に基づくものなどのサイドチャネル攻撃は、匿名のセットサイズを縮小するために使用できます。特に、クライアント固有の償還のコンテキストに拘束されるインタラクティブなトークンの場合、発行プロトコル中のクライアントの匿名性セットは、Originの課題の時間と対応するトークン償還の間に発行を開始したクライアントで構成されています。その時間ウィンドウ中に特定の発行者を使用するクライアントの数に応じて、セットは小さい場合があります。特定の展開モデルとトークンチャレンジと償還のコンテキストのタイプを選択する前に、アプリケーションはそのようなサイドチャネルを考慮する必要があります。
This document describes security and privacy requirements for the Privacy Pass redemption and issuance protocols. It also describes deployment models built around non-collusion assumptions and privacy considerations for using Privacy Pass within those models. Ensuring Client privacy -- separation of attestation and redemption contexts -- requires active work on behalf of the Client, especially in the presence of malicious Issuers and Origins. Implementing the mitigations discussed in Sections 4 and 6 is therefore necessary to ensure that Privacy Pass offers meaningful privacy improvements to end users.
このドキュメントでは、プライバシーパス償還と発行プロトコルのセキュリティとプライバシーの要件について説明します。また、これらのモデル内でプライバシーパスを使用するための非共謀の仮定とプライバシーに関する考慮事項を中心に構築された展開モデルについても説明しています。クライアントのプライバシーを確保すること - 証明と償還のコンテキストの分離 - は、特に悪意のある発行者と起源の存在下で、クライアントに代わって積極的な作業が必要です。したがって、セクション4および6で説明した軽減を実装することは、プライバシーパスがエンドユーザーに有意義なプライバシーの改善を提供することを保証するために必要です。
Depending on the Origin's token challenge, Clients can request and cache more than one token using an issuance protocol. Cached tokens help improve privacy by separating the time of token issuance from the time of token redemption; they also allow Clients to reduce the overhead of receiving new tokens via the issuance protocol.
Originのトークンチャレンジに応じて、クライアントは発行プロトコルを使用して複数のトークンを要求およびキャッシュできます。キャッシュされたトークンは、トークン発行の時間をトークン償還時に分離することにより、プライバシーを改善するのに役立ちます。また、クライアントは、発行プロトコルを介して新しいトークンを受信するオーバーヘッドを減らすことができます。
As a consequence, Origins that send token challenges that are compatible with cached tokens need to take precautions to ensure that tokens are not replayed. This is typically done via keeping track of tokens that are redeemed for the period of time in which cached tokens would be accepted for particular challenges.
結果として、キャッシュされたトークンと互換性のあるトークンの課題を送信する起源は、トークンが再生されないようにするために予防策を講じる必要があります。これは通常、特定の課題にキャッシュされたトークンが受け入れられる期間にわたって償還されるトークンを追跡することによって行われます。
Moreover, since tokens are not intrinsically bound to Clients, it is possible for malicious Clients to collude and share tokens in a so-called "hoarding attack". As an example of this attack, many distributed Clients could obtain cacheable tokens and then share them with a single Client to redeem the tokens in a way that would violate an Origin's attempt to limit tokens to any one particular Client. In general, mechanisms for mitigating hoarding attacks depend on the deployment model and use case. For example, in the Joint Origin and Issuer model, comparing the issuance and redemption contexts can help detect hoarding attacks, i.e., if the distribution of redemption contexts is noticeably different from the distribution of issuance contexts. Rate-limiting issuance, at either the Client, Attester, or Issuer, can also help mitigate these attacks.
さらに、トークンは本質的にクライアントに縛られていないため、悪意のあるクライアントはいわゆる「買いだめ攻撃」でトークンを共有して共有することができます。この攻撃の例として、多くの分散クライアントがキャッシュ可能なトークンを取得し、1つのクライアントと共有して、トークンを特定のクライアントに制限するオリジンの試みに違反する方法でトークンを引き換えることができます。一般に、買いだめ攻撃を緩和するためのメカニズムは、展開モデルとユースケースに依存します。たとえば、共同起源と発行者モデルでは、発行と償還のコンテキストを比較すると、買いだめ攻撃の検出に役立ちます。つまり、償還コンテキストの分布が発行コンテキストの分布と著しく異なる場合。クライアント、アテスター、または発行者のいずれかでの料金制限発行も、これらの攻撃を軽減するのに役立ちます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[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>.
[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>.
[CENTRALIZATION]
Nottingham, M., "Centralization, Decentralization, and
Internet Standards", RFC 9518, DOI 10.17487/RFC9518,
December 2023, <https://www.rfc-editor.org/info/rfc9518>.
[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>.
[DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", May 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>.
[HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee,
C-K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S.,
Sung, Y-C., and A. Zhang, "DIT: De-Identified
Authenticated Telemetry at Scale", January 2021,
<https://research.fb.com/privatestats>.
[ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood,
"Privacy Pass Issuance Protocols", RFC 9578,
DOI 10.17487/RFC9578, June 2024,
<https://www.rfc-editor.org/info/rfc9578>.
[KLOR20] Kreuter, B., Lepoint, T., Orrù, M., Raykova, M., and
Springer International Publishing, "Anonymous Tokens with
Private Metadata Bit", Advances in Cryptology - CRYPTO
2020, pp. 308-336, DOI 10.1007/978-3-030-56784-2_11, 2020,
<https://doi.org/10.1007/978-3-030-56784-2_11>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/info/rfc9458>.
[PrivacyPassCloudflare]
Sullivan, N., "Cloudflare supports Privacy Pass", November
2017, <https://blog.cloudflare.com/cloudflare-supports-
privacy-pass/>.
[RATE-LIMITED]
Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and
C. A. Wood, "Rate-Limited Token Issuance Protocol", Work
in Progress, Internet-Draft, draft-ietf-privacypass-rate-
limit-tokens-06, 1 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-rate-limit-tokens-06>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
The authors would like to thank Eric Kinnear, Scott Hendrickson, Tommy Pauly, Christopher Patton, Benjamin Schwartz, Martin Thomson, Steven Valdez, and other contributors of the Privacy Pass Working Group for many helpful contributions to this document.
著者は、エリック・キニア、スコット・ヘンドリクソン、トミー・ポーリー、クリストファー・パットン、ベンジャミン・シュワルツ、マーティン・トムソン、スティーブン・バルデス、およびこの文書への多くの有益な貢献について、プライバシーパスワーキンググループのその他の貢献者に感謝したいと思います。
Alex Davidson
NOVA LINCS, Universidade NOVA de Lisboa
Largo da Torre
Caparica
Portugal
Email: alex.davidson92@gmail.com
Jana Iyengar
Fastly
Email: jri@fastly.com
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco, CA 94107
United States of America
Email: caw@heapingbits.net