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

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 7 Apr 2006 10:19:27 +0100

I will split the issue into three pieces :

1 - At this stage, I believe that everybody agrees that the draft 
cannot remain silent on that topic and, at minimum, the topic 
has to be adddressed in the security considerations section.

2 - Then, I quote the proposal from Kurt:

[Text deleted]

> I would however agree that the document should not be silent
> on the subject.  It should state something like:

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

> Note that I didn't mention Unicode in my suggestion.  As noted
> above, the spoofing problem is not limited to Unicode.

Section 4.1.2.6 from RFC 3280 states:

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

This rule is insufficient. The proposal from Kurt is nice and complements that rule.
Thus his sentence (or an adaptation of it) should be placed in the main body 
of the document.

3 - Finally, while I agree that spoofing may also happen with PrintableString, 
the use of Unicode is more dangerous than the use PrintableString, since it opens 
new possibilities.

So we should have a sentence like :

      (a)  if the character set is sufficient, the string SHOULD be
      represented as a PrintableString;

Denis

>- Kurt
>
>
>
>>Denis
>>
>>>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: Juergen Brauckmann <[email-masked]>
Date: Fri, 07 Apr 2006 11:02:32 +0200

>       represented as a PrintableString;

How does that help?

If a CA issues a certificate for company1 and for a spoofing site that
wants to look like company1 (this time with an utf8-encoded DN because
of all the fancy characters), it is IMHO irrelevant whether the DN of
the original company1 certificate was encoded in PrintableString or
UTF8. It simply depends on the fonts used by the relying parties whether
the spoofing attack succeeds.

I don't see that its harder for an attacker to construct a spoofing name
against a "real" name with a PrintableString "l" than an UTF8 "l".

Juergen

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 07 Apr 2006 12:38:23 +0200

I think it is a bad idea to select the type of the encoding i.e. 
printable string vs utf8
dynamically, i.e. encode printable string when possible else do utf8. 
The printable
string certs will probably be usable everywhere but the utf8 may have 
problems.

Would a CA tell users: Well, if you could remove your Umlaut or Accent ...
I don't think that everybody have the money as France Telecom to remove the
two accents on the "e"s.

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Apr 2006 13:47:33 -0400

>has to be adddressed in the security considerations section.

I do not agree.  One option is to add text as part of 
RFC3280bis.  The point of this document is to make a simple fix, and 
allow both PrintableString and UTF8String.

We have done the community a real disservice by not getting this 
document out long ago.  We bundled this change with RFC3280bis, and 
it got delayed, and delayed, and delayed.  Your issue has caused much 
discussion, and it is causing further delay.  And, I see very little 
support on the list for your position.

Russ