Certificate meta-information file

[breard-r]

There will be a point where it is necessary to store informations about a certificate that do not belong to the configuration. For example, this may be necessary to implement STAR certificates (RFC 8739). I have not read the full specification, but from the few I read it seems necessary to keep track of some state on the client side, at least in order to know if it's a "traditional" certificate or a STAR.

Where to store this file?

There is multiple possibilities, the one I find the more promising being:

• one file per certificate stored along with the private key and the certificate
• one file per certificate stored in a dedicated directory
• one unique file stored I don't know where which contains the entries for all the certificates

I would prefer the one file per certificate approche since it would be coherent with what has already be done for the accounts and is easier for people to manage.
Using this approche, the file_name_format will be used with:

• file_type set to something like meta
• ext set to bin (if bincode is chosen)

Which file format?

The file format itself should be the same one as the account's. Currently that is the binary format provided by the bincode crate, however it might evolve if necessary.

Because the file's content may evolve in the future, this should be taken into consideration from the beginning. I don't remember how bincode allows this, but I think the following method should work: try to load the latest structure, if it fails try the previous ones until it matches and upgrade to the latest.

When?

I would like to limit new features before the async rewrite, however it doesn't prevent discussing this future improvement.

[jcgruenhage]

I think it makes sense to consider prior art here, to see how other ACME clients tackle this, if at all. I'll start by listing the ones I know of the top of my head:

• acmetool is the only one that has it documented in every single detail, see https://github.com/hlandau/acmetool/blob/master/_doc/SCHEMA.md
• lego uses a json file that's sitting in the same directory as the certificate and private key

Regarding the format: bincode itself doesn't handle schema differences at all, and from what I can tell, it might accidentally parse data even if the structs did change, so automatically falling back if it doesn't parse is dangerous.

It would be possible to split this into a wrapper instead, that contains a version number and a byte vec. After parsing the version number, the byte vec could be parsed again, this time through the correct struct. A fancy version of this, which would allow us to skip all the replication of the fields for the different versions is provided by https://lib.rs/crates/obake.