gnutls_server_name_set and IDN
daniel at cacert.org
Thu Sep 24 02:43:51 CEST 2009
On Thursday 24 September 2009 01:59:05 you wrote:
> Improved now, thanks, see:
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
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.
> "Server applications SHOULD validate server_name against any ...
> That makes sense to me. I'll forward that to the TLS list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Gnutls-devel