RE: Last Call summary for draft-ietf-pkix-cert-utf8

Ted Hardie <hardie@qualcomm.com> Thu, 13 April 2006 15:45 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU40w-0000Kp-JK for pkix-archive@lists.ietf.org; Thu, 13 Apr 2006 11:45:46 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU40w-0000wW-2E for pkix-archive@lists.ietf.org; Thu, 13 Apr 2006 11:45:46 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DF09LB046945; Thu, 13 Apr 2006 08:00:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k3DF090w046944; Thu, 13 Apr 2006 08:00:09 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3DF08te046937 for <ietf-pkix@imc.org>; Thu, 13 Apr 2006 08:00:09 -0700 (MST) (envelope-from hardie@qualcomm.com)
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DExxCh014134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2006 08:00:00 -0700
Received: from [129.46.225.88] (dhcp-campbell-28.qualcomm.com [129.46.225.88]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k3DExvJF012243; Thu, 13 Apr 2006 07:59:58 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230900c0641768db5c@[10.0.1.4]>
In-Reply-To: <7.0.0.16.2.20060413102956.059d9560@vigilsec.com>
References: <82D5657AE1F54347A734BDD33637C8790241A5B3@EXVS01.ex.dslextreme.net> <7.0.0.16.2.20060413102956.059d9560@vigilsec.com>
Date: Thu, 13 Apr 2006 07:59:56 -0700
To: Russ Housley <housley@vigilsec.com>, ietf-pkix@imc.org
From: Ted Hardie <hardie@qualcomm.com>
Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8
Cc: iesg@ietf.org
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4

At 10:32 AM -0400 4/13/06, Russ Housley wrote:
>I suggest the following.  I think it adds the concept of "similar looking."
>
>   When strings are mapped from internal representations to visual representations,
>   sometimes two different strings will have the same or similar visual representations.
>   This can happen for many different reasons, including use of similar glyphs and
>   multiple items being combined into a single glyph. 

"Multiple items being combined into a single glyph" sounds like you mean
"the use of composed characters" (e + ' equaling

 has a raft of different instances,
each with their own tricky bits).  If that is what you mean, I'd suggest
using that phrasing, as




>As a result of this situation,
>   people doing visual comparisons between two different names may think they are
>   the same when in fact they are not.  Also, people may mistake one string for
>   another.  Issuers of certificates and relying parties both need to be aware of
>   this situation.
>
>This does not impose any untestable requirements.  Any concerns with this text?
>
>Russ
>
>
>At 07:36 AM 4/13/2006, Santosh Chokhani wrote:
>>When strings are mapped from internal representations to visual
>>representations, sometimes two different strings will have
>>the same visual representations.  This can happen due to similar glyphs,
>>multiple items being combined into a single glyph among other reasons.
>>When
>>this happens people doing visual comparisons between two different names
>>may
>>think they are the same when in fact they are not.  Also, people may
>>mistake one string for another.  Issuers of certificates and relying
>>parties both need to be aware of these facts.