> On 11 Jan 2017, at 21:23, Christian Heimes <christ...@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 _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig