Hi Dennis,

I enjoyed reading this draft. I think it is well-written. Aside from some
to-be-figured-out details that have already been pointed out, it seems very
practical, which is rather nice.

The one thing that makes me frown a bit is the intended versioning scheme.
I don't think consuming identifiers is a problem, but perhaps we can
pre-define the code points and variables for the next, say, N=0xff years?
Then the versioning mechanism is set for the foreseeable future. (You could
even say that we wrap the code points after N years).

Cheers,

Thom

Op vr 7 jul 2023 om 00:18 schreef Dennis Jackson <ietf=
40dennis-jackson...@dmarc.ietf.org>:

> Hi all,
>
> I've submitted the draft below that describes a new TLS certificate
> compression scheme that I'm calling 'Abridged Certs' for now. The aim is
> to deliver excellent compression for existing classical certificate
> chains and smooth the transition to PQ certificate chains by eliminating
> the root and intermediate certificates from the bytes on the wire. It
> uses a shared dictionary constructed from the CA certificates listed in
> the CCADB [1] and the associated extensions used in end entity
> certificates.
>
> Abridged Certs compresses the median certificate chain from ~4000 to
> ~1000 bytes based on a sample from the Tranco Top 100k. This beats
> traditional TLS certificate compression which produces a median of ~3200
> bytes when used alone and ~1400 bytes when combined with the outright
> removal of CA certificates from the certificate chain. The draft
> includes a more detailed evaluation.
>
> There were a few other key considerations. This draft doesn't impact
> trust decisions, require trust in the certificates in the shared
> dictionary or involve extra error handling. Nor does the draft favor
> popular CAs or websites due to the construction of the shared
> dictionary. Finally, most browsers already ship with a complete list of
> trusted intermediate and root certificates that this draft reuses to
> reduce the client storage footprint to a few kilobytes.
>
> I would love to get feedback from the working group on whether the draft
> is worth developing further.
>
> For those interested, a few issues are tagged DISCUSS in the body of the
> draft, including arrangements for deploying new versions with updated
> dictionaries and the tradeoff between equitable CA treatment and the
> disk space required on servers (currently 3MB).
>
> Best,
> Dennis
>
> [1] Mozilla operates the Common CA Database on behalf of Apple,
> Microsoft, Google and other members.
>
> On 06/07/2023 23:11, internet-dra...@ietf.org wrote:
> > A new version of I-D, draft-jackson-tls-cert-abridge-00.txt
> > has been successfully submitted by Dennis Jackson and posted to the
> > IETF repository.
> >
> > Name:         draft-jackson-tls-cert-abridge
> > Revision:     00
> > Title:                Abridged Compression for WebPKI Certificates
> > Document date:        2023-07-06
> > Group:                Individual Submission
> > Pages:                19
> > URL:
> https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
> > Html:
> https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge
> >
> >
> > Abstract:
> >     This draft defines a new TLS Certificate Compression scheme which
> >     uses a shared dictionary of root and intermediate WebPKI
> >     certificates.  The scheme smooths the transition to post-quantum
> >     certificates by eliminating the root and intermediate certificates
> >     from the TLS certificate chain without impacting trust negotiation.
> >     It also delivers better compression than alternative proposals whilst
> >     ensuring fair treatment for both CAs and website operators.  It may
> >     also be useful in other applications which store certificate chains,
> >     e.g.  Certificate Transparency logs.
> >
> >
>
> >
> >
> > The IETF Secretariat
> >
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to