On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote: > Hi Ilari, > > On 10/07/2023 20:19, Ilari Liusvaara wrote: > > > > And an alternative idea: > > > > [...] > > > > 1) Where if next certificate in chain is also not found, zstd uses > > empty dictionary. Otherwise it uses dictionary associated with the > > next certificate in chain. > > > > [...] > > > > This allows dictionaries to be specific to CA, avoiding tradeoffs > > between CAs. > > Interesting idea! Can you share more about the motivation for using many > small dictionaries rather than a single combined one? Is it purely for > supporting memory constrained devices? We can already ensure that each CA > contributes an equal number of bytes to the pass 2 dictionary. > > One drawback is that some of the data isn't unique to a particular issuer > (e.g. the CT log ids) and so would either have to be handled in its own pass > or be included as redundant data in each individual dictionary.
Actually, I don't think this idea would work well: Clients would still need at least all the dictionaries for end-entity certificates, for the case where server certificate is from unknown CA and certificate validation is overridden. Because to comply with TLS 1.3 requirements (CV validation is required), the client needs the server signature key, which is embedded in server certificate, which in turn needs dictionary to decompress. Altough I think it is technically possible to just skip CV validation, allowing the decompression to be skipped. However, this breaks the TLS 1.3 specification. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
