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

"Stefan Santesson" <stefans@microsoft.com> Sat, 15 April 2006 11:54 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUjMU-0005eq-Rp for pkix-archive@lists.ietf.org; Sat, 15 Apr 2006 07:54:46 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUjMS-000483-97 for pkix-archive@lists.ietf.org; Sat, 15 Apr 2006 07:54: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 k3FAqwLe068604; Sat, 15 Apr 2006 03:52:58 -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 k3FAqwN1068602; Sat, 15 Apr 2006 03:52:58 -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 mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k3FAqtBY068544 for <ietf-pkix@imc.org>; Sat, 15 Apr 2006 03:52:56 -0700 (MST) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Apr 2006 11:52:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8
Date: Sat, 15 Apr 2006 11:52:46 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA1D73@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <7.0.0.16.2.20060413114840.059c9c38@vigilsec.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Last Call summary for draft-ietf-pkix-cert-utf8
Thread-Index: AcZfG/N8gWeYIRxeSKGv+KVSk9Nm8QBXnBgA
From: Stefan Santesson <stefans@microsoft.com>
To: Russ Housley <housley@vigilsec.com>, Ted Hardie <hardie@qualcomm.com>
Cc: iesg@ietf.org, ietf-pkix@imc.org
X-OriginalArrivalTime: 15 Apr 2006 10:52:51.0881 (UTC) FILETIME=[BE21F190:01C6607A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k3FAquBY068582
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: 37af5f8fbf6f013c5b771388e24b09e7

I'm fine with this text.

I would oppose inclusion of requirements on the CA regarding name
assignments of reasons stated in the thread.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security


> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Russ Housley
> Sent: den 13 april 2006 18:11
> To: Ted Hardie
> Cc: iesg@ietf.org; ietf-pkix@imc.org
> Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8
> 
> 
> Ted:
> 
> Thanks for the improved text.  Here it is all put together:
> 
>     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
>     use of composed characters (such as e + ' equaling U+00E9, the
Korean
>     composed characters, and vowels above consonant clusters in
> certain languages).
>     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 11:05 AM 4/13/2006, you wrote:
> >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 U+00E9, the Korean
> composed
> >characters, vowels above consonant clusters in certain
> >languages).  Each of the
> >cases in which that occurs  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 it is a
> >more recognized term of art.   If you mean something else, I don't
think
> I'm
> >clear on what exactly you mean.
> >                                 Ted
> >
> >
> >
> >
> > >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.