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
different purposes.

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

Reply via email to