Remove review files.

master
Hernâni Marques 4 years ago
parent 5eae3e1e04
commit 731eaa2713

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

@ -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]

@ -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>
<