Re: [Medup] Issues draft-birk-pep-trustwords (was: New Version Notification for draft-birk-pep-trustwords-03.txt)

Alessandro Vesely <vesely@tana.it> Tue, 26 March 2019 18:00 UTC

Return-Path: <vesely@tana.it>
X-Original-To: medup@ietfa.amsl.com
Delivered-To: medup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D7B1207CF for <medup@ietfa.amsl.com>; Tue, 26 Mar 2019 11:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWlZfw3BGnAO for <medup@ietfa.amsl.com>; Tue, 26 Mar 2019 11:00:05 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A151207C4 for <medup@ietf.org>; Tue, 26 Mar 2019 11:00:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1553623201; bh=dBPEavA6SArCeRUPhJ9QmkPbNHXE666MN2k9tNLh7pE=; l=2258; h=To:References:From:Date:In-Reply-To; b=AmSAEb5zp1IRGUBJLmFNczAo8oH8juM7TNaWAPvQGUsF4aGt7XHB2PqUQwhUOHjXQ yL0vjUSDjO6dakibUXlKjdi0Q5pitbPpbnlOX6d+cHfqn0h9Fw+qTRbjjO917u6Okd HsfNmxe8YZw+yNv2MbP09LIN90iYjDQlspkCDIjLJlj8J8xTuGlRkQypQoOqg
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 26 Mar 2019 19:00:01 +0100 id 00000000005DC03D.000000005C9A68A1.00007BB9
To: medup@ietf.org
References: <155234487151.23050.3654986147342430959.idtracker@ietfa.amsl.com> <c3e504db-695d-dd2a-5e6f-8d4cbb60c540@pep.foundation> <alpine.DEB.2.20.1903222318030.28768@softronics.hoeneisen.ch>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <5762b2c1-2cb1-c99f-90fb-eb293820f6d5@tana.it>
Date: Tue, 26 Mar 2019 19:00:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1903222318030.28768@softronics.hoeneisen.ch>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/medup/D8kSfPxZTxzRpRssnRLx6JQ2pT8>
Subject: Re: [Medup] Issues draft-birk-pep-trustwords (was: New Version Notification for draft-birk-pep-trustwords-03.txt)
X-BeenThere: medup@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Missing Elements for Decentralized and Usable Privacy <medup.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/medup>, <mailto:medup-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/medup/>
List-Post: <mailto:medup@ietf.org>
List-Help: <mailto:medup-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/medup>, <mailto:medup-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 18:00:08 -0000

On Fri 22/Mar/2019 23:55:40 +0100 Bernie Hoeneisen wrote:
> 
> The IANA Registration for trustwords (a basic concept applied in pEp)
> https://www.ietf.org/internet-drafts/draft-birk-pep-trustwords-03.txt
> has several open issues, we'd need your feedback on, e.g.:
> 
> 
> 1) Localization:
>    How should non-ASCII-7bit letters or language symbols be represented
>    in the wordlists? UTF-8? HTML-like encoding? IDNA? Any better solution?

UTF-8, the other precursors are not quite as universal.


> 2) Registration format:
>    The format for registrations of at IANA is normaly (peudo-)XML.
>    While XML is concise for registering wordlists, the files
>    for registration will contain lot of XML overhead and thus get rather
>    long. Is this an issue? Use another format, e.g. CSV?

If the registration requires a specification, a plain text format would seem to
be easier and more conforming to classic RFCs.  E.g.:

language code: en
bit size: 8
...

IANA may provide HTML, XML, CSV versions as needed.


> 3) ISO language code:
>    Which ISO language code either 639-1 or 639-3 shall be used, to
>    designate the language, 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, ...)
>    With ISO-639-3 more languages can be addressed, in particular
>    less widespread languages and dialects.

ISO-639-1, the less languages the better.  Similar languages generate
confusion; for example, aig (Antigua and Barbuda Creole English) contains many
words that look like English, so it would be harder for a verifier to first
establish what wordlist is being used.


> 4) Bitsize (how many bits can be mapped with a wordlist):
>    e.g. a bitsize of 16 allows for a list containing 2^16 = 65536 words.
> 
>    Should this be kept open or should only certain values for bitsize
>    be allowed to be registerd?
>    If latter applies, which values are useful (e.g. 8, 12 and 16)


Open sound better.  Using wordlists may give rise to a totally new kind of
blockchains, where meaningful phrases are the target.  We shouldn't limit
creativity by imposing a fixed size.


jm2c

Ale
--