Good point, understood, thanks. > I was suggesting either have it be a single label for the entire message or > putting the label into the TLS1.3 Cert Compression codepoint.
I think the former sounds more reasonable. 2 codepoints for (only CA pass 1 compression) and (Pass1+Pass2) seems to be wasting codepoints. The problem I am trying to address is cases where 1/ SCTs are not available (like Private PKIs), or 2/ the server is lazy and does not want to create that dictionary, or 3/ the benefit of Pass 2 is not important enough. I understand that you will collect data for 3/ to hopefully prove it, so I will wait for those. But I think 1/ and 2/ are still worth addressing. From: TLS <tls-boun...@ietf.org> On Behalf Of Dennis Jackson Sent: Wednesday, March 6, 2024 7:39 AM To: tls@ietf.org Subject: RE: [EXTERNAL] [TLS] draft-ietf-tls-cert-abridge Update CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Panos, On 05/03/2024 04:14, Kampanakis, Panos wrote: Hi Dennis, > I can see two different ways to handle it. Either as you suggest, we have it > be a runtime decision and we just prefix the compressed form with a byte to > indicate whether pass 2 has been used. Alternatively, we can define two > codepoints, (pass 1 + pass 2, pass 1). > I'd like to experiment with both operations and measure what the real world > difference is first, then we can make a decision on how to proceed. There's > also been more interest in the non-webpki use case than I expected, so that > needs to factor in to whichever option we pick. Maybe these will not matter for the scenario I am considering. Let’s say the client advertised support for draft-ietf-tls-cert-abridge. And the server sent back - CompressedCertificate which includes the 2 identifiers for the ICA and RootCA from Pass 1. - uncompressed, traditional CertificateEnty of the end-entity certificate Or it sent back - uncompressed, traditional CertificateEnties for the ICA and RootCA certs - CompressedCertificate which includes the ZStandard compressed (based on the Pass2 dictionary) end-entity cert My point is that nothing should prevent the client from being able to handle these two scenarios and normative language should point that out. Any software that can parse certs in compressed form, ought to be able to parse them in regular form if the server did not support Pass1 (CA cers were not available for some reason) or Pass2 (eg. if CT Logs were not available for some reason). Am I overseeing something? Yes I think so. TLS1.3 Certificate Compression applies to the entire Certificate Message, not individual CertificateEntries in that message. Those individual entries don't currently carry identifiers about what type they are, their type is negotiated earlier in the EncryptedExtensions extension. So to handle this as you propose, we'd need to define a type field for each entry to specify whether that particular entry had undergone a particular pass (or both). In my message, I was suggesting either have it be a single label for the entire message or putting the label into the TLS1.3 Cert Compression codepoint. Best, Dennis
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
