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

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 12 Apr 2006 15:47:44 +0100

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

Regards,

Denis Pinkas

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 12 Apr 2006 07:58:41 -0700

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.

Thanks,

Jim Schaad 

> 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,
> 
> 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."
> 
> >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."
> >
> >Denis supported Kurt's text although he argued that it 
> should go in the 
> >main body of the document not the security considerations section.
> >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.
> >
> >

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Apr 2006 10:44:42 -0400

Denis,

PKIX (and X.509) standards do not assume that every CA will be aware 
of the subject names in certs issued by any other CA. So, the phrase 
"hat has the same or a similar visual representation of DN already 
assigned to another entity" is asking too much relative to our 
(other) standards. It also appears to require a CA to have knowledge 
of rendering conventions by an unbounded number of applications in 
every natural language.  I think that is unreasonable.

Steve