Subject: Re: Last Call: 'Update to DirectoryString Processing in the Internet X.509Public Key Infrastructure Certificate and Certificate RevocationList

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 6 Apr 2006 08:52:24 +0100

To the IESG,

I have strong concerns with this document.

Santosh Chokhani wrote on 4/3/2006: Given the problems with UTF8 in terms 
of spoofing, should we not require or strongly urge the use of printable string 
when printable string will suffice ?

I totally agree with him.

On 06/03/2006, I wrote to the PKIX mailing list: 

 Michel Suignard from Microsoft gave a presentation on Unicode security considerations.
 As Unicode is used in security sensitive applications, there are a number of ways 
 where two strings that look similar or identical can actually be different strings. 
 Examples include domain names and other iidentifiers. The presentation discussed 
 many of the causes of these problems and gave numerous examples of potentially 
 confusing character combinations. The presentation also discussed the Unicode
 Consortium's current best practices in avoiding these problems. The presentation 
 was followed by  questions: 

      Paul Hoffman pointed out that in addition to the Unicode security issues people need to be
      aware of encoding. The most obvious case of this is the URL parsing attacks where Unicode
      escapes could be used to get around prohibited characters. Paul specifically mentioned cases
      where identifiers and text in environment might use different encodings. Paul warned that
      functions trying to enforce Unicode limitations might need to consider as many as seven
      common encodings. 

      Another concern is scripts written to assume that their input is just octets. With US ASCII there
      is only one way to represent characters. However if some parts of a system interpret characters
      as Unicode and some as ASCII, then problems may result. Network management scripts may
      be a particular concern. 

      The issue of backward compatibility was discussed. The IETF is in an unfortunate position
      because in order to correct errors in normalization the Unicode consortium made
      non-backward-compatible changes. These changes require us to decide what to do about the
      stringprep specification. Currently, stringprep is still using an old version of Unicode. Michel
      points out that this is not an acceptable long-term solution because characters have been added
      that parts of the world will want to use. 

      Nico Williams pointed out that there are other levels at which this problem exists. For example,
      misspellings can be instances of the same problem. Also, the ways in which we can fix this
      problem are limited. For instance, we cannot add prohibited characters to stringprep tables. 

      There was a discussion of the common solutions proposed to address this problem. Solutions
      include awareness of language and awareness of characters that do not normally go together.
      None of these solutions is perfect.
 
=====================================================================================================

Using different character sets, it is possible to have the same *visual* 
representation for differents DNs when thse DNs are coded using UTF8String. 

(text deleted)

RFC 3280 states:

   The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name field.

If only this rule is maintained, then a CA could legitimately issue 
two certificates that contain two different DNs, but which have the 
same *visual* representation.  

:-(

=====================================================================================================

I believe that it is necessary:

 1) to follow the position from Santosh,
 2) to add a section in the security considerations section to deal with these aspects.

Denis

>The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
>to consider the following document:
>
>- 'Update to DirectoryString Processing in the Internet X.509 Public Key 
>   Infrastructure Certificate and Certificate Revocation List (CRL) Profile '
>   <draft-ietf-pkix-cert-utf8-02.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2006-04-12.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-cert-utf8-02.txt

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Apr 2006 12:04:45 -0700

Denis,

I have a potential problem with the position that you have taken.  While it
works for those places which use only the ASCII characters set, it leaves
countries whos strings can only be represented in UTF8 strings left hanging
in the wind.  I am not sure that we can say that we are only going to
address this problem for a portion of the name space in the world and tell
everyone else that they are on their own.  This would lead to a
proliferation of solutions where each characterset creates its own
PrintableString type.

jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, April 06, 2006 12:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: 'Update to DirectoryString Processing 
> in the Internet X.509Public Key Infrastructure Certificate 
> and Certificate RevocationList 
> 
> 
> To the IESG,
> 
> Santosh Chokhani wrote on 4/3/2006: Given the problems with 
> UTF8 in terms of spoofing, should we not require or strongly 
> urge the use of printable string when printable string will suffice ?
> 
>  As Unicode is used in security sensitive applications, there 
> are a number of ways  where two strings that look similar or 
> identical can actually be different strings. 
>  Examples include domain names and other iidentifiers. The 
> presentation discussed  many of the causes of these problems 
> and gave numerous examples of potentially  confusing 
> character combinations. The presentation also discussed the 
> Unicode  Consortium's current best practices in avoiding 
> these problems. The presentation  was followed by  questions: 
> 
>       Paul Hoffman pointed out that in addition to the 
> Unicode security issues people need to be
>       escapes could be used to get around prohibited 
> characters. Paul specifically mentioned cases
>       Another concern is scripts written to assume that their 
> input is just octets. With US ASCII there
>       is only one way to represent characters. However if 
> some parts of a system interpret characters
>       stringprep specification. Currently, stringprep is 
> still using an old version of Unicode. Michel
>       points out that this is not an acceptable long-term 
> solution because characters have been added
>       Nico Williams pointed out that there are other levels 
> at which this problem exists. For example,
>       problem are limited. For instance, we cannot add 
> prohibited characters to stringprep tables. 
> 
>       include awareness of language and awareness of 
> characters that do not normally go together.
> Using different character sets, it is possible to have the 
> same *visual* representation for differents DNs when thse DNs 
> are coded using UTF8String. 
> 
> (text deleted)
> 
> RFC 3280 states:
> 
> If only this rule is maintained, then a CA could legitimately 
> issue two certificates that contain two different DNs, but 
> which have the same *visual* representation.  
> 
> :-(
> 
> >The IESG has received a request from the Public-Key Infrastructure 
> >(X.509) WG to consider the following document:
> >