Documentation and encoding of non-standardized formats

[cjpatton]

draft-ietf-tls-subcerts-09 specifies the wire format of the DC but not the corresponding key. Similarly, draft-ietf-tls-esni-09 specifies the wire format of the ECH configs used by the client, but not how the config and corresponding key are stored by the server. Interop tests will require these values to be generated prior to spinning up servers, so we will need to agree on how these values will be encoded.

I propose that the format of each artifact be specified in TLS syntax, then encoded in base64 before writing it to disk. Concretely, the following seems reasonable for an ECH key:

struct {
     opaque sk<0..2^16-1>;
     ECHConfig config<0..2^16>; // draft-ietf-tls-esni-09
} ECHKey;

The format of sk is specific to the KEM algorithm. For example, for DHKEM(X25519, HKDF-SHA256), this would simply be the clamped, 32-byte scalar as defined in RFC7748. (As for the NIST curves, I believe NIST has a standard encoding of scalars.)

[cjpatton]

In #25 it was suggested to use PKCS#8 as the format for private keys. This is convenient for NSS, and is pretty straightforward to implement for cloudflare-go. BoringSSL and rustls may not want to have to support PKCS#8, however.