< draft-birk-pep-trustwords-03.txt   draft-birk-pep-trustwords-04.txt >
Network Working Group V. Birk Network Working Group B. Hoeneisen
Internet-Draft H. Marques Internet-Draft Ucom.ch
Intended status: Standards Track pEp Foundation Intended status: Standards Track H. Marques
Expires: September 12, 2019 B. Hoeneisen Expires: January 9, 2020 pEp Foundation
Ucom.ch July 08, 2019
March 11, 2019
IANA Registration of Trustword Lists: Guide, Template and IANA IANA Registration of Trustword Lists: Guide, Template and IANA
Considerations Considerations
draft-birk-pep-trustwords-03 draft-birk-pep-trustwords-04
Abstract Abstract
This document specifies the IANA Registration Guidelines for This document specifies the IANA Registration Guidelines for
Trustwords, describes corresponding registration procedures, and Trustwords, describes corresponding registration procedures, and
provides a guideline for creating Trustword list specifications. provides a guideline for creating Trustword list specifications.
Trustwords are common words in a natural language (e.g., English) to Trustwords are common words in a natural language (e.g., English),
which the hexadecimal strings are mapped to. This makes verification which hexadecimal strings are mapped to. Such a mapping makes
processes (e.g., comparison of fingerprints), more practical and less verification processes like fingerprint comparisons more practical,
prone to misunderstandings. and less prone to misunderstandings.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. The Concept of Trustword Mapping . . . . . . . . . . . . . . 3 1.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Concept of Trustword Mapping . . . . . . . . . . . . . . 4
3.2. Previous work . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Number of Trustwords for a language . . . . . . . . . . . 4 2.2. Previous work . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Language . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Number of Trustwords for a language . . . . . . . . . . . 5
3.5. The nature of the words . . . . . . . . . . . . . . . . . 5 2.4. Language . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 2.5. The nature of the words . . . . . . . . . . . . . . . . . 6
4.1. Registration Template (XML chunk) . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4.2. IANA Registration . . . . . . . . . . . . . . . . . . . . 7 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
4.2.1. Language Code (<languagecode>) . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Bit Size (<bitsize>) . . . . . . . . . . . . . . . . 7 5.1. Registration Template (XML chunk) . . . . . . . . . . . . 6
4.2.3. Number Of Unique Words (<numberofuniquewords>) . . . 7 5.2. IANA Registration . . . . . . . . . . . . . . . . . . . . 8
4.2.4. Bijectivity (<bijective>) . . . . . . . . . . . . . . 8 5.2.1. Language Code (<languagecode>) . . . . . . . . . . . 8
4.2.5. Version (<version>) . . . . . . . . . . . . . . . . . 8 5.2.2. Bit Size (<bitsize>) . . . . . . . . . . . . . . . . 8
4.2.6. Registration Document(s) (<registrationdocs>) . . . . 8 5.2.3. Number Of Unique Words (<numberofuniquewords>) . . . 8
4.2.7. Requesters (<requesters>) . . . . . . . . . . . . . . 8 5.2.4. Bijectivity (<bijective>) . . . . . . . . . . . . . . 8
4.2.8. Further Information (<additionalinfo>) . . . . . . . 9 5.2.5. Version (<version>) . . . . . . . . . . . . . . . . . 8
4.2.9. Wordlist (<wordlist>) . . . . . . . . . . . . . . . . 9 5.2.6. Registration Document(s) (<registrationdocs>) . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.2.7. Requesters (<requesters>) . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5.2.8. Further Information (<additionalinfo>) . . . . . . . 9
5.2.9. Wordlist (<wordlist>) . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. IANA XML Template Example . . . . . . . . . . . . . 12 Appendix A. IANA XML Template Example . . . . . . . . . . . . . 12
Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 12 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 13
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
In public-key cryptography comparing the public keys' fingerprints of In public-key cryptography, comparing the respective public key
the communication partners involved is vital to ensure that there is fingerprints for each of the communication partners involved is vital
no man-in-the-middle (MITM) attack on the communication channel. to ensure that there is no Man-in-the-Middle (MITM) attack on the
Fingerprints normally consist of a chain of hexadecimal chars. communication channel. These fingerprints normally consist of a
However, comparing hexadecimal strings is often impractical for chain of hexadecimal characters, which are often impractical,
regular human users and prone to misunderstandings. cumbersome, and prone to misunderstandings for end-users.
To mitigate these challenges, several systems offer the comparison of To mitigate these challenges, several systems offer Trustword
Trustwords as an alternative to hexadecimal strings. Trustwords are comparison as an alternative to these hexadecimal strings.
common words in a natural language (e.g., English) to which the Trustwords are common words in a natural language (e.g., English),
hexadecimal strings are mapped to. This makes the verification which these hexadecimal strings are mapped to. Using Trustwords
process more natural for human users. makes verification processes like fingerprint comparisons more
natural for users.
For example, in pEp's proposition of Privacy by Default For example, in pEp's Privacy by Default proposition [I-D.birk-pep]
[I-D.birk-pep] Trustwords are used to achieve easy contact Trustwords are used to facilitate easy contact verification for end-
verification for end-to-end encryption. Trustword comparison is to-end encryption. Trustword comparison is offered after the peers
offered after the peers have exchanged public keys opportunistically. have opportunistically exchanged public keys. Examples of Trustword
Examples for Trustword lists used by current pEp implementations can lists used by current pEp implementations can be found here in CSV
be found in CSV format, here: format: https://pep.foundation/dev/repos/pEpEngine/file/tip/db.
https://pep.foundation/dev/repos/pEpEngine/file/tip/db.
In addition to contact verification, Trustwords are also used for In addition to contact verification, Trustwords are also used for
other purposes, such as Human-Readable 128-bit Keys [RFC1751], One other purposes, such as Human-Readable 128-bit Keys [RFC1751], One
Time Passwords (OTP) [RFC1760] [RFC2289], SSH host-key verification, Time Passwords (OTP) [RFC1760] [RFC2289], SSH host-key verification,
VPN Server certificate verification, and to import or synchronize VPN server certificate verification, deriving private keys in
secret key across different devices of the same user blockchain applications for cryptocurrencies, and to import or
[E-D.birk-pep-keysync]. Further ideas include to use Trustwords for synchronize secret keys across multiple devices owned by a single
contact verification in Extensible Messaging and Presence Protocol user [I-D.hoeneisen-pep-keysync]. Further ideas include the use of
(XMPP) [RFC6120], for X.509 [RFC3647] certificate verification in Trustwords for private key recovery in case of loss, contact
browsers or in block chain applications for crypto currencies. verification in Extensible Messaging and Presence Protocol (XMPP)
[RFC6120], or for X.509 certificate verification in browsers
[RFC3647].
2. Terms 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
o pEp Handshake: The process when Alice - e.g., in-person or via 1.2. Terms
phone - contacts Bob to verify Trustwords (or by fallback:
fingerprints) is called pEp Handshake. The following terms are defined for the scope of this document:
o pEp Handshake: The process of one user contacting another over an
independent channel in order to verify Trustwords (or by fallback:
fingerprints). This can be done in-person or through established
verbal communication channels, like a phone call.
[I-D.marques-pep-handshake] [I-D.marques-pep-handshake]
o Man-in-the-middle attack (MITM): cf. [RFC4949] o Man-in-the-middle (MITM) attack: cf. [RFC4949], which states: "A
form of active wiretapping attack in which the attacker intercepts
and selectively modifies communicated data to masquerade as one or
more of the entities involved in a communication association."
3. The Concept of Trustword Mapping 2. The Concept of Trustword Mapping
3.1. Example 2.1. Example
A fingerprint typically looks like: As already discussed, fingerprints normally consist of a string of
hexadecimal characters. A typical fingerprint looks like this:
F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13
Its mapping to English Trustwords could look like: Instead of the hexadecimal string, Trustwords allow users to compare
ten common words of a language of their choosing. For example, the
above fingerprint, mapped to English Trustwords, might appear as:
dog house brother town fat bath school banana kite task dog house brother town fat bath school banana kite task
Or its mapping to German Trustwords could like like: The same fingerprint might appear in German Trustwords as:
klima gelb lappen weg trinken alles kaputt rasen rucksack durch klima gelb lappen weg trinken alles kaputt rasen rucksack durch
Instead of the former hexadecimal string, users can compare ten Note: These examples are for illustration purposes only, and are not
common words of their language. derived from any published Trustword list.
Note: This examples are for illustration purposes only and do not 2.2. Previous work
make use any any published Trustword list.
3.2. Previous work The basic concept of Trustword mapping - also known as a biometric
word list - for fingerprint comparison is well-documented. Examples
of this concept are used with One-Time Passwords (OTP) [RFC1751]
[RFC1760] [RFC2289], as well as the PGP Word List ("Pretty Good
Privacy word list" [PGP.wl]. Furthermore, cryptocurrencies use a
similar concept for deriving private keys [bitcoin.wl].
The basic concept of Trustwords mapping has been already documented [[ TODO: Explain each previous usage a bit further and synchronize
in the past, e.g. for use in One-Time Passwords (OTP) [RFC1751] with section Section 1. ]]
[RFC1760] [RFC2289] or the PGP Word List ("Pretty Good Privacy word
list" [PGP.wl], also called a biometric word list, to compare
fingerprints.
Regarding today's needs, previous proposals have the following Regarding today's needs, previous proposals have the following
shortcomings: shortcomings:
o Limited number of Trustwords (small Trustword dictionaries), which o Small/limited word lists, which generally result in more words to
generally results in more Trustwords to be compared compare
o Usually only available in English language, which does not o Existing word lists are usually only available in English, which
normally allow its usage by non-English speakers in a secure limits their usefulness for non-English speakers
manner
Furthermore, there are differences in the basic concept: Furthermore, there are differences in the basic concept:
o This work allows for better tailoring the target audience to o The Trustword concept suggested herein intends to improve
ordinary human users, i.e. not technical stuff (or IT geeks) only. usability and security for all users, instead of only the
technically-savvy.
o As in many usage scenarios the Trustwords are only read (and o In many use cases, Trustwords are only read (aloud) during the
compared), but not written down nor typed in by humans, there is a comparison process, rather than being written or typed. For
less strong need to keep the Trustwords themselves short. One example, two users might compare their respective Trustwords
such scenario is to use a side channel (e.g. phone) to compare the during a phone call. Verbal comparison reduces the need to keep
Trustwords. In fact longer Trustwords increases increase the the actual Trustwords short. The use of longer Trustwords
entropy, as the dictionary is larger and the likelihood for increases the entropy within the system, as it allows for a larger
phonetic collision can be decreased. dictionary, and thus reduces the likelihood of phonetic
collisions.
3.3. Number of Trustwords for a language 2.3. Number of Trustwords for a language
If the number of Trustwords is low, a lot of Trustwords need to be If the number of Trustwords in a dictionary is low, shorter parts of
compared, which make a comparison somewhat cumbersome for users. the original string (e.g., fingerprint) can be mapped to a single
This may lead to degraded usability. Trustword. Thus, many Trustwords will need to be compared, which
results in a potentially cumbersome process for users, and lead to
reduced usability.
To reduce the number of Trustwords to compare, in pEp's proposition To reduce the number of Trustwords that need to be compared, pEp's
of Privacy by Default [I-D.birk-pep] 16-bit scalars are mapped to Privacy by Default proposition [I-D.birk-pep] calls for 16-bit
natural language words. Therefore, the size (by number of key - scalars to be mapped to natural language words. Therefore, the size
value pairs) of any key - value pair structure is 65536. However, (by number of key-value pairs) of any key-value pair structure is
the number of unique values to be used in a language may be less than 65536. However, the number of unique values to be used in a language
65536. This can be addressed e.g. by using the same value may be smaller than this number. This discrepancy can be addressed
(Trustword) for more than one key. In these cases, the entropy of by using the same value, or Trustword, for more than one key. In
the representation is slightly reduced. (Example: A Trustwords list such cases, the entropy of the representation is slightly reduced.
of just 42000 words still allows for an entropy of log_2(42000) ~= For example, a Trustword list of 42000 words still allows for an
15.36 bits in 16-bit mappings.) entropy of log_2(42000), which is roughly 15.36 bits in 16-bit
mappings. As a consequence such Trustword lists are not bijective.
On the other hand, small sized Trustword lists allow for Trustwords On the other hand, small Trustword lists allow for Trustwords
with shorter strings, which are easier to use in scenarios where consisting of words with shorter strings (number of short words per
Trustwords have to be typed in e.g. OTP applications. natural language is normally limited), which are easier to use in
implementations where Trustwords have to be typed or written, such as
in OTP applications.
The specification allows for different dictionary sizes. Note: This specification allows for registration of variable numbers
of Trustwords per dictionary.
3.4. Language 2.4. Language
Although English is rather widespread around the world, the vast Although English is used around the world, the vast majority of the
majority of the worlds' population does not speak English. For an global population is not English-speaking. For an application to be
application to be useful for ordinary people, localization is a must. useful to as wide of a user base as possible, localization is
Thus, Trustword lists in different languages can be registered. essential. Therefore, this specification allows for registration of
Trustword lists in different languages.
For applications where two human establish communication it is very In applications where two humans are attempting to establish secure
likely that they share a common language. So far no real use case communications, it is likely that they share a common language. At
for translations between Trustword lists in different languages has this time, no real-world use cases for Trustword list translation
been identified. As translations also drastically increases the capability have been identified. Because the translation process
complexity for IANA registrations, translations of Trustwords beyond inherently - and drastically - increases complexity from an IANA
registration standpoint, the topic of Trustword translation is beyond
the scope of this document. the scope of this document.
3.5. The nature of the words 2.5. The nature of the words
Every Trustwords list SHOULD be cleared from swearwords in order to Every Trustword list SHOULD be clear of offensive language (i.e.,
not offense users. This is a task to be carried out by speakers of swear/curse words, slurs, derogatory language, etc.). This process
the respective natural language (i.e., by native language speakers). SHOULD be performed by native speakers of each respective language.
4. IANA Considerations 3. Security Considerations
There are no specific security considerations.
4. Privacy Considerations
[[ TODO ]]
5. IANA Considerations
Each natural language requires a different set of Trustwords. To Each natural language requires a different set of Trustwords. To
allow implementers for identical Trustword lists, a IANA registry is allow implementers for identical Trustword lists, a IANA registry is
to be established. The IANA registration policy according to to be established. The IANA registration policy according to
[RFC8126] is "Expert Review" and "Specification Required". [RFC8126] is "Expert Review" and "Specification Required".
[[ Note: Further details of the IANA registry and requirements for [[ Note: Further details of the IANA registry and requirements for
the expert to assess the specification are for further study. A the expert to assess the specification are for further study. A
similar approach as used in [RFC6117] is likely followed. ]] similar approach as used in [RFC6117] is likely followed. ]]
4.1. Registration Template (XML chunk) 5.1. Registration Template (XML chunk)
<record> <record>
<languagecode> <languagecode>
<!-- ISO 639-3 (e.g. eng, deu, ...) --> <!-- ISO 639-3 (e.g. eng, deu, ...) -->
</languagecode> </languagecode>
<bitsize> <bitsize>
<!-- How many bits can be mapped with this list <!-- How many bits can be mapped with this list
(e.g. 8, 16, ...) --> (e.g. 8, 16, ...) -->
</bitsize> </bitsize>
<numberofuniquewords> <numberofuniquewords>
skipping to change at page 7, line 17 skipping to change at page 8, line 5
<org> <!-- Organization Name --> </org> <org> <!-- Organization Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri> <uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated> <updated> <!-- date format YYYY-MM-DD --> </updated>
</person> </person>
<!-- repeat person section for each person --> <!-- repeat person section for each person -->
</people> </people>
Authors of a Wordlist are encouraged to use these XML chunks as a Authors of a Wordlist are encouraged to use these XML chunks as a
template to create the IANA Registration Template. template to create the IANA Registration Template.
4.2. IANA Registration 5.2. IANA Registration
An IANA registration will contain the fallowing elements: An IANA registration will contain the fallowing elements:
4.2.1. Language Code (<languagecode>) 5.2.1. Language Code (<languagecode>)
The language code follows the ISO 639-3 specification [ISO693], e.g., The language code follows the ISO 639-3 specification [ISO639], e.g.,
eng, deu. eng, deu.
[[ Note: It is for further study, which of the ISO 639 Specifications [[ Note: It is for further study, which of the ISO 639 Specifications
is most suitable to address the Trustwords' challenge. ]] is most suitable to address the Trustwords' challenge. ]]
Example usage for German: Example usage for German:
e.g. <languagecode>deu</languagecode> e.g. <languagecode>deu</languagecode>
4.2.2. Bit Size (<bitsize>) 5.2.2. Bit Size (<bitsize>)
The bit size is the number of bits that can be mapped with the The bit size is the number of bits that can be mapped with the
Wordlist. The number of registered words in a word list MUST be 2 ^ Wordlist. The number of registered words in a word list MUST be 2 ^
"(<bitsize>)". "(<bitsize>)".
Example usage for 16-bit Wordlist: Example usage for 16-bit Wordlist:
e.g. <bitsize>16</bitsize> e.g. <bitsize>16</bitsize>
4.2.3. Number Of Unique Words (<numberofuniquewords>) 5.2.3. Number Of Unique Words (<numberofuniquewords>)
The number of unique words that are registered. The number of unique words that are registered.
e.g. <numberofuniquewords>65536</numberofuniquewords> e.g. <numberofuniquewords>65536</numberofuniquewords>
4.2.4. Bijectivity (<bijective>) 5.2.4. Bijectivity (<bijective>)
Whether the registered Wordlist has a one-to-one mapping, meaning the Whether the registered Wordlist has a one-to-one mapping, meaning the
number of unique words registered equals 2 ^ "(<bitsize>)". number of unique words registered equals 2 ^ "(<bitsize>)".
Valid content: ( yes | no ) Valid content: ( yes | no )
e.g. <bijective>yes</bijective> e.g. <bijective>yes</bijective>
4.2.5. Version (<version>) 5.2.5. Version (<version>)
The version of the Wordlist MUST be unique within a language code. The version of the Wordlist MUST be unique within a language code.
[[ Note: Requirements to a "smart" composition of the version number [[ Note: Requirements to a "smart" composition of the version number
are for further study ]] are for further study ]]
e.g. <version>b.1.2</version> e.g. <version>b.1.2</version>
4.2.6. Registration Document(s) (<registrationdocs>) 5.2.6. Registration Document(s) (<registrationdocs>)
Reference(s) to the Document(s) containing the Wordlist Reference(s) to the Document(s) containing the Wordlist
e.g. <registrationdocs> e.g. <registrationdocs>
<xref type="rfc" data="rfc4979"/> <xref type="rfc" data="rfc4979"/>
</registrationdocs> </registrationdocs>
e.g. <registrationdocs> e.g. <registrationdocs>
<xref type="rfc" data="rfc8888"/> (obsoleted by RFC 9999) <xref type="rfc" data="rfc8888"/> (obsoleted by RFC 9999)
<xref type="rfc" data="rfc9999"/> <xref type="rfc" data="rfc9999"/>
</registrationdocs> </registrationdocs>
e.g. <registrationdocs> e.g. <registrationdocs>
[International Telecommunications Union, [International Telecommunications Union,
"Wordlist for Foobar application", "Wordlist for Foobar application",
ITU-F Recommendation B.193, Release 73, Mar 2009.] ITU-F Recommendation B.193, Release 73, Mar 2009.]
</registrationdocs> </registrationdocs>
4.2.7. Requesters (<requesters>) 5.2.7. Requesters (<requesters>)
The persons requesting the registration of the Wordlist. Usually The persons requesting the registration of the Wordlist. Usually
these are the authors of the Wordlist. these are the authors of the Wordlist.
e.g. <requesters> e.g. <requesters>
<xref type="person" data="John_Doe"/> <xref type="person" data="John_Doe"/>
</requesters> </requesters>
<people> <people>
<person id="John_Doe"> <person id="John_Doe">
skipping to change at page 9, line 22 skipping to change at page 9, line 47
<org>Example Inc.</org> <org>Example Inc.</org>
<uri>mailto:john.doe@example.com</uri> <uri>mailto:john.doe@example.com</uri>
<updated>2018-06-20</updated> <updated>2018-06-20</updated>
</person> </person>
</people> </people>
Note: If there is more than one requester, there must be one <xref> Note: If there is more than one requester, there must be one <xref>
element per requester in the <requesters> element, and one <person> element per requester in the <requesters> element, and one <person>
chunk per requester in the <people> element. chunk per requester in the <people> element.
4.2.8. Further Information (<additionalinfo>) 5.2.8. Further Information (<additionalinfo>)
Any other information the authors deem interesting. Any other information the authors deem interesting.
e.g. <additionalinfo> e.g. <additionalinfo>
<paragraph>more info goes here</paragraph> <paragraph>more info goes here</paragraph>
</additionalinfo> </additionalinfo>
Note: If there is no such additional information, then the Note: If there is no such additional information, then the
<additionalinfo> element is omitted. <additionalinfo> element is omitted.
4.2.9. Wordlist (<wordlist>) 5.2.9. Wordlist (<wordlist>)
The full Wordlist to be registered. The number of words MUST be a The full Wordlist to be registered. The number of words MUST be a
power of 2 as specified above. The element names serve as key used power of 2 as specified above. The element names serve as key used
for enumeration of the Trustwords (starting at 0) and the elements for enumeration of the Trustwords (starting at 0) and the elements
contains the values being individual natural language words in the contains the values being individual natural language words in the
respective language. respective language.
e.g. <wordlist> e.g. <wordlist>
<w0>first</w0> <w0>first</w0>
<w1>second</w1> <w1>second</w1>
[...] [...]
<w65535>last<w65535> <w65535>last<w65535>
</wordlist> </wordlist>
] ]> ] ]>
[[ Note: The exact representation of the Wordlist is for further [[ Note: The exact representation of the Wordlist is for further
study. ]] study. ]]
5. Security Considerations 6. Acknowledgments
There are no special security considerations.
6. Acknowledgements
The authors would like to thank the following people who have The authors would like to thank the following people who have
provided feedback or significant contributions to the development of provided feedback or significant contributions to the development of
this document: Andrew Sullivan, Claudio Luck, Daniel Kahn Gilmore, this document: Andrew Sullivan, Claudio Luck, Daniel Kahn Gilmore,
Michael Richardson, Rich Salz, and Yoav Nir. Kelly Bristol, Michael Richardson, Rich Salz, Volker Birk, and Yoav
Nir.
This work was initially created by pEp Foundation, and then reviewed This work was initially created by pEp Foundation, and then reviewed
and extended with funding by the Internet Society's Beyond the Net and extended with funding by the Internet Society's Beyond the Net
Programme on standardizing pEp. [ISOC.bnet] Programme on standardizing pEp. [ISOC.bnet]
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 10, line 40 skipping to change at page 11, line 16
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References 7.2. Informative References
[E-D.birk-pep-keysync] [bitcoin.wl]
Birk, V. and H. Marques, "pretty Easy privacy (pEp): Key "Seed Phrase", June 2019, <https://en.bitcoin.it/w/
Synchronization Protocol", June 2018, index.php?title=Seed_phrase&oldid=66492#Word_Lists>.
<https://pep.foundation/dev/repos/internet-
drafts/file/tip/pep-keysync/
draft-birk-pep-keysync-NN.txt>.
Early draft
[I-D.birk-pep] [I-D.birk-pep]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Privacy by Default", draft-birk-pep-03 (work in progress), Privacy by Default", draft-birk-pep-03 (work in progress),
March 2019. March 2019.
[I-D.hoeneisen-pep-keysync]
Hoeneisen, B. and H. Marques, "pretty Easy privacy (pEp):
Key Synchronization Protocol", draft-hoeneisen-pep-
keysync-00 (work in progress), July 2019.
[I-D.marques-pep-handshake] [I-D.marques-pep-handshake]
Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
Contact and Channel Authentication through Handshake", Contact and Channel Authentication through Handshake",
draft-marques-pep-handshake-01 (work in progress), October draft-marques-pep-handshake-03 (work in progress), July
2018. 2019.
[ISO693] "Language codes - ISO 639", n.d., [ISO639] "Language codes - ISO 639", n.d.,
<https://www.iso.org/iso-639-language-codes.html>. <https://www.iso.org/iso-639-language-codes.html>.
[ISOC.bnet] [ISOC.bnet]
Simao, I., "Beyond the Net. 12 Innovative Projects Simao, I., "Beyond the Net. 12 Innovative Projects
Selected for Beyond the Net Funding. Implementing Privacy Selected for Beyond the Net Funding. Implementing Privacy
via Mass Encryption: Standardizing pretty Easy privacy's via Mass Encryption: Standardizing pretty Easy privacy's
protocols", June 2017, <https://www.internetsociety.org/ protocols", June 2017, <https://www.internetsociety.org/
blog/2017/06/12-innovative-projects-selected-for-beyond- blog/2017/06/12-innovative-projects-selected-for-beyond-
the-net-funding/>. the-net-funding/>.
skipping to change at page 12, line 49 skipping to change at page 13, line 44
<org>Curia Romana</org> <org>Curia Romana</org>
<uri>mailto:julius.cesar@example.com</uri> <uri>mailto:julius.cesar@example.com</uri>
<updated>1999-12-31</updated> <updated>1999-12-31</updated>
</person> </person>
</people> </people>
Appendix B. Document Changelog Appendix B. Document Changelog
[[ RFC Editor: This section is to be removed before publication ]] [[ RFC Editor: This section is to be removed before publication ]]
o draft-birk-pep-trustwords-04:
* Add Privacy Considerations section
* Swapped Security and IANA Consideration Sections
* Corrected typo in ISO references
* Updated Introduction, Terms and concept Sections
o draft-birk-pep-trustwords-03:
* Update references
* Minor edits
o draft-birk-pep-trustwords-02: o draft-birk-pep-trustwords-02:
* Minor editorial changes and bug fixes * Minor editorial changes and bug fixes
* Added more items to Open Issues * Added more items to Open Issues
* Add usage example * Add usage example
o draft-birk-pep-trustwords-01: o draft-birk-pep-trustwords-01:
* Included feedback from mailing list and IETF-101 SECDISPATCH * Included feedback from mailing list and IETF-101 SECDISPATCH
WG, e.g. WG, e.g.
+ Added more explanatory text / less focused on the main use + Added more explanatory text / less focused on the main use
skipping to change at page 13, line 31 skipping to change at page 14, line 42
* Added draft IANA XML Registration template, considerations, * Added draft IANA XML Registration template, considerations,
explanation and examples explanation and examples
* Added Changelog to Appendix * Added Changelog to Appendix
* Added Open Issue section to Appendix * Added Open Issue section to Appendix
Appendix C. Open Issues Appendix C. Open Issues
[[ RFC Editor: This section should be empty and is to be removed [[ RFC Editor: This section should be empty and is to be removed
before publication ]] before publication. ]]
o Better explain previous work on Trustwords
o More explanatory text for Trustword use cases, properties and o More explanatory text for Trustword use cases, properties and
requirements requirements
o Further details of the IANA registry and requirements for the o Further details of the IANA registry and requirements for the
expert to assess the specification expert to assess the specification
o Decide which ISO language code either 639-1 or 639-3 to use, i.e., o Decide which ISO language code either 639-1 or 639-3 to use, i.e.,
ISO-639-1 (e.g., ca, de, en, ...) as currently used in pEp ISO-639-1 (e.g., ca, de, en, ...) as currently used in pEp
implementations (running code) or ISO-693-3 (eng, deu, ita, ...) implementations (running code) or ISO-639-3 (eng, deu, ita, ...)
o Adjust exact representation of wordlists o Adjust exact representation of wordlists
* e.g. XML, CSV, ... * e.g. XML, CSV, ...
* Syntax for non-ASCII letters or language symbols (UTF-8) in * Syntax for non-ASCII letters or language symbols (UTF-8) in
Wordlists Wordlists
o Need for optional entropy value assigned to words, to account for o Need for optional entropy value assigned to words, to account for
similar phonetics among words in the same wordlist? similar phonetics among words in the same wordlist?
skipping to change at page 14, line 19 skipping to change at page 15, line 33
number number
o Decide whether in non-bijective Wordlists the redundant words need o Decide whether in non-bijective Wordlists the redundant words need
to be repeated in the IANA Registration to be repeated in the IANA Registration
o Register only a hash over the wordlist with IANA? o Register only a hash over the wordlist with IANA?
o Does it make sense to open registrations for other patterns than o Does it make sense to open registrations for other patterns than
just words, e.g., images? just words, e.g., images?
o Create terms section by file inclusion - cf. other drafts
Authors' Addresses Authors' Addresses
Volker Birk Bernie Hoeneisen
pEp Foundation Ucom Standards Track Solutions GmbH
Oberer Graben 4 CH-8046 Zuerich
CH-8400 Winterthur
Switzerland Switzerland
Email: volker.birk@pep.foundation Phone: +41 44 500 52 40
URI: https://pep.foundation/ Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: https://ucom.ch/
Hernani Marques Hernani Marques
pEp Foundation pEp Foundation
Oberer Graben 4 Oberer Graben 4
CH-8400 Winterthur CH-8400 Winterthur
Switzerland Switzerland
Email: hernani.marques@pep.foundation Email: hernani.marques@pep.foundation
URI: https://pep.foundation/ URI: https://pep.foundation/
Bernie Hoeneisen
Ucom Standards Track Solutions GmbH
CH-8046 Zuerich
Switzerland
Phone: +41 44 500 52 44
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: https://ucom.ch/
 End of changes. 65 change blocks. 
168 lines changed or deleted 213 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/