Re: [I18nrp] Mappings for IDNA2008 ?

"Patrik Fältström " <paf@frobbit.se> Fri, 08 February 2019 19:47 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: i18nrp@ietfa.amsl.com
Delivered-To: i18nrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A3A130F74 for <i18nrp@ietfa.amsl.com>; Fri, 8 Feb 2019 11:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
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 qnz5JWh-EcTV for <i18nrp@ietfa.amsl.com>; Fri, 8 Feb 2019 11:47:27 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BA2130F72 for <i18nrp@ietf.org>; Fri, 8 Feb 2019 11:47:27 -0800 (PST)
Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:932:a0b9:61be:d623]) by mail.frobbit.se (Postfix) with ESMTPSA id CDFD523899; Fri, 8 Feb 2019 20:47:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1549655244; bh=qMNo3Su87+GupmUiYYkGPCoGqYuklWVCalRwG8oo2q4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uO7BQK7pxsoKCNz6bV8Xwr6HloM4IyHNvVaFKXd6m0ouzGgNieSq/5Or3tpIrczwL SLqWUYJEdGYQTCyJm0YUoLp9KBGlDz/noSZWNHwXe5eYn+PTecOkEQvyqKRL08BNaO Gt6ZVLguSsutqc3Mnwr9R8EIeoR0ayI3DHM4NHEU=
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" <paf@frobbit.se>
To: "Andrew Sullivan" <ajs@anvilwalrusden.com>
Cc: i18nrp@ietf.org
Date: Fri, 08 Feb 2019 20:47:24 +0100
X-Mailer: MailMate (1.12.4r5597)
Message-ID: <C01DE66F-1BB8-41CE-9574-2C338C38EAA2@frobbit.se>
In-Reply-To: <20190208193829.skaujoeq2xgzwzg7@mx4.yitter.info>
References: <20190204225047.02583200DC1666@ary.qy> <6660b7e2-1d5b-6a5d-3d1c-55a757e24843@ix.netcom.com> <ADDA4540-9169-4EE6-B33E-3A0D9EED0BD7@frobbit.se> <16ff0d27-9508-7fdd-bc89-9d6fd47396b1@ix.netcom.com> <D5B49CC8-7AEF-4E81-8774-F3F1F05682E8@frobbit.se> <320f4bc3-17b1-595b-34c7-8f95f69c0f33@ix.netcom.com> <B87C6774-4FF7-4A18-A81D-D0834401C293@frobbit.se> <bc7b727d-f75c-bbba-4f63-ebd1dcd87085@it.aoyama.ac.jp> <A5549B92-9414-4210-A94D-8E53339D3961@frobbit.se> <20190208193829.skaujoeq2xgzwzg7@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_AB4DD9E9-B485-42C7-A4D8-0B85031432F9_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/m88U32cL6Ty3NWO9sX1JDRHPbqc>
Subject: Re: [I18nrp] Mappings for IDNA2008 ?
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Review Procedures <i18nrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18nrp/>
List-Post: <mailto:i18nrp@ietf.org>
List-Help: <mailto:i18nrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2019 19:47:29 -0000

On 8 Feb 2019, at 20:38, Andrew Sullivan wrote:

> On Fri, Feb 08, 2019 at 08:16:39PM +0100, Patrik Fältström wrote:
>>
>>  modified with the delta that the LOCALE defines.
>
> I'm still trying to understand how you know what the locale of the various network identifiers are.  People might recall that this was one of the problems we have identified as a serious issue in the past.
> You can know what the locale is, maybe, at lookup time, but since the information doesn't travel around with the identifier you can't know what the locale is at creation time.  And that, of course, is how you get a security problem out of this.

For example, if I as a user with $LC_CTYPE == sv_SE.UTF-8 do type or view a string of characters, then I am pretty sure I am interested in having case folding and others things mapped according to that LOCALE. But only when/if the input/output should include such mappings. Most of them should probably not have any mappings at all.

And what you point out about security is once again exactly why IDNA2008 is not including any mappings at all. It gives the ability for the application to do the mapping of characters in such a way that the rendered glyphs are such that the end user is not surprised. And that might be very different for me than you. Depending on for example LC_CTYPE.

   Patrik