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

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 6 Apr 2006 03:36:30 -0700

Denis,

I have been rethinking my position.  In terms of spoofing the human
relying party using character encoding, requiring printable string when
possible does not defeat the threat of intentionally created UTF8 string
that is similar.  Protection of human relying parties will require
banning UTF8 altogether.

The benefit of strongly recommending or mandating printable string where
possible is only to those high assurance environments where the relying
parties reject UTF8.  That benefit is not so much a security benefit,
but interoperability benefit in terms of being able to accept more
certificates since more certificates will be encoded as printable
string.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Thursday, April 06, 2006 3: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,

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: Russ Housley <[email-masked]>
Date: Thu, 06 Apr 2006 09:30:05 -0400

Santosh:

RFC 3280 says that the only encoding allowed (after December 31, 
2003) is UTF8String.  Clearly, this MUST statement was not followed 
in implementations, and the document that we are discussing updates 
RFC 3280 to allow either UTF8String or PrintableString.  If we 
discourage the use of UTF8String, then we are penalizing the folks 
that followed RFC 3280 -- that does not seem right to me.

Russ