> On 11 Jan 2017, at 21:23, Christian Heimes <[email protected]> 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
[email protected]
https://mail.python.org/mailman/listinfo/security-sig
