gnutls_server_name_set and IDN

[Daniel Black]

On Wednesday 23 September 2009 18:57:28 Simon Josefsson wrote:
> Daniel Black <daniel at cacert.org> writes:
> > Should gnutls_server_name_set convert the domain name to ACE as per
> > RFC4366 3.1 where it talks about IDNA (RFC 3490)?
> >
> > Using libidn function call can make this occur using idna_to_ascii_8z can
> > make this happen though this is adding dependency.
> 
> That text has been dropped from RFC 4366bis:
> 
> http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3
> 
> I think the text in RFC 4366 is confusing and difficult to implement
> interoperably.

definitely. Its rewrite is clearer. It did take me a bit to realise that ASCII 
was only 0-7F and not the same as UTF-8.

> What the new text means is that GnuTLS applications are responsible for
> converting any internationalized domain name into ACE before passing the
> string on to GnuTLS.

Ok. Some really clear text in the documentation about this would be good. As 
the UTF-8/ ASCII error may be common is it beneficial to validate this input to 
check for >7F characters?

Attached patch clarifies the gnutls_server_name_set function input. I'm not 
sure a UTF-8 -> ASCII replacement on gnutls_server_name_get is entirely true 
however some additional clarification here would be good.

> Let me know what you think of this, there is still time to bring this up
> in the IETF.

Its clarify also simplifies it to the point that their is no mention of IDNA as 
an appropriate mechanism to convert encodings to ASCII. Was this intentional? 
I'm of the opinion, until abused otherwise, that appending "UTF-8 and other 
character sets can be converted to ASCII using the ToASCII function defined in 
RFC3490 section 4." (or similar) to the "HostName" definition paragraph.

also maybe 6.1. could say, in response to the last bit of 3.1, + "Server 
applications SHOULD validate server_name against any application layer 
equivalent field."

Thanks Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls_server_name_set-docfix.patch
Type: text/x-patch
Size: 575 bytes
Desc: not available
URL: </pipermail/attachments/20090924/b6f1143f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20090924/b6f1143f/attachment.pgp>