On 07/07/2023 17:42, Salz, Rich wrote:
I would love to get feedback from the working group on whether the draft is
worth developing further.
I read your document [1] and found it very interesting.
Thanks Rich!
I found the handling of extensions complicated, although I admit to reading
that part very quickly.
How much simpler would things be if the identifier were just a SHA256 hash of
the CA, perhaps truncated? You send an array of (url, timestamp) as an
extension, and then the server just sends the digest of its cert chain, perhaps
even its own cert.
So this draft is doing two different things: building the dictionaries
in a fair way and then specifying how to use them as part of the
existing TLS Certificate Compression extension. Implementations only
care about the second part which only involves a bit of string
substitution and a call to ZStd. They don't have to know or care about
how the dictionaries were built or do any new kind of negotiation.
I don't follow your comment about the handling of extensions, the code
doing the compression and decompression isn't aware of what an extension
is or handling them specially, its just swapping strings. In order to
compress the larger strings which issuers add to end entity certificates
(e.g. OCSP & CRL URLs, practice statements), the dictionary does include
some extensions made by each issuer, but these are just concatenated
binary strings.
Best,
Dennis
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
