It is not clear what exactly is replaced if cert_data is known.
Obviously overriding the length field would be more compact, but it
also can be interpreted as replacing the value, wasting 3 bytes.
(Reminds me of RFC 8879, which is not clear about similar things.)
CertificateEntry and Certificate length fields are just waste of
space, since both can be recovered in other ways when decoding.
RFC 8879 does not allow ignoring unrecognized three-byte identifiers.
Instead, the connection MUST be terminated with bad_certificate alert.
This has consequence that any client that can ever add a custom trust
anchor via any means must have the complete certificate list (whereas
partial list would be enough if no custom trust anchors can ever be
added).
And I find the last comment about transcript validation failing very
scary.
Section 3.2.:
Using alternate scheme could result drastically reduced implementation
complexity.
Furthermore, one can't even use standard zstd decoder with this due to
security reasons. One needs special one (but seems like reference zstd
library ships that as alternative API).
Section 3.2.1.:
I suspect that having CA-specific dictionaries would make it much
easier to be equitable and improve compression.
Then I don't think the dictionary construction method is good:
Using just one certificate is very dubious.
It is more optimal to consider byte substrings with no structure.
Section 3.2.1.1.:
Caching monolithic compression from startup does not work because of
extension fields.
For caching to work, one would have to compress the certificate
entries independently and leave the extension fields in between
uncompressed.
Section 5.1.:
I think the argument about adding roots taking time is flawed. Roots
are usually not even included in the chain, but intermediates are,
and can change much faster.
I remember seeing one CA that judging from naming of the intermediate
rotated it every 6 months.
Section 5.4:
I think the current complexity as I understand the draft is just
scary.
I consider not being able to adjust extension fields in the fly to
be a hard blocker (that is already a hard blocker for implementing
RFC 8879 sending side).