gnutls_server_name_set and IDN

[Daniel Black]

On Thursday 24 September 2009 01:59:05 you wrote:
> Improved now, thanks, see:
> 
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a12
> 90e27f8643b68a6c2dda

thank you. I'm assuming no mention of ACE because of reasons below.

> 
> > As the UTF-8/ ASCII error may be common is it beneficial to validate
> > this input to check for >7F characters?
> 
> ....not being able to interop
> against such a server just because of a input sanitation code seems
> overkill.
ack.

I assume people are passing UTF-8 to the socket connect method and then 
passing the same string to gnutls_server_name_set (IP or not). Which reminds 
me I need to find and IP address or not method out of socket structures.

> > 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?
> 
> Yes I think/hope so -- not mentioning IDNA specifically avoids
> inheriting the problems associated with it: support of non-ASCII
> hostnames then becomes entirely the IDNA specifications' problem.

it totally leaves the implementer in the dark find that spec though. I guess 
once its approved, provide documentation on gnutls and see what happens.

> IDNAbis is in WGLC now, so any such reference would be obsolete soon....Then 
implementers will ask whether the intention is that TLS SNI is only to be used 
with IDNA and not IDNAbis.
yep agree.

> "Server applications SHOULD validate server_name against any ...
> 
> That makes sense to me.  I'll forward that to the TLS list.
Thanks
-------------- 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/840b08f3/attachment.pgp>