[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnutls_server_name_set and IDN
From: |
Daniel Black |
Subject: |
Re: gnutls_server_name_set and IDN |
Date: |
Thu, 24 Sep 2009 10:43:51 +1000 |
User-agent: |
KMail/1.12.1 (Linux/2.6.30.1-vs2.3.0.36.14-pre3-gentoo-r4; KDE/4.3.1; x86_64; ; ) |
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
signature.asc
Description: This is a digitally signed message part.