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
But I thought retired people were supposed to sleep in?
From: TLS On Behalf Of Dennis Jackson
Sent: Wednesday, March 6, 2024 7:39 AM
To: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cert-abridge Update
[External email]
Hi Panos,
On 05/03/2024 04:14, Kampanakis, Panos wrote:
Hi
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
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
Hi Panos,
On 02/03/2024 04:09, Kampanakis, Panos wrote:
Hi Dennis,
I created a git issue
https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but I
am pasting it here for the sake of the discussion:
What does the client do if the server only does Pass 1 and compresses
/ omits
Hi Dennis,
I created a git issue
https://github.com/tlswg/draft-ietf-tls-cert-abridge/issues/23 but I am pasting
it here for the sake of the discussion:
What does the client do if the server only does Pass 1 and compresses / omits
the chain certs but does not compress the end-entity certs
