pEp Foundation

Oberer Graben 4 CH-8400 Winterthur Switzerland volker.birk@pep.foundation https://pep.foundation/

pEp Foundation

Oberer Graben 4 CH-8400 Winterthur Switzerland hernani.marques@pep.foundation https://pep.foundation/

Ucom Standards Track Solutions GmbH

CH-8046 Zuerich Switzerland +41 44 500 52 44 bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) https://ucom.ch/

This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes verification processes (e.g., comparison of fingerprints), more practical and less prone to misunderstandings.

In public-key cryptography comparing the public keys’ fingerprints of the communication partners involved is vital to ensure that there is no man-in-the-middle (MITM) attack on the communication channel. Fingerprints normally consist of a chain of hexadecimal chars. However, comparing hexadecimal strings is often impractical for regular human users and prone to misunderstandings. To mitigate these challenges, several systems offer the comparison of Trustwords as an alternative to hexadecimal strings. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes the verification process more natural for human users. For example, in pEp’s proposition of Privacy by Default Trustwords are used to achieve easy contact verification for end-to-end encryption. Trustword comparison is offered after the peers have exchanged public keys opportunistically. Examples for Trustword lists used by current pEp implementations can be found in CSV format, here: https://pep.foundation/dev/repos/pEpEngine/file/tip/db. In addition to contact verification, Trustwords are also used for other purposes, such as Human-Readable 128-bit Keys , One Time Passwords (OTP) , SSH host-key verification, VPN Server certificate verification, and to import or synchronize secret key across different devices of the same user . Further ideas include to use Trustwords for contact verification in Extensible Messaging and Presence Protocol (XMPP) , for X.509 certificate verification in browsers or in block chain applications for crypto currencies.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in . pEp Handshake: The process when Alice – e.g., in-person or via phone – contacts Bob to verify Trustwords (or by fallback: fingerprints) is called pEp Handshake. Man-in-the-middle attack (MITM): cf.

A fingerprint typically looks like: F482 E952 2F48 618B 01BC 31DC 5428 D7FA ACDC 3F13 Its mapping to English Trustwords could look like: dog house brother town fat bath school banana kite task Or its mapping to German Trustwords could like like: klima gelb lappen weg trinken alles kaputt rasen rucksack durch Instead of the former hexadecimal string, users can compare ten common words of their language. Note: This examples are for illustration purposes only and do not make use any any published Trustword list.

The basic concept of Trustwords mapping has been already documented in the past, e.g. for use in One-Time Passwords (OTP) or the PGP Word List (“Pretty Good Privacy word list” , also called a biometric word list, to compare fingerprints. Regarding today’s needs, previous proposals have the following shortcomings: Limited number of Trustwords (small Trustword dictionaries), which generally results in more Trustwords to be compared Usually only available in English language, which does not normally allow its usage by non-English speakers in a secure manner Furthermore, there are differences in the basic concept: This work allows for better tailoring the target audience to ordinary human users, i.e. not technical stuff (or IT geeks) only. As in many usage scenarios the Trustwords are only read (and compared), but not written down nor typed in by humans, there is a less strong need to keep the Trustwords themselves short. One such scenario is to use a side channel (e.g. phone) to compare the Trustwords. In fact longer Trustwords increases increase the entropy, as the dictionary is larger and the likelihood for phonetic collision can be decreased.

If the number of Trustwords is low, a lot of Trustwords need to be compared, which make a comparison somewhat cumbersome for users. This may lead to degraded usability. To reduce the number of Trustwords to compare, in pEp’s proposition of Privacy by Default 16-bit scalars are mapped to natural language words. Therefore, the size (by number of key – value pairs) of any key – value pair structure is 65536. However, the number of unique values to be used in a language may be less than 65536. This can be addressed e.g. by using the same value (Trustword) for more than one key. In these cases, the entropy of the representation is slightly reduced. (Example: A Trustwords list of just 42000 words still allows for an entropy of log_2(42000) ~= 15.36 bits in 16-bit mappings.) On the other hand, small sized Trustword lists allow for Trustwords with shorter strings, which are easier to use in scenarios where Trustwords have to be typed in e.g. OTP applications. The specification allows for different dictionary sizes.

Although English is rather widespread around the world, the vast majority of the worlds’ population does not speak English. For an application to be useful for ordinary people, localization is a must. Thus, Trustword lists in different languages can be registered. For applications where two human establish communication it is very likely that they share a common language. So far no real use case for translations between Trustword lists in different languages has been identified. As translations also drastically increases the complexity for IANA registrations, translations of Trustwords beyond the scope of this document.

Every Trustwords list SHOULD be cleared from swearwords in order to not offense users. This is a task to be carried out by speakers of the respective natural language (i.e., by native language speakers).

Each natural language requires a different set of Trustwords. To allow implementers for identical Trustword lists, a IANA registry is to be established. The IANA registration policy according to is “Expert Review” and “Specification Required”. [[ Note: Further details of the IANA registry and requirements for the expert to assess the specification are for further study. A similar approach as used in is likely followed. ]]

first second [...] last ]]>

