IDNA200x and PKIX chain validation
Paul Hoffman
phoffman at imc.org
Fri Mar 28 20:45:45 CET 2008
At 12:33 PM +0100 3/28/08, Simon Josefsson wrote:
>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 turksh.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.
No, it won't. The browser looks up an A record for xn--turksh-s9a.tr
and takes the user there (if it exists). The site that is at
xn--turksh-s9a.tr had better no be using a certificate for TURKISH.TR
or MICKEYMOUSE.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 xn--turksh-s9a.tr.
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
affected.
More information about the Idna-update
mailing list