> One crucial requirement for such an API is to provide a way to do server
> certificate verification, or to specify how it should be done by the
> underlying software.  Clients that don't check servers' certificates are
> surprisingly common, and put their users at risk.  I encountered
> another such unfixed project just yesterday.
>
> Another requirement is to allow control of exactly what crypto algorithms
> and TLS/SSL versions will be accepted.  There are well-known
> vulnerabilities in earlier versions, and it's important that users who want
> to can avoid accepting connections using those versions.
>
> Ideally, the API should support sending client certificates.

Very good points all. OpenSSL probably has command line flags for all of
these.

Are you able to write parts of SRFIs while serving as the SRFI editor? I
can try to put these together but I wouldn't rely on myself to get it right.

> Despite the general recommendation against implementing one's own crypto,
> there are some examples of what appear to be excellent new implementations
> in other languages, e.g. Ocaml-TLS <https://github.com/mirleft/ocaml-tls>.
> Perhaps someone will make an attempt at an implementation in Scheme.  I'd
> certainly be willing to entertain the possibility that it would be better
> than one written in C.

<https://akkuscm.org/packages/TerribleTLS/> -- TLS 1.0 and 1.1 in pure R6RS

<https://github.com/weinholt/industria> has a lot of pure R6RS crypto
but not yet SSL/TLS

I agree that it's good that crypto implementations start popping up in
non-C languages. However, one problem is that it's hard to wipe secret
data from memory in a GC'ed language. I've never seen a good solution;
languages that hit that problem tend to simply ignore it :-/ Go is the
most recent example I came across.