Authors of a Wordlist are encouraged to use these XML chunks as a template to create the IANA Registration Template.

An IANA registration will contain the fallowing elements:

The language code follows the ISO 639-3 specification , e.g., eng, deu. [[ Note: It is for further study, which of the ISO 639 Specifications is most suitable to address the Trustwords’ challenge. ]] Example usage for German:

deu ]]>

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 ^ (<bitsize>). Example usage for 16-bit Wordlist:

16 ]]>

The number of unique words that are registered.

65536 ]]>

Whether the registered Wordlist has a one-to-one mapping, meaning the number of unique words registered equals 2 ^ (<bitsize>). Valid content: ( yes | no )

yes ]]>

The version of the Wordlist MUST be unique within a language code. [[ Note: Requirements to a “smart” composition of the version number are for further study ]]

b.1.2 ]]>

Reference(s) to the Document(s) containing the Wordlist

e.g. (obsoleted by RFC 9999) e.g. [International Telecommunications Union, "Wordlist for Foobar application", ITU-F Recommendation B.193, Release 73, Mar 2009.] ]]>

The persons requesting the registration of the Wordlist. Usually these are the authors of the Wordlist.

John Doe Example Inc. mailto:john.doe@example.com 2018-06-20 ]]>

Note: If there is more than one requester, there must be one <xref> element per requester in the <requesters> element, and one <person> chunk per requester in the <people> element.

Any other information the authors deem interesting.

more info goes here ]]>

Note: If there is no such additional information, then the <additionalinfo> element is omitted.

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 for enumeration of the Trustwords (starting at 0) and the elements contains the values being individual natural language words in the respective language.

first second [...] last ] ]> ]]>

[[ Note: The exact representation of the Wordlist is for further study. ]]

There are no special security considerations.

The authors would like to thank the following people who have provided feedback or significant contributions to the development of this document: Andrew Sullivan, Claudio Luck, Daniel Kahn Gilmore, Michael Richardson, Rich Salz, and Yoav Nir. This work was initially created by pEp Foundation, and then reviewed and extended with funding by the Internet Society’s Beyond the Net Programme on standardizing pEp.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226. The pretty Easy privacy (pEp) protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure end-to-end interpersonal messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer-to-peer synchronization of private keys and other user data across devices). pEp also introduces means to verify communication peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME), and are written with the intent to be interoperable with already widely-deployed systems in order to facilitate and ease adoption and implementation. This document outlines the general design choices and principles of pEp. This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK] This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK] The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] In interpersonal messaging end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks. This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily authenticate their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp). Early draft

This section contains a non-normative example of the IANA Registration Template XML chunk.

lat 16 57337 no n.0.1 This Wordlist has been optimized for the Roman Standards Process. errare humanum [...] est Julius Caesar Curia Romana mailto:julius.cesar@example.com 1999-12-31 ]]>

[[ RFC Editor: This section is to be removed before publication ]] draft-birk-pep-trustwords-02: Minor editorial changes and bug fixes Added more items to Open Issues Add usage example draft-birk-pep-trustwords-01: Included feedback from mailing list and IETF-101 SECDISPATCH WG, e.g. Added more explanatory text / less focused on the main use case Bit size as parameter Explicitly stated translations are out-of-scope for this document Added draft IANA XML Registration template, considerations, explanation and examples Added Changelog to Appendix Added Open Issue section to Appendix

[[ RFC Editor: This section should be empty and is to be removed before publication ]] More explanatory text for Trustword use cases, properties and requirements Further details of the IANA registry and requirements for the expert to assess the specification 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 implementations (running code) or ISO-693-3 (eng, deu, ita, …) Adjust exact representation of wordlists e.g. XML, CSV, … Syntax for non-ASCII letters or language symbols (UTF-8) in Wordlists Need for optional entropy value assigned to words, to account for similar phonetics among words in the same wordlist? Need for an additional field, to define what a wordlist is optimized for, e.g., “entropy”, “minimize word lengths”, …? Work out (requirements for) “smart” composition of the version number Decide whether in non-bijective Wordlists the redundant words need to be repeated in the IANA Registration Register only a hash over the wordlist with IANA? Does it make sense to open registrations for other patterns than just words, e.g., images? Create terms section by file inclusion - cf. other drafts