IDNA200x and PKIX chain validation

[Paul Hoffman]

At 8:18 PM +0100 3/27/08, Simon Josefsson wrote:
>John C Klensin <klensin at jck.com> writes:
>
>>  --On Thursday, 27 March, 2008 09:40 -0700 Paul Hoffman
>>  <phoffman at imc.org> wrote:
>>
>>>  At 4:26 PM +0100 3/27/08, Simon Josefsson wrote:
>>>>  Doesn't this approach lead to, for example, that the outcome
>>>>  of X.509 certificate chain validation will depend on the
>>>>  locale in which the application is running in?
>>>
>>>  Not at all. The domain names used in chain validation are
>>>  expressed as punycode/A-labels.
>>
>>  And, as I understand it, are generally also in length-string
>>  label format, rather than dot-separated domain names.   So they
>>  are isolated from almost anything that goes on in the
>>  "characters the user is expected to see and interact with" side
>>  of things.
>
>I don't follow this.  Yes, domain names in certificates are stored as
>A-labels/LDH-labels today.  But the matching that takes places is
>against what the user types (the hostname in a https URL, for example).

Arrrgh, no. Chain validation has nothing to do with what the user typed.

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. Even in those cases, the application 
has already fully converted the "typed-in domain" to an A-label 
before the protocol has happened; otherwise, the application wouldn't 
know where the endpoint for the protocol was. Therefore, the two 
A-labels can be compared exactly.

>If the user types an IDN, that is converted into a A-label using
>IDNA200x and used during comparisons with what's in the certificate
>(possibly a IDNA2003 value).

Exactly right. The converted value is used for comparison.

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