IDNA200x and PKIX chain validation

Paul Hoffman phoffman at
Fri Mar 28 20:45:45 CET 2008

At 12:33 PM +0100 3/28/08, Simon Josefsson wrote:
>Paul Hoffman <phoffman at> 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://é", which is in
>>  IDNA2003. VeryBrokenBrowser for IDNA200x comes out with
>> The browser then resolves to an
>>  A record, goes there on port 443, and starts TLS. The certificate it
>>  receives will list, not
>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ž, which is then looked
>up as  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.

No, it won't. The browser looks up an A record for 
and takes the user there (if it exists). The site that is at had better no be using a certificate for TURKISH.TR 

>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

The administrator who registers multiple names, regardless of why 
they are multiple, needs to make sure that there is a cert for each 
name. IDNA200x does not change this. Again: if the user has gotten 
there, they resolved a DNS name to an A record. Someone had to set 
that mapping.

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

We disagree here too, for the same reason. If there is a 
backwards-incompatible change, the administrator needs to register a 
new name. They will need a new certificate that matches that new 
name. There is still no chance that the PKIX matching rules will be 

More information about the Idna-update mailing list