Put X509.Authenticator.authenticate into an IO monad?

[dsheets]

Is this reasonable? What if a user's authentication routine requires I/O?

[hannesm]

I'd prefer to not have a user's authentication routine to require I/O. any specific use case in mind?

[dsheets]

Logging certificates to disk or implementing something like Perspectives/Convergence are use cases.

[dsheets]

Also SCVP (RFC 5055).

[dsheets]

And anything else that does DPD/DPV (RFC 3379).

[dsheets]

As we just discussed, exposing an intermediate state value (abstract) would also solve this problem. @pqwy suggested using that approach at a low level and putting a monadic interface on it at a higher level (e.g. TLS).

[pqwy]

To wrap up:

x509 was split out of, and developed in parallel with ocaml-tls.

We absolutely knew that as some point, we would want the certificate authenticator to do wild things and potentially talk over the network. tls is actually monadic in anticipation of this; the idea was to parameterize over the underlying monad and allow it to be instantiated over Lwt.t, to make it possible to hand off to the cert library smoothly.

But in the course of writing tls, its purity turned out to be an asset more and more. And on the other hand, it currently looks like certificates are the only place in tls where we would want to plug an effect in. So it turns out that the value of converting tls to interop with a side-effecting x509 is not clear.

As x509's primary consumer is ocaml-tls, changes in this library depend on how we shape the other library. There are several ways to mix tls with a side-effecting x509, and it's absolutely on the table, from the beginning.

But please do not expect this do be done too soon; it's fiddly and it's unclear how to do it properly.