Evaluate TLS handshake certificate chain compression

[JeremyRand]

Encaya's design is premised largely on the idea that TLS handshake bytes are cheaper than Namecoin blockchain bytes. This is true, but TLS handshake bytes are not free. In particular, QUIC seems to derive a noticeable performance boost when the cert chain is sufficiently small. This has led to TLS certificate chain compression being standardized by IETF.

Notable citations:

1. RFC 8879: TLS Certificate Compression
2. Does the QUIC handshake require compression to be fast?
3. On the interplay between TLS certificates and QUIC performance

Citation 2 claims:

The result was a certificate chain budget for an efficient handshake between 3,333 and 4,356 bytes depending on whether the initial client packet size was at the low or high end of the range.

There are some obvious attributes of Encaya cert chains that are likely to affect their size relative to non-Namecoin cert chains:

• Encaya uses ECDSA for the entire chain. This should yield a major advantage over non-Namecoin cert chains, which frequently involve RSA.
  • Would EdDSA yield a further improvement, given that EdDSA uses compressed public keys by default?
• Encaya chains may have more certs than non-Namecoin cert chains. Out of the box, Encaya chains are 2 certs (the end-entity cert, and the Domain CA cert), which matches non-Namecoin chains, but Encaya chains will have more certs if the domain owner is using one or more subordinate CAs.
  • Would encouraging domain owners to avoid subordinate CAs in favor of Selector=Cert #82 yield an improvement?
  • Is there some trick we could use to remove the Domain CA from the cert chain, i.e. the end-entity cert lists the Domain AIA Parent CA as the issuer? I don't recall anyone ever seriously looking into this. I think the current design arose primarily because the Domain CA existed before we were using AIA, and adding a separate Domain AIA Parent CA involved fewer code changes.
• Encaya Domain CAs are abnormally large due to the stapled data in the Issuer Serial Number and the AIA Issuer URL.
  • Is the encoding of the stapled data optimally compact? Can we tweak anything there?
  • Does the redundancy of the Issuer Serial Number and the AIA Issuer URL compress effectively?
  • Can we tweak the encoding of either the Issuer Serial Number or the AIA Issuer URL to make them compress better together? (The Issuer Serial Number can be arbitrary binary data in principle, although ASCII is better for display in cert viewers. The AIA Issuer URL must be a valid URL, which imposes notable constraints.)
  • Can we tweak the encoding of either the Issuer Serial Number or the AIA Issuer URL to make it compress better with the rest of the certificate? Is there any common data there?

What do our cert chains look like size-wise right now? Will we derive a benefit from tweaking things?