Remove review files.

pep-trustwords/review/draft-birk-pep-trustwords-04-pre20190707-KRB.txt

@@ -1,940 +0,0 @@
-
-**[krb] Note: I've just rewritten the entire paragraph for any changes
-I suggest, unless it is just one or two words to fix. That way, you can
-just copy-paste the changes (if they're all acceptable) without having
-to retype. Hopefully that cuts down on some of the work?
-
-
-Network Working Group                                       B. Hoeneisen
-Internet-Draft                                                   Ucom.ch
-Intended status: Standards Track                              H. Marques
-Expires: January 8, 2020                                  pEp Foundation
-                                                           July 07, 2019
-
-
-     IANA Registration of Trustword Lists: Guide, Template and IANA
-                             Considerations
-                      draft-birk-pep-trustwords-04
-
-Abstract
-
-   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.
-**[krb] "Trustwords are common words in a natural language (e.g., English),
-which hexadecimal strings are mapped to.  Trustwords make verification
-processes like fingerprint comparisons more practical, and less prone to
-misunderstandings."
-
-Status of This Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at https://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on January 8, 2020.
-
-Copyright Notice
-
-   Copyright (c) 2019 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
-   (https://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 1]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
-     1.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.  The Concept of Trustword Mapping  . . . . . . . . . . . . . .   4
-     2.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
-     2.2.  Previous work . . . . . . . . . . . . . . . . . . . . . .   4
-     2.3.  Number of Trustwords for a language . . . . . . . . . . .   5
-     2.4.  Language  . . . . . . . . . . . . . . . . . . . . . . . .   5
-     2.5.  The nature of the words . . . . . . . . . . . . . . . . .   5
-   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
-   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
-     5.1.  Registration Template (XML chunk) . . . . . . . . . . . .   6
-     5.2.  IANA Registration . . . . . . . . . . . . . . . . . . . .   7
-       5.2.1.  Language Code (<languagecode>)  . . . . . . . . . . .   7
-       5.2.2.  Bit Size (<bitsize>)  . . . . . . . . . . . . . . . .   8
-       5.2.3.  Number Of Unique Words (<numberofuniquewords>)  . . .   8
-       5.2.4.  Bijectivity (<bijective>) . . . . . . . . . . . . . .   8
-       5.2.5.  Version (<version>) . . . . . . . . . . . . . . . . .   8
-       5.2.6.  Registration Document(s) (<registrationdocs>) . . . .   8
-       5.2.7.  Requesters (<requesters>) . . . . . . . . . . . . . .   9
-       5.2.8.  Further Information (<additionalinfo>)  . . . . . . .   9
-       5.2.9.  Wordlist (<wordlist>) . . . . . . . . . . . . . . . .  10
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
-     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
-   Appendix A.  IANA XML Template Example  . . . . . . . . . . . . .  12
-   Appendix B.  Document Changelog . . . . . . . . . . . . . . . . .  13
-   Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  14
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
-
-1.  Introduction
-
-   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.
-**[krb] "In public-key cryptography, comparing the respective public key
-fingerprints for each of the communication partners involved is vital to
-ensure that there is no Man-in-the-Middle (MitM) attack on the communication
-channel.  These fingerprints normally consist of a chain of hexadecimal
-characters, which are often impractical, cumbersome, and prone to
-misunderstandings for end-users."
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 2]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   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.
-**[krb] "To mitigate these challenges, several systems offer Trustword
-comparison as an alternative to these hexadecimal strings.  Trustwords
-are common words in a natural language (e.g., English), which these hexadecimal
-strings are mapped to.  Trustwords make verification processes like fingerprint
-comparisons more natural for users." (We keep saying "human users", which sounds odd.)
-
-   For example, in pEp's proposition of Privacy by Default
-   [I-D.birk-pep] 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.
-**[krb] "For example, in pEp's Privacy by Default proposition [I-D.birk-pep],
-Trustwords are used to facilitate easy contact verification for end-to-end
-encryption.  Trustword comparison is offered after the peers have
-opportunistically exchanged public keys.  Examples of Trustword lists
-used by current pEp implementations can be found here in CSV format:"
-
-   In addition to contact verification, Trustwords could also be used
-   for private key recovery in case of loss.
-
-   Currently Trustwords are also used for other purposes, such as Human-
-   Readable 128-bit Keys [RFC1751], One Time Passwords (OTP) [RFC1760]
-   [RFC2289], SSH host-key verification, VPN Server certificate
-   verification, and to import or synchronize secret key across
-   different devices of the same user [I-D.hoeneisen-pep-keysync].
-   Further ideas include to use Trustwords for contact verification in
-   Extensible Messaging and Presence Protocol (XMPP) [RFC6120], for
-   X.509 [RFC3647] certificate verification in browsers or in block
-   chain applications for crypto currencies.
-**[krb] "In addition to contact verification, Trustwords are also used
-for other purposes, such as Human-Readable 128-bit Keys [RFC1751], One
-Time Passwords (OTP) [RFC1760] [RFC2289], SSH host-key verification,
-VPN server certificate verification, and to import or synchronize secret
-keys across multiple devices owned by a single user [I-D-hoeneisen-pep-keysync].
-Further ideas include the use of Trustwords for contact verification in
-Extensible Messaging and Presence Protocol (XMPP) [RFC6120], for X.509
-certificate verification in browsers [RFC3647], or in blockchain
-applications for cryptocurrencies."
-
-1.1.  Requirements Language
-
-   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 [RFC2119].
-
-1.2.  Terms
-
-   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]
-
-   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."
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 3]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-2.  The Concept of Trustword Mapping
-
-2.1.  Example
-
-   A fingerprint typically looks like:
-**[krb] "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
-
-   Its mapping to English Trustwords could look like:
-**[krb] "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
-
-   Or its mapping to German Trustwords could like like:
-**[krb] "The same fingerprint might appear in German Trustwords as:"
-
-      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.
-**[krb] Moved, see above.
-
-   Note: This examples are for illustration purposes only and do not
-   make use any any published Trustword list.
-**[krb] "Note: These examples are for illustration purposes only, and
-are not derived from any published Trustword list."
-
-2.2.  Previous work
-
-   The basic concept of Trustwords mapping has been already documented
-   in the past, e.g. for use in One-Time Passwords (OTP) [RFC1751]
-   [RFC1760] [RFC2289] or the PGP Word List ("Pretty Good Privacy word
-   list" [PGP.wl], also called a biometric word list, to compare
-   fingerprints.  Furthermore, crypto-currencies are using a similar
-   concept for deriving private keys [bitcoin.wl].
-**[krb] "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]." I've already seen two different forms of it,
-so for consistency, I'm making a call to use 'cryptocurrency'/
-'cryptocurrencies' as one word through the I-D. Looks to be the more common way
-to write it, based on a quick search. Please find/replace to fix throughout.
-
-   Regarding today's needs, previous proposals have the following
-   shortcomings:
-
-   o  Limited number of Trustwords (small Trustword dictionaries), which
-      generally results in more Trustwords to be compared
-**[krb] "Small/limited Trustword dictionaries, which generally result in more Trustwords to compare"
-
-   o  Usually only available in English language, which does not
-      normally allow its usage by non-English speakers in a secure
-      manner
-**[krb] "Trustwords are usually only available in English, which limits their usefulness for non-English speakers"
-
-   Furthermore, there are differences in the basic concept:
-
-   o  This work allows for better tailoring the target audience to
-      ordinary human users, i.e. not technical stuff (or IT geeks) only.
-**[krb] "The Trustword concept improves usability and security for all users, instead of only the technically-savvy."
-
-   o  As in many usage scenarios the Trustwords are only read (and
-      compared), but not written down nor typed in by humans, there is a
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 4]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-      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.
-**[krb] "In many use cases, Trustwords are only read aloud during the
-comparison process, rather than being written or typed.  For example,
-two users might compare their respective Trustwords during a phone call.
-Verbal comparison reduces the need to keep the actual Trustwords short.
-The use of longer Trustwords increases the entropy within the system as
-it allows for a larger dictionary.  Larger dictionaries reduce the
-likelihood of phonetic collision."
-
-2.3.  Number of Trustwords for a language
-
-   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.
-**[krb] "If the number of Trustwords in a dictionary is low, many
-Trustwords will need to be compared.  This results in a comparison
-process that can be cumbersome for users, and lead to reduced
-usability." May wish to BRIEFLY clarify why this results in more Trustwords
-needing to be compared; is it because of duplicity issues or something
-like that? I've tried to google this and am still unclear.
-
-   To reduce the number of Trustwords to compare, in pEp's proposition
-   of Privacy by Default [I-D.birk-pep] 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.)
-**[krb] "To reduce the number of Trustwords that need to be compared,
-pEp's Privacy by Default proposition [I-D.birk-pep] calls for 16-bit
-scalars to be 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
-smaller than this number.  This discrepancy can be addressed by using
-the same value, or Trustword, for more than one key.  In such cases,
-the entropy of the representation is slightly reduced.  For example,
-a Trustword list of 42000 words still allows for an entropy of
-log_2(42000), which is roughly 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.
-**[krb] I'd suggest putting this in with the first paragraph, to illustrate
-the two sides of the problem, before giving pEp's approach.
-Suggest: "On the other hand, small Trustword lists allow for Trustwords
-with shorter strings (as in the original hexadecimal string can be shorter,
-or the words themselves can be shorter?), 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.
-**[krb] Which specification? pEp's proposed spec, or the Trustword
-spec as a whole? Need to add that. If it's pEp's, I'd put this
-sentence at the end of the relevant paragraph.
-
-2.4.  Language
-
-   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.
-**[krb] "Although English is used around the world, the vast majority
-of the global population is not English-speaking.  For an application
-to be useful to as wide of a user base as possible, localization is
-essential.  Therefore, 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.
-**[krb] "In applications where two humans are attempting to establish
-secure communications, it is likely that they share a common language.
-At this time, no real-world use cases for Trustword list translation
-capability have been identified.  Because the translation process
-inherently - and drastically - increases complexity from an IANA
-registration standpoint, the topic of Trustword translation is beyond
-the scope of this document."
-
-2.5.  The nature of the words
-
-   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).
-**[krb] "Every Trustword list SHOULD be clear of offensive language (i.e.,
-swear/curse words, slurs, derogatory language, etc.).  This process should
-be performed by native speakers of each respective language."
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 5]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-3.  Security Considerations
-
-   There are no special security considerations.
-
-4.  Privacy Considerations
-
-   [[ TODO ]]
-
-5.  IANA Considerations
-
-   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
-   [RFC8126] 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 [RFC6117] is likely followed. ]]
-
-5.1.  Registration Template (XML chunk)
-
-     <record>
-       <languagecode>
-         <!--  ISO 639-3 (e.g. eng, deu, ...) -->
-       </languagecode>
-       <bitsize>
-         <!-- How many bits can be mapped with this list
-              (e.g. 8, 16, ...) -->
-       </bitsize>
-       <numberofuniquewords>
-         <!-- number of unique words registered
-              (e.g. 256, 65536, ...) -->
-       </numberofuniquewords>
-       <bijective>
-         <!-- whether or not the list allows for a two-way-mapping
-              (e.g. yes, no) -->
-       </bijective>
-       <version>
-         <!-- version number within language
-              (e.g. b.1.2, n.0.1, ...)  -->
-       </version>
-       <registrationdocs>
-         <!-- Change accordingly -->
-         <xref type="rfc" data="rfc2551"/>
-       </registrationdocs>
-       <requesters>
-         <!-- Change accordingly -->
-         <xref type="person" data="John_Doe"/>
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 6]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-         <xref type="person" data="Jane_Dale"/>
-       </requesters>
-       <additionalinfo>
-         <paragraph>
-           <!-- Text with additional information about
-                the Wordlist to be registered -->
-         </paragraph>
-         <artwork>
-           <!-- There can be artwork sections, too -->
-         </artwork>
-       </additionalinfo>
-       <wordlist>
-         <!-- Change accordingly -->
-         <w0>first</w0>
-         <w1>second</w1>
-         [...]
-         <w65535>last<w65535>
-       </wordlist>
-     </record>
-
-     <people>
-       <person id="John_Doe">
-         <name> <!-- Firstname Lastname --> </name>
-         <org> <!-- Organization Name --> </org>
-         <uri> <!-- mailto: or http: URI --> </uri>
-         <updated> <!-- date format YYYY-MM-DD --> </updated>
-       </person>
-       <!-- repeat person section for each person -->
-     </people>
-
-   Authors of a Wordlist are encouraged to use these XML chunks as a
-   template to create the IANA Registration Template.
-
-5.2.  IANA Registration
-
-   An IANA registration will contain the fallowing elements:
-
-5.2.1.  Language Code (<languagecode>)
-
-   The language code follows the ISO 639-3 specification [ISO639], 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:
-
-   e.g.  <languagecode>deu</languagecode>
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 7]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-5.2.2.  Bit Size (<bitsize>)
-
-   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:
-
-   e.g.  <bitsize>16</bitsize>
-
-5.2.3.  Number Of Unique Words (<numberofuniquewords>)
-
-   The number of unique words that are registered.
-
-   e.g.  <numberofuniquewords>65536</numberofuniquewords>
-
-5.2.4.  Bijectivity (<bijective>)
-
-   Whether the registered Wordlist has a one-to-one mapping, meaning the
-   number of unique words registered equals 2 ^ "(<bitsize>)".
-
-   Valid content: ( yes | no )
-
-   e.g.  <bijective>yes</bijective>
-
-5.2.5.  Version (<version>)
-
-   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 ]]
-
-   e.g.  <version>b.1.2</version>
-
-5.2.6.  Registration Document(s) (<registrationdocs>)
-
-   Reference(s) to the Document(s) containing the Wordlist
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 8]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   e.g.  <registrationdocs>
-           <xref type="rfc" data="rfc4979"/>
-         </registrationdocs>
-
-   e.g.  <registrationdocs>
-           <xref type="rfc" data="rfc8888"/> (obsoleted by RFC 9999)
-           <xref type="rfc" data="rfc9999"/>
-         </registrationdocs>
-
-   e.g.  <registrationdocs>
-           [International Telecommunications Union,
-           "Wordlist for Foobar application",
-           ITU-F Recommendation B.193, Release 73, Mar 2009.]
-         </registrationdocs>
-
-5.2.7.  Requesters (<requesters>)
-
-   The persons requesting the registration of the Wordlist.  Usually
-   these are the authors of the Wordlist.
-
-   e.g.  <requesters>
-           <xref type="person" data="John_Doe"/>
-         </requesters>
-
-         <people>
-           <person id="John_Doe">
-             <name>John Doe</name>
-             <org>Example Inc.</org>
-             <uri>mailto:john.doe@example.com</uri>
-             <updated>2018-06-20</updated>
-           </person>
-         </people>
-
-   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.
-
-5.2.8.  Further Information (<additionalinfo>)
-
-   Any other information the authors deem interesting.
-
-   e.g.  <additionalinfo>
-           <paragraph>more info goes here</paragraph>
-         </additionalinfo>
-
-   Note: If there is no such additional information, then the
-   <additionalinfo> element is omitted.
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 9]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-5.2.9.  Wordlist (<wordlist>)
-
-   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.
-
-   e.g.  <wordlist>
-           <w0>first</w0>
-           <w1>second</w1>
-           [...]
-           <w65535>last<w65535>
-         </wordlist>
-
-   ] ]>
-
-   [[ Note: The exact representation of the Wordlist is for further
-   study.  ]]
-
-6.  Acknowledgements
-
-   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, Volker Birk, 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.  [ISOC.bnet]
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119,
-              DOI 10.17487/RFC2119, March 1997,
-              <https://www.rfc-editor.org/info/rfc2119>.
-
-   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
-              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
-              <https://www.rfc-editor.org/info/rfc4949>.
-
-   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
-              Writing an IANA Considerations Section in RFCs", BCP 26,
-              RFC 8126, DOI 10.17487/RFC8126, June 2017,
-              <https://www.rfc-editor.org/info/rfc8126>.
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 10]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-7.2.  Informative References
-
-   [bitcoin.wl]
-              "Seed Phrase", June 2019, <https://en.bitcoin.it/w/
-              index.php?title=Seed_phrase&oldid=66492#Word_Lists>.
-
-   [I-D.birk-pep]
-              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
-              Privacy by Default", draft-birk-pep-03 (work in progress),
-              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]
-              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
-              Contact and Channel Authentication through Handshake",
-              draft-marques-pep-handshake-02 (work in progress), March
-              2019.
-
-   [ISO639]   "Language codes - ISO 639", n.d.,
-              <https://www.iso.org/iso-639-language-codes.html>.
-
-   [ISOC.bnet]
-              Simao, I., "Beyond the Net. 12 Innovative Projects
-              Selected for Beyond the Net Funding. Implementing Privacy
-              via Mass Encryption: Standardizing pretty Easy privacy's
-              protocols", June 2017, <https://www.internetsociety.org/
-              blog/2017/06/12-innovative-projects-selected-for-beyond-
-              the-net-funding/>.
-
-   [PGP.wl]   "PGP word list", November 2017,
-              <https://en.wikipedia.org/w/
-              index.php?title=PGP_word_list&oldid=749481933>.
-
-   [RFC1751]  McDonald, D., "A Convention for Human-Readable 128-bit
-              Keys", RFC 1751, DOI 10.17487/RFC1751, December 1994,
-              <https://www.rfc-editor.org/info/rfc1751>.
-
-   [RFC1760]  Haller, N., "The S/KEY One-Time Password System",
-              RFC 1760, DOI 10.17487/RFC1760, February 1995,
-              <https://www.rfc-editor.org/info/rfc1760>.
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 11]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
-              Time Password System", STD 61, RFC 2289,
-              DOI 10.17487/RFC2289, February 1998,
-              <https://www.rfc-editor.org/info/rfc2289>.
-
-   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
-              Wu, "Internet X.509 Public Key Infrastructure Certificate
-              Policy and Certification Practices Framework", RFC 3647,
-              DOI 10.17487/RFC3647, November 2003,
-              <https://www.rfc-editor.org/info/rfc3647>.
-
-   [RFC6117]  Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
-              Registration of Enumservices: Guide, Template, and IANA
-              Considerations", RFC 6117, DOI 10.17487/RFC6117, March
-              2011, <https://www.rfc-editor.org/info/rfc6117>.
-
-   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
-              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
-              March 2011, <https://www.rfc-editor.org/info/rfc6120>.
-
-Appendix A.  IANA XML Template Example
-
-   This section contains a non-normative example of the IANA
-   Registration Template XML chunk.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 12]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-     <record>
-       <languagecode>lat</languagecode>
-       <bitsize>16</bitsize>
-       <numberofuniquewords>57337</numberofuniquewords>
-       <bijective>no</bijective>
-       <version>n.0.1</version>
-       <registrationdocs>
-         <xref type="rfc" data="rfc2551"/>
-       </registrationdocs>
-       <requesters>
-         <xref type="person" data="Julius_Caesar"/>
-       </requesters>
-       <additionalinfo>
-         <paragraph>
-           This Wordlist has been optimized for
-           the Roman Standards Process.
-         </paragraph>
-       </additionalinfo>
-       <wordlist>
-         <w0>errare</w0>
-         <w1>humanum</w1>
-         [...]
-         <w65535>est<w65535>
-       </wordlist>
-     </record>
-
-     <people>
-       <person id="Julius_Caesar">
-         <name>Julius Caesar</name>
-         <org>Curia Romana</org>
-         <uri>mailto:julius.cesar@example.com</uri>
-         <updated>1999-12-31</updated>
-       </person>
-     </people>
-
-Appendix B.  Document Changelog
-
-   [[ 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
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 13]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   o  draft-birk-pep-trustwords-03:
-
-      *  Update references
-
-      *  Minor edits
-
-   o  draft-birk-pep-trustwords-02:
-
-      *  Minor editorial changes and bug fixes
-
-      *  Added more items to Open Issues
-
-      *  Add usage example
-
-   o  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
-
-Appendix C.  Open Issues
-
-   [[ RFC Editor: This section should be empty and is to be removed
-   before publication ]]
-
-   o  More explanatory text for Trustword use cases, properties and
-      requirements
-
-   o  Further details of the IANA registry and requirements for the
-      expert to assess the specification
-
-   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
-      implementations (running code) or ISO-639-3 (eng, deu, ita, ...)
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 14]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   o  Adjust exact representation of wordlists
-
-      *  e.g.  XML, CSV, ...
-
-      *  Syntax for non-ASCII letters or language symbols (UTF-8) in
-         Wordlists
-
-   o  Need for optional entropy value assigned to words, to account for
-      similar phonetics among words in the same wordlist?
-
-   o  Need for an additional field, to define what a wordlist is
-      optimized for, e.g., "entropy", "minimize word lengths", ...?
-
-   o  Work out (requirements for) "smart" composition of the version
-      number
-
-   o  Decide whether in non-bijective Wordlists the redundant words need
-      to be repeated in the IANA Registration
-
-   o  Register only a hash over the wordlist with IANA?
-
-   o  Does it make sense to open registrations for other patterns than
-      just words, e.g., images?
-
-Authors' Addresses
-
-   Bernie Hoeneisen
-   Ucom Standards Track Solutions GmbH
-   CH-8046 Zuerich
-   Switzerland
-
-   Phone: +41 44 500 52 40
-   Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
-   URI:   https://ucom.ch/
-
-
-   Hernani Marques
-   pEp Foundation
-   Oberer Graben 4
-   CH-8400 Winterthur
-   Switzerland
-
-   Email: hernani.marques@pep.foundation
-   URI:   https://pep.foundation/
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 15]

