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

From: "Andrews, Rick" <[email-masked]>
Date: Thu, 6 Apr 2006 11:10:01 -0700

Kurt,

I don't agree that it's really a CA issue. The CA verifies that the
company requesting the certificate owns the domain name and optionally
the Organization name that will appear in the cert. If the company
legitimately purchased the domain name, they should be able to get a
certificate. I would argue that it's the responsibility of the domain
name registrar or registry to filter out domain requests that are
misleading. A phisher can mount an attack without using an SSL
certificate. That's why the Unicode Consortium, in Unicode Technical
Report #36 (Unicode Security Considerations), described recommendations
for domain registrars and registries.
(http://www.unicode.org/draft/reports/tr36/tr36.html)

-Rick

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kurt D. Zeilenga
> Sent: Thursday, April 06, 2006 8:31 AM
> To: Denis Pinkas
> Cc: [email-masked]; [email-masked]
> Subject: Re: Last Call: 'Update to DirectoryString Processing 
> in the Internet X.509PublicKey Infrastructure Certificate and 
> Certificate RevocationList
> 
> 
> At 06:07 AM 4/6/2006, Denis Pinkas wrote:
> >Mandating the use UTF8 was/is an error, because it is a 
> major security 
> >threat and that error should be corrected ASAP.
> 
> I disagree that this mandate is in error.  I disagree that 
> its a major security threat.  And I disagree that 
> printableString significantly reduces the spoofing threat.  
> One can generally create spoofs of one printableString using 
> only printableString.
> 
> As Stefan pointed out, this is really a CA issue.  Users who 
> choose to trust a CA, choose to trust that the CA is taking 
> appropriate steps not to allow one to obtain a certificate 
> that appears that it belongs to another.
> 
> 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.
> 
> - 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-ut
> f8-02.txt
> >>
> >>
> >>
> >>
> >>
> >
> >Regards,
> >
> >Denis Pinkas
> 
> 
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Apr 2006 11:51:40 -0700

At 11:10 AM 4/6/2006, Andrews, Rick wrote:
>Kurt,
>
>I don't agree that it's really a CA issue.

I argue that it's still a CA issue (or an issue
of which CAs a user chooses to trust).

>The CA verifies that the
>certificate.

First, I wasn't restricting my concerns to domain names nor
to Unicode.  In particular, I was including spoofing of the
subject DN distinguished values, including those in user
certificates (which generally don't contain domain name
distinguished values) and including strings restricted to
characters allowed in a printableString.

But even if we talk only about domain names, I note that a
CA is not obligated to issue certificates for all domains.  It
can choose to only issue certificates for those domains who
registries have and follow decent anti-spoofing policies.
This is good practice.

For instance, I can "own" ebay.com|.boolean.net (which I, the
owner of boolean.net, could create for spoofing ebay.com in URLs).
I would think that it is not only reasonable for a CA to deny
issuing of a certificate to the domain owner in this case, but
that it should the recommended practice to deny such certificate
requests.

>I would argue that it's the responsibility of the domain
>misleading.

CAs who defer responsibility to the domain name registrar or
registry are effectively deferring the responsibility to the
attacker.  The attacker is in many scenarios, such as the one
I suggest above, is the domain name registrar and/or registry.

>A phisher can mount an attack without using an SSL
>certificate.

Of course.

>That's why the Unicode Consortium, in Unicode Technical

I believe the Unicode Consortium recognized that their
recommendations for domain registrars and registries only
partially address Unicode security concerns in domain
names.  The Unicode Consortium made recommendations to
others to partially address other concerns.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 6 Apr 2006 16:04:23 -0400

>of which CAs a user chooses to trust).

in large part the problem we face is the notion of trusted third 
party CAs, vs. authoritative CAs. we have a few of the former, but 
essentially none of the latter, and this exacerbates the problem.

>characters allowed in a printableString.

same comment as above. if CAs were aligned with the DNS name space, 
this would be a much  more manageable issue.

>registries have and follow decent anti-spoofing policies.

you are right that CAs are not OBLIGATED to issue certs to anyone, 
but TTP CAs tend to WANT to issue certs to everyone, because that is 
how they make money!

>that it should the recommended practice to deny such certificate

if a CA makes such value judgements it may leave itself open to 
charges of restraint of trade, especially given the relatively 
monopolistic CA market for SSL server certs.

>I suggest above, is the domain name registrar and/or registry.

a TTP CA always relies on other sources to identify subjects. in the 
DNS space registrars are the appropriate sources of DNS name 
verification data. thus a CA is not implicitly negligent by relying 
on registrars.

Steve

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Fri, 07 Apr 2006 06:50:29 +0900

> of which CAs a user chooses to trust).

I agree to this point.
CA , as a Trusted Third Party, should have responsibility for avoiding
from issuing the mistakable subject name, as same as registrars avoid
the phishable FQDN.

Subject name should be distinguishable to human also.

> This is good practice.

Yes, it is good practice, not specification.

On Thu, 06 Apr 2006 11:51:40 -0700

-- 
Masaki SHIMAOKA <[email-masked]>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4172)