[要約] RFC 6973は、インターネットプロトコルの設計と開発におけるプライバシーの考慮事項に焦点を当てた文書です。このRFCの目的は、プロトコル設計者がプライバシーを脅かす可能性のある要素を識別し、それらを軽減するためのガイダンスを提供することにあります。利用場面としては、新しいインターネットプロトコルや技術の開発段階で、プライバシーへの影響を評価し、考慮する際に参照されます。関連するRFCには、プライバシーに関連する様々な側面を扱うRFC 7258（Pervasive Monitoringの脅威に関するもの）やRFC 7624（インターネットにおけるプライバシーの考慮事項）などがあります。
Internet Architecture Board (IAB) A. Cooper
Request for Comments: 6973 CDT
Category: Informational H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
B. Aboba
Skype
J. Peterson
NeuStar, Inc.
J. Morris
M. Hansen ULD R. Smith Janet July 2013
M.ハンセンULD R.スミスジャネット2013年7月
Privacy Considerations for Internet Protocols
インターネットプロトコルのプライバシーに関する考慮事項
Abstract
概要
This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.
このドキュメントは、プロトコル仕様に含めるためのプライバシーの考慮事項を開発するためのガイダンスを提供します。これは、インターネットプロトコルの設計者、実装者、およびユーザーがプライバシー関連の設計の選択を認識できるようにすることを目的としています。個々のRFCが特定のプライバシーに関する考慮事項を保証するかどうかは、ドキュメントのコンテンツに依存することを示唆しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6973.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6973で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Scope of Privacy Implications of Internet Protocols .............5
3. Terminology .....................................................6
3.1. Entities ...................................................7
3.2. Data and Analysis ..........................................8
3.3. Identifiability ............................................9
4. Communications Model ...........................................10
5. Privacy Threats ................................................12
5.1. Combined Security-Privacy Threats .........................13
5.1.1. Surveillance .......................................13
5.1.2. Stored Data Compromise .............................14
5.1.3. Intrusion ..........................................14
5.1.4. Misattribution .....................................14
5.2. Privacy-Specific Threats ..................................15
5.2.1. Correlation ........................................15
5.2.2. Identification .....................................16
5.2.3. Secondary Use ......................................16
5.2.4. Disclosure .........................................17
5.2.5. Exclusion ..........................................17
6. Threat Mitigations .............................................18
6.1. Data Minimization .........................................18
6.1.1. Anonymity ..........................................19
6.1.2. Pseudonymity .......................................20
6.1.3. Identity Confidentiality ...........................20
6.1.4. Data Minimization within Identity Management .......21
6.2. User Participation ........................................21
6.3. Security ..................................................22
7. Guidelines .....................................................23
7.1. Data Minimization .........................................24
7.2. User Participation ........................................25
7.3. Security ..................................................25
7.4. General ...................................................26
8. Example ........................................................26
9. Security Considerations ........................................31
10. Acknowledgements ..............................................31
11. IAB Members at the Time of Approval ...........................32
12. Informative References ........................................32
[RFC3552] provides detailed guidance to protocol designers about both how to consider security as part of protocol design and how to inform readers of protocol specifications about security issues. This document intends to provide a similar set of guidelines for considering privacy in protocol design.
[RFC3552]は、プロトコル設計の一部としてセキュリティを検討する方法と、セキュリティの問題についてプロトコル仕様を読者に通知する方法の両方について、プロトコル設計者に詳細なガイダンスを提供します。このドキュメントは、プロトコル設計でプライバシーを考慮するための同様のガイドラインのセットを提供することを目的としています。
Privacy is a complicated concept with a rich history that spans many disciplines. With regard to data, often it is a concept applied to "personal data", commonly defined as information relating to an identified or identifiable individual. Many sets of privacy principles and privacy design frameworks have been developed in different forums over the years. These include the Fair Information Practices [FIPs], a baseline set of privacy protections pertaining to the collection and use of personal data (often based on the principles established in [OECD], for example), and the Privacy by Design concept, which provides high-level privacy guidance for systems design (see [PbD] for one example). The guidance provided in this document is inspired by this prior work, but it aims to be more concrete, pointing protocol designers to specific engineering choices that can impact the privacy of the individuals that make use of Internet protocols.
プライバシーは、多くの分野にまたがる豊富な歴史を持つ複雑な概念です。データに関しては、多くの場合、「個人データ」に適用される概念であり、一般に、識別された、または識別可能な個人に関する情報として定義されます。プライバシー原則とプライバシー設計フレームワークの多くのセットは、長年にわたってさまざまなフォーラムで開発されてきました。これらには、公正情報慣行[FIP]、個人データの収集と使用に関連するプライバシー保護のベースラインセット（多くの場合[OECD]で確立された原則に基づくなど）、およびプライバシーに関する設計コンセプトが含まれます。システム設計の高レベルのプライバシーガイダンス（1つの例については[PbD]を参照）。このドキュメントで提供されるガイダンスは、この以前の作業に触発されたものですが、インターネットプロトコルを使用する個人のプライバシーに影響を与える可能性がある特定のエンジニアリングの選択をプロトコル設計者に示す、より具体的なものにすることを目的としています。
Different people have radically different conceptions of what privacy means, both in general and as it relates to them personally [Westin]. Furthermore, privacy as a legal concept is understood differently in different jurisdictions. The guidance provided in this document is generic and can be used to inform the design of any protocol to be used anywhere in the world, without reference to specific legal frameworks.
プライバシーの意味については、人々によって考え方が根本的に異なります。プライバシーの意味については、一般的にも、個人的には[Westin]と関連しています。さらに、法的概念としてのプライバシーは、管轄区域によって理解が異なります。このドキュメントで提供されるガイダンスは一般的なものであり、特定の法的枠組みを参照することなく、世界中のどこででも使用されるプロトコルの設計を通知するために使用できます。
Whether any individual document warrants a specific privacy considerations section will depend on the document's content. Documents whose entire focus is privacy may not merit a separate section (for example, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks" [RFC3325]). For certain specifications, privacy considerations are a subset of security considerations and can be discussed explicitly in the security considerations section. Some documents will not require discussion of privacy considerations (for example, "Definition of the Opus Audio Codec" [RFC6716]). The guidance provided here can and should be used to assess the privacy considerations of protocol, architectural, and operational specifications and to decide whether those considerations are to be documented in a stand-alone section, within the security considerations section, or throughout the document. The guidance provided here is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a privacy considerations section.
個々のドキュメントが特定のプライバシーに関する考慮事項を保証するかどうかは、ドキュメントのコンテンツによって異なります。プライバシーに重点が置かれているドキュメントは、別のセクション（たとえば、「信頼されたネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」[RFC3325]）に値しない場合があります。特定の仕様では、プライバシーの考慮事項はセキュリティの考慮事項のサブセットであり、セキュリティの考慮事項のセクションで明示的に説明できます。一部のドキュメントでは、プライバシーに関する考慮事項の説明は必要ありません（たとえば、 "Opusオーディオコーデックの定義" [RFC6716]）。ここで提供されるガイダンスは、プロトコル、アーキテクチャ、および運用仕様のプライバシーに関する考慮事項を評価し、それらの考慮事項をスタンドアロンセクション、セキュリティに関する考慮事項セクション、またはドキュメント全体のいずれに文書化するかを決定するために使用できます。ここで提供されるガイダンスは、プライバシー分析の思考プロセスを支援することを目的としています。プライバシーに関する考慮事項セクションの記述方法についての具体的な指示は提供していません。
This document is organized as follows. Section 2 describes the extent to which the guidance offered here is applicable within the IETF and within the larger Internet community. Section 3 explains the terminology used in this document. Section 4 reviews typical communications architectures to understand at which points there may be privacy threats. Section 5 discusses threats to privacy as they apply to Internet protocols. Section 6 outlines mitigations of those threats. Section 7 provides the guidelines for analyzing and documenting privacy considerations within IETF specifications. Section 8 examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework.
このドキュメントは次のように構成されています。セクション2では、ここで提供されるガイダンスがIETF内およびより大きなインターネットコミュニティ内で適用される範囲について説明します。セクション3では、このドキュメントで使用されている用語について説明します。セクション4では、プライバシーの脅威が存在する可能性がある時点を理解するために、一般的な通信アーキテクチャを確認します。セクション5では、インターネットプロトコルに適用されるプライバシーに対する脅威について説明します。セクション6では、これらの脅威の緩和策の概要を説明します。セクション7は、IETF仕様内のプライバシーに関する考慮事項を分析および文書化するためのガイドラインを提供します。セクション8では、IETFプロトコルのプライバシー特性を調べて、ガイダンスフレームワークの使用法を示します。
Internet protocols are often built flexibly, making them useful in a variety of architectures, contexts, and deployment scenarios without requiring significant interdependency between disparately designed components. Although protocol designers often have a particular target architecture or set of architectures in mind at design time, it is not uncommon for architectural frameworks to develop later, after implementations exist and have been deployed in combination with other protocols or components to form complete systems.
多くの場合、インターネットプロトコルは柔軟に構築されているため、さまざまに設計されたコンポーネント間の相互依存を必要とせずに、さまざまなアーキテクチャ、コンテキスト、および展開シナリオで役立ちます。プロトコル設計者は、設計時に特定のターゲットアーキテクチャまたは一連のアーキテクチャを念頭に置いていることがよくありますが、実装が存在し、他のプロトコルまたはコンポーネントと組み合わせて展開されて完全なシステムを形成した後、アーキテクチャフレームワークが後で開発されることも珍しくありません。
As a consequence, the extent to which protocol designers can foresee all of the privacy implications of a particular protocol at design time is limited. An individual protocol may be relatively benign on its own, and it may make use of privacy and security features at lower layers of the protocol stack (Internet Protocol Security, Transport Layer Security, and so forth) to mitigate the risk of attack. But when deployed within a larger system or used in a way not envisioned at design time, its use may create new privacy risks. Protocols are often implemented and deployed long after design time by different people than those who did the protocol design. The guidelines in Section 7 ask protocol designers to consider how their protocols are expected to interact with systems and information that exist outside the protocol bounds, but not to imagine every possible deployment scenario.
その結果、プロトコル設計者が設計時に特定のプロトコルのプライバシーへの影響をすべて予測できる範囲は限られています。個々のプロトコルは、それ自体では比較的無害であり、プロトコルスタックの下位層（インターネットプロトコルセキュリティ、トランスポート層セキュリティなど）でプライバシーとセキュリティ機能を利用して、攻撃のリスクを軽減します。ただし、大規模なシステム内に配置したり、設計時に想定されていなかった方法で使用したりすると、その使用によって新しいプライバシーリスクが生じる可能性があります。プロトコルは、多くの場合、プロトコルの設計を行った人とは別の人によって、設計時間のかなり後に実装および展開されます。セクション7のガイドラインでは、プロトコルの設計者に、プロトコルがプロトコルの境界外にあるシステムや情報とどのように相互作用することが期待されるかを検討するよう求めていますが、考えられるすべての展開シナリオを想像する必要はありません。
Furthermore, in many cases the privacy properties of a system are dependent upon the complete system design where various protocols are combined together to form a product solution; the implementation, which includes the user interface design; and operational deployment practices, including default privacy settings and security processes of the company doing the deployment. These details are specific to particular instantiations and generally outside the scope of the work conducted in the IETF. The guidance provided here may be useful in making choices about these details, but its primary aim is to assist with the design, implementation, and operation of protocols.
さらに、多くの場合、システムのプライバシープロパティは、さまざまなプロトコルを組み合わせて製品ソリューションを形成する完全なシステム設計に依存しています。ユーザーインターフェイスの設計を含む実装。展開を行う企業のデフォルトのプライバシー設定とセキュリティプロセスを含む運用展開の実践。これらの詳細は特定のインスタンス化に固有であり、一般にIETFで行われた作業の範囲外です。ここで提供されるガイダンスは、これらの詳細についての選択に役立つ可能性がありますが、その主な目的は、プロトコルの設計、実装、および操作を支援することです。
Transparency of data collection and use -- often effectuated through user interface design -- is normally relied on (whether rightly or wrongly) as a key factor in determining the privacy impact of a system. Although most IETF activities do not involve standardizing user interfaces or user-facing communications, in some cases, understanding expected user interactions can be important for protocol design. Unexpected user behavior may have an adverse impact on security and/or privacy.
データの収集と使用の透明性（ユーザーインターフェイスの設計を通じて実施されることが多い）は、通常、システムのプライバシーへの影響を判断する際の重要な要素として（正当かどうかに関係なく）信頼されています。ほとんどのIETFアクティビティには、ユーザーインターフェイスやユーザー向け通信の標準化は含まれていませんが、場合によっては、予期されるユーザーインタラクションを理解することがプロトコル設計にとって重要になることがあります。ユーザーの予期しない動作は、セキュリティやプライバシーに悪影響を与える可能性があります。
In sum, privacy issues, even those related to protocol development, go beyond the technical guidance discussed herein. As an example, consider HTTP [RFC2616], which was designed to allow the exchange of arbitrary data. A complete analysis of the privacy considerations for uses of HTTP might include what type of data is exchanged, how this data is stored, and how it is processed. Hence the analysis for an individual's static personal web page would be different than the use of HTTP for exchanging health records. A protocol designer working on HTTP extensions (such as Web Distributed Authoring and Versioning (WebDAV) [RFC4918]) is not expected to describe the privacy risks derived from all possible usage scenarios, but rather the privacy properties specific to the extensions and any particular uses of the extensions that are expected and foreseen at design time.
要するに、プライバシーの問題は、プロトコル開発に関連するものでさえ、ここで説明する技術的なガイダンスを超えています。例として、任意のデータの交換を可能にするように設計されたHTTP [RFC2616]を考えます。 HTTPの使用に関するプライバシーの考慮事項の完全な分析には、交換されるデータのタイプ、このデータの保管方法、およびデータの処理方法が含まれる場合があります。したがって、個人の静的な個人用Webページの分析は、ヘルスレコードの交換にHTTPを使用する場合とは異なります。 HTTP拡張（Web分散オーサリングとバージョン管理（WebDAV）[RFC4918]など）に取り組んでいるプロトコル設計者は、考えられるすべての使用シナリオから派生するプライバシーリスクを説明するのではなく、拡張と特定の使用に固有のプライバシープロパティを説明することが期待されます設計時に予測され、予測される拡張機能の
This section defines basic terms used in this document, with references to pre-existing definitions as appropriate. As in [RFC4949], each entry is preceded by a dollar sign ($) and a space for automated searching. Note that this document does not try to attempt to define the term 'privacy' with a brief definition. Instead, privacy is the sum of what is contained in this document. We therefore follow the approach taken by [RFC3552]. Examples of several different brief definitions are provided in [RFC4949].
このセクションでは、このドキュメントで使用される基本的な用語を定義し、必要に応じて既存の定義を参照します。 [RFC4949]と同様に、各エントリの前にはドル記号（$）と自動検索用のスペースが付いています。このドキュメントは、「プライバシー」という用語を簡単な定義で定義しようとするものではないことに注意してください。代わりに、プライバシーはこのドキュメントに含まれているものの合計です。したがって、[RFC3552]が採用するアプローチに従います。いくつかの異なる簡単な定義の例が[RFC4949]で提供されています。
Several of these terms are further elaborated in Section 4.
これらの用語のいくつかは、セクション4でさらに詳しく説明されています。
$ Attacker: An entity that works against one or more privacy protection goals. Unlike observers, attackers' behavior is unauthorized.
$攻撃者：1つ以上のプライバシー保護目標に反して働くエンティティ。オブザーバーとは異なり、攻撃者の行動は不正です。
$ Eavesdropper: A type of attacker that passively observes an initiator's communications without the initiator's knowledge or authorization. See [RFC4949].
$盗聴者：イニシエーターの知識や許可なしにイニシエーターの通信を受動的に監視する攻撃者の一種。 [RFC4949]を参照してください。
$ Enabler: A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path.
$イネーブラー：直接通信パスにいなくても、開始者と受信者の間の通信を容易にするプロトコルエンティティ。
$ Individual: A human being.
$個人：人間。
$ Initiator: A protocol entity that initiates communications with a recipient.
$ Initiator：受信者との通信を開始するプロトコルエンティティ。
$ Intermediary: A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate. Unlike an eavesdropper, an intermediary is an entity that is part of the communication architecture and therefore at least tacitly authorized. For example, a SIP [RFC3261] proxy is an intermediary in the SIP architecture.
$仲介：開始者と受信者の間に位置し、開始者と受信者が通信するために必要なプロトコルエンティティ。盗聴者とは異なり、仲介者は通信アーキテクチャの一部であり、したがって暗黙のうちに許可されたエンティティです。たとえば、SIP [RFC3261]プロキシはSIPアーキテクチャの仲介者です。
$ Observer: An entity that is able to observe and collect information from communications, potentially posing privacy threats, depending on the context. As defined in this document, initiators, recipients, intermediaries, and enablers can all be observers. Observers are distinguished from eavesdroppers by being at least tacitly authorized.
$オブザーバー：通信に応じて情報を監視および収集でき、状況によってはプライバシーの脅威をもたらす可能性のあるエンティティ。このドキュメントで定義されているように、開始者、受信者、仲介者、およびイネーブラはすべてオブザーバになることができます。オブザーバーは、少なくとも暗黙のうちに許可されることにより、盗聴者と区別されます。
$ Recipient: A protocol entity that receives communications from an initiator.
$受信者：イニシエーターからの通信を受信するプロトコルエンティティ。
$ Attack: An intentional act by which an entity attempts to violate an individual's privacy. See [RFC4949].
$攻撃：エンティティが個人のプライバシーを侵害しようとする意図的な行為。 [RFC4949]を参照してください。
$ Correlation: The combination of various pieces of information that relate to an individual or that obtain that characteristic when combined.
$相関：個人に関連する、または組み合わせたときにその特性を取得するさまざまな情報の組み合わせ。
$ Fingerprint: A set of information elements that identifies a device or application instance.
$指紋：デバイスまたはアプリケーションのインスタンスを識別する情報要素のセット。
$ Fingerprinting: The process of an observer or attacker uniquely identifying (with a sufficiently high probability) a device or application instance based on multiple information elements communicated to the observer or attacker. See [EFF].
$フィンガープリント：オブザーバーまたは攻撃者に伝達された複数の情報要素に基づいて、デバイスまたはアプリケーションインスタンスを（十分に高い確率で）一意に識別するオブザーバーまたは攻撃者のプロセス。 [EFF]を参照してください。
$ Item of Interest (IOI): Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, identities, communications content, and the fact that a communication interaction has taken place.
$関心のあるアイテム（IOI）：オブザーバーまたは攻撃者が関心を持つ可能性のあるデータアイテム。これには、属性、識別子、ID、通信コンテンツ、および通信の相互作用が行われたという事実が含まれます。
$ Personal Data: Any information relating to an individual who can be identified, directly or indirectly.
$個人データ：直接的または間接的に識別できる個人に関するあらゆる情報。
$ (Protocol) Interaction: A unit of communication within a particular protocol. A single interaction may be comprised of a single message between an initiator and recipient or multiple messages, depending on the protocol.
$（プロトコル）インタラクション：特定のプロトコル内の通信の単位。単一の対話は、プロトコルに応じて、開始者と受信者の間の単一のメッセージまたは複数のメッセージで構成されます。
$ Traffic Analysis: The inference of information from observation of traffic flows (presence, absence, amount, direction, timing, packet size, packet composition, and/or frequency), even if flows are encrypted. See [RFC4949].
$トラフィック分析：フローが暗号化されている場合でも、トラフィックフロー（存在、不在、量、方向、タイミング、パケットサイズ、パケット構成、および/または頻度）の観測からの情報の推論。 [RFC4949]を参照してください。
$ Undetectability: The inability of an observer or attacker to sufficiently distinguish whether an item of interest exists or not.
$検出不能：オブザーバーまたは攻撃者が関心のあるアイテムが存在するかどうかを十分に区別できないこと。
$ Unlinkability: Within a particular set of information, the inability of an observer or attacker to distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker).
$リンク不可：特定の情報セット内で、オブザーバーまたは攻撃者が2つの関心のあるアイテムが関連しているかどうかを区別できない（オブザーバーまたは攻撃者にとって有用である可能性が十分に高い確率で）。
$ Anonymity: The state of being anonymous.
$匿名性：匿名であることの状態。
$ Anonymity Set: A set of individuals that have the same attributes, making them indistinguishable from each other from the perspective of a particular attacker or observer.
$匿名セット：同じ属性を持つ個人のセットであり、特定の攻撃者または監視者の観点から、それらを互いに区別できなくします。
$ Anonymous: A state of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set).
$匿名：オブザーバーまたは攻撃者が他の個人のセット（匿名セット）内の個人を識別できない個人の状態。
$ Attribute: A property of an individual.
$属性：個人のプロパティ。
$ Identifiability: The extent to which an individual is identifiable.
$識別可能性：個人が識別可能な範囲。
$ Identifiable: A property in which an individual's identity is capable of being known to an observer or attacker.
$識別可能：オブザーバーまたは攻撃者が個人の身元を知ることができるプロパティ。
$ Identification: The linking of information to a particular individual to infer an individual's identity or to allow the inference of an individual's identity in some context.
$識別：特定の個人に情報をリンクして、個人のアイデンティティを推測したり、特定のコンテキストで個人のアイデンティティを推測できるようにします。
$ Identified: A state in which an individual's identity is known.
$ Identified：個人のアイデンティティが知られている状態。
$ Identifier: A data object uniquely referring to a specific identity of a protocol entity or individual in some context. See [RFC4949]. Identifiers can be based upon natural names -- official names, personal names, and/or nicknames -- or can be artificial (for example, x9z32vb). However, identifiers are by definition unique within their context of use, while natural names are often not unique.
$識別子：特定のコンテキストでプロトコルエンティティまたは個人の特定のIDを一意に参照するデータオブジェクト。 [RFC4949]を参照してください。識別子は、正式名、個人名、ニックネームなどの自然名に基づくことも、人工的なもの（たとえば、x9z32vb）にすることもできます。ただし、自然名は多くの場合一意ではありませんが、識別子は定義上、使用のコンテキスト内で一意です。
$ Identity: Any subset of an individual's attributes, including names, that identifies the individual within a given context. Individuals usually have multiple identities for use in different contexts.
$ Identity：特定のコンテキスト内で個人を識別する、名前を含む個人の属性のサブセット。個人は通常、異なるコンテキストで使用するために複数のIDを持っています。
$ Identity Confidentiality: A property of an individual where only the recipient can sufficiently identify the individual within a set of other individuals. This can be a desirable property of authentication protocols.
$アイデンティティ機密性：受信者だけが他の個人のセット内で個人を十分に識別できる個人の特性。これは、認証プロトコルの望ましい特性になり得ます。
$ Identity Provider: An entity (usually an organization) that is responsible for establishing, maintaining, securing, and vouching for the identities associated with individuals.
$ IDプロバイダー：個人に関連付けられたIDの確立、維持、保護、保証を担当するエンティティ（通常は組織）。
$ Official Name: A personal name for an individual that is registered in some official context (for example, the name on an individual's birth certificate). Official names are often not unique.
$正式名：何らかの正式なコンテキストで登録されている個人の個人名（たとえば、個人の出生証明書の名前）。多くの場合、正式名称は一意ではありません。
$ Personal Name: A natural name for an individual. Personal names are often not unique and often comprise given names in combination with a family name. An individual may have multiple personal names at any time and over a lifetime, including official names. From a technological perspective, it cannot always be determined whether a given reference to an individual is, or is based upon, the individual's personal name(s) (see Pseudonym).
$個人名：個人の自然な名前。多くの場合、個人名は一意ではなく、姓と姓の組み合わせで構成されます。個人は、正式な名前を含め、いつでも一生にわたって複数の個人名を持つことができます。技術的な観点から、特定の個人への言及が個人の個人名であるか、または個人名に基づいているかどうかを常に判断できるわけではありません（仮名を参照）。
$ Pseudonym: A name assumed by an individual in some context, unrelated to the individual's personal names known by others in that context, with an intent of not revealing the individual's identities associated with his or her other names. Pseudonyms are often not unique.
$仮名：あるコンテキストで個人が想定する名前で、そのコンテキストで他の人が知っている個人の個人名とは無関係であり、他の名前に関連付けられている個人の身元を明らかにしないことを目的としています。多くの場合、仮名は一意ではありません。
$ Pseudonymity: The state of being pseudonymous.
$偽名：偽名である状態。
$ Pseudonymous: A property of an individual in which the individual is identified by a pseudonym.
$偽名：個人が偽名で識別される個人のプロパティ。
$ Real Name: See Personal Name and Official Name.
$実名：個人名と正式名を参照してください。
$ Relying Party: An entity that relies on assertions of individuals' identities from identity providers in order to provide services to individuals. In effect, the relying party delegates aspects of identity management to the identity provider(s). Such delegation requires protocol exchanges, trust, and a common understanding of semantics of information exchanged between the relying party and the identity provider.
$証明書利用者：個人にサービスを提供するために、アイデンティティプロバイダーからの個人のアイデンティティのアサーションに依存するエンティティ。実際には、証明書利用者はID管理の側面をIDプロバイダーに委任します。このような委任には、プロトコルの交換、信頼、および証明書利用者とIDプロバイダーの間で交換される情報のセマンティクスの共通理解が必要です。
To understand attacks in the privacy-harm sense, it is helpful to consider the overall communication architecture and different actors' roles within it. Consider a protocol entity, the "initiator", that initiates communication with some recipient. Privacy analysis is most relevant for protocols with use cases in which the initiator acts on behalf of an individual (or different individuals at different times). It is this individual whose privacy is potentially threatened (although in some instances an initiator communicates information about another individual, in which case both of their privacy interests will be implicated).
プライバシー侵害の意味での攻撃を理解するには、全体的な通信アーキテクチャと、その中でのさまざまなアクターの役割を検討することが役立ちます。ある受信者との通信を開始する「開始者」というプロトコルエンティティを考えてみましょう。プライバシー分析は、イニシエーターが個人（または別の時間に別の個人）の代わりに機能するユースケースを持つプロトコルに最も関連しています。プライバシーが脅かされる可能性があるのはこの個人です（場合によっては、開始者が別の個人に関する情報を通信しますが、その場合、両方のプライバシーの利害が関係します）。
Communications may be direct between the initiator and the recipient, or they may involve an application-layer intermediary (such as a proxy, cache, or relay) that is necessary for the two parties to communicate. In some cases, this intermediary stays in the communication path for the entire duration of the communication; sometimes it is only used for communication establishment, for either inbound or outbound communication. In some cases, there may be a series of intermediaries that are traversed. At lower layers, additional entities involved in packet forwarding may interfere with privacy protection goals as well.
通信は、開始者と受信者の間で直接行われる場合もあれば、2つのパーティが通信するために必要なアプリケーション層の仲介（プロキシ、キャッシュ、リレーなど）を伴う場合もあります。場合によっては、この仲介者は通信の期間全体にわたって通信パスに留まります。場合によっては、インバウンドまたはアウトバウンド通信のいずれかの通信確立にのみ使用されます。場合によっては、トラバースされる一連の仲介者が存在することがあります。下位層では、パケット転送に関与する追加のエンティティもプライバシー保護の目標に干渉する可能性があります。
Some communications tasks require multiple protocol interactions with different entities. For example, a request to an HTTP server may be preceded by an interaction between the initiator and an Authentication, Authorization, and Accounting (AAA) server for network access and to a Domain Name System (DNS) server for name resolution. In this case, the HTTP server is the recipient and the other entities are enablers of the initiator-to-recipient communication. Similarly, a single communication with the recipient might generate further protocol interactions between either the initiator or the recipient and other entities, and the roles of the entities might change with each interaction. For example, an HTTP request might trigger interactions with an authentication server or with other resource servers wherein the recipient becomes an initiator in those later interactions.
一部の通信タスクでは、異なるエンティティとの複数のプロトコルの相互作用が必要です。たとえば、HTTPサーバーへの要求の前に、ネットワークアクセスの場合はイニシエーターと認証、承認、およびアカウンティング（AAA）サーバー間の相互作用、名前解決の場合はドメインネームシステム（DNS）サーバーへの相互作用があります。この場合、HTTPサーバーが受信者であり、他のエンティティは開始者から受信者への通信のイネーブラーです。同様に、受信者との単一の通信により、開始者または受信者と他のエンティティーとの間にプロトコルの相互作用がさらに発生し、エンティティーの役割が相互作用ごとに変わる可能性があります。たとえば、HTTP要求は、認証サーバーまたは他のリソースサーバーとの対話をトリガーする可能性があり、受信者はその後の対話でイニシエーターになります。
Thus, when conducting privacy analysis of an architecture that involves multiple communications phases, the entities involved may take on different -- or opposing -- roles from a privacy considerations perspective in each phase. Understanding the privacy implications of the architecture as a whole may require a separate analysis of each phase.
したがって、複数の通信フェーズが含まれるアーキテクチャのプライバシー分析を実施する場合、関係するエンティティは、各フェーズのプライバシーに関する考慮事項の観点から、異なる、または反対の役割を果たす可能性があります。アーキテクチャ全体のプライバシーへの影響を理解するには、各フェーズの個別の分析が必要になる場合があります。
Protocol design is often predicated on the notion that recipients, intermediaries, and enablers are assumed to be authorized to receive and handle data from initiators. As [RFC3552] explains, "we assume that the end systems engaging in a protocol exchange have not themselves been compromised". However, privacy analysis requires questioning this assumption, since systems are often compromised for the purpose of obtaining personal data.
プロトコルの設計は、多くの場合、受信者、仲介者、およびイネーブラがイニシエータからのデータの受信および処理を許可されていると見なされるという概念に基づいています。 [RFC3552]が説明しているように、「プロトコル交換に従事しているエンドシステム自体は危険にさらされていないと想定しています」。ただし、個人データを取得する目的でシステムが侵害されることが多いため、プライバシー分析ではこの仮定に疑問を投げかける必要があります。
Although recipients, intermediaries, and enablers may not generally be considered as attackers, they may all pose privacy threats (depending on the context) because they are able to observe, collect, process, and transfer privacy-relevant data. These entities are collectively described below as "observers" to distinguish them from traditional attackers. From a privacy perspective, one important type of attacker is an eavesdropper: an entity that passively observes the initiator's communications without the initiator's knowledge or authorization.
受信者、仲介者、およびイネーブラは一般に攻撃者とは見なされませんが、プライバシーに関連するデータを監視、収集、処理、および転送できるため、すべてがコンテキストに応じてプライバシーを脅かす可能性があります。これらのエンティティは、従来の攻撃者と区別するために、以下「監視者」と総称して説明されています。プライバシーの観点から、攻撃者の重要なタイプの1つは盗聴者です。つまり、開始者の知識や許可なしに、開始者の通信を受動的に監視するエンティティです。
The threat descriptions in the next section explain how observers and attackers might act to harm individuals' privacy. Different kinds of attacks may be feasible at different points in the communications path. For example, an observer could mount surveillance or identification attacks between the initiator and intermediary, or instead could surveil an enabler (e.g., by observing DNS queries from the initiator).
次のセクションの脅威の説明では、オブザーバーと攻撃者が個人のプライバシーを侵害するためにどのように行動するかを説明しています。通信パスのさまざまなポイントで、さまざまな種類の攻撃が実行される可能性があります。たとえば、オブザーバーは、イニシエーターと仲介者の間に監視または識別攻撃を仕掛けるか、イネーブラーを監視できます（たとえば、イニシエーターからのDNSクエリを監視することによって）。
Privacy harms come in a number of forms, including harms to financial standing, reputation, solitude, autonomy, and safety. A victim of identity theft or blackmail, for example, may suffer a financial loss as a result. Reputational harm can occur when disclosure of information about an individual, whether true or false, subjects that individual to stigma, embarrassment, or loss of personal dignity. Intrusion or interruption of an individual's life or activities can harm the individual's ability to be left alone. When individuals or their activities are monitored, exposed, or at risk of exposure, those individuals may be stifled from expressing themselves, associating with others, and generally conducting their lives freely. They may also feel a general sense of unease, in that it is "creepy" to be monitored or to have data collected about them. In cases where such monitoring is for the purpose of stalking or violence (for example, monitoring communications to or from a domestic abuse shelter), it can put individuals in physical danger.
プライバシーへの危害には、財務状況、評判、孤独、自律性、安全への危害など、さまざまな形があります。たとえば、個人情報の盗難や恐喝の被害者は、結果として経済的損失を被る可能性があります。評判上の危害は、個人に関する情報の開示が真実であろうと偽であろうと、その個人にスティグマ、恥ずかしさ、または個人の尊厳の喪失をもたらす場合に発生する可能性があります。個人の生活または活動への侵入または妨害は、個人が放っておく能力を損なう可能性があります。個人またはその活動が監視、曝露、または曝露のリスクがある場合、それらの個人は、自分を表現したり、他の人と関わったり、一般的に自由に生活したりすることができなくなります。また、監視したり、データを収集したりするのが「気味が悪い」という一般的な不安を感じるかもしれません。そのような監視がストーカー行為や暴力を目的とする場合（たとえば、家庭内暴力シェルターとの間の通信の監視）、個人を物理的に危険にさらす可能性があります。
This section lists common privacy threats (drawing liberally from [Solove], as well as [CoE]), showing how each of them may cause individuals to incur privacy harms and providing examples of how these threats can exist on the Internet. This threat modeling is inspired by security threat analysis. Although it is not a perfect fit for assessing privacy risks in Internet protocols and systems, no better methodology has been developed to date.
このセクションでは、一般的なプライバシーの脅威（[Solove]と[CoE]から自由に引用）をリストし、それぞれがどのようにして個人にプライバシーの害を及ぼす可能性があるかを示し、これらの脅威がインターネット上にどのように存在するかの例を示します。この脅威のモデリングは、セキュリティの脅威分析に触発されています。これは、インターネットプロトコルおよびシステムのプライバシーリスクを評価するのに最適ではありませんが、これまでのところ、より優れた方法論は開発されていません。
Some privacy threats are already considered in Internet protocols as a matter of routine security analysis. Others are more pure privacy threats that existing security considerations do not usually address. The threats described here are divided into those that may also be considered security threats and those that are primarily privacy threats.
一部のプライバシーの脅威は、日常的なセキュリティ分析の問題として、インターネットプロトコルですでに考慮されています。その他は、既存のセキュリティの考慮事項では通常は対処されない、より純粋なプライバシーの脅威です。ここで説明する脅威は、セキュリティの脅威と見なされる脅威と、主にプライバシーの脅威に分類されます。
Note that an individual's awareness of and consent to the practices described below may change an individual's perception of and concern for the extent to which they threaten privacy. If an individual authorizes surveillance of his own activities, for example, the individual may be able to take actions to mitigate the harms associated with it or may consider the risk of harm to be tolerable.
以下に説明する慣行に対する個人の認識と同意は、プライバシーに対する脅威の程度に対する個人の認識と懸念を変える可能性があることに注意してください。たとえば、個人が自分の活動の監視を許可した場合、その個人は、それに関連する危害を軽減するための措置を講じることができるか、危害のリスクを許容できると見なすことができます。
Surveillance is the observation or monitoring of an individual's communications or activities. The effects of surveillance on the individual can range from anxiety and discomfort to behavioral changes such as inhibition and self-censorship, and even to the perpetration of violence against the individual. The individual need not be aware of the surveillance for it to impact his or her privacy -- the possibility of surveillance may be enough to harm individual autonomy.
監視は、個人のコミュニケーションまたは活動の観察または監視です。個人に対する監視の影響は、不安や不快感から、抑制や自己検閲などの行動の変化、さらには個人に対する暴力の蔓延までさまざまです。個人は、自分のプライバシーに影響を与えるために監視を認識する必要はありません。監視の可能性は、個人の自律性を損なうのに十分かもしれません。
Surveillance can impact privacy, even if the individuals being surveilled are not identifiable or if their communications are encrypted. For example, an observer or eavesdropper that conducts traffic analysis may be able to determine what type of traffic is present (real-time communications or bulk file transfers, for example) or which protocols are in use, even if the observed communications are encrypted or the communicants are unidentifiable. This kind of surveillance can adversely impact the individuals involved by causing them to become targets for further investigation or enforcement activities. It may also enable attacks that are specific to the protocol, such as redirection to a specialized interception point or protocol-specific denials of service. Protocols that use predictable packet sizes or timing or include fixed tokens at predictable offsets within a packet can facilitate this kind of surveillance.
監視対象の個人が識別できない場合や、通信が暗号化されている場合でも、監視はプライバシーに影響を与える可能性があります。たとえば、トラフィック分析を行うオブザーバーまたは盗聴者は、観察された通信が暗号化されている場合でも、使用されているトラフィックのタイプ（リアルタイム通信やバルクファイル転送など）または使用中のプロトコルを特定できる場合があります。コミュニカントは識別できません。この種の監視は、関係する個人をさらなる調査または執行活動の標的にすることにより、個人に悪影響を与える可能性があります。また、特殊な傍受ポイントへのリダイレクトやプロトコル固有のサービス拒否など、プロトコル固有の攻撃を可能にする可能性もあります。予測可能なパケットサイズやタイミングを使用したり、パケット内の予測可能なオフセットに固定トークンを含めたりするプロトコルは、この種の監視を容易にします。
Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. Confidentiality protections (as discussed in Section 3 of [RFC3552]) are necessary to prevent surveillance of the content of communications. To prevent traffic analysis or other surveillance of communications patterns, other measures may be necessary, such as [Tor].
監視は、通信経路に沿った任意の場所で監視者または盗聴者が行うことができます。 （[RFC3552]のセクション3で説明されているように）機密保護は、通信内容の監視を防ぐために必要です。トラフィック分析やその他の通信パターンの監視を防ぐために、[Tor]などの他の対策が必要になる場合があります。
End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access expose individuals to potential financial, reputational, or physical harm.
保存されたデータを不正または不適切なアクセスから保護するための適切な対策を講じていないエンドシステムは、個人を潜在的な金銭的、評判的、または物理的な危害にさらします。
Protecting against stored data compromise is typically outside the scope of IETF protocols. However, a number of common protocol functions -- key management, access control, or operational logging, for example -- require the storage of data about initiators of communications. When requiring or recommending that information about initiators or their communications be stored or logged by end systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize the potential for that information to be compromised and for that potential to be weighed against the benefits of data storage. Any recipient, intermediary, or enabler that stores data may be vulnerable to compromise. (Note that stored data compromise is distinct from purposeful disclosure, which is discussed in Section 5.2.4.)
保存されたデータの侵害に対する保護は、通常、IETFプロトコルの範囲外です。ただし、多くの一般的なプロトコル機能（キー管理、アクセス制御、操作ログなど）では、通信の開始者に関するデータの保存が必要です。イニシエータまたはその通信に関する情報をエンドシステムで保存または記録することを要求または推奨する場合（たとえば、RFC 6302 [RFC6302]を参照）、その情報が危険にさらされる可能性と、その可能性が考慮される可能性を認識することが重要です。データストレージの利点に反する。データを保存する受信者、仲介者、またはイネーブラーは、セキュリティ侵害を受ける可能性があります。 （保存されたデータの侵害は、セクション5.2.4で説明されている意図的な開示とは異なります。）
Intrusion consists of invasive acts that disturb or interrupt one's life or activities. Intrusion can thwart individuals' desires to be left alone, sap their time or attention, or interrupt their activities. This threat is focused on intrusion into one's life rather than direct intrusion into one's communications. The latter is captured in Section 5.1.1.
侵入は、自分の生活や活動を妨害したり妨害したりする侵略的な行為で構成されています。侵入は、一人にされたいという個人の欲求を妨害し、彼らの時間や注意を失い、あるいは彼らの活動を妨害する可能性があります。この脅威は、通信に直接侵入するのではなく、生活に侵入することに焦点を当てています。後者はセクション5.1.1でキャプチャされます。
Unsolicited messages and denial-of-service attacks are the most common types of intrusion on the Internet. Intrusion can be perpetrated by any attacker that is capable of sending unwanted traffic to the initiator.
未承諾メッセージとサービス拒否攻撃は、インターネットへの侵入の最も一般的なタイプです。侵入は、不要なトラフィックをイニシエーターに送信できるすべての攻撃者によって実行される可能性があります。
Misattribution occurs when data or communications related to one individual are attributed to another. Misattribution can result in adverse reputational, financial, or other consequences for individuals that are misidentified.
誤配は、ある個人に関連するデータまたは通信が別の個人に起因する場合に発生します。誤認は、誤認された個人に不利な評判、財務、またはその他の結果をもたらす可能性があります。
Misattribution in the protocol context comes as a result of using inadequate or insecure forms of identity or authentication, and is sometimes related to spoofing. For example, as [RFC6269] notes, abuse mitigation is often conducted on the basis of the source IP address, such that connections from individual IP addresses may be prevented or temporarily blacklisted if abusive activity is determined to be sourced from those addresses. However, in the case where a single IP address is shared by multiple individuals, those penalties may be suffered by all individuals sharing the address, even if they were not involved in the abuse. This threat can be mitigated by using identity management mechanisms with proper forms of authentication (ideally with cryptographic properties) so that actions can be attributed uniquely to an individual to provide the basis for accountability without generating false positives.
プロトコルコンテキストの誤配分は、IDまたは認証の不適切または安全でない形式を使用した結果として発生し、スプーフィングに関連している場合があります。たとえば、[RFC6269]が注記しているように、不正行為の軽減は送信元IPアドレスに基づいて行われることが多く、個々のIPアドレスからの接続は防止されるか、それらのアドレスから悪用されていると判断された場合は一時的にブラックリストに登録されます。ただし、1つのIPアドレスが複数の個人によって共有されている場合、たとえ悪用に関わっていなくても、アドレスを共有しているすべての個人がこれらのペナルティを受ける可能性があります。この脅威は、適切な認証形式（理想的には暗号化プロパティ）を備えたID管理メカニズムを使用して軽減できるため、アクションを個人に一意に起因させて、誤検知を生成せずにアカウンタビリティの基礎を提供できます。
Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined. Correlation can defy people's expectations of the limits of what others know about them. It can increase the power that those doing the correlating have over individuals as well as correlators' ability to pass judgment, threatening individual autonomy and reputation.
相関とは、個人に関連するさまざまな情報の組み合わせ、または組み合わせたときにその特性を取得することです。相関関係は、他人が自分について知っていることの限界についての人々の期待に反する可能性があります。これは、相関を行う人々が個人に対して持つ力と、判断を下す相関者の能力を高め、個人の自律性と評判を脅かします。
Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing individuals' activities to be tracked and combined over time. The use of persistent or infrequently replaced identifiers at any layer of the stack can facilitate correlation. For example, an initiator's persistent use of the same device ID, certificate, or email address across multiple interactions could allow recipients (and observers) to correlate all of the initiator's communications over time.
相関は識別と密接に関連しています。インターネットプロトコルは、個人の活動を追跡し、時間の経過とともに結合できるようにすることで、関連付けを容易にします。スタックの任意の層で永続的または頻繁に置換されない識別子を使用すると、相関が容易になります。たとえば、イニシエーターが複数の対話にわたって同じデバイスID、証明書、または電子メールアドレスを永続的に使用すると、受信者（およびオブザーバー）がすべてのイニシエーターの通信を経時的に関連付けることができます。
As an example, consider Transport Layer Security (TLS) session resumption [RFC5246] or TLS session resumption without server-side state [RFC5077]. In RFC 5246 [RFC5246], a server provides the client with a session_id in the ServerHello message and caches the master_secret for later exchanges. When the client initiates a new connection with the server, it re-uses the previously obtained session_id in its ClientHello message. The server agrees to resume the session by using the same session_id and the previously stored master_secret for the generation of the TLS Record Layer security association. RFC 5077 [RFC5077] borrows from the session resumption design idea, but the server encapsulates all state information into a ticket instead of caching it. An attacker who is able to observe the protocol exchanges between the TLS client and the TLS server is able to link the initial exchange to subsequently resumed TLS sessions when the session_id and the ticket are exchanged in the clear (which is the case with data exchanged in the initial handshake messages).
例として、トランスポート層セキュリティ（TLS）セッションの再開[RFC5246]またはサーバー側の状態なしのTLSセッションの再開[RFC5077]を検討してください。 RFC 5246 [RFC5246]では、サーバーはクライアントにServerHelloメッセージのsession_idを提供し、後で交換するためにmaster_secretをキャッシュします。クライアントがサーバーとの新しい接続を開始すると、以前に取得したsession_idをClientHelloメッセージで再利用します。サーバーは、TLS Record Layerセキュリティアソシエーションの生成に同じsession_idと以前に保存されたmaster_secretを使用してセッションを再開することに同意します。 RFC 5077 [RFC5077]はセッション再開設計のアイデアを取り入れていますが、サーバーはすべての状態情報をキャッシュするのではなく、チケットにカプセル化します。 TLSクライアントとTLSサーバー間のプロトコル交換を監視できる攻撃者は、session_idとチケットがクリアテキストで交換されるときに、最初の交換をその後再開されたTLSセッションにリンクすることができます（データ交換の場合）最初のハンドシェイクメッセージ）。
In theory, any observer or attacker that receives an initiator's communications can engage in correlation. The extent of the potential for correlation will depend on what data the entity receives from the initiator and has access to otherwise. Often, intermediaries only require a small amount of information for message routing and/or security. In theory, protocol mechanisms could ensure that end-to-end information is not made accessible to these entities, but in practice the difficulty of deploying end-to-end security procedures, additional messaging or computational overhead, and other business or legal requirements often slow or prevent the deployment of end-to-end security mechanisms, giving intermediaries greater exposure to initiators' data than is strictly necessary from a technical point of view.
理論的には、イニシエーターの通信を受信するオブザーバーまたは攻撃者は、相関に関与できます。相関の可能性の程度は、エンティティがイニシエーターから受信し、他の方法でアクセスできるデータによって異なります。多くの場合、仲介者はメッセージのルーティングやセキュリティのために少量の情報しか必要としません。理論的には、プロトコルメカニズムにより、エンドツーエンドの情報にこれらのエンティティからアクセスできないようにすることができますが、実際には、エンドツーエンドのセキュリティ手順、追加のメッセージングまたは計算オーバーヘッド、およびその他のビジネス要件や法的要件を展開することの難しさエンドツーエンドのセキュリティメカニズムの展開を遅らせたり、防止したりして、技術的な観点から厳密に必要な場合よりも仲介者がイニシエーターのデータにさらされる機会を増やします。
Identification is the linking of information to a particular individual to infer an individual's identity or to allow the inference of an individual's identity. In some contexts, it is perfectly legitimate to identify individuals, whereas in others, identification may potentially stifle individuals' activities or expression by inhibiting their ability to be anonymous or pseudonymous. Identification also makes it easier for individuals to be explicitly controlled by others (e.g., governments) and to be treated differentially compared to other individuals.
識別とは、特定の個人に情報をリンクして、個人のアイデンティティを推測したり、個人のアイデンティティを推測できるようにすることです。個人を特定することは完全に正当な場合もありますが、匿名または偽名になる能力を阻害することにより、個人の活動や表現を阻害する可能性もあります。識別により、個人が他の人（政府など）によって明示的に制御され、他の個人と比較して差別的に扱われることも容易になります。
Many protocols provide functionality to convey the idea that some means has been provided to validate that entities are who they claim to be. Often, this is accomplished with cryptographic authentication. Furthermore, many protocol identifiers, such as those used in SIP or the Extensible Messaging and Presence Protocol (XMPP), may allow for the direct identification of individuals. Protocol identifiers may also contribute indirectly to identification via correlation. For example, a web site that does not directly authenticate users may be able to match its HTTP header logs with logs from another site that does authenticate users, rendering users on the first site identifiable.
多くのプロトコルは、エンティティーが本人であると主張する人物であることを検証するためにいくつかの手段が提供されているという考えを伝える機能を提供します。多くの場合、これは暗号化認証で行われます。さらに、SIPやExtensible Messaging and Presence Protocol（XMPP）で使用されているものなど、多くのプロトコル識別子により、個人を直接識別することができます。プロトコル識別子は、相関を介した識別に間接的に寄与する場合もあります。たとえば、ユーザーを直接認証しないWebサイトは、HTTPヘッダーログを、ユーザーを認証する別のサイトのログと照合して、最初のサイトのユーザーを識別可能にすることができます。
As with correlation, any observer or attacker may be able to engage in identification, depending on the information about the initiator that is available via the protocol mechanism or other channels.
相関関係と同様に、プロトコルメカニズムまたは他のチャネルを介して利用できるイニシエーターに関する情報によっては、任意のオブザーバーまたは攻撃者が識別に従事できる場合があります。
Secondary use is the use of collected information about an individual without the individual's consent for a purpose different from that for which the information was collected. Secondary use may violate people's expectations or desires. The potential for secondary use can generate uncertainty as to how one's information will be used in the future, potentially discouraging information exchange in the first place. Secondary use encompasses any use of data, including disclosure.
二次利用とは、個人の同意を得ずに収集した情報を、情報を収集した目的とは異なる目的で使用することです。二次利用は、人々の期待や欲望に反する可能性があります。二次利用の可能性は、自分の情報が将来どのように使用されるかについて不確実性を生み出し、そもそも情報交換を妨げる可能性があります。二次利用には、開示を含むデータのあらゆる利用が含まれます。
One example of secondary use would be an authentication server that uses a network access server's Access-Requests to track an initiator's location. Any observer or attacker could potentially make unwanted secondary uses of initiators' data. Protecting against secondary use is typically outside the scope of IETF protocols.
二次使用の一例は、イニシエーターの場所を追跡するためにネットワークアクセスサーバーのアクセス要求を使用する認証サーバーです。オブザーバーまたは攻撃者は、イニシエーターのデータを不要に二次利用する可能性があります。通常、二次使用からの保護はIETFプロトコルの範囲外です。
Disclosure is the revelation of information about an individual that affects the way others judge the individual. Disclosure can violate individuals' expectations of the confidentiality of the data they share. The threat of disclosure may deter people from engaging in certain activities for fear of reputational harm, or simply because they do not wish to be observed.
開示とは、他人が個人を判断する方法に影響を与える個人に関する情報の暴露です。開示は、共有するデータの機密性に対する個人の期待に違反する可能性があります。情報開示の脅威は、評判への危害を恐れて、または単に見られたくないという理由で人々が特定の活動に従事することを妨げるかもしれません。
Any observer or attacker that receives data about an initiator may engage in disclosure. Sometimes disclosure is unintentional because system designers do not realize that information being exchanged relates to individuals. The most common way for protocols to limit disclosure is by providing access control mechanisms (discussed in Section 5.2.5). A further example is provided by the IETF geolocation privacy architecture [RFC6280], which supports a way for users to express a preference that their location information not be disclosed beyond the intended recipient.
イニシエーターに関するデータを受信するオブザーバーまたは攻撃者は、開示に関与する可能性があります。交換される情報が個人に関連していることをシステム設計者が認識していないため、開示が意図的でない場合があります。プロトコルが開示を制限する最も一般的な方法は、アクセス制御メカニズムを提供することです（セクション5.2.5で説明）。さらなる例は、IETFジオロケーションプライバシーアーキテクチャ[RFC6280]によって提供されます。これは、ユーザーが自分の位置情報を意図した受信者以外には公開しないという好みを表現する方法をサポートします。
Exclusion is the failure to allow individuals to know about the data that others have about them and to participate in its handling and use. Exclusion reduces accountability on the part of entities that maintain information about people and creates a sense of vulnerability in relation to individuals' ability to control how information about them is collected and used.
除外は、個人が他の人が持っているデータについて知ることができず、その取り扱いと使用に参加できないことです。除外は、人々に関する情報を維持するエンティティの責任を軽減し、個人に関する情報の収集方法と使用方法を制御する個人の能力に関連して脆弱性を生み出します。
The most common way for Internet protocols to be involved in enforcing exclusion is through access control mechanisms. The presence architecture developed in the IETF is a good example where individuals are included in the control of information about them. Using a rules expression language (e.g., presence authorization rules [RFC5025]), presence clients can authorize the specific conditions under which their presence information may be shared.
インターネットプロトコルが除外の実施に関与する最も一般的な方法は、アクセス制御メカニズムを使用することです。 IETFで開発されたプレゼンスアーキテクチャは、個人がそれらに関する情報の制御に含まれる良い例です。ルール式言語（たとえば、プレゼンス承認ルール[RFC5025]）を使用して、プレゼンスクライアントは、プレゼンス情報を共有できる特定の条件を承認できます。
Exclusion is primarily considered problematic when the recipient fails to involve the initiator in decisions about data collection, handling, and use. Eavesdroppers engage in exclusion by their very nature, since their data collection and handling practices are covert.
除外は、受信者がデータの収集、処理、および使用に関する決定に開始者を関与させることができない場合、主に問題があると見なされます。盗聴者は、データの収集と取り扱いの慣行が隠されているため、その性質上、排除されます。
Privacy is notoriously difficult to measure and quantify. The extent to which a particular protocol, system, or architecture "protects" or "enhances" privacy is dependent on a large number of factors relating to its design, use, and potential misuse. However, there are certain widely recognized classes of mitigations against the threats discussed in Section 5. This section describes three categories of relevant mitigations: (1) data minimization, (2) user participation, and (3) security. The privacy mitigations described in this section can loosely be mapped to existing privacy principles, such as the Fair Information Practices, but they have been adapted to fit the target audience of this document.
プライバシーの測定と定量化は非常に困難です。特定のプロトコル、システム、またはアーキテクチャがプライバシーを「保護」または「強化」する程度は、その設計、使用、および潜在的な誤用に関連する多数の要因に依存します。ただし、セクション5で説明した脅威に対する広く認識されている特定の緩和策のクラスがあります。このセクションでは、関連する緩和策の3つのカテゴリについて説明します。（1）データの最小化、（2）ユーザーの参加、（3）セキュリティ。このセクションで説明するプライバシー緩和策は、公正情報慣行などの既存のプライバシー原則に大まかにマッピングできますが、このドキュメントの対象読者に合わせて調整されています。
Data minimization refers to collecting, using, disclosing, and storing the minimal data necessary to perform a task. Reducing the amount of data exchanged reduces the amount of data that can be misused or leaked.
データの最小化とは、タスクを実行するために必要な最小限のデータを収集、使用、開示、および保存することを指します。交換されるデータの量を減らすと、誤用または漏洩する可能性のあるデータの量が減ります。
Data minimization can be effectuated in a number of different ways, including by limiting collection, use, disclosure, retention, identifiability, sensitivity, and access to personal data. Limiting the data collected by protocol elements to only what is necessary (collection limitation) is the most straightforward way to help reduce privacy risks associated with the use of the protocol. In some cases, protocol designers may also be able to recommend limits to the use or retention of data, although protocols themselves are not often capable of controlling these properties.
データの最小化は、収集、使用、開示、保持、識別可能性、機密性、個人データへのアクセスを制限するなど、さまざまな方法で実現できます。プロトコル要素によって収集されるデータを必要なものだけに制限すること（収集制限）は、プロトコルの使用に関連するプライバシーリスクを軽減するのに役立つ最も簡単な方法です。プロトコル自体はこれらのプロパティを制御できないことが多いですが、場合によっては、プロトコル設計者がデータの使用または保持の制限を推奨できる場合もあります。
However, the most direct application of data minimization to protocol design is limiting identifiability. Reducing the identifiability of data by using pseudonyms or no identifiers at all helps to weaken the link between an individual and his or her communications. Allowing for the periodic creation of new or randomized identifiers reduces the possibility that multiple protocol interactions or communications can be correlated back to the same individual. The following sections explore a number of different properties related to identifiability that protocol designers may seek to achieve.
ただし、データ最小化をプロトコル設計に直接適用すると、識別可能性が制限されます。仮名を使用するか、識別子をまったく使用しないことでデータの識別可能性を低下させると、個人と個人の通信の間のリンクを弱めるのに役立ちます。新しい識別子またはランダム化された識別子を定期的に作成できるようにすることで、複数のプロトコルの相互作用や通信を同じ個人に関連付けることができる可能性が低くなります。次のセクションでは、プロトコル設計者が実現しようとする可能性のある識別可能性に関連するさまざまなプロパティについて説明します。
Data minimization mitigates the following threats: surveillance, stored data compromise, correlation, identification, secondary use, and disclosure.
データの最小化により、監視、保存データの侵害、相関、識別、二次利用、開示といった脅威が軽減されます。
To enable anonymity of an individual, there must exist a set of individuals that appear to have the same attribute(s) as the individual. To the attacker or the observer, these individuals must appear indistinguishable from each other. The set of all such individuals is known as the anonymity set, and membership of this set may vary over time.
個人の匿名性を有効にするには、個人と同じ属性を持つように見える個人のセットが存在する必要があります。攻撃者または観察者にとって、これらの個人は互いに区別できないように見える必要があります。そのようなすべての個人のセットは匿名セットと呼ばれ、このセットのメンバーシップは時間とともに変化する可能性があります。
The composition of the anonymity set depends on the knowledge of the observer or attacker. Thus, anonymity is relative with respect to the observer or attacker. An initiator may be anonymous only within a set of potential initiators -- its initiator anonymity set -- which itself may be a subset of all individuals that may initiate communications. Conversely, a recipient may be anonymous only within a set of potential recipients -- its recipient anonymity set. Both anonymity sets may be disjoint, may overlap, or may be the same.
匿名セットの構成は、観察者または攻撃者の知識に依存します。したがって、匿名性はオブザーバーまたは攻撃者に対して相対的です。イニシエーターは、潜在的なイニシエーターのセット（そのイニシエーターの匿名性セット）内でのみ匿名である可能性があります。逆に、受信者は、潜在的な受信者のセット（受信者の匿名性セット）内でのみ匿名である場合があります。両方の匿名セットは互いに素であるか、重複しているか、同じである可能性があります。
As an example, consider RFC 3325 (P-Asserted-Identity (PAI)) [RFC3325], an extension for the Session Initiation Protocol (SIP) that allows an individual, such as a Voice over IP (VoIP) caller, to instruct an intermediary that he or she trusts not to populate the SIP From header field with the individual's authenticated and verified identity. The recipient of the call, as well as any other entity outside of the individual's trust domain, would therefore only learn that the SIP message (typically a SIP INVITE) was sent with a header field 'From: "Anonymous" <sip:anonymous@anonymous.invalid>' rather than the individual's address-of-record, which is typically thought of as the "public address" of the user. When PAI is used, the individual becomes anonymous within the initiator anonymity set that is populated by every individual making use of that specific intermediary.
例として、RFC 3325（P-Asserted-Identity（PAI））[RFC3325]を検討してください。これは、Voice over IP（VoIP）の呼び出し元などの個人が指示できるようにする、Session Initiation Protocol（SIP）の拡張です。 SIP Fromヘッダーフィールドに個人の認証および検証済みのIDを入力しないと信頼している仲介者。したがって、呼び出しの受信者、および個人の信頼ドメイン外の他のエンティティは、SIPメッセージ（通常はSIP INVITE）がヘッダーフィールド 'From： "Anonymous" <sip：anonymous @で送信されたことを知るだけです。 anonymous.invalid> 'ではなく、通常はユーザーの「パブリックアドレス」と見なされる個人のレコードのアドレス。 PAIを使用すると、その特定の仲介者を利用するすべての個人によって入力される開始者匿名セット内で、個人が匿名になります。
Note that this example ignores the fact that the recipient may infer or obtain personal data from the other SIP payloads (e.g., SIP Via and Contact headers, the Session Description Protocol (SDP)). The implication is that PAI only attempts to address a particular threat, namely the disclosure of identity (in the From header) with respect to the recipient. This caveat makes the analysis of the specific protocol extension easier but cannot be assumed when conducting analysis of an entire architecture.
この例では、受信者が他のSIPペイロード（SIP ViaおよびContactヘッダー、Session Description Protocol（SDP）など）から個人データを推測または取得する可能性があるという事実を無視していることに注意してください。つまり、PAIは特定の脅威、つまり受信者に関する（Fromヘッダー内の）IDの開示にのみ対処しようとします。この警告により、特定のプロトコル拡張の分析が容易になりますが、アーキテクチャ全体の分析を行う場合は想定できません。
In the context of Internet protocols, almost all identifiers can be nicknames or pseudonyms, since there is typically no requirement to use personal names in protocols. However, in certain scenarios it is reasonable to assume that personal names will be used (with vCard [RFC6350], for example).
通常、プロトコルで個人名を使用する必要がないため、インターネットプロトコルのコンテキストでは、ほとんどすべての識別子をニックネームまたは仮名にすることができます。ただし、特定のシナリオでは、個人名が使用されると想定するのが妥当です（たとえば、vCard [RFC6350]で）。
Pseudonymity is strengthened when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen pseudonyms are more frequently used for new actions (making them, from an observer's or attacker's perspective, unlinkable).
仮名にリンクできる個人データが少ないと、仮名性が強化されます。同じ仮名が使用される頻度が少なく、コンテキストが少ない場合。独立して選択された仮名は、新しいアクションでより頻繁に使用されます（オブザーバーまたは攻撃者の観点から、それらをリンク不可にします）。
For Internet protocols, the following are important considerations: whether protocols allow pseudonyms to be changed without human interaction, the default length of pseudonym lifetimes, to whom pseudonyms are exposed, how individuals are able to control disclosure, how often pseudonyms can be changed, and the consequences of changing them.
インターネットプロトコルの場合、重要な考慮事項は次のとおりです。プロトコルが人の介入なしに仮名を変更できるかどうか、仮名の有効期間のデフォルトの長さ、仮名が公開される対象、個人が開示を制御できる方法、仮名を変更できる頻度、およびそれらを変更した結果。
An initiator has identity confidentiality when any party other than the recipient cannot sufficiently identify the initiator within the anonymity set. The size of the anonymity set has a direct impact on identity confidentiality, since the smaller the set is, the easier it is to identify the initiator. Identity confidentiality aims to provide a protection against eavesdroppers and intermediaries rather than against the intended communication endpoints.
受信者以外の当事者が匿名セット内のイニシエーターを十分に識別できない場合、イニシエーターはID機密性を持ちます。匿名セットのサイズは、IDの機密性に直接影響します。セットが小さいほど、開始者の識別が容易になるためです。 IDの機密性は、意図された通信エンドポイントではなく、盗聴者および仲介者に対する保護を提供することを目的としています。
As an example, consider the network access authentication procedures utilizing the Extensible Authentication Protocol (EAP) [RFC3748]. EAP includes an identity exchange where the Identity Response is primarily used for routing purposes and selecting which EAP method to use. Since EAP Identity Requests and Identity Responses are sent in cleartext, eavesdroppers and intermediaries along the communication path between the EAP peer and the EAP server can snoop on the identity, which is encoded in the form of the Network Access Identifier (NAI) as defined in RFC 4282 [RFC4282]. To address this threat, as discussed in RFC 4282 [RFC4282], the username part of the NAI (but not the realm part) can be hidden from these eavesdroppers and intermediaries with the cryptographic support offered by EAP methods. Identity confidentiality has become a recommended design criteria for EAP (see [RFC4017]). The EAP method for 3rd Generation Authentication and Key Agreement (EAP-AKA) [RFC4187], for example, protects the EAP peer's identity against passive adversaries by utilizing temporal identities. The EAP-Internet Key Exchange Protocol version 2 (EAP-IKEv2) method [RFC5106] is an example of an EAP method that offers protection against active attackers with regard to the individual's identity.
例として、拡張認証プロトコル（EAP）[RFC3748]を利用したネットワークアクセス認証手順を考えてみましょう。 EAPには、アイデンティティー交換が主にルーティングの目的で使用され、使用するEAPメソッドを選択するアイデンティティー交換が含まれます。 EAP ID要求とID応答はクリアテキストで送信されるため、EAPピアとEAPサーバーの間の通信パスに沿った盗聴者と仲介者は、ネットワークアクセスID（NAI）の形式でエンコードされたIDをスヌーピングできます。 RFC 4282 [RFC4282]。この脅威に対処するには、RFC 4282 [RFC4282]で説明されているように、NAIのユーザー名の部分（レルムの部分ではない）をこれらの盗聴者やEAPメソッドによって提供される暗号化サポートの仲介者から隠すことができます。 IDの機密性は、EAPの推奨設計基準になっています（[RFC4017]を参照）。たとえば、第3世代認証およびキー合意（EAP-AKA）のEAP方式（EAP-AKA）[RFC4187]は、一時的なIDを利用して、EAPピアのIDをパッシブな敵から保護します。 EAP-インターネットキー交換プロトコルバージョン2（EAP-IKEv2）メソッド[RFC5106]は、個人のIDに関してアクティブな攻撃者に対する保護を提供するEAPメソッドの例です。
Modern systems are increasingly relying on multi-party transactions to authenticate individuals. Many of these systems make use of an identity provider that is responsible for providing AAA functionality to relying parties that offer some protected resources. To facilitate these functions, an identity provider will usually go through a process of verifying the individual's identity and issuing credentials to the individual. When an individual seeks to make use of a service provided by the relying party, the relying party relies on the authentication assertions provided by its identity provider. Note that in more sophisticated scenarios the authentication assertions are traits that demonstrate the individual's capabilities and roles. The authorization responsibility may also be shared between the identity provider and the relying party and does not necessarily need to reside only with the identity provider.
現代のシステムは、個人を認証するためにマルチパーティのトランザクションにますます依存しています。これらのシステムの多くは、保護されたリソースを提供する証明書利用者にAAA機能を提供する責任があるIDプロバイダーを利用しています。これらの機能を容易にするために、IDプロバイダーは通常、個人のIDを確認し、個人に資格情報を発行するプロセスを実行します。個人が証明書利用者によって提供されるサービスを利用しようとするとき、証明書利用者は、IDプロバイダーによって提供される認証アサーションに依存します。より高度なシナリオでは、認証アサーションは個人の機能と役割を示す特性であることに注意してください。承認の責任は、IDプロバイダーと証明書利用者の間で共有することもでき、必ずしもIDプロバイダーのみに存在する必要はありません。
Such systems have the ability to support a number of properties that minimize data collection in different ways:
このようなシステムには、さまざまな方法でデータ収集を最小限に抑えるいくつかのプロパティをサポートする機能があります。
In certain use cases, relying parties do not need to know the real name or date of birth of an individual (for example, when the individual's age is the only attribute that needs to be authenticated).
特定のユースケースでは、証明書利用者は個人の実名または生年月日を知る必要がありません（たとえば、個人の年齢が認証が必要な唯一の属性である場合）。
Relying parties that collude can be prevented from using an individual's credentials to track the individual. That is, two different relying parties can be prevented from determining that the same individual has authenticated to both of them. This typically requires identity management protocol support as well as support by both the relying party and the identity provider.
共謀する信頼パーティは、個人の資格情報を使用して個人を追跡できないようにすることができます。つまり、2つの異なる証明書利用者が、同じ個人が両方の証明書に認証されていると判断しないようにすることができます。これには、通常、ID管理プロトコルのサポートと、証明書利用者とIDプロバイダーの両方によるサポートが必要です。
The identity provider can be prevented from knowing which relying parties an individual interacted with. This requires, at a minimum, avoiding direct communication between the identity provider and the relying party at the time when access to a resource by the initiator is made.
IDプロバイダーは、個人が対話した依存パーティを知ることを防止できます。これには、少なくとも、イニシエーターによるリソースへのアクセスが行われるときに、アイデンティティプロバイダーと依存パーティとの間の直接通信を回避することが必要です。
As explained in Section 5.2.5, data collection and use that happen "in secret", without the individual's knowledge, are apt to violate the individual's expectation of privacy and may create incentives for misuse of data. As a result, privacy regimes tend to include provisions to require informing individuals about data collection and use and involving them in decisions about the treatment of their data. In an engineering context, supporting the goal of user participation usually means providing ways for users to control the data that is shared about them. It may also mean providing ways for users to signal how they expect their data to be used and shared. Different protocol and architectural designs can make supporting user participation (for example, the ability to support a dialog box for user interaction) easier or harder; for example, OAuth-based services may have more natural hooks for user input than AAA services.
セクション5.2.5で説明したように、個人が知らないうちに「秘密裏に」行われるデータの収集と使用は、個人のプライバシーに対する期待に違反する傾向があり、データの悪用に対するインセンティブを生み出す可能性があります。その結果、プライバシー体制には、データの収集と使用について個人に通知し、データの取り扱いに関する決定に彼らを関与させることを要求する規定が含まれる傾向があります。エンジニアリングのコンテキストでは、ユーザー参加の目標をサポートすることは通常、ユーザーが共有するデータを制御する方法をユーザーに提供することを意味します。また、ユーザーが自分のデータがどのように使用および共有されるかをユーザーに知らせる方法を提供することも意味します。さまざまなプロトコルとアーキテクチャの設計により、ユーザーの参加をサポートする（たとえば、ユーザーインタラクション用のダイアログボックスをサポートする機能など）が容易または難しくなります。たとえば、OAuthベースのサービスには、AAAサービスよりもユーザー入力のためのより自然なフックがあります。
User participation mitigates the following threats: surveillance, secondary use, disclosure, and exclusion.
ユーザーの参加により、監視、二次利用、開示、除外といった脅威が緩和されます。
Keeping data secure at rest and in transit is another important component of privacy protection. As they are described in Section 2 of [RFC3552], a number of security goals also serve to enhance privacy:
保管中および転送中のデータを安全に保つことは、プライバシー保護のもう1つの重要なコンポーネントです。 [RFC3552]のセクション2で説明されているように、いくつかのセキュリティ目標もプライバシーの強化に役立ちます。
o Confidentiality: Keeping data secret from unintended listeners.
o 機密性：意図しないリスナーからデータを秘密に保ちます。
o Peer entity authentication: Ensuring that the endpoint of a communication is the one that is intended (in support of maintaining confidentiality).
o ピアエンティティ認証：通信のエンドポイントが意図したものであることを保証します（機密性の維持をサポートするため）。
o Unauthorized usage: Limiting data access to only those users who are authorized. (Note that this goal also falls within data minimization.)
o 不正使用：データアクセスを許可されたユーザーのみに制限します。 （この目標もデータの最小化に含まれることに注意してください。）
o Inappropriate usage: Limiting how authorized users can use data. (Note that this goal also falls within data minimization.)
o 不適切な使用：許可されたユーザーがデータを使用する方法を制限します。 （この目標もデータの最小化に含まれることに注意してください。）
Note that even when these goals are achieved, the existence of items of interest -- attributes, identifiers, identities, communications, actions (such as the sending or receiving of a communication), or anything else an attacker or observer might be interested in -- may still be detectable, even if they are not readable. Thus, undetectability, in which an observer or attacker cannot sufficiently distinguish whether an item of interest exists or not, may be considered as a further security goal (albeit one that can be extremely difficult to accomplish).
これらの目標が達成された場合でも、関心のある項目の存在-属性、識別子、アイデンティティ、通信、アクション（通信の送信または受信など）、または攻撃者やオブザーバーが関心を持っている可能性のある何か- -読み取れない場合でも、検出できる場合があります。したがって、オブザーバーまたは攻撃者が関心のあるアイテムが存在するかどうかを十分に区別できない検出不能は、さらなるセキュリティ目標と見なすことができます（ただし、達成するのは非常に難しい場合があります）。
Detection of the protocols or applications in use via traffic analysis may be particularly difficult to defend against. As with the anonymity of individuals, achieving "protocol anonymity" requires that multiple protocols or applications exist that appear to have the same attributes -- packet sizes, content, token locations, or inter-packet timing, for example. An attacker or observer will not be able to use traffic analysis to identify which protocol or application is in use if multiple protocols or applications are indistinguishable.
トラフィック分析による使用中のプロトコルまたはアプリケーションの検出は、防御するのが特に難しい場合があります。個人の匿名性と同様に、「プロトコルの匿名性」を実現するには、パケットサイズ、コンテンツ、トークンの場所、パケット間のタイミングなど、同じ属性を持つ複数のプロトコルまたはアプリケーションが存在する必要があります。複数のプロトコルまたはアプリケーションが区別できない場合、攻撃者またはオブザーバーはトラフィック分析を使用して、どのプロトコルまたはアプリケーションが使用されているかを特定することはできません。
Defending against the threat of traffic analysis will be possible to different extents for different protocols, may depend on implementation- or use-specific details, and may depend on which other protocols already exist and whether they share similar traffic characteristics. The defenses will also vary relative to what the protocol is designed to do; for example, in some situations randomizing packet sizes, timing, or token locations will reduce the threat of traffic analysis, whereas in other situations (real-time communications, for example) holding some or all of those factors constant is a more appropriate defense. See "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562] for an example of how these kinds of trade-offs should be evaluated.
トラフィック分析の脅威に対する防御は、プロトコルごとにさまざまな範囲で可能であり、実装または使用固有の詳細に依存する可能性があり、他にどのプロトコルが既に存在しているか、およびそれらが類似のトラフィック特性を共有するかどうかに依存する可能性があります。防御策は、プロトコルの設計に応じて異なります。たとえば、パケットサイズ、タイミング、またはトークンの場所をランダム化すると、トラフィック分析の脅威を軽減できる場合がありますが、他の状況（リアルタイム通信など）では、これらの要因の一部またはすべてを一定に保つ方が適切な防御策です。これらの種類のトレードオフを評価する方法の例については、「セキュアRTPでの可変ビットレートオーディオの使用に関するガイドライン」[RFC6562]を参照してください。
By providing proper security protection, the following threats can be mitigated: surveillance, stored data compromise, misattribution, secondary use, disclosure, and intrusion.
適切なセキュリティ保護を提供することにより、監視、保存データの侵害、誤配、二次利用、開示、侵入などの脅威を軽減できます。
This section provides guidance for document authors in the form of a questionnaire about a protocol being designed. The questionnaire may be useful at any point in the design process, particularly after document authors have developed a high-level protocol model as described in [RFC4101].
このセクションでは、設計されているプロトコルに関するアンケートの形式でドキュメント作成者にガイダンスを提供します。アンケートは、特にドキュメントの作成者が[RFC4101]で説明されている高レベルのプロトコルモデルを開発した後、設計プロセスのどの時点でも役立つ可能性があります。
Note that the guidance provided in this section does not recommend specific practices. The range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how privacy might be balanced against other design goals. However, by carefully considering the answers to each question, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion of whether the protocol adequately protects against privacy threats. This guidance is meant to help the thought process of privacy analysis; it does not provide specific directions for how to write a privacy considerations section.
このセクションで提供されるガイダンスは、特定のプラクティスを推奨するものではないことに注意してください。 IETFで開発されたプロトコルの範囲は広すぎるため、データの特定の使用や、プライバシーを他の設計目標とどのようにバランスさせるかについての推奨を行うことはできません。ただし、各質問への回答を慎重に検討することにより、ドキュメントの作成者は、プロトコルがプライバシーの脅威から適切に保護されているかどうかを検討するための基礎として役立つ包括的な分析を作成できるはずです。このガイダンスは、プライバシー分析の思考プロセスを支援することを目的としています。プライバシーに関する考慮事項セクションの記述方法についての具体的な指示は提供していません。
The framework is divided into four sections: three sections that address each of the mitigation classes from Section 6, plus a general section. Security is not fully elaborated, since substantial guidance already exists in [RFC3552].
フレームワークは4つのセクションに分かれています。セクション6の各軽減策クラスに対応する3つのセクションと一般的なセクションです。 [RFC3552]には実質的なガイダンスがすでに存在するため、セキュリティは完全には詳しく説明されていません。
a. Identifiers. What identifiers does the protocol use for distinguishing initiators of communications? Does the protocol use identifiers that allow different protocol interactions to be correlated? What identifiers could be omitted or be made less identifying while still fulfilling the protocol's goals?
a. 識別子。プロトコルは、通信の開始者を区別するためにどの識別子を使用しますか？プロトコルは、異なるプロトコルの相互作用を相関させることができる識別子を使用していますか？プロトコルの目標を満たしながら、どの識別子を省略したり識別しにくくしたりできますか？
b. Data. What information does the protocol expose about individuals, their devices, and/or their device usage (other than the identifiers discussed in (a))? To what extent is this information linked to the identities of the individuals? How does the protocol combine personal data with the identifiers discussed in (a)?
b. データ。プロトコルは、個人、デバイス、デバイスの使用状況についてどのような情報を公開しますか（（a）で説明した識別子以外）？この情報は、個人のアイデンティティとどの程度関連していますか？プロトコルは、個人データを（a）で説明した識別子とどのように組み合わせますか？
c. Observers. Which information discussed in (a) and (b) is exposed to each other protocol entity (i.e., recipients, intermediaries, and enablers)? Are there ways for protocol implementers to choose to limit the information shared with each entity? Are there operational controls available to limit the information shared with each entity?
c. オブザーバー。 （a）と（b）で説明されている情報のうち、他のプロトコルエンティティ（受信者、仲介者、イネーブラ）に公開されているものはどれですか？プロトコル実装者が各エンティティと共有する情報を制限することを選択する方法はありますか？各エンティティと共有する情報を制限するために利用できる運用管理はありますか？
d. Fingerprinting. In many cases, the specific ordering and/or occurrences of information elements in a protocol allow users, devices, or software using the protocol to be fingerprinted. Is this protocol vulnerable to fingerprinting? If so, how? Can it be designed to reduce or eliminate the vulnerability? If not, why not?
d. フィンガープリント。多くの場合、プロトコル内の情報要素の特定の順序および/または出現により、プロトコルを使用するユーザー、デバイス、またはソフトウェアをフィンガープリントできます。このプロトコルはフィンガープリントに対して脆弱ですか？もしそうなら、どうですか？脆弱性を軽減または排除するように設計できますか？そうでない場合、なぜそうではないのですか？
e. Persistence of identifiers. What assumptions are made in the protocol design about the lifetime of the identifiers discussed in (a)? Does the protocol allow implementers or users to delete or replace identifiers? How often does the specification recommend deleting or replacing identifiers by default? Can the identifiers, along with other state information, be set to automatically expire?
e. 識別子の永続性。 （a）で説明されている識別子の寿命について、プロトコル設計ではどのような仮定が行われていますか？このプロトコルでは、実装者またはユーザーが識別子を削除または置換できますか？仕様では、デフォルトで識別子の削除または置き換えをどのくらいの頻度で推奨していますか？識別子は、他の状態情報とともに、自動的に期限切れになるように設定できますか？
f. Correlation. Does the protocol allow for correlation of identifiers? Are there expected ways that information exposed by the protocol will be combined or correlated with information obtained outside the protocol? How will such combination or correlation facilitate fingerprinting of a user, device, or application? Are there expected combinations or correlations with outside data that will make users of the protocol more identifiable?
f. 相関。プロトコルは識別子の相関を可能にしますか？プロトコルによって公開された情報が、プロトコルの外部で取得された情報と組み合わされたり関連付けられたりすることが予想される方法はありますか？そのような組み合わせまたは相関は、ユーザー、デバイス、またはアプリケーションのフィンガープリントをどのように促進しますか？プロトコルのユーザーをより識別しやすくする外部データとの予想される組み合わせまたは相関関係はありますか？
g. Retention. Does the protocol or its anticipated uses require that the information discussed in (a) or (b) be retained by recipients, intermediaries, or enablers? If so, why? Is the retention expected to be persistent or temporary?
g. 保持。プロトコルまたはその予想される使用では、（a）または（b）で説明されている情報を受信者、仲介者、またはイネーブラが保持する必要がありますか？もしそうなら、なぜですか？保持は永続的または一時的であると予想されますか？
a. User control. What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol? If no such mechanisms or controls are specified, is it expected that control and consent will be handled outside of the protocol?
a. ユーザーコントロール。個人データまたは識別子がプロトコルを介して共有または公開される前に、プロトコルはどのような制御または同意メカニズムを定義または必要としますか？そのようなメカニズムまたは制御が指定されていない場合、制御と同意はプロトコルの外部で処理されることが予想されますか？
b. Control over sharing with individual recipients. Does the protocol provide ways for initiators to share different information with different recipients? If not, are there mechanisms that exist outside of the protocol to provide initiators with such control?
b. 個々の受信者との共有を制御します。プロトコルは、開始者が異なる情報を異なる受信者と共有する方法を提供しますか？そうでない場合、イニシエータにそのような制御を提供するためにプロトコルの外部に存在するメカニズムはありますか？
c. Control over sharing with intermediaries. Does the protocol provide ways for initiators to limit which information is shared with intermediaries? If not, are there mechanisms that exist outside of the protocol to provide users with such control? Is it expected that users will have relationships that govern the use of the information (contractual or otherwise) with those who operate these intermediaries?
c. 仲介者との共有の制御。プロトコルは、仲介者と共有する情報を開始者が制限する方法を提供していますか？そうでない場合、ユーザーにそのような制御を提供するためにプロトコルの外部に存在するメカニズムはありますか？ユーザーは、これらの仲介者を運営する人との情報の使用（契約またはその他）を管理する関係を持つことが期待されますか？
d. Preference expression. Does the protocol provide ways for initiators to express individuals' preferences to recipients or intermediaries with regard to the collection, use, or disclosure of their personal data?
d. プリファレンス式。プロトコルは、開始者が個人データの収集、使用、または開示に関して受信者または仲介者に個人の好みを表現する方法を提供していますか？
a. Surveillance. How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analysis? Does the protocol leak information that can be observed through traffic analysis, such as by using a fixed token at fixed offsets, or packet sizes or timing that allow observers to determine characteristics of the traffic (e.g., which protocol is in use or whether the traffic is part of a real-time flow)?
a. 監視。プロトコルのセキュリティに関する考慮事項により、盗聴やトラフィック分析などの監視がどのように防止されますか？プロトコルは、固定オフセットで固定トークンを使用するなどのトラフィック分析を通じて観察できる情報、またはオブザーバーがトラフィックの特性（たとえば、どのプロトコルが使用されているか、またはトラフィックがリアルタイムフローの一部です）？
b. Stored data compromise. How do the protocol's security considerations prevent or mitigate stored data compromise?
b. 保存されたデータの侵害。プロトコルのセキュリティに関する考慮事項は、格納されたデータの侵害をどのように防止または軽減しますか？
c. Intrusion. How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally?
c. 侵入。より一般的には、プロトコルのセキュリティに関する考慮事項により、サービス拒否攻撃や迷惑な通信などの侵入をどのように防止または軽減しますか？
d. Misattribution. How do the protocol's mechanisms for identifying and/or authenticating individuals prevent misattribution?
d. 誤表示。個人を識別および/または認証するためのプロトコルのメカニズムは、誤認をどのように防止しますか？
a. Trade-offs. Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, or privacy and other design goals? Describe the trade-offs and the rationale for the design chosen.
a. トレードオフ。プロトコルは、プライバシーとユーザビリティ、プライバシーと効率、プライバシーと実装性、またはプライバシーとその他の設計目標の間でトレードオフを行いますか？選択した設計のトレードオフと理論的根拠を説明してください。
b. Defaults. If the protocol can be operated in multiple modes or with multiple configurable options, does the default mode or option minimize the amount, identifiability, and persistence of the data and identifiers exposed by the protocol? Does the default mode or option maximize the opportunity for user participation? Does it provide the strictest security features of all the modes/options? If the answer to any of these questions is no, explain why less protective defaults were chosen.
b. デフォルト。プロトコルを複数のモードまたは複数の構成可能なオプションで操作できる場合、デフォルトのモードまたはオプションは、プロトコルによって公開されるデータと識別子の量、識別可能性、および永続性を最小限に抑えますか？デフォルトのモードまたはオプションは、ユーザー参加の機会を最大化しますか？すべてのモード/オプションの最も厳しいセキュリティ機能を提供していますか？これらの質問のいずれかに対する答えが「いいえ」である場合、より低い保護デフォルトが選択された理由を説明してください。
The following section gives an example of the threat analysis and threat mitigations recommended by this document. It covers a particularly difficult application protocol, presence, to try to demonstrate these principles on an architecture that is vulnerable to many of the threats described above. This text is not intended as an example of a privacy considerations section that might appear in an IETF specification, but rather as an example of the thinking that should go into the design of a protocol when considering privacy as a first principle.
次のセクションでは、このドキュメントで推奨されている脅威分析と脅威軽減の例を示します。上記の脅威の多くに対して脆弱なアーキテクチャでこれらの原則を実証するために、特に難しいアプリケーションプロトコル、プレゼンスについて説明します。このテキストは、IETF仕様に表示される可能性のあるプライバシーに関する考慮事項のセクションの例としてではなく、プライバシーを第一の原則として検討する場合にプロトコルの設計に入る必要がある考え方の例として意図されています。
A presence service, as defined in the abstract in [RFC2778], allows users of a communications service to monitor one another's availability and disposition in order to make decisions about communicating. Presence information is highly dynamic and generally characterizes whether a user is online or offline, busy or idle, away from communications devices or nearby, and the like. Necessarily, this information has certain privacy implications, and from the start the IETF approached this work with the aim of providing users with the controls to determine how their presence information would be shared. The Common Profile for Presence (CPP) [RFC3859] defines a set of logical operations for delivery of presence information. This abstract model is applicable to multiple presence systems. The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence system [RFC3856] uses CPP as its baseline architecture, and the presence operations in the Extensible Messaging and Presence Protocol (XMPP) have also been mapped to CPP [RFC3922].
[RFC2778]の要約で定義されているプレゼンスサービスを使用すると、通信サービスのユーザーは、通信に関する意思決定を行うために、互いの可用性と性質を監視できます。プレゼンス情報は非常に動的であり、一般に、ユーザーがオンラインかオフラインか、ビジーかアイドルか、通信デバイスから離れているか近くにいるかなどを特徴付けます。必然的に、この情報には特定のプライバシーの影響があり、IETFは最初から、プレゼンス情報の共有方法を決定するためのコントロールをユーザーに提供する目的でこの作業に取り組みました。プレゼンスの共通プロファイル（CPP）[RFC3859]は、プレゼンス情報を配信するための一連の論理操作を定義しています。この抽象モデルは、複数のプレゼンスシステムに適用できます。 SIP for Instant Messaging and Presence Leveraging Extensions（SIMPLE）プレゼンスシステム[RFC3856]はCPPをベースラインアーキテクチャとして使用し、Extensible Messaging and Presence Protocol（XMPP）のプレゼンス操作もCPP [RFC3922]にマッピングされています。
The fundamental architecture defined in RFC 2778 and RFC 3859 is a mediated one. Clients (presentities in RFC 2778 terms) publish their presence information to presence servers, which in turn distribute information to authorized watchers. Presence servers thus retain presence information for an interval of time, until it either changes or expires, so that it can be revealed to authorized watchers upon request. This architecture mirrors existing pre-standard deployment models. The integration of an explicit authorization mechanism into the presence architecture has been widely successful in involving the end users in the decision-making process before sharing information. Nearly all presence systems deployed today provide such a mechanism, typically through a reciprocal authorization system by which a pair of users, when they agree to be "buddies", consent to divulge their presence information to one another. Buddylists are managed by servers but controlled by end users. Users can also explicitly block one another through a similar interface, and in some deployments it is desirable to provide "polite blocking" of various kinds.
RFC 2778およびRFC 3859で定義されている基本的なアーキテクチャは、仲介されたものです。クライアント（RFC 2778用語でのプレゼンティティ）は、プレゼンス情報をプレゼンスサーバーに発行し、次にプレゼンスサーバーが許可されたウォッチャーに情報を配信します。したがって、プレゼンスサーバーは、プレゼンス情報が変更または期限切れになるまで一定期間保持するため、リクエストに応じて、許可されたウォッチャーに公開できます。このアーキテクチャは、既存の先行標準導入モデルを反映しています。明示的な承認メカニズムをプレゼンスアーキテクチャに統合することで、情報を共有する前の意思決定プロセスにエンドユーザーを参加させることができます。今日配備されているほとんどすべてのプレゼンスシステムは、通常、相互認証システムを通じてこのようなメカニズムを提供します。これにより、ユーザーのペアが「バディ」であることに同意した場合、プレゼンス情報を互いに漏らすことに同意します。仏教徒はサーバーによって管理されますが、エンドユーザーによって制御されます。ユーザーは、同様のインターフェースを介して相互に明示的にブロックすることもできます。一部のデプロイメントでは、さまざまな種類の「ポライトブロック」を提供することが望ましい場合があります。
From a perspective of privacy design, however, the classical presence architecture represents nearly a worst-case scenario. In terms of data minimization, presentities share their sensitive information with presence services, and while services only share this presence information with watchers authorized by the user, no technical mechanism constrains those watchers from relaying presence to further third parties. Any of these entities could conceivably log or retain presence information indefinitely. The sensitivity cannot be mitigated by rendering the user anonymous, as it is indeed the purpose of the system to facilitate communications between users who know one another. The identifiers employed by users are long-lived and often contain personal information, including personal names and the domains of service providers. While users do participate in the construction of buddylists and blacklists, they do so with little prospect for accountability: the user effectively throws their presence information over the wall to a presence server that in turn distributes the information to watchers. Users typically have no way to verify that presence is being distributed only to authorized watchers, especially as it is the server that authenticates watchers, not the end user. Moreover, connections between the server and all publishers and consumers of presence data are an attractive target for eavesdroppers and require strong confidentiality mechanisms, though again the end user has no way to verify what mechanisms are in place between the presence server and a watcher.
ただし、プライバシー設計の観点から見ると、古典的なプレゼンスアーキテクチャは、最悪のケースに近いシナリオを表しています。データの最小化に関して、プレゼンティティは機密情報をプレゼンスサービスと共有し、サービスはこのプレゼンス情報をユーザーによって承認されたウォッチャーとのみ共有しますが、これらのウォッチャーがプレゼンスを第三者に中継することを制限する技術的なメカニズムはありません。これらのエンティティのいずれかが、おそらく無期限にプレゼンス情報を記録または保持する可能性があります。機密性は、ユーザーを匿名にすることによって軽減することはできません。これは、実際にシステムの目的がお互いを知っているユーザー間の通信を容易にするためです。ユーザーが使用する識別子は長期間有効であり、多くの場合、個人名やサービスプロバイダーのドメインなどの個人情報が含まれています。ユーザーはバディリストとブラックリストの構築に参加しますが、アカウンタビリティの見込みがほとんどないため、参加します。ユーザーは、プレゼンス情報を壁を越えてプレゼンスサーバーに効果的に送信し、プレゼンスサーバーがウォッチャーに情報を配信します。特にエンドユーザーではなくウォッチャーを認証するサーバーであるため、ユーザーは通常、承認されたウォッチャーにのみプレゼンスが配信されていることを確認する方法がありません。さらに、サーバーとすべてのパブリッシャーおよびプレゼンスデータのコンシューマー間の接続は、盗聴者にとって魅力的なターゲットであり、強力な機密性メカニズムが必要ですが、エンドユーザーはプレゼンスサーバーとウォッチャーの間にどのメカニズムが配置されているかを確認する方法がありません。
Additionally, the sensitivity of presence information is not limited to the disposition and capability to communicate. Capabilities can reveal the type of device that a user employs, for example, and since multiple devices can publish the same user's presence, there are significant risks of allowing attackers to correlate user devices. An important extension to presence was developed to enable the support for location sharing. The effort to standardize protocols for systems sharing geolocation was started in the GEOPRIV working group. During the initial requirements and privacy threat analysis in the process of chartering the working group, it became clear that the system would require an underlying communication mechanism supporting user consent to share location information. The resemblance of these requirements to the presence framework was quickly recognized, and this design decision was documented in [RFC4079]. Location information thus mingles with other presence information available through the system to intermediaries and to authorized watchers.
さらに、プレゼンス情報の機密性は、通信の性質と機能に限定されません。たとえば、ユーザーが使用するデバイスのタイプを明らかにすることができます。また、複数のデバイスが同じユーザーのプレゼンスを公開できるため、攻撃者がユーザーデバイスを関連付けることができるという重大なリスクがあります。位置情報の共有をサポートするために、プレゼンスに対する重要な拡張が開発されました。ジオロケーションを共有するシステムのプロトコルを標準化する取り組みは、GEOPRIVワーキンググループで開始されました。ワーキンググループをチャーターするプロセスの初期要件とプライバシーの脅威の分析中に、位置情報を共有するにはユーザーの同意をサポートする基本的な通信メカニズムがシステムに必要であることが明らかになりました。プレゼンスフレームワークに対するこれらの要件の類似性はすぐに認識され、この設計の決定は[RFC4079]に文書化されました。したがって、ロケーション情報は、システムを介して仲介者および許可されたウォッチャーが利用できる他のプレゼンス情報と混ざります。
Privacy concerns about presence information largely arise due to the built-in mediation of the presence architecture. The need for a presence server is motivated by two primary design requirements of presence: in the first place, the server can respond with an "offline" indication when the user is not online; in the second place, the server can compose presence information published by different devices under the user's control. Additionally, to facilitate the use of URIs as identifiers for entities, some service must operate a host with the domain name appearing in a presence URI, and in practical terms no commercial presence architecture would force end users to own and operate their own domain names. Many end users of applications like presence are behind NATs or firewalls and effectively cannot receive direct connections from the Internet -- the persistent bidirectional channel these clients open and maintain with a presence server is essential to the operation of the protocol.
プレゼンス情報に関するプライバシーの懸念は、主にプレゼンスアーキテクチャの組み込みメディエーションが原因で発生します。プレゼンスサーバーの必要性は、プレゼンスの2つの主要な設計要件によって動機付けられています。そもそも、ユーザーがオンラインでない場合、サーバーは "オフライン"の表示で応答できます。 2番目に、サーバーはユーザーの制御下にあるさまざまなデバイスによって公開されたプレゼンス情報を作成できます。さらに、エンティティの識別子としてのURIの使用を容易にするために、一部のサービスは、プレゼンスURIに表示されるドメイン名でホストを操作する必要があります。実際には、商用のプレゼンスアーキテクチャではエンドユーザーが自分のドメイン名を所有および操作する必要はありません。プレゼンスなどのアプリケーションの多くのエンドユーザーはNATまたはファイアウォールの背後にあり、インターネットから直接接続を効果的に受信できません。これらのクライアントがプレゼンスサーバーで開いて維持する永続的な双方向チャネルは、プロトコルの動作に不可欠です。
One must first ask if the trade-off of mediation for presence is worthwhile. Does a server need to be in the middle of all publications of presence information? It might seem that end-to-end encryption of the presence information could solve many of these problems. A presentity could encrypt the presence information with the public key of a watcher and only then send the presence information through the server. The IETF defined an object format for presence information called the Presence Information Data Format (PIDF), which for the purposes of conveying location information was extended to the PIDF Location Object (PIDF-LO) -- these XML objects were designed to accommodate an encrypted wrapper. Encrypting this data would have the added benefit of preventing stored cleartext presence information from being seized by an attacker who manages to compromise a presence server. This proposal, however, quickly runs into usability problems. Discovering the public keys of watchers is the first difficulty, one that few Internet protocols have addressed successfully. This solution would then require the presentity to publish one encrypted copy of its presence information per authorized watcher to the presence service, regardless of whether or not a watcher is actively seeking presence information -- for a presentity with many watchers, this may place an unacceptable burden on the presence server, especially given the dynamism of presence information. Finally, it prevents the server from composing presence information reported by multiple devices under the same user's control. On the whole, these difficulties render object encryption of presence information a doubtful prospect.
最初に、調停とプレゼンスのトレードオフに価値があるかどうかを尋ねる必要があります。サーバーは、プレゼンス情報のすべての公開の中央にある必要がありますか？プレゼンス情報をエンドツーエンドで暗号化すると、これらの問題の多くを解決できるように思えるかもしれません。プレゼンティティは、ウォッチャーの公開キーを使用してプレゼンス情報を暗号化してから、サーバーを介してのみプレゼンス情報を送信できます。 IETFは、プレゼンス情報データフォーマット（PIDF）と呼ばれるプレゼンス情報のオブジェクトフォーマットを定義しました。これは、位置情報を伝えるために、PIDFロケーションオブジェクト（PIDF-LO）に拡張されました。これらのXMLオブジェクトは、暗号化に対応するように設計されていますラッパー。このデータを暗号化すると、プレゼンスサーバーのセキュリティを侵害した攻撃者が、保存されているクリアテキストのプレゼンス情報を押収されるのを防ぐという追加の利点があります。ただし、この提案はユーザビリティの問題にすぐにぶつかります。ウォッチャーの公開鍵を発見することが最初の困難であり、いくつかのインターネットプロトコルがうまく対処していない問題の1つです。このソリューションでは、ウォッチャーが積極的にプレゼンス情報を探しているかどうかに関係なく、許可されたウォッチャーごとにプレゼンス情報の暗号化されたコピーを1つプレゼンスサービスに公開する必要があります。多くのウォッチャーがいるプレゼンティティの場合、これは許容できない場合があります特にプレゼンス情報のダイナミズムを考えると、プレゼンスサーバーの負担。最後に、サーバーが同じユーザーの制御下にある複数のデバイスから報告されたプレゼンス情報を作成することを防ぎます。全体として、これらの困難により、プレゼンス情報のオブジェクトの暗号化は疑わしい見通しとなっています。
Some protocols that support presence information, such as SIP, can operate intermediaries in a redirecting mode rather than a publishing or proxying mode. Instead of sending presence information through the server, in other words, these protocols can merely redirect watchers to the presentity, and then presence information could pass directly and securely from the presentity to the watcher. It is worth noting that this would disclose the IP address of the presentity to the watcher, which has its own set of risks. In that case, the presentity can decide exactly what information it would like to share with the watcher in question, it can authenticate the watcher itself with whatever strength of credential it chooses, and with end-to-end encryption it can reduce the likelihood of any eavesdropping. In a redirection architecture, a presence server could still provide the necessary "offline" indication without requiring the presence server to observe and forward all information itself. This mechanism is more promising than encryption but also suffers from significant difficulties. It too does not provide for composition of presence information from multiple devices -- it in fact forces the watcher to perform this composition itself. The largest single impediment to this approach is, however, the difficulty of creating end-to-end connections between the presentity's device(s) and a watcher, as some or all of these endpoints may be behind NATs or firewalls that prevent peer-to-peer connections. While there are potential solutions for this problem, like Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN), they add complexity to the overall system.
SIPなどのプレゼンス情報をサポートする一部のプロトコルは、パブリッシングモードまたはプロキシモードではなく、リダイレクトモードで仲介者を操作できます。つまり、これらのプロトコルは、サーバーを介してプレゼンス情報を送信する代わりに、ウォッチャーをプレゼンティティにリダイレクトするだけで、プレゼンス情報をプレゼンティティからウォッチャーに直接かつ安全に渡すことができます。これにより、プレゼンティティのIPアドレスがウォッチャーに開示されることに注意してください。ウォッチャーには独自のリスクがあります。その場合、プレゼンティティは問題のウォッチャーと共有する情報を正確に決定でき、選択した資格情報の強度でウォッチャー自体を認証できます。エンドツーエンドの暗号化により、可能性を減らすことができます。盗聴。リダイレクトアーキテクチャでは、プレゼンスサーバーがすべての情報を監視して転送する必要なく、プレゼンスサーバーが必要な「オフライン」表示を提供できます。このメカニズムは暗号化よりも有望ですが、重大な問題も抱えています。また、複数のデバイスからのプレゼンス情報の構成は提供されません。実際、ウォッチャーはこの構成自体を実行する必要があります。ただし、このアプローチの最大の障害は、プレゼンティティのデバイスとウォッチャーの間にエンドツーエンド接続を作成することが難しいことです。これらのエンドポイントの一部またはすべてが、ピアツーピアを妨げるNATまたはファイアウォールの背後にある可能性があるためです。 -ピア接続。この問題には、NATのセッショントラバーサルユーティリティ（STUN）やNATを介したリレーを使用したトラバーサル（TURN）などの潜在的な解決策がありますが、システム全体が複雑になります。
Consequently, mediation is a difficult feature of the presence architecture to remove. It is hard to minimize the data shared with intermediaries, especially due to the requirement for composition. Control over sharing with intermediaries must therefore come from some other explicit component of the architecture. As such, the presence work in the IETF focused on improving user participation in the activities of the presence server. This work began in the GEOPRIV working group, with controls on location privacy, as location of users is perceived as having especially sensitive properties. With the aim of meeting the privacy requirements defined in [RFC2779], a set of usage indications, such as whether retransmission is allowed or when the retention period expires, have been added to the PIDF-LO such that they always travel with the location information itself. These privacy preferences apply not only to the intermediaries that store and forward presence information but also to the watchers who consume it.
したがって、メディエーションは、プレゼンスアーキテクチャの削除が難しい機能です。特に構成の要件のため、仲介者と共有するデータを最小限に抑えることは困難です。したがって、仲介者との共有の制御は、アーキテクチャーの他の明示的なコンポーネントから行う必要があります。そのため、IETFでのプレゼンス作業は、プレゼンスサーバーのアクティビティへのユーザーの参加を改善することに重点を置いていました。この作業は、位置情報のプライバシーを制御するGEOPRIVワーキンググループで始まりました。ユーザーの位置情報は、特に機密性の高い特性を持つものとして認識されています。 [RFC2779]で定義されたプライバシー要件を満たすことを目的として、再送信が許可されるか、保持期間が満了するかなどの一連の使用状況表示が常に位置情報と一緒に移動するようにPIDF-LOに追加されました自体。これらのプライバシー設定は、プレゼンス情報を保存および転送する仲介者だけでなく、それを使用するウォッチャーにも適用されます。
This approach very much follows the spirit of Creative Commons [CC], namely the usage of a limited number of conditions (such as 'Share Alike' [CC-SA]). Unlike Creative Commons, the GEOPRIV working group did not, however, initiate work to produce legal language or design graphical icons, since this would fall outside the scope of the IETF. In particular, the GEOPRIV rules state a preference on the retention and retransmission of location information; while GEOPRIV cannot force any entity receiving a PIDF-LO object to abide by those preferences, if users lack the ability to express them at all, we can guarantee their preferences will not be honored. The GEOPRIV rules can provide a means to establish accountability.
このアプローチは、クリエイティブコモンズ[CC]の精神、つまり限られた数の条件の使用（ 'Share Alike' [CC-SA]など）に非常によく従います。ただし、クリエイティブコモンズとは異なり、GEOPRIVワーキンググループは、IETFの範囲外であるため、合法的な言語を作成したり、グラフィックアイコンをデザインしたりする作業を開始しませんでした。特に、GEOPRIVルールは、位置情報の保持と再送信の優先順位を示しています。 GEOPRIVはPIDF-LOオブジェクトを受け取るエンティティにこれらの設定を強制することはできませんが、ユーザーがそれらをまったく表現できない場合は、設定が守られないことを保証できます。 GEOPRIVルールは、アカウンタビリティを確立する手段を提供できます。
The retention and retransmission elements were envisioned as the most essential examples of preference expression in sharing presence. The PIDF object was designed for extensibility, and the rulesets created for the PIDF-LO can also be extended to provide new expressions of user preference. Not all user preference information should be bound into a particular PIDF object, however; many forms of access control policy assumed by the presence architecture need to be provisioned in the presence server by some interface with the user. This requirement eventually triggered the standardization of a general access control policy language called the common policy framework (defined in [RFC4745]). This language allows one to express ways to control the distribution of information as simple conditions, actions, and transformation rules expressed in an XML format. Common Policy itself is an abstract format that needs to be instantiated: two examples can be found with the presence authorization rules [RFC5025] and the Geolocation Policy [RFC6772]. The former provides additional expressiveness for presence-based systems, while the latter defines syntax and semantics for location-based conditions and transformations.
保持と再送信の要素は、プレゼンスを共有する際の選好表現の最も重要な例として想定されていました。 PIDFオブジェクトは拡張性を考慮して設計されており、PIDF-LO用に作成されたルールセットを拡張して、ユーザー設定の新しい表現を提供することもできます。ただし、すべてのユーザー設定情報を特定のPIDFオブジェクトにバインドする必要はありません。プレゼンスアーキテクチャで想定されている多くの形式のアクセス制御ポリシーは、ユーザーとの何らかのインターフェースによってプレゼンスサーバーでプロビジョニングする必要があります。この要件は最終的に、共通ポリシーフレームワーク（[RFC4745]で定義）と呼ばれる一般的なアクセス制御ポリシー言語の標準化を引き起こしました。この言語を使用すると、情報の配布を制御する方法を、XML形式で表現された単純な条件、アクション、および変換ルールとして表現できます。共通ポリシー自体は、インスタンス化が必要な抽象的な形式です。プレゼンス認証ルール[RFC5025]と位置情報ポリシー[RFC6772]を使用した2つの例があります。前者はプレゼンスベースのシステムに追加の表現力を提供し、後者はロケーションベースの条件と変換の構文とセマンティクスを定義します。
Ultimately, the privacy work on presence represents a compromise between privacy principles and the needs of the architecture and marketplace. While it was not feasible to remove intermediaries from the architecture entirely or prevent their access to presence information, the IETF did provide a way for users to express their preferences and provision their controls at the presence service. We have not had great successes in the implementation space with privacy mechanisms thus far, but by documenting and acknowledging the limitations of these mechanisms, the designers were able to provide implementers, and end users, with an informed perspective on the privacy properties of the IETF's presence protocols.
最終的に、プレゼンスに関するプライバシーの取り組みは、プライバシーの原則と、アーキテクチャおよび市場のニーズとの間の妥協点を表しています。アーキテクチャから仲介者を完全に削除したり、プレゼンス情報へのアクセスを禁止したりすることは不可能でしたが、IETFは、ユーザーが好みを表現し、プレゼンスサービスでコントロールをプロビジョニングする方法を提供しました。これまでのところ、プライバシーメカニズムを使用した実装スペースでは大きな成功はありませんでしたが、これらのメカニズムの制限を文書化して確認することにより、設計者は実装者とエンドユーザーにIETFのプライバシープロパティに関する十分な情報を提供することができました。プレゼンスプロトコル。
This document describes privacy aspects that protocol designers should consider in addition to regular security analysis.
このドキュメントでは、定期的なセキュリティ分析に加えて、プロトコル設計者が考慮すべきプライバシーの側面について説明します。
We would like to thank Christine Runnegar for her extensive helpful review comments.
クリスティーン・ルネガーの広範囲にわたる有益なレビューコメントに感謝します。
We would like to thank Scott Brim, Kasey Chappelle, Marc Linsner, Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat Sakimura, Bjoern Hoehrmann, David Singer, Dean Willis, Lucy Lynch, Trent Adams, Mark Lizar, Martin Thomson, Josh Howlett, Mischa Tuffield, S. Moonesamy, Zhou Sujing, Claudia Diaz, Leif Johansson, Jeff Hodges, Stephen Farrell, Steven Johnston, Cullen Jennings, Ted Hardie, Dave Thaler, Klaas Wierenga, Adrian Farrel, Stephane Bortzmeyer, Dave Crocker, and Hector Santos for their useful feedback on this document.
Scott Brim、Kasey Chappelle、Marc Linsner、Bryan McLaughlin、Nick Mathewson、Eric Rescorla、Scott Bradner、Nat Sakimura、Bjoern Hoehrmann、David Singer、Dean Willis、Lucy Lynch、Trent Adams、Mark Lizar、Martin Thomson、ジョシュハウレット、ミーシャタフフィールド、S。ムーネサミー、周スージン、クローディアディアス、レイフヨハンソン、ジェフホッジス、スティーブンファレル、スティーブンジョンストン、カレンジェニングス、テッドハーディ、デイブターラー、クラースウィレンガ、エイドリアンファレル、ステファンボーツメイヤー、ディーンこのドキュメントに関する有益なフィードバックをくださったHector Santos。
Finally, we would like to thank the participants for the feedback they provided during the December 2010 Internet Privacy workshop co-organized by MIT, ISOC, W3C, and the IAB.
最後に、参加者に、MIT、ISOC、W3C、およびIABが共催する2010年12月のインターネットプライバシーワークショップ中に提供したフィードバックについて感謝の意を表します。
Although John Morris is currently employed by the U.S. Government, he participated in the development of this document in his personal capacity, and the views expressed in the document may not reflect those of his employer.
ジョンモリスは現在米国政府に雇用されていますが、この文書の作成には個人的に参加しており、文書に記載されている見解は彼の雇用主の見解を反映していない場合があります。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスキャロンアリッサクーパースペンサードーキンスジョエルハルパーンラスハウズリーエリオットリアシンリーアンドリューサリバンデイブターラーハネスチョーフェニグ
[CC-SA] Creative Commons, "Share Alike", 2012, <http://wiki.creativecommons.org/Share_Alike>.
[CC-SA]クリエイティブコモンズ、「Share Alike」、2012、<http://wiki.creativecommons.org/Share_Alike>。
[CC] Creative Commons, "Creative Commons", 2012, <http://creativecommons.org/>.
[CC]クリエイティブコモンズ、「クリエイティブコモンズ」、2012年、<http://creativecommons.org/>。
[CoE] Council of Europe, "Recommendation CM/Rec(2010)13 of the Committee of Ministers to member states on the protection of individuals with regard to automatic processing of personal data in the context of profiling", November 2010, <https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>.
[CoE]欧州評議会、「プロファイリングのコンテキストにおける個人データの自動処理に関する個人の保護に関する加盟国への閣僚委員会の勧告CM / Rec（2010）13」、2010年11月、<https： //wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>。
[EFF] Electronic Frontier Foundation, "Panopticlick", 2013, <http://panopticlick.eff.org>.
[EFF] Electronic Frontier Foundation、「Panopticlick」、2013、<http://panopticlick.eff.org>。
[FIPs] Gellman, B., "Fair Information Practices: A Basic History", 2012, <http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>.
[FIPs] Gellman、B。、「Fair Information Practices：A Basic History」、2012、<http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>。
[OECD] Organisation for Economic Co-operation and Development, "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data", (adopted 1980), September 2010, <http://www.oecd.org/>.
[OECD]経済協力開発機構、「プライバシーの保護と個人データの越境フローに関するOECDガイドライン」（1980年に採択）、2010年9月、<http://www.oecd.org/>。
[PbD] Office of the Information and Privacy Commissioner, Ontario, Canada, "Privacy by Design", 2013, <http://privacybydesign.ca/>.
[PbD] Office of the Information and Privacy Commissioner、オンタリオ、カナダ、「Privacy by Design」、2013、<http://privacybydesign.ca/>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「A Presence and Instant Messagingのモデル」、RFC 2778、2000年2月。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC2779] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「Instant Messaging / Presence Protocol Requirements」、RFC 2779、2000年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「Trusted Networks内のAsserted IdentityのためのSession Initiation Protocol（SIP）のプライベート拡張」、RFC 3325、2002年11月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859] Peterson、J。、「Common Profile for Presence（CPP）」、RFC 3859、2004年8月。
[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.
[RFC3922] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）to Common Presence and Instant Messaging（CPIM）」、RFC 3922、2004年10月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]スタンリー、D。、ウォーカー、J。、およびB.アボバ、「ワイヤレスLANの拡張認証プロトコル（EAP）メソッドの要件」、RFC 4017、2005年3月。
[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
[RFC4079] Peterson、J。、「GEOPRIVロケーションオブジェクトの配布のためのプレゼンスアーキテクチャ」、RFC 4079、2005年7月。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101] Rescorla、E。およびIAB、「Writing Protocol Models」、RFC 4101、2005年6月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187] Arkko、J。およびH. Haverinen、「Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement（EAP-AKA）」、RFC 4187、2006年1月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745] Schulzrinne、H.、Tschofenig、H.、Morris、J.、Cuellar、J.、Polk、J.、J。Rosenberg、「Common Policy：A Document Format for Expressing Privacy Preferences」、RFC 4745、2月2007年
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918] Dusseault、L。、「Web Distributed Authoring and Versioning（WebDAV）のHTTP拡張機能」、RFC 4918、2007年6月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
[RFC5025] Rosenberg、J。、「Presence Authorization Rules」、RFC 5025、2007年12月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、RFC 5077、2008年1月。
[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
[RFC5106] Tschofenig、H.、Kroeselberg、D.、Pashalidis、A.、Ohba、Y。、およびF. Bersani、「Extensible Authentication Protocol-Internet Key Exchange Protocol version 2（EAP-IKEv2）Method」、RFC 5106 、2008年2月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、2011年6月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302] Durand、A.、Gashinsky、I.、Lee、D。、およびS. Sheppard、「インターネットに面したサーバーのロギングに関する推奨事項」、BCP 162、RFC 6302、2011年6月。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
[RFC6350] Perreault、S。、「vCard Format Specification」、RFC 6350、2011年8月。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
[RFC6562]パーキンス、C。およびJM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、2012年3月。
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, September 2012.
[RFC6716] Valin、JM。、Vos、K。、およびT. Terriberry、「Definition of the Opus Audio Codec」、RFC 6716、2012年9月。
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.
[RFC6772] Schulzrinne、H.、Tschofenig、H.、Cuellar、J.、Polk、J.、Morris、J。、およびM. Thomson、「Geolocation Policy：A Document Format for Express Privacy Preferences for Location Information」、RFC 6772、2013年1月。
[Solove] Solove, D., "Understanding Privacy", March 2010.
[Solove] Solove、D。、「Understanding Privacy」、2010年3月。
[Tor] The Tor Project, Inc., "Tor", 2013, <https://www.torproject.org/>.
[Tor] The Tor Project、Inc.、「Tor」、2013、<https://www.torproject.org/>。
[Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey of Westin's Studies", December 2005, <http://reports-archive.adm.cs.cmu.edu/anon/isri2005/ CMU-ISRI-05-138.pdf>.
[ウェスティン]クマラグル、P。およびL.クラナー、「プライバシーインデックス：ウェスティンの研究の調査」、2005年12月、<http://reports-archive.adm.cs.cmu.edu/anon/isri2005/ CMU-ISRI -05-138.pdf>。
Authors' Addresses
著者のアドレス
Alissa Cooper CDT 1634 Eye St. NW, Suite 1100 Washington, DC 20006 US
アリッサクーパーCDT 1634アイセントNW、スイート1100ワシントンDC 20006 US
Phone: +1-202-637-9800
EMail: acooper@cdt.org
URI: http://www.cdt.org/
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Bernard Aboba Skype
バーナードアボバスカイプ
EMail: bernard_aboba@hotmail.com
Jon Peterson NeuStar, Inc. 1800 Sutter St. Suite 570 Concord, CA 94520 US
Jon Peterson NeuStar、Inc. 1800 Sutter St. Suite 570 Concord、CA 94520 US
EMail: jon.peterson@neustar.biz
John B. Morris, Jr.
ジョン・B・モリス・ジュニア
EMail: ietf@jmorris.org
Marit Hansen ULD
マリット・ハンセンULD
EMail: marit.hansen@datenschutzzentrum.de
Rhys Smith Janet
リース・スミス・ジャネット
EMail: rhys.smith@ja.net