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