On 13 January 2017 at 23:56, Cory Benfield <c...@lukasa.co.uk> wrote:
> While we’re here, I should point out that this does not replace the abstract
> contexts entirely, because we still need the wrap_* methods. These would now
> just be fed a Configuration object (I’m more comfortable with the name
> Configuration than Policy for this usage) in their constructor, and then
> could use the wrap_* methods as needed.
Having a relatively passive configuration object sounds OK to me, and
I agree it's distinct from a Policy object (which would store
constraints on what an acceptable configuration looks like, rather
than a specific configuration).
> How does that idea sound to the rest of the list?
It would definitely address my concern about making it easy for people
to re-use the standard library's default TLS configuration settings,
and it would also make it easier to have different defaults for
So the essential stack would look like:
TLSConfig[uration?]: implementation independent, settings only
TLSClientContext: ABC to combine settings with a specific TLS implementation
TLSServerContext: ABC to combine settings with a specific TLS implementation
TLSSocket: ABC to combine a context with a network socket
TLSBuffer: ABC to combine a context with a pair of data buffers
And then TLSPolicy would be a potential future implementation
independent addition that could be used to constrain acceptable TLS
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
Security-SIG mailing list