On 11 Jan 2017, at 21:23, Christian Heimes <christian@cheimes.de> wrote:
* Do we need to define blocking / non blocking state of the socket?
I think we want to support both. I’m not sure we need to expose it in the API: the implementation can check by asking the socket directly if it cares.
* What about STARTTLS support, do we need to define how to deal with data that has been transmitted before?
Hrm. I’m inclined to want to hold off on that to begin with, though you’re welcome to propose an API extension if you have a concrete idea of how to do it.
Maybe we can get away without any extension to the API. SRV-ID uses underline to signal a service identifier, e.g. _http.www.example.org. In the future an application could pass down a service identifier as server_hostname argument and let the TLS library deal with it like this:
if server_hostname.startswith('_'): srvid = server_hostname service, hostname = server_hostname.split('.', 1) service = service[1:] else: service = srvid = None hostname = server_hostname
Yup. That could well work. Another good argument for “wait and see” ;).
OpenSSL's hostname verification code accept IDN A-labels. SubjecAltNames are encoded as IA5String containing IDN A-labels, too. For most flexibility the wrap functions should accept server_hostnames as both U-label and A-label. If you add an encode_hostname() method to the context, than users can easily override the method to switch between IDNA 2003, 2008 or perform custom checks to prevent homoglyphic confusion attacks.
My question here is: do we need to pursue this in the abstract API? Or can it be left up to concrete implementations to worry about? Cory