pep-trustwords/review/draft-birk-pep-trustwords-04-pre20190707.txt

@@ -1,840 +0,0 @@
-
-
-
-
-Network Working Group                                       B. Hoeneisen
-Internet-Draft                                                   Ucom.ch
-Intended status: Standards Track                              H. Marques
-Expires: January 8, 2020                                  pEp Foundation
-                                                           July 07, 2019
-
-
-     IANA Registration of Trustword Lists: Guide, Template and IANA
-                             Considerations
-                      draft-birk-pep-trustwords-04
-
-Abstract
-
-   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.
-
-Status of This Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at https://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on January 8, 2020.
-
-Copyright Notice
-
-   Copyright (c) 2019 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
-   (https://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 1]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
-     1.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.  The Concept of Trustword Mapping  . . . . . . . . . . . . . .   4
-     2.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
-     2.2.  Previous work . . . . . . . . . . . . . . . . . . . . . .   4
-     2.3.  Number of Trustwords for a language . . . . . . . . . . .   5
-     2.4.  Language  . . . . . . . . . . . . . . . . . . . . . . . .   5
-     2.5.  The nature of the words . . . . . . . . . . . . . . . . .   5
-   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
-   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
-     5.1.  Registration Template (XML chunk) . . . . . . . . . . . .   6
-     5.2.  IANA Registration . . . . . . . . . . . . . . . . . . . .   7
-       5.2.1.  Language Code (<languagecode>)  . . . . . . . . . . .   7
-       5.2.2.  Bit Size (<bitsize>)  . . . . . . . . . . . . . . . .   8
-       5.2.3.  Number Of Unique Words (<numberofuniquewords>)  . . .   8
-       5.2.4.  Bijectivity (<bijective>) . . . . . . . . . . . . . .   8
-       5.2.5.  Version (<version>) . . . . . . . . . . . . . . . . .   8
-       5.2.6.  Registration Document(s) (<registrationdocs>) . . . .   8
-       5.2.7.  Requesters (<requesters>) . . . . . . . . . . . . . .   9
-       5.2.8.  Further Information (<additionalinfo>)  . . . . . . .   9
-       5.2.9.  Wordlist (<wordlist>) . . . . . . . . . . . . . . . .  10
-   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
-     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
-   Appendix A.  IANA XML Template Example  . . . . . . . . . . . . .  12
-   Appendix B.  Document Changelog . . . . . . . . . . . . . . . . .  13
-   Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  14
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
-
-1.  Introduction
-
-   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.
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 2]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   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
-   [I-D.birk-pep] 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 could also be used
-   for private key recovery in case of loss.
-
-   Currently Trustwords are also used for other purposes, such as Human-
-   Readable 128-bit Keys [RFC1751], One Time Passwords (OTP) [RFC1760]
-   [RFC2289], SSH host-key verification, VPN Server certificate
-   verification, and to import or synchronize secret key across
-   different devices of the same user [I-D.hoeneisen-pep-keysync].
-   Further ideas include to use Trustwords for contact verification in
-   Extensible Messaging and Presence Protocol (XMPP) [RFC6120], for
-   X.509 [RFC3647] certificate verification in browsers or in block
-   chain applications for crypto currencies.
-
-1.1.  Requirements Language
-
-   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 [RFC2119].
-
-1.2.  Terms
-
-   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]
-
-   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."
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 3]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-2.  The Concept of Trustword Mapping
-
-2.1.  Example
-
-   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.
-
-2.2.  Previous work
-
-   The basic concept of Trustwords mapping has been already documented
-   in the past, e.g. for use in One-Time Passwords (OTP) [RFC1751]
-   [RFC1760] [RFC2289] or the PGP Word List ("Pretty Good Privacy word
-   list" [PGP.wl], also called a biometric word list, to compare
-   fingerprints.  Furthermore, crypto-currencies are using a similar
-   concept for deriving private keys [bitcoin.wl].
-
-   Regarding today's needs, previous proposals have the following
-   shortcomings:
-
-   o  Limited number of Trustwords (small Trustword dictionaries), which
-      generally results in more Trustwords to be compared
-
-   o  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:
-
-   o  This work allows for better tailoring the target audience to
-      ordinary human users, i.e. not technical stuff (or IT geeks) only.
-
-   o  As in many usage scenarios the Trustwords are only read (and
-      compared), but not written down nor typed in by humans, there is a
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 4]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-      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.
-
-2.3.  Number of Trustwords for a language
-
-   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 [I-D.birk-pep] 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.
-
-2.4.  Language
-
-   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.
-
-2.5.  The nature of the words
-
-   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).
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 5]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-3.  Security Considerations
-
-   There are no special security considerations.
-
-4.  Privacy Considerations
-
-   [[ TODO ]]
-
-5.  IANA Considerations
-
-   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
-   [RFC8126] 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 [RFC6117] is likely followed. ]]
-
-5.1.  Registration Template (XML chunk)
-
-     <record>
-       <languagecode>
-         <!--  ISO 639-3 (e.g. eng, deu, ...) -->
-       </languagecode>
-       <bitsize>
-         <!-- How many bits can be mapped with this list
-              (e.g. 8, 16, ...) -->
-       </bitsize>
-       <numberofuniquewords>
-         <!-- number of unique words registered
-              (e.g. 256, 65536, ...) -->
-       </numberofuniquewords>
-       <bijective>
-         <!-- whether or not the list allows for a two-way-mapping
-              (e.g. yes, no) -->
-       </bijective>
-       <version>
-         <!-- version number within language
-              (e.g. b.1.2, n.0.1, ...)  -->
-       </version>
-       <registrationdocs>
-         <!-- Change accordingly -->
-         <xref type="rfc" data="rfc2551"/>
-       </registrationdocs>
-       <requesters>
-         <!-- Change accordingly -->
-         <xref type="person" data="John_Doe"/>
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 6]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-         <xref type="person" data="Jane_Dale"/>
-       </requesters>
-       <additionalinfo>
-         <paragraph>
-           <!-- Text with additional information about
-                the Wordlist to be registered -->
-         </paragraph>
-         <artwork>
-           <!-- There can be artwork sections, too -->
-         </artwork>
-       </additionalinfo>
-       <wordlist>
-         <!-- Change accordingly -->
-         <w0>first</w0>
-         <w1>second</w1>
-         [...]
-         <w65535>last<w65535>
-       </wordlist>
-     </record>
-
-     <people>
-       <person id="John_Doe">
-         <name> <!-- Firstname Lastname --> </name>
-         <org> <!-- Organization Name --> </org>
-         <uri> <!-- mailto: or http: URI --> </uri>
-         <updated> <!-- date format YYYY-MM-DD --> </updated>
-       </person>
-       <!-- repeat person section for each person -->
-     </people>
-
-   Authors of a Wordlist are encouraged to use these XML chunks as a
-   template to create the IANA Registration Template.
-
-5.2.  IANA Registration
-
-   An IANA registration will contain the fallowing elements:
-
-5.2.1.  Language Code (<languagecode>)
-
-   The language code follows the ISO 639-3 specification [ISO639], 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:
-
-   e.g.  <languagecode>deu</languagecode>
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 7]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-5.2.2.  Bit Size (<bitsize>)
-
-   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:
-
-   e.g.  <bitsize>16</bitsize>
-
-5.2.3.  Number Of Unique Words (<numberofuniquewords>)
-
-   The number of unique words that are registered.
-
-   e.g.  <numberofuniquewords>65536</numberofuniquewords>
-
-5.2.4.  Bijectivity (<bijective>)
-
-   Whether the registered Wordlist has a one-to-one mapping, meaning the
-   number of unique words registered equals 2 ^ "(<bitsize>)".
-
-   Valid content: ( yes | no )
-
-   e.g.  <bijective>yes</bijective>
-
-5.2.5.  Version (<version>)
-
-   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 ]]
-
-   e.g.  <version>b.1.2</version>
-
-5.2.6.  Registration Document(s) (<registrationdocs>)
-
-   Reference(s) to the Document(s) containing the Wordlist
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 8]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   e.g.  <registrationdocs>
-           <xref type="rfc" data="rfc4979"/>
-         </registrationdocs>
-
-   e.g.  <registrationdocs>
-           <xref type="rfc" data="rfc8888"/> (obsoleted by RFC 9999)
-           <xref type="rfc" data="rfc9999"/>
-         </registrationdocs>
-
-   e.g.  <registrationdocs>
-           [International Telecommunications Union,
-           "Wordlist for Foobar application",
-           ITU-F Recommendation B.193, Release 73, Mar 2009.]
-         </registrationdocs>
-
-5.2.7.  Requesters (<requesters>)
-
-   The persons requesting the registration of the Wordlist.  Usually
-   these are the authors of the Wordlist.
-
-   e.g.  <requesters>
-           <xref type="person" data="John_Doe"/>
-         </requesters>
-
-         <people>
-           <person id="John_Doe">
-             <name>John Doe</name>
-             <org>Example Inc.</org>
-             <uri>mailto:john.doe@example.com</uri>
-             <updated>2018-06-20</updated>
-           </person>
-         </people>
-
-   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.
-
-5.2.8.  Further Information (<additionalinfo>)
-
-   Any other information the authors deem interesting.
-
-   e.g.  <additionalinfo>
-           <paragraph>more info goes here</paragraph>
-         </additionalinfo>
-
-   Note: If there is no such additional information, then the
-   <additionalinfo> element is omitted.
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020                [Page 9]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-5.2.9.  Wordlist (<wordlist>)
-
-   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.
-
-   e.g.  <wordlist>
-           <w0>first</w0>
-           <w1>second</w1>
-           [...]
-           <w65535>last<w65535>
-         </wordlist>
-
-   ] ]>
-
-   [[ Note: The exact representation of the Wordlist is for further
-   study.  ]]
-
-6.  Acknowledgments
-
-   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, Volker Birk, 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.  [ISOC.bnet]
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119,
-              DOI 10.17487/RFC2119, March 1997,
-              <https://www.rfc-editor.org/info/rfc2119>.
-
-   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
-              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
-              <https://www.rfc-editor.org/info/rfc4949>.
-
-   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
-              Writing an IANA Considerations Section in RFCs", BCP 26,
-              RFC 8126, DOI 10.17487/RFC8126, June 2017,
-              <https://www.rfc-editor.org/info/rfc8126>.
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 10]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-7.2.  Informative References
-
-   [bitcoin.wl]
-              "Seed Phrase", June 2019, <https://en.bitcoin.it/w/
-              index.php?title=Seed_phrase&oldid=66492#Word_Lists>.
-
-   [I-D.birk-pep]
-              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
-              Privacy by Default", draft-birk-pep-03 (work in progress),
-              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]
-              Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp):
-              Contact and Channel Authentication through Handshake",
-              draft-marques-pep-handshake-02 (work in progress), March
-              2019.
-
-   [ISO639]   "Language codes - ISO 639", n.d.,
-              <https://www.iso.org/iso-639-language-codes.html>.
-
-   [ISOC.bnet]
-              Simao, I., "Beyond the Net. 12 Innovative Projects
-              Selected for Beyond the Net Funding. Implementing Privacy
-              via Mass Encryption: Standardizing pretty Easy privacy's
-              protocols", June 2017, <https://www.internetsociety.org/
-              blog/2017/06/12-innovative-projects-selected-for-beyond-
-              the-net-funding/>.
-
-   [PGP.wl]   "PGP word list", November 2017,
-              <https://en.wikipedia.org/w/
-              index.php?title=PGP_word_list&oldid=749481933>.
-
-   [RFC1751]  McDonald, D., "A Convention for Human-Readable 128-bit
-              Keys", RFC 1751, DOI 10.17487/RFC1751, December 1994,
-              <https://www.rfc-editor.org/info/rfc1751>.
-
-   [RFC1760]  Haller, N., "The S/KEY One-Time Password System",
-              RFC 1760, DOI 10.17487/RFC1760, February 1995,
-              <https://www.rfc-editor.org/info/rfc1760>.
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 11]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
-              Time Password System", STD 61, RFC 2289,
-              DOI 10.17487/RFC2289, February 1998,
-              <https://www.rfc-editor.org/info/rfc2289>.
-
-   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
-              Wu, "Internet X.509 Public Key Infrastructure Certificate
-              Policy and Certification Practices Framework", RFC 3647,
-              DOI 10.17487/RFC3647, November 2003,
-              <https://www.rfc-editor.org/info/rfc3647>.
-
-   [RFC6117]  Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
-              Registration of Enumservices: Guide, Template, and IANA
-              Considerations", RFC 6117, DOI 10.17487/RFC6117, March
-              2011, <https://www.rfc-editor.org/info/rfc6117>.
-
-   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
-              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
-              March 2011, <https://www.rfc-editor.org/info/rfc6120>.
-
-Appendix A.  IANA XML Template Example
-
-   This section contains a non-normative example of the IANA
-   Registration Template XML chunk.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 12]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-     <record>
-       <languagecode>lat</languagecode>
-       <bitsize>16</bitsize>
-       <numberofuniquewords>57337</numberofuniquewords>
-       <bijective>no</bijective>
-       <version>n.0.1</version>
-       <registrationdocs>
-         <xref type="rfc" data="rfc2551"/>
-       </registrationdocs>
-       <requesters>
-         <xref type="person" data="Julius_Caesar"/>
-       </requesters>
-       <additionalinfo>
-         <paragraph>
-           This Wordlist has been optimized for
-           the Roman Standards Process.
-         </paragraph>
-       </additionalinfo>
-       <wordlist>
-         <w0>errare</w0>
-         <w1>humanum</w1>
-         [...]
-         <w65535>est<w65535>
-       </wordlist>
-     </record>
-
-     <people>
-       <person id="Julius_Caesar">
-         <name>Julius Caesar</name>
-         <org>Curia Romana</org>
-         <uri>mailto:julius.cesar@example.com</uri>
-         <updated>1999-12-31</updated>
-       </person>
-     </people>
-
-Appendix B.  Document Changelog
-
-   [[ 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
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 13]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   o  draft-birk-pep-trustwords-03:
-
-      *  Update references
-
-      *  Minor edits
-
-   o  draft-birk-pep-trustwords-02:
-
-      *  Minor editorial changes and bug fixes
-
-      *  Added more items to Open Issues
-
-      *  Add usage example
-
-   o  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
-
-Appendix C.  Open Issues
-
-   [[ RFC Editor: This section should be empty and is to be removed
-   before publication ]]
-
-   o  More explanatory text for Trustword use cases, properties and
-      requirements
-
-   o  Further details of the IANA registry and requirements for the
-      expert to assess the specification
-
-   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
-      implementations (running code) or ISO-639-3 (eng, deu, ita, ...)
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 14]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   o  Adjust exact representation of wordlists
-
-      *  e.g.  XML, CSV, ...
-
-      *  Syntax for non-ASCII letters or language symbols (UTF-8) in
-         Wordlists
-
-   o  Need for optional entropy value assigned to words, to account for
-      similar phonetics among words in the same wordlist?
-
-   o  Need for an additional field, to define what a wordlist is
-      optimized for, e.g., "entropy", "minimize word lengths", ...?
-
-   o  Work out (requirements for) "smart" composition of the version
-      number
-
-   o  Decide whether in non-bijective Wordlists the redundant words need
-      to be repeated in the IANA Registration
-
-   o  Register only a hash over the wordlist with IANA?
-
-   o  Does it make sense to open registrations for other patterns than
-      just words, e.g., images?
-
-Authors' Addresses
-
-   Bernie Hoeneisen
-   Ucom Standards Track Solutions GmbH
-   CH-8046 Zuerich
-   Switzerland
-
-   Phone: +41 44 500 52 40
-   Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
-   URI:   https://ucom.ch/
-
-
-   Hernani Marques
-   pEp Foundation
-   Oberer Graben 4
-   CH-8400 Winterthur
-   Switzerland
-
-   Email: hernani.marques@pep.foundation
-   URI:   https://pep.foundation/
-
-
-
-
-
-
-
-Hoeneisen & Marques      Expires January 8, 2020               [Page 15]

