One document matched: draft-iab-privacy-terminology-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3325 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY RFC6265 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY I-D.iab-privacy-considerations SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iab-privacy-considerations.xml">
<!ENTITY I-D.iab-identifier-comparison SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iab-identifier-comparison.xml">
<!ENTITY RFC3748 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC4017 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml">
<!ENTITY RFC4282 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY RFC4187 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml">
<!ENTITY RFC4949 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5106 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5106.xml">
<!ENTITY RFC6350 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6350.xml">
<!ENTITY RFC5077 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY RFC5246 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
]>
<rfc ipr="trust200902" category="info" docName="draft-iab-privacy-terminology-01.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no"?>
<?rfc compact="no"?>
<?rfc strict="no"?>
<front>
<title>Privacy Terminology and Concepts</title>
<author initials="M." surname="Hansen" fullname="Marit Hansen">
<organization>ULD Kiel</organization>
<address>
<email>marit.hansen@datenschutzzentrum.de</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="R." surname="Smith" fullname="Rhys Smith">
<organization>JANET(UK)</organization>
<address>
<email>rhys.smith@ja.net</email>
</address>
</author>
<author initials="A." surname="Cooper" fullname="Alissa Cooper">
<organization>CDT</organization>
<address>
<email>acooper@cdt.org</email>
</address>
</author>
<date year="2012"/>
<abstract>
<t>Privacy is a concept that has been debated and argued throughout the last few millennia. Its most striking feature is the difficulty that disparate parties encounter when they attempt to precisely define it. In order to discuss privacy in a meaningful way, a tightly defined context is necessary. The specific context of privacy used within this document is that of personal data in Internet protocols. Personal data is any information relating to a data subject, where a data subject is an identified natural person or a natural person who can be identified, directly or indirectly.
</t>
<t>
A lot of work within the IETF involves defining protocols that can potentially transport (either explicitly or implicitly) personal data. This document aims to establish a consistent lexicon around privacy for IETF contributors to use when discussing privacy considerations within their work.</t>
<t>Note: This document is discussed at https://www.ietf.org/mailman/listinfo/ietf-privacy </t>
</abstract>
</front>
<middle>
<!-- **************************************************************************************** -->
<section anchor="intro" title="Introduction">
<t>
Privacy is a concept that has been debated and argued throughout the last few millennia by all manner of people, including philosophers, psychologists, lawyers, and more recently, computer scientists. Its most striking feature is the difficulty that disparate parties encounter when they attempt to precisely define it. Each individual, group, and culture has its own views and preconceptions about privacy, some of which are mutually complimentary and some of which diverge. However, it is generally (but not unanimously) agreed that the protection of privacy is "A Good Thing." People often do not realize how they value privacy until they lose it.
</t>
<!-- <t>
Even within the specific content of computing and computer science, there are still many facets to privacy. For example, consideration of privacy in terms of personal information is distinctly different from consideration of privacy in a geographical information sense: in the former a loss of privacy might be framed as the uncontrolled release of personal information without the subject's consent, while in the latter it might be the ability to compute the location of an individual beyond a certain degree of accuracy.
</t>-->
<t>
In order to discuss privacy in a meaningful way, a tightly defined context is necessary. The specific context of privacy used within this document is that of "personal data" in Internet protocols. Personal data is any information relating to a data subject, where a data subject is an identified natural person or a natural person who can be identified, directly or indirectly. </t>
<t>A lot of work within the IETF involves defining protocols that can potentially transport personal data. Protocols are therefore capable of enabling both privacy protections and privacy breaches.
Protocol architects often do not assume a specific relationship between the identifiers and data elements communicated in protocols and the humans using the software running the protocols. However, a protocol may facilitate the identification of a natural person depending on how protocol identifiers and other state are created and communicated. <!-- For example, multiple hosts used by different persons may be attached to an single Internet gateway within a household. From the Internet Service Provider point of view all these devices belong to a single person: the subscriber with whom a contract was established. In this specific context, discussions of privacy largely centre around the collection minimalization, the usage, and release of such personal data.-->
</t>
<t>
One commonly held privacy objective is that of data minimization -- eliminating the potential for personal data to be collected. Often, however, the collection of personal data cannot not be prevented entirely, in which case the goal is to minimize the amount of personal data that can be collected for a given purpose and to offer ways to control the dissemination of personal data. This document focuses on introducing terms used to describe privacy properties that support data minimization.
</t>
<t>Other techniques have been proposed and implemented that aim to enhance privacy by providing misinformation (inaccurate or erroneous information, provided usually without conscious effort to mislead or deceive) or disinformation (deliberately false or distorted information provided in order to mislead or deceive). These techniques are out of scope for this document.
</t>
<t>
This document aims to establish a basic lexicon around privacy so that IETF contributors who wish to discuss privacy considerations within their work (see <xref target="I-D.iab-privacy-considerations"/>) can do so using terminology consistent across areas. Note that it does not attempt to define all aspects of privacy terminology, rather it discusses terms describing the most common ideas and concepts.
</t>
</section>
<!-- **************************************************************************************** -->
<section title="Basic Terms">
<t>
<list style="hanging">
<t hangText="Personal data:">Any information relating to a data subject.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Data subject:">An identified natural person or a natural person who can be identified, directly or indirectly.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Item of Interest (IOI):">Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, communication actions (such as sending data to or receiving data from certain communication partners), etc.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Initiator:">The protocol entity that starts a communication interaction with a recipient. The term "initiator" is used rather than "sender" to highlight the fact that many protocols use bidirectional communication where both ends send and receive data</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Recipient:">A protocol entity that recieves communications from an initiator.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Attacker:">An entity that intentionally works against some protection goal. It is assumed that an attacker uses all information available to infer information about its items of interest. <!-- When necessary for the understanding of the definition we qualify the capabilities of the observer in the communication architecture. [I have no idea what the last sentence means. -ALC]--> </t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Observer:">A protocol entity that is authorized to receive and handle data from an initiator and thereby is able to observe and collect information, potentially posing privacy threats depending on the context. These entities are not generally considered as "attackers" in the security sense, but they are still capable of privacy invasion.
</t>
</list>
</t>
</section>
<!-- **************************************************************************************** -->
<section title="Identifiability">
<t>
<list style="hanging">
<t hangText="Identity:">Any subset of a data subject's attributes that identifies the
data subject within a given context. Data subjects usually have
multiple identities for use in different contexts.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Identifier:">A data object that represents a specific identity of a protocol entity or data subject. See <xref target="RFC4949" />.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Identifiability:">The extent to which a data subject is identifiable.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Identification:">The linking of information to a particular data subject to infer
the subject's identity.
</t>
</list>
</t>
<t>The following sub-sections define terms related to different ways of reducing identifiability. </t>
<section title="Anonymity">
<t>
<list style="hanging">
<t hangText="Anonymous:">A property of a data subject in which an observer or attacker cannot identify the data subject within a set of other subjects (the anonymity set).</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Anonymity:">The state of being anonymous.</t>
</list>
</t>
<t>To enable anonymity of a data subject, there must exist a set of data subjects with potentially the same attributes, i.e., to the attacker or the observer these data subjects must appear indistinguishable from each other. The set of all such data subjects is known as the anonymity set and membership of this set may vary over time. <!-- [What does it mean for the subjects to have "potentially" the same attributes?-ALC]--> </t>
<t>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 data subjects that may initiate communications. Conversely, a recipient may be anonymous only within a set of potential receipients -- its receipient anonymity set. Both anonymity sets may be disjoint, may overlap, or may be the same.
</t>
<t>As an example consider RFC 3325 (P-Asserted-Identity, PAI) <xref target="RFC3325"/>, an extension for the Session Initiation Protocol (SIP), that allows a data subject, such as a VoIP caller, to instruct an intermediary that he or she trusts not to populate the SIP From header field with the subject's authenticated and verified identity. The recipient of the call, as well as any other entity outside of the data subject'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 subject's address-of-record, which is typically thought of as the "public address" of the user (the data subject). When PAI is used, the data subject becomes anonymous within the initiator anonymity set that is populated by every data subject making use of that specific intermediary.
</t>
<t>Note: This example ignores the fact that other personal data may be inferred from the other SIP protocol payloads. This caveat makes the analysis of the specific protocol extension easier but cannot be assumed when conducting analysis of an entire architecture.</t>
</section>
<section title="Pseudonymity">
<t>
<list style="hanging">
<t hangText="Pseudonym:">An identifier of a subject other than one of the
subject's real names.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Real name:">The opposite of a pseudonym. For example, a natural person may possess the names that
appear on his or her birth certificate or on other official identity documents issued by the
state. A natural person's real name typically comprises his or her given names and a family name. A data subject may have multiple real names over a lifetime, including legal names. Note that
from a technological perspective it cannot always be determined whether an
identifier of a data subject is a pseudonym or a real name.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Pseudonymous:">A property of a data subject in which the subject is identified by
a pseudonym.</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Pseudonymity:">The state of being pseudonymous.</t>
</list>
</t>
<t>In the context of IETF protocols almost all identifiers are pseudonyms since there is typically no requirement
to use real names in protocols. However, in certain scenarios it is reasonable to assume that real names
will be used (with vCard <xref target="RFC6350" />, for example). </t>
<t>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).</t>
<t>For Internet protocols it is important whether protocols allow pseudonyms to be changed without human interaction,
the default length of pseudonym lifetimes, to whom pseudonyms are exposed,
how data subjects are able to control disclosure, how often
pseudonyms can be changed, and the consequences of changing them.
These aspects are described in <xref target="I-D.iab-privacy-considerations"/>.</t>
<!-- Example with a transaction pseudonym here. -->
</section>
<section title="Identity Confidentiality">
<t>
<list style="hanging">
<t hangText="Identity confidentiality:">A property of a data subject wherein any party other than the recipient
cannot sufficiently identify the data subject within the anonymity set. In comparison to anonymity and pseudonymity, identity confidentiality is concerned with eavesdroppers and intermediaries.
</t>
</list>
</t>
<t>As an example, consider the network access authentication procedures utilizing the Extensible Authentication
Protocol (EAP) <xref target="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 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. To address this treat, as discussed in RFC 4282 <xref target="RFC4282"/>, the user's identity can be hidden against these observers with the cryptography support by EAP methods. Identity confidentiality has become a recommended design criteria for EAP (see <xref target="RFC4017"/>). EAP-AKA <xref target="RFC4187"/>, for example, protects the EAP peer's identity against passive adversaries by utilizing temporal identities. EAP-IKEv2 <xref target="RFC5106"/> is an example of an EAP method that offers protection against active observers with regard to the data subject's identity.</t>
</section>
<section title="Identity Management">
<t>
<list style="hanging">
<t hangText="Identity Provider (IdP):">An entity (usually an organization) that has a relationship with a data subject and is responsible for providing authentication and authorization information to relying parties (see below). To facilitate the provision of authentication and authorization, an IdP will usually go through a process of verifying the data subject's identity and issuing the subject a set of credentials. Each function that the IdP performs -- identity verification, credential issuing, providing authentication assertions, providing authorization assertions, and so forth -- may be performed by separate entities, but for the purposes of this document, it is assumed that a single entity is performing all of them.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Relying Party (RP):">An entity that relies on authentication and authorization of a data subject provided by an identity provider, typically to process a transaction or grant access to information or a system.
</t>
</list>
</t>
<!--
<t>
<list style="hanging">
<t hangText="Recipient identity anonymity:">A property of a recipient wherein the recipient's identity is kept anonymous from the initiator. For example, consider an identity management scenario, which is a three party scenario, where an identity provider, who manages the data subjects credentials and attributes, shall not observe activities of data subjects throughout the Internet as they interact with relying parties. [I do not understand this example at all. Who is the initiator? Who is the recipient? Also, isn't "identity anonymity" redundant? Isn't all of anonymity about hiding identity? If not, what else is it about? -ALC]</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="Initiator identity anonymity:"> A property of an initiator wherein the initiator remains anonymous towards the recipient. Within the identity management scenario the initiator role corresponds to the identity provider and the recipients are the relying parties. As such, with this property a relying party will not determine the identity provider used by a data subject for a given transaction. [Again I don't understand this. Are we talking about not revealing the identity of the identity provider to the relying party? Doesn't the relying party need to know the identity of the identity provider in order to do transactions with it? Also, why do we even care about the identity of the identity provider? It seems to me that the protecting the identity of the data subject that uses the identity provider is the much more relevant topic. -ALC]</t>
</list>
</t>
-->
</section>
</section>
<!--
****************************************************************************************
-->
<section anchor="unlinkability" title="Unlinkability">
<t>
<list style="hanging">
<t hangText="Unlinkability:"> Within a particular
set of information, a state in which an observer or attacker cannot
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).</t>
</list>
</t>
<t>Unlinkability of two or more messages may depend on whether their content is
protected against the observer or attacker. In the cases where this is not true, messages may only be unlinkable if it is
assumed that the observer or attacker is not able to infer information about the initiator or receipient from the
message content itself. It is worth noting that even if the content itself does not betray linkable information explicitly, deep semantic analysis of a message sequence can often detect certain characteristics that link them
together, including similarities in structure, style, use of particular words or phrases, consistent
appearance of certain grammatical errors, and so forth.
</t>
<!-- <t>
The unlinkability property can be considered as a more fine-grained version of anonymity
since there are many more relations where unlinkability might be problematic that the single relation
of "anonymity" between data subjects and IOIs. [I tried to edit the previous sentence but I don't really know what it means. -ALC] As such, it may be necessary to explicitly
state which attributes anonymity refers to (beyond the subject-to-IOI relationship).
An observer or attacker might be able to link various messages while not necessarily weakening anonymity
of a particular data subject. As an example, an observer, in spite of being able to link
all encrypted messages in a set of transactions, may not learn the identify of the data subject that
is the source of the transactions.
</t>
-->
<t>
There are several items of terminology highly related to unlinkability:
</t>
<t>
<list style="hanging">
<t hangText="Correlation:">The combination of various pieces of information about a data subject. <!-- while that subject remains anonymous to the observer--> For example, if an observer or attacker concludes that a data subject
plays a specific computer game, reads a specific news article on a website, and uploads specific videos, then the data subject's activities have been correlated, even if the observer or attacker is unable to identify the specific data subject. <!-- [Swapped in correlation here to be consistent with considerations doc. -ALC]--></t>
<t hangText="Relationship anonymity:">When an initiator and receipient (or each
recipient in the case of multicast) are unlinkable. The classical MIX-net <xref target="Chau81"/>
without dummy traffic is one implementation with this property: the observer sees who sends and receives messages and when they are sent and received, but it cannot figure out who is sending messages
to whom.
</t>
<t hangText="Unlinkable protocol interaction:">When one protocol interaction is not linkable to another protocol interaction of the same protocol. <vspace blankLines="1"/>
<!-- refers the ability to render
a set of actions by a subject unlinkable from one another over a sequence of protocol runs (sessions).-->
An example of a protocol that does not provide this property is Transport Layer Security (TLS) session resumption <xref target="RFC5246"/> or the TLS session resumption without server side state <xref target="RFC5077"/>. In RFC 5246 <xref target="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 <xref target="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 is exchanged in clear (which is the case with data exchange in the initial handshake messages).
<!--
This term is useful for cases where a sequence of interactions between an initiator and a recipient is necessary for the application logic rather than a single-shot message. We refer to this as a session. When doing an analysis with respect to unlinkability we compare this session to a sequence of sessions to determine whether or not they are linkable. [I don't really understand what is meant by "session" here. -ALC] -->
</t>
<t hangText="Fingerprinting:">The process of an observer or attacker partially or fully
identifying a device, application, or initiator based on multiple
information elements communicated to the observer or attacker. For example, the Panopticlick project by the Electronic Frontier Foundation uses parameters an HTTP-based Web browser shares with sites it visits to determine the uniqueness of the browser <xref target="panopticlick"/>.
</t>
</list>
</t>
</section>
<!--
****************************************************************************************
-->
<section anchor="undetectability" title="Undetectability">
<t>
<list style="hanging">
<t hangText="Undetectability:"> The state in which an observer or attacker cannot sufficiently distinguish whether an item of interest exists or
not.</t>
</list>
</t>
<t>In contrast to anonymity and unlinkability, where the IOI is protected indirectly through protection of the IOI's relationship to a subject or other IOI, undetectability means the IOI is directly protected.
For example, undetectability is as a desirable property of steganographic
systems.</t>
<t>If we consider the case where an IOI is a message, then undetectability means that the message is not sufficiently discernible from other messages (from, e.g., random noise).</t>
<t>Achieving anonymity, unlinkability, and undetectability may enable extreme data minimization. Unfortunately, this would also prevent a certain class of useful two-way communication scenarios.
Therefore, for many
applications, a certain amount of linkability and detectability is usually accepted while attempting to retain unlinkability between the data subject and his or her transactions. This is achieved through the use of appropriate kinds of pseudonymous identifiers. These identifiers are then often used to refer
to established state or are used for access control purposes, see <xref target="I-D.iab-identifier-comparison"/>. <!-- [This para seems like it needs to be at the end since it discusses undetectability, but right now there is no concluding section in which to put it, so I put it here for now. -ALC]--> </t>
</section>
<!--
****************************************************************************************
-->
<!--
<section anchor="known-mechs"
title="Known Mechanisms for Anonymity, Undetectability, and Unobservability">
<t>Before it makes sense to speak about any particular mechanisms for anonymity,
undetectability, and unobservability in communications, let us first remark that all of them
assume that stations of users do not emit signals the observer considered is able to use for
identification of stations or their behavior or even for identification of users or their
behavior. So if you travel around taking with you a mobile phone sending more or less
continuously signals to update its location information within a cellular radio network,
don't be surprised if you are tracked using its signals. If you use a computer emitting lots
of radiation due to a lack of shielding, don't be surprised if observers using high-tech
equipment know quite a bit about what's happening within your machine. If you use a
computer, PDA, or smartphone without sophisticated access control, don't be surprised if
Trojan horses send your secrets to anybody interested whenever you are online - or via
electromagnetic emanations even if you think you are completely offline.</t>
<t>DC-net <xref target="Chau85"/>, <xref target="Chau88"/>, and MIX-net <xref target="Chau81"
/> are mechanisms to achieve initiator anonymity and relationship anonymity, respectively, both
against strong observers. If we add dummy traffic, both provide for the corresponding
unobservability <xref target="PfPW91"/>. If dummy traffic is used to pad sending and/or
receiving on the initiator's and/or recipient's line to a constant rate traffic, MIX-nets can
even provide initiator and/or recipient anonymity and unobservability. </t>
<t>Broadcast <xref target="Chau85"/>, <xref target="PfWa86"/>, <xref target="Waid90"/> and
private information retrieval <xref target="CoBi95"/> are mechanisms to achieve recipient
anonymity against strong observers. If we add dummy traffic, both provide for recipient
unobservability.</t>
<t> This may be summarized: A mechanism to achieve some kind of anonymity appropriately
combined with dummy traffic yields the corresponding kind of unobservability.</t>
<t> Of course, dummy traffic alone can be used to make the number and/or length of sent
messages undetectable by everybody except for the recipients; respectively, dummy traffic
can be used to make the number and/or length of received messages undetectable by everybody
except for the initiators. (Note: Misinformation and disinformation may be regarded as semantic
dummy traffic, i.e., communication from which an observer cannot decide which are real
requests with real data or which are fake ones. Assuming the authenticity of misinformation
or disinformation may lead to privacy problems for (innocent) bystanders.) </t>
<t>As a side remark, we mention steganography and spread spectrum as two other well-known
undetectability mechanisms.</t>
<t> The usual concept to achieve undetectability of IOIs at some layer, e.g., sending
meaningful messages, is to achieve statistical independence of all discernible phenomena at
some lower implementation layer. An example is sending dummy messages at some lower layer to
achieve, e.g., a constant rate flow of messages looking - by means of encryption - randomly
for all parties except the initiator and the recipient(s). </t>
</section>
-->
<!--
****************************************************************************************
-->
<!--
<section anchor="known-other" title="Known mechanisms and other properties of pseudonyms">
<t>A digital pseudonym could be realized as a public key to test digital signatures where the
holder of the pseudonym can prove holdership by forming a digital signature which is created
using the corresponding private key <xref target="Chau81"/>. The most prominent example for
digital pseudonyms are public keys generated by the user himself/herself, e.g., using PGP.
In using PGP, each user may create an unlimited number of key pairs by himself/herself (at
this moment, such a key pair is an initially unlinked pseudonym), bind each of them to an
e-mail address, self-certify each public key by using his/her digital signature or asking
another introducer to do so, and circulate it.</t>
<t>A public key certificate bears a digital signature of a so-called certification authority
and provides some assurance to the binding of a public key to another pseudonym, usually
held by the same subject. In case that pseudonym is the civil identity (the real name) of a
subject, such a certificate is called an identity certificate. An attribute certificate is a
digital certificate which contains further information (attribute values) and clearly refers
to a specific public key certificate. Independent of certificates, attributes may be used as
identifiers of sets of subjects as well. Normally, attributes refer to sets of subjects
(i.e., the anonymity set), not to one specific subject.</t>
<t>There are several other properties of pseudonyms related to their use, such as revocation,
lifetime of the pseudonym, non-transferability, frequency of pseudonym changeover, the
ability to reveal civil identities in case of abuse, etc. Some of the properties may require
extension of the digital pseudonym by attributes of some kind. The binding of attributes to
a pseudonym can be documented in an attribute certificate produced either by the holder
himself/herself or by a certification authority.
</t>
</section>
-->
<!--
****************************************************************************************
-->
<section title="Example">
<t>[To be provided in a future version once the guidance is settled.]</t>
</section>
<!--
****************************************************************************************
-->
<section anchor="acks" title="Acknowledgments">
<t>Parts of this document utilizes content from <xref target="anon_terminology"/>, which had a long history starting in
2000 and whose quality was improved due to the feedback from a number of people. The authors would like to thank Andreas Pfitzmann for his work on an earlier draft version of this
document.</t>
<t>Within the IETF a number of persons had provided their feedback to this document. We would like to thank Scott Brim, Marc Linsner, Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat Sakimura, Bjoern Hoehrmann,
David Singer, Dean Willis, Christine Runnegar, Lucy Lynch, Trend Adams, Mark Lizar, Martin Thomson, Josh Howlett, Mischa Tuffield, S. Moonesamy, Ted Hardie, Zhou Sujing, Claudia Diaz, Leif Johansson, and Klaas Wierenga.
</t>
</section>
<!--
****************************************************************************************
-->
<section anchor="security" title="Security Considerations">
<t>This document introduces terminology for talking about privacy within IETF specifications. Since
privacy protection often relies on security mechanisms then this document is also related to security
in its broader context.</t>
</section>
<!--
****************************************************************************************
-->
<section anchor="iana" title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!--
****************************************************************************************
-->
</middle>
<back>
<references title="Normative References">
&I-D.iab-privacy-considerations;
<reference anchor="id">
<front>
<title>Identifier - Wikipedia</title>
<author/>
<date year="2011" month="Dec" />
</front>
<seriesInfo name="Wikipedia" value=", URL: http://en.wikipedia.org/wiki/Identifier"/>
</reference>
</references>
<references title="Informative References">
&RFC3325;
&I-D.iab-identifier-comparison;
&RFC6265;
&RFC3748;
&RFC4017;
&RFC4282;
&RFC4187;
&RFC4949;
&RFC5106;
&RFC6350;
&RFC5077;
&RFC5246;
<reference anchor="panopticlick">
<front>
<title>How Unique Is Your Web Browser?</title>
<author fullname="Peter Eckersley" initials="P." surname="Eckersley"> </author>
<date year="2009"/>
</front>
<seriesInfo name="Electronig Frontier Foundation" value=", URL: https://panopticlick.eff.org/browser-uniqueness.pdf"/>
</reference>
<reference anchor="Chau81">
<front>
<title>Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms</title>
<author fullname="David Chaum" initials="D." surname="Chaum"> </author>
<date year="1981"/>
</front>
<seriesInfo name="Communications of the ACM" value=", 24/2, 84-88"/>
</reference>
<reference anchor="anon_terminology">
<front>
<title>A terminology for talking about privacy by data minimization:
Anonymity, Unlinkability, Undetectability, Unobservability,
Pseudonymity, and Identity Management</title>
<author fullname="Andreas Pfitzmann" initials="A." surname="Pfitzmann"> </author>
<author fullname="Marit Hansen" initials="M." surname="Hansen"> </author>
<date year="2010"/>
</front>
<seriesInfo name="URL: http://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf" value=", version 034"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:25:02 |