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

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 13 Apr 2006 04:36:09 -0700

Jim,

I ok with your text, except I would replace frequent with some times and
make some minor adjustments and hence the following:

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.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Thursday, April 13, 2006 12:25 AM
To: Santosh Chokhani; [email-masked]; [email-masked]
Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8

I would second this approach.  I don't think we can impose a task on CAs
that we have no idea how to fix and many of us would consider to be
unsolvable.  Stating that the problem exists and both the CA and relying
party need to be aware of the problem is sufficient.

Suggested text:

When strings are mapped from internal representations to visual
representations, it frequently occurs that 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.  Issuers of
certifificates and relying parties both need to be aware of this fact.

Jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Wednesday, April 12, 2006 5:10 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Last Call summary for draft-ietf-pkix-cert-utf8
> 
> 
> For those of you who care, I simply tried to make Kurt's 
> language parsable.
> 
> Personally, I think the I-D should move to RFC status as is.
> 
> If folks really insist, we can say in security section that 
> human relying party should be aware of names that appear similar.
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: Wednesday, April 12, 2006 12:59 PM
> To: [email-masked]; 'Sam Hartman'; 
> [email-masked]; Jim Schaad
> Cc: [email-masked]
> Subject: Re: Last Call summary for draft-ietf-pkix-cert-utf8
> 
> 
> Jim,
> 
> >Denis,
> 
> >If you want to have a SHALL NOT or a SHOULD NOT in this statement,
> please
> >provide me an algorithm that I can give to a CA to do this 
> enforcement.
> 
> It was stated at the IETF in Paris that there was no perfect 
> solution to this problem.
> 
> Sam said that there is no consensus to make a specific 
> recommendation for mitigating this risk. I agree. Hence, we 
> are not going to provide any algorithm. The way to solve this 
> issue is the problem of the CA.
> The requirement remains.
> 
> Denis
> 
> >Thanks,
> 
> >Jim Schaad
> 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> >> Sent: Wednesday, April 12, 2006 7:48 AM
> >> To: [email-masked]; Sam Hartman; [email-masked]
> >> Cc: [email-masked]
> >> Subject: Re: Last Call summary for draft-ietf-pkix-cert-utf8
> >> 
> >> 
> >> Sam,
> >> 
> >> Your position as Security Area Director is the following :
> >> 
> >> "This concern must be mentioned as a residual risk even if 
> there is 
> >> no consensus to make a specific recommendation for mitigating this 
> >> risk.  So I will need wording possibly similar to that 
> suggested by 
> >> Kurt to document this security consideration.  I would propose 
> >> accepting Kurt's wording except that it doesn't seem to parse as 
> >> valid English for me."
> >> 
> >> I would propose to insert:
> >> 
> >>   "Two different subject names might easily appear (using the same 
> >> font
> >>   or different fonts) to have the same or close visual 
> >> representations,
> >>   hence before assigning a subject name to an entity, CAs 
> conforming 
> >> to
> >>   this profile SHOULD NOT assign a subject name that has 
> the same or
> a
> >>   similar visual representation of DN already assigned to another 
> >> entity".
> >> 
> >> I would however have no problem to change "SHOULD NOT" into "SHALL 
> >> NOT".
> >> 
> >> Denis
> >> 
> >> >Sam,
> >> >
> >> >How about the following:
> >> >
> >> >"Different character strings can appear to be the same
> >> string to human
> >> >relying parties.  In order to reduce this risk, CAs should
> >> define and
> >> >follow appropriate policies to reduce this risk by:
> >> >
> >> >1. Selecting their own names that are not easy to spoof to human 
> >> >relying parties; and 2. Asserting subject names that are 
> not easy to
> 
> >> >spoof to human relying parties."
> >> >
> >> >-----Original Message-----
> >> >From: [email-masked]
> >> >[mailto:[email-masked]]
> >> >On Behalf Of Sam Hartman
> >> >Sent: Tuesday, April 11, 2006 8:46 PM
> >> >To: [email-masked]
> >> >Cc: [email-masked]
> >> >Subject: Last Call summary for draft-ietf-pkix-cert-utf8
> >> >
> >> >
> >> >
> >> >
> >> >Denis Pinkas indicated that he had strong concerns about the
> >> document
> >> >because of spoofing attacks.  He believed that we should 
> recommend 
> >> >PrintableString where possible.
> >> >
> >> >Jim Schaad believed that supporting internationalization is
> >> important
> >> >and that we should afford people the same anti-spoofing 
> protection 
> >> >regardless of their character set.  Santosh Chokhani, Stefan
> >> Santesson
> >> >and Kurt Zeilenga also disagreed with Denis.  Kurt believed that 
> >> >spoofing i a problem even in the PrintableString case.
> >> >Kurt believed that security considerations text such as the
> >> following
> >> >should be added to the draft:
> >> >
> >> >     Two different character strings can easily appear (in
> >> >     common and/or a particular font) to be the same string and
> >> >     hence CAs should have and follow appropriate policies to
> >> >     reduce as to who is the subject of any certificate 
> they issue.
> >> >
> >> >
> >> >Denis supported Kurt's text although he argued that it
> >> should go in the
> >> >main body of the document not the security considerations section.
> >> >Denis also proposed that we recommend the use of
> >> PrintableString where
> >> >possible.  There was general disagreement with this 
> recommendation.
> >> >
> >> >A few people disagreed with the idea of adding security
> >> considerations
> >> >text.
> >> >
> >> >There was also a discussion of the appropriateness of CAs
> >> choosing to
> >> >issue certificates to anyone who had a domain name registered or 
> >> >whether they should filter the certificate requests.  This
> >> discussion
> >> >is largely out of scope and reached no consensus.
> >> >
> >> >I conclude there is no rough consensus to change the
> >> document in regard
> >> >to these issues.  I conclude that this discussion does 
> not challenge
> 
> >> >the rough consensus to publish the document.
> >> >
> >> >
> >> >However I find that Kurt has raised a substantive issue 
> that must be
> 
> >> >addressed before publication.  Neither RFC 3280 nor this draft 
> >> >discusses the security consideration of one name being 
> confused for 
> >> >another.  This concern must be mentioned as a residual 
> risk even if 
> >> >there is no consensus to make a specific recommendation for 
> >> mitigating 
> >> >this risk.  So I will need wording possibly similar to that 
> >> suggested 
> >> >by Kurt to document this security consideration.  I would propose 
> >> >accepting Kurt's wording except that it doesn't seem to 
> >> parse as valid 
> >> >English for me.
> >> >--Sam
> >> >
> 
> 
> 
> 
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Apr 2006 10:32:39 -0400

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.  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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Apr 2006 07:59:56 -0700

At 10:32 AM -0400 4/13/06, Russ Housley wrote:
>   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.
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Apr 2006 09:05:26 -0700

At 07:32 AM 4/13/2006, Russ Housley wrote:

>   multiple items being combined into a single glyph.  As a result of this situation,

This text adequately addresses my concern.  Thanks, Kurt

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 13 Apr 2006 10:41:50 -0700

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

jim 

> [mailto:[email-masked]] On Behalf Of Ted Hardie
> Sent: Thursday, April 13, 2006 8:00 AM
> To: Russ Housley; [email-masked]
> Cc: [email-masked]
> "Multiple items being combined into a single glyph" sounds 
> like you mean "the use of composed characters" (e + ' equaling
> 
> each with their own tricky bits).  If that is what you mean, 
> I'd suggest using that phrasing, as
> 
> 
> 
> 
> >>representations, sometimes two different strings will have the same 
> >>visual representations.  This can happen due to similar glyphs, 
> >>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.
> 
> 
>