On Thu, Sep 24, 2009 at 01:00:34AM +1000, Daniel Black wrote:
> On Wednesday 23 September 2009 13:25:09 Victor Duchovni wrote:
> > On Wed, Sep 23, 2009 at 11:03:55AM +1000, Daniel Black wrote:
> > > Should SSL_set_tlsext_host_name convert the domain name to ACE as per
> > > RFC4366 3.1 where it talks about IDNA (RFC 3490)?
> >
> > On the wire, domain names are always of the ASCII xn--mumble variety. The
> > corresponding Unicode is a matter of user display. Thus, to the extent
> > that hostnames are exchanged in SNI, they are ASCII host names. The RFC
> > is clear as mud of course. :-(
>
> http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3 got
> mentioned to me and though it clears it up it misses references to ACE.
>
> > So SSL_set_tlsext_host_name() is a valid ASCII domain name, that may
> > encode a Unicode name, but is not directly unicode.
>
> given the number of people/application programmers that will assume UTF-8 is
> valid here is validating characters > x7F worth it?
Such clients are in violation of the specification, there is no way for
the client to advertise the character-set of the hostname, and assuming
UTF-8, is neither robust nor easy to implement.
I would just ignore non-ASCII hostnames, if the hostname is being using
to select a server certificate/key pair for a DNS name. Pretend no SNI
data is sent.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
