On 2017-01-11 21:16, Cory Benfield wrote:
>
>> On 11 Jan 2017, at 19:36, Christian Heimes <christ...@cheimes.de
>> <mailto:christ...@cheimes.de>> wrote:
>>
>> Since this function is only required for TLS servers and TLS client cert
>> authentication, I'd rather mark this function provisional or not define
>> it in the first version.
>
> Is that the best option? Will there be any TLS implementation that
> cannot meet a stripped down version of this function’s requirements? If
> we can achieve a minimum viable approach whereby 80% of the use-case
> (unencrypted/encrypted certs on disk) can be met, I’d like to be able to
> meet it.
Of course we can solve any problem by adding just another layer of
abstraction! :) In this case it seems preferable and matches my idea for
3.7 improvements. How about you change register_certificates() to accept
a list of certificate instances (sorted from EE, intermediate 1 (issuer
of EE), intermediate 2 (issuer of 1), intermediate 3 ...) and a key
object. The exact nature of a certificate class is implementation specific.
The approach has also the benefit that file to list of certificates is
handled by the certificate class:
class Certificate:
@abstractclassmethod
def from_buffer(cls, filename: (str, bytes)) -> List(Certificate):
pass
@abstractclassmethod
def from_file(cls, filename: path) -> List(Certificate):
pass
>> Implementors should initial context with sensible default settings,
>> preferable system-wide settings. For example Fedora is currently
>> implementing https://fedoraproject.org/wiki/Changes/CryptoPolicy for
>> OpenSSL, NSS and GnuTLS.
>
> Is this an additional requirement to create_default_context, which
> should presumably be able using this API to do sensible things?
I would rather make the default contexts secure by default without the
need of a secure factory function. set_ciphers() should not be needed at
all to get good settings. Only poor slobs should use set_ciphers() to
enable bad ciphers for broken legacy systems.
> When you say “not defining this at all”, do you mean not using
> “server_side”? Because we definitely need the some wrap methods.
Sorry, I was not precise here. I meant that both wrap methods should be
limited to ClientContext and ServerContext classes. There is no good use
case to have a context that supports both client and server connections.
In Python code:
del _BaseContext.wrap_socket
del _BaseContext.wrap_buffers
:)
Christian
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
