sftcd

I did a bit of prototyping of the `ECHStore` stuff above - I have a [branch](https://github.com/sftcd/openssl/tree/ECHStore-1) where the `_init()` `_free()`, `_new_config()` and `_make_pemech()` functions work, and it looks quite feasible,...

> I think the concept of the ECHStore, broadly in line with what you are proposing, is the right way to go. I would call it `OSSL_ECHSTORE` instead though to...

> We don't need to expose any internal structure or fields of an ECHConfig or ECHConfigList. Ah, good. > They can be entirely opaque with constructors for various sources (e.g....

> So I don't see that any application ever needs to know about an ECHConfig I guess, to be fair, if one wanted to offer a rich API for handling...

> By passing the raw bytes around you have to parse it every time. Using an object you can parse it once, and just pass that object around from then...

Just checking in case we're talking past one another: an ECHConfigList is not like an X.509 certification path - there's no chaining and the list is just a set of...

> I don't think we can know how applications will use these APIs, nor how they will evolve over time, whether we will want to enable access to the initially...

So, based on yesterday's discussions I've pushed a new version of [the API design](https://github.com/sftcd/openssl/blob/feature/ech/doc/designs/ech-api.md) and the [demo code](https://github.com/sftcd/openssl/blob/feature/ech/demos/sslecho/echecho.c). I'd say maybe best to read the API doc from scratch as...

ping! I've travel next week so could make progress on that `OSSL_ECHSTORE` stuff if it looks like the the right direction. Is it? Also - I hope we're not expecting...

ping again:-) feedback welcome!