pep-trustwords/review/draft-birk-pep-trustwords-04-pre20190708-KRB.txt

@@ -1,843 +0,0 @@
-
-
-
-
-Network Working Group                                       B. Hoeneisen
-Internet-Draft                                                   Ucom.ch
-Intended status: Standards Track                              H. Marques
-Expires: January 9, 2020                                  pEp Foundation
-                                                           July 08, 2019
-
-
-     IANA Registration of Trustword Lists: Guide, Template and IANA
-                             Considerations
-                      draft-birk-pep-trustwords-04
-
-Abstract
-
-   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),
-   which hexadecimal strings are mapped to.  Such a mapping makes
-   verification processes like fingerprint comparisons more practical,
-   and less prone to misunderstandings.
-
-Status of This Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at https://datatracker.ietf.org/drafts/current/.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on January 9, 2020.
-
-Copyright Notice
-
-   Copyright (c) 2019 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
-   (https://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-
-
-
-Hoeneisen & Marques      Expires January 9, 2020                [Page 1]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
-     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
-     1.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.  The Concept of Trustword Mapping  . . . . . . . . . . . . . .   4
-     2.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
-     2.2.  Previous work . . . . . . . . . . . . . . . . . . . . . .   4
-     2.3.  Number of Trustwords for a language . . . . . . . . . . .   5
-     2.4.  Language  . . . . . . . . . . . . . . . . . . . . . . . .   5
-     2.5.  The nature of the words . . . . . . . . . . . . . . . . .   6
-   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
-   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
-     5.1.  Registration Template (XML chunk) . . . . . . . . . . . .   6
-     5.2.  IANA Registration . . . . . . . . . . . . . . . . . . . .   8
-       5.2.1.  Language Code (<languagecode>)  . . . . . . . . . . .   8
-       5.2.2.  Bit Size (<bitsize>)  . . . . . . . . . . . . . . . .   8
-       5.2.3.  Number Of Unique Words (<numberofuniquewords>)  . . .   8
-       5.2.4.  Bijectivity (<bijective>) . . . . . . . . . . . . . .   8
-       5.2.5.  Version (<version>) . . . . . . . . . . . . . . . . .   8
-       5.2.6.  Registration Document(s) (<registrationdocs>) . . . .   9
-       5.2.7.  Requesters (<requesters>) . . . . . . . . . . . . . .   9
-       5.2.8.  Further Information (<additionalinfo>)  . . . . . . .   9
-       5.2.9.  Wordlist (<wordlist>) . . . . . . . . . . . . . . . .  10
-   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
-     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
-   Appendix A.  IANA XML Template Example  . . . . . . . . . . . . .  12
-   Appendix B.  Document Changelog . . . . . . . . . . . . . . . . .  13
-   Appendix C.  Open Issues  . . . . . . . . . . . . . . . . . . . .  14
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
-
-1.  Introduction
-
-   In public-key cryptography, comparing the respective public key
-   fingerprints for each of the communication partners involved is vital
-   to ensure that there is no Man-in-the-Middle (MITM) attack on the
-   communication channel.  These fingerprints normally consist of a
-   chain of hexadecimal characters, which are often impractical,
-   cumbersome, and prone to misunderstandings for end-users.
-
-
-
-Hoeneisen & Marques      Expires January 9, 2020                [Page 2]
-
-Internet-Draft    IANA Registration of Trustword Lists         July 2019
-
-
-   To mitigate these challenges, several systems offer Trustword
-   comparison as an alternative to these hexadecimal strings.
-   Trustwords are common words in a natural language (e.g., English),
-   which these hexadecimal strings are mapped to.  Using Trustwords
-   makes verification processes like fingerprint comparisons more
-   natural for users.
-
-   For example, in pEp's Privacy by Default proposition [I-D.birk-pep]
-   Trustwords are used to facilitate easy contact verification for end-
-   to-end encryption.  Trustword comparison is offered after the peers
-   have opportunistically exchanged public keys.  Examples of Trustword
-   lists used by current pEp implementations can be found here in CSV
-   format: 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 [RFC1751], One
-   Time Passwords (OTP) [RFC1760] [RFC2289], SSH host-key verification,
-   VPN server certificate verification, deriving private keys in
-   blockchain applications for cryptocurrencies, and to import or
-   synchronize secret keys across multiple devices owned by a single
-   user [I-D.hoeneisen-pep-keysync].  Further ideas include the use of
-   Trustwords for private key recovery in case of loss, contact
-   verification in Extensible Messaging and Presence Protocol (XMPP)
-   [RFC6120], or for X.509 certificate verification in browsers
-   [RFC3647].