[136020] in cryptography@c2.net mail archive
Re: TLS Server Name Indication and IDNA?
daemon@ATHENA.MIT.EDU (Paul Hoffman)
Fri Oct 24 08:25:39 2008
In-Reply-To: <20080929152906.GP29713@np305c2n2.ms.com>
Date: Mon, 29 Sep 2008 16:21:04 -0700
To: Victor Duchovni <Victor.Duchovni@morganstanley.com>,
cryptography@metzdowd.com
From: Paul Hoffman <paul.hoffman@vpnc.org>
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@metzdowd.com
