Re: [idn] nameprep2 and the slash homograph issue

"Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord.cnri.reston.va.us> Wed, 23 February 2005 10:57 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02346 for <idn-archive@lists.ietf.org>; Wed, 23 Feb 2005 05:57:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3u8O-000Ooh-CG for idn-data@psg.com; Wed, 23 Feb 2005 10:52:48 +0000
Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3u8L-000OoL-Eg for idn@ops.ietf.org; Wed, 23 Feb 2005 10:52:45 +0000
Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3u8K-0006Qs-00 for <idn@ops.ietf.org>; Wed, 23 Feb 2005 02:52:44 -0800
Date: Wed, 23 Feb 2005 10:52:44 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord.cnri.reston.va.us>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] nameprep2 and the slash homograph issue
Message-ID: <20050223105244.GE21463~@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <D872CCF059514053ECF8A198@scan.jck.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D872CCF059514053ECF8A198@scan.jck.com>
User-Agent: Mutt/1.5.6+20040722i
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1
Sender: owner-idn@ops.ietf.org
Precedence: bulk

John C Klensin <klensin@jck.com> wrote:

> If we find a need to start banning characters that we could not agree
> on banning the first time around, there is another approach, also
> unpleasant but IMO less problematic, that could be considered.  Just
> as RFC 2822 moved past a lot of legacy nonsense by having two separate
> "create" and "accept" syntaxes, we could define an additional profile,
> say "NameRegisterPrep".  It would look a lot like Nameprep but would
> ban the characters you are now suggesting banning, plus, based on what
> I think is growing experience in the registries, ban any character
> that mapped to anything else.
>
> The lookup process would remain the same, with no changes to Nameprep
> being made at all.

But browser implementers want to protect their users today against
malicious names that may exist in the DNS today.  I don't see how
this proposal would help them do that.  Browser implementors are
comtemplating banning characters in IDNs the browser (that is, failing
to look up names containing blacklisted characters), and I was trying
to think of a less drastic, less blatantly nonconformant, but equally
protective measure that could be taken in the browser.

AMC