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 07:45 UTC

Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03342 for <idn-archive@lists.ietf.org>; Wed, 23 Feb 2005 02:45:25 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3qws-000Ka0-Tl for idn-data@psg.com; Wed, 23 Feb 2005 07:28:42 +0000
Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3qwq-000KZj-V8 for idn@ops.ietf.org; Wed, 23 Feb 2005 07:28:41 +0000
Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3qwn-0005fV-00 for <idn@ops.ietf.org>; Tue, 22 Feb 2005 23:28:37 -0800
Date: Wed, 23 Feb 2005 07:28:37 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord.cnri.reston.va.us>
To: idn@ops.ietf.org
Subject: Re: [idn] nameprep2 and the slash homograph issue
Message-ID: <20050223072837.GA21463~@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <421B8484.3070802@vanderpoel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <421B8484.3070802@vanderpoel.org>
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

Erik van der Poel <erik@vanderpoel.org> wrote:

> Another argument against banning the slash homograph is that any new
> banning would require a new ACE prefix, which is a lot of work, and,
> as John said, there should be a high threshold for any demonstration
> that tries to show that a new prefix is necessary.

An alternative, rather than banning the character, is to recommend
that it not be shown; the ACE form could be shown instead.  This would
effectively make the character useless in domain names (for both
phishers and honest folks) without requiring a new ACE prefix.

We could push ToUnicode down inside a wrapper function, ToDisplay.
Applications would never call ToUnicode directly anymore.  Whenever
they wanted to display a domain name, they'd call ToDisplay, which
would call ToUnicode, check the result, and if it didn't like it, call
ToASCII.  (Of course, since ToUnicode typically calls ToASCII, there are
opportunities to optimize that logic.)

AMC