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 <tls-boun...@ietf.org> *On Behalf Of * Dennis Jackson
*Sent:* Friday, March 1, 2024 8:03 AM
*To:* TLS List <tls@ietf.org>
*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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
