TLS Server Name Indication and IDNA?

[Paul Hoffman]

RFC 4366 is somewhat of a mess. I do not remember the authors asking 
the authors of IDNA (of which I am one) about what they should do.

FWIW, I'm not sure why this would be on the cryptography list, but 
I'm not sure of that for most of the "we can design a better UI" 
threads either.

>What should the SMTP client put in the RFC 4366 section 3.1 "HostName":
>
>     - The ACE domain it is working with (xn--exmple-cua.com)?
>     - The underlying UTF8 domain name? (exämple.com)?

Hopefully, the former. But if that doesn't work, try the latter.

>What should the server do when it receives the client's "HostName"?
>
>     - Convert ACE to UTF8?
>     - Convert UTF8 to ACE?

Hopefully, neither: leave it as an ACE.

>What type of comparison is the server expected to perform?
>
>     - Convert UTF8 CommanName to ACE (also leave IA5 alone) and then compare?
>     - Convert ACE names in either subjectAltName or CN to UTF8 and then
>       compare UTF8 strings (with NAMEPREP, STRINGPREP and all that jazz)?

Hopefully, neither: leave it as an ACE.

>This can be (to say the least) rather unpleasant. If IDNA is only between
>the user and the UI, with everything on the wire in ACE form,

Yes.

>then all
>the pain is avoided:

Yes+. That's why we designed IDNA that way.

--Paul Hoffman, Director
--VPN Consortium

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com