IDNA200x and PKIX chain validation

[Simon Josefsson]

Paul Hoffman <phoffman at imc.org> writes:

> I think you are referring to validating the applicability of a
> particular cert given to a relying party during a protocol exchange,
> such as in the TLS handshake.

Yes, exactly.  Sorry for the confusion.

>>If the A-label can be different depending
>>on the locale in which the browser runs in, the validation will yield
>>different results.
>
> We disagree here. The application compares the A-label used in the
> protocol (such as to get to the HTTP server) and the A-label in the
> certificate.
>
> Assume that VeryBrokenBrowser maps e-acute (é) to e-umlaut (ë) in my
> locale. I enter "https://éxample.com", which is xn--xample-9ua.com in
> IDNA2003. VeryBrokenBrowser for IDNA200x comes out with
> xn--xample-ova.com. The browser then resolves xn--xample-ova.com to an
> A record, goes there on port 443, and starts TLS. The certificate it
> receives will list xn--xample-ova.com, not xn--xample-9ua.com.

Compare instead that the user types TURKISH.TR into
SeeminglyCorrectBrowser, which is running in a turkish locale, and
happens to map the name to lower-case (as suggested in IDNA200x
-protocol section 5.3), which yields turkısh.tr, which is then looked
up as xn--turksh-s9a.tr.  Assume also that the administrators of that
site registered for a certificate for TURKISH.TR and received a
SubjectAltName of TURKISH.TR.  TLS hostname verification will fail here.

The problem here is that the browser and the X.509 system used different
IDNA mappings without someone (i.e., administrator) manually noticing
that this happened, and had to manually make sure that the certificate
also contained xn--turksh-s9a.tr.

In IDNA2003 this never happens, as far as I can tell, since that
document prescribes a mechanism that is locale-independent.

I suspect there are other examples where locale-depended mapping cause
interop problems like this.

Further, if IDNA200x makes backwards incompatible changes so that it
produces A-labels that are different from what IDNA2003 produces, the
problems are more complex.  (The PR-29 strings is one example of such
changes, but I'm not sure whether there are other realistic examples.)

/Simon