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

["Jim Schaad" <[e-mail]>]

This is what I meant,  I just could not remember the correct phase last
night.

jim 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ted Hardie
> Sent: Thursday, April 13, 2006 8:00 AM
> To: Russ Housley; [e-mail]
> Cc: [e-mail]
> Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8
> 
> 
> 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.
> 
> 
>