Re: [TLS] draft-ietf-tls-cert-abridge Update

[Dennis Jackson <[e-mail]>]

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 the chain certs but does not compress the end-entity certs 
> (Pass 2)?
>
> The client should be fine with that. It should be able to reconstruct 
> the chain and used the uncompressed end-entity cert. It should not 
> fail the handshake. I suggest the Implementation Complexity Section to 
> say something like
>
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.

Best,
Dennis

> /> Servers MAY chose to compress just the cert chain or the 
> end-certificate depending on their ability to perform Pass 1 or 2 
> respectively. Client MUST be able to process a compressed chain or an 
> end-entity certificate independently./
>
> Thanks,
>
> Panos
>
> *From:* TLS <[e-mail]> *On Behalf Of * Dennis Jackson
> *Sent:* Friday, March 1, 2024 8:03 AM
> *To:* TLS List <[e-mail]>
> *Subject:* [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 all,
>
> I wanted to give a quick update on the draft.
>
> On the implementation side, we have now landed support for TLS 
> Certificate Compression in Firefox Nightly which was a prerequisite 
> for experimenting with this scheme (thank you to Anna Weine). We're 
> working on a rust crate implementing the current draft and expect to 
> start experimenting with abridged certs in Firefox (with a server-side 
> partner) ahead of IETF 120.
>
> On the editorial side, I've addressed the comments on presentation and 
> clarification made since IETF 117 which are now in the editors copy - 
> there's an overall diff here [1] and atomic changes here [2] . There 
> are two small PRs I've opened addressing minor comments by Ben Schwarz 
> on fingerprinting considerations [3] and Jared Crawford on the 
> ordering of certificates [4]. Feedback is welcome via mail or on the 
> PRs directly.
>
> Best,
> Dennis
>
> [1] 
> https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt 
> <https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-cert-abridge&url_2=https://tlswg.github.io/draft-ietf-tls-cert-abridge/draft-ietf-tls-cert-abridge.txt>
>
> [2] https://github.com/tlswg/draft-ietf-tls-cert-abridge/commits/main/
>
> [3] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/21/files
>
> [4] https://github.com/tlswg/draft-ietf-tls-cert-abridge/pull/19/files
>