A stamp of approval if ever there was one.
Thank you.
What, however, hinders adoption as a "working man's"
TLS library? Neglecting performance and variety of
cipher support, would or should anything prevent me
from using Tiny TLS to secure channels between
"inner circle machines" (that talk to a set of
well-known participants)?
My advice is not to use obscure TLS libraries in production. Look at the recent Frankencerts paper to see what goes wrong: only OpenSSL, NSS, and Bouncycastle (the mainstream libraries) properly rejected pathological X.509 certificates.
If you're trying to deploy pure-Python applications, I like tlslite. Of course, I have to say that, because Trevor is much smarter than me.
Personally, I think your realistic production choices are OpenSSL or NSS.
Vacillating between floating away on my recently-inflated feeling of
self-worth and trying to keep you engaged on a very uneven playing field
(as in my not knowing Adam from Eve, so to speak), I'll simply opt for
another Thank you.
Apropos nothing else: tlslite and Adam Langley's golang/crypto/tls are the two best codebases on the Internet to (a) learn TLS from and (b) build tools with. They are both extremely great projects.
What, however, hinders adoption as a "working man's" TLS library? Neglecting performance and variety of cipher support, would or should anything prevent me from using Tiny TLS to secure channels between "inner circle machines" (that talk to a set of well-known participants)?