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

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 7 Apr 2006 10:52:23 +0100

Denis,

I don't think there is an agreement yet that the problem must be solved
in this document. If this requires extensive thought then we are
probably better of solving it in RFC 3280bis. As long as this draft is
hold back, the current governing wordings in 3280 remains, which is much
worse.

Stefan Santesson

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 7 april 2006 11:19
> To: Kurt D. Zeilenga
> Cc: [email-masked]; [email-masked]
> Subject: Re: Last Call: 'Update to DirectoryString Processing in the
> Internet X.509PublicKeyInfrastructure Certificate and Certificate
> RevocationList
> 
> 
> 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:owner-ietf-
> [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: "Santosh Chokhani" <[email-masked]>
Date: Fri, 7 Apr 2006 04:18:55 -0700

I do not have objection to the sentence Denis suggests.

But, it does not reduce the threat.  The analysis was posted in my
yesterday's post.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Friday, April 07, 2006 5:19 AM
To: Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]
Subject: Re: Last Call: 'Update to DirectoryString Processing in the
Internet X.509PublicKeyInfrastructure Certificate and Certificate
RevocationList

[Text deleted]

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.

Denis

where
relying
>>>parties reject UTF8.  That benefit is not so much a security benefit,
printable
security
presentation
the
>>>Unicode
>>> Consortium's current best practices in avoiding these problems. The
>>>presentation 
security
>>>      escapes could be used to get around prohibited characters. Paul
is
>>>      is only one way to represent characters. However if some parts
of
>>>      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
>>>      stringprep specification. Currently, stringprep is still using
an
>>>      Nico Williams pointed out that there are other levels at which
ways
address
>>>this problem. Solutions
>>>      include awareness of language and awareness of characters that
do
>>>      None of these solutions is perfect.
===
*visual*
field.
>>>same *visual* representation.  
===
with
>>>>- 'Update to DirectoryString Processing in the Internet X.509 Public
>>>Key 
>>>>   Infrastructure Certificate and Certificate Revocation List (CRL)
>>>Profile '
solicits

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 7 Apr 2006 04:23:47 -0700

In my humble opinion the threat can not be reduced unless you ban UTF8.

You can improve interoperability with those environments who ban UTF8.

If relying parties started providing human users notice (which I doubt
will happen) "beware of UTF8", requiring or recommending printable
string can reduce those pop up warnings.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Friday, April 07, 2006 5:52 AM
To: Denis Pinkas; Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]
Subject: RE: Last Call: 'Update to DirectoryString Processing in the
Internet X.509PublicKeyInfrastructure Certificate and Certificate
RevocationList

Denis,

Stefan Santesson

CA
complements
main
since
relying
benefit,
the
security
presentation
the
The
security
Paul
is
parts of
Network
is in
Unicode
using an
which
ways
that do
==
field.
==
Public
(CRL)
solicits

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 7 Apr 2006 11:39:50 -0700

I do not agree with Phillip.

Certain environments would prefer to be exclusively printable, or printable
for CA and printable for end entities to the maximum extent possible.

These implementations want to remain IETF standards compliant.  We do not
want to change 3280 so that they are no longer in compliance with the IETF
standards.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: Friday, April 07, 2006 12:05 PM
To: Stefan Santesson; Denis Pinkas; Kurt D. Zeilenga
Cc: [email-masked]; [email-masked]
Subject: RE: Last Call: 'Update to DirectoryString Processing in the
Internet X.509PublicKeyInfrastructure Certificate and Certificate
RevocationList

I think that we should plan to phase out the use of all encodings other than
unicode at some point in the future. We are not in a world planning to move
to X.500 at any point in the future. The X.500 encodings, teletex encodings
etc are all legacy. 

We are not just writing a draft for today, it may be a decade before we
return to these docs. I would not like to have a SHOULD that directs people
to insert unnecessary code paths.

We do have something of an issue re punycode, do we transliterate or not. I
don't think it matters provided we pick one and stick with it.

As someone who deals with phishing I do not think that there is the
slightest significance of so called homologue attacks that is not already
realized in lookalike domain names. It is not going to be possible to defeat
phishing if the examination is at the character code level. People do not
recognize X.500 DNs, nor should they. People do not even recognize DNS
names, nor were they designed for that purpose.

The way to fix phishing is to make use of the LOGOTYPE extension and have
the CA authenticate the actual cue that the user responds to.

I suggest the following:

* UNICODE be clearly identified as the future target to which everything
eventually transitions.
* Explain the issues to do with character sets in the security
considerations section
* Let CAs be the judge of what is best and what is the best timing for
transition

I don't think that many CAs are going to be reading the document as a guide
to how to provide legacy support for long deployed applications and how to
avoid the type of attacks described. What I want the document to do is to
create the opportunity to eventually transition to one single coherent
scheme at some point in the distant future.

> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Subject: RE: Last Call: 'Update to DirectoryString Processing 
> in the Internet X.509PublicKeyInfrastructure Certificate and 
> Certificate RevocationList
> 
> 
> Denis,
> 
> I don't think there is an agreement yet that the problem must 
> be solved in this document. If this requires extensive 
> thought then we are probably better of solving it in RFC 
> 3280bis. As long as this draft is hold back, the current 
> governing wordings in 3280 remains, which is much worse.
> 
> 
> Stefan Santesson
> 
> 
> > cannot remain silent on that topic and, at minimum, the 
> topic has to 
> > be adddressed in the security considerations section.
> > 
> > > I would however agree that the document should not be 
> silent on the 
> > > subject.  It should state something like:
> > 
> > PrintableString, the use of Unicode is more dangerous than the use 
> > PrintableString,
> since
> > it opens
> > new possibilities.
> > 
> > >>>terms of spoofing, should we not require or strongly 
> urge the use 
> > >>>of
> > printable
> > >>>string
> > >>>number of ways  where two strings that look similar or identical 
> > >>>can actually be different strings.
> > >>>potentially  confusing character combinations. The presentation 
> > >>>also discussed
> the
> > >>>Unicode

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Apr 2006 18:00:57 -0700

The existing text works for me.

I think it is a fine and good thing to promote UTF8 as the target to aim at.

Clearly we are not in a position to deploy UTF8 exclusively by the target
date set even if we finish the time machine.

What I was arguing against was what appeared to be a misguided proposal that
appeared to be a half baked notion to stop phishing based on a fundamental
misunderstanding of the nature of cousin domain attacks. There is no form of
static syntax constraints that can possibly prevent cousin domain attacks
because there is an infinite number of domains of the form xxx-example.com
that can be used to produce convincing domains. Syntax constraints are
useful and it is certainly a good idea for CAs to exercise due care and
attention when issuing certificates with I18N names, particularly those
involving mixed code pages. Such caution cannot be reduced to a set of rules
and nothing is achieved by telling people to only use ASCII characters.

> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Monday, April 10, 2006 7:29 PM
> To: Hallam-Baker, Phillip
> Cc: Stefan Santesson; Denis Pinkas; Kurt D. Zeilenga; 
> [email-masked]; [email-masked]
> Subject: Re: Last Call: 'Update to DirectoryString Processing 
> Phil, this discussion has wondered a bit and I'm trying to 
> figure out where you are in it.  Do you support the current draft?
> If not, what concerns do you have and what changes would you 
> like to see made?
> 
> 
>