On Fri, Jul 7, 2023 at 1:21 PM Dennis Jackson <i...@dennis-jackson.uk> wrote:
> Thank you for the comments. I'll fix most of them - responses inline for > the rest: > > On 07/07/2023 17:38, Eric Rescorla wrote: > > S 3.1.2. > > 7. Order the list by the date each certificate was included in the > CCADB, breaking ties with the lexicographic ordering of the > SHA256 certificate fingerprint. > > Would it be simpler to just sort by the hash? > > Possibly a premature optimization, but I was thinking that if a new > version only included new certificates, it'd be nice to only have to append > the new data to the existing dictionaries. I haven't yet worked out if > that's actually going to deliver anything useful though. > Fair enough. > > 1. If so, replace the opaque cert_data member of > CertificateEntry with its adjusted three byte identifier and > copy the CertificateEntry structure with corrected lengths to > the output. > > It seems like this is not injective in the face of certificates > whose length is greater than or equal to 0xff0000. That's probably > not a problem, but I think you should make it clear and have some > way to manage it. > > If the length is corrected, isn't the only risk a collision with a > certificate which is exactly three bytes and starts with 0xff? > Ah yes, I had forgotten about the length value. This indeed seems fine. S 3.2.1 > How much value are you getting from the CT logs? It seems like > additional complexity. I agree with your comment about having > this submitted to CCADB. > > It seemed the fairest repeatable way to check whether a CA was offering > certificates to WebPKI clients without having to write a lot of emails. I > agree its not desirable to keep as a dependency in the long run. > Can you elaborate on the concern here? I.e., is it that we will overinclude or underinclude if we just use CCADB? Thanks, -Ekr S 5.1. > ISTM that there are plenty of code points available. > > Thanks! > > Best, > Dennis > > > > > > > > > On Thu, Jul 6, 2023 at 3:18 PM Dennis Jackson <ietf= > 40dennis-jackson...@dmarc.ietf.org> wrote: > >> 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 listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
