On Mon, Jul 10, 2023 at 10:54 AM Dennis Jackson <i...@dennis-jackson.uk> wrote:
> > On 07/07/2023 21:28, Eric Rescorla wrote: > > 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? > > Sorry, this answer came out garbled. Using CT gives two things: > > 1) There are large extensions in end-entity certs which are specific to > the issuer and change little between certs. For example, the URLs for OCSP, > CRL and the practice statement are typically the same. Using CT logs lets > me pull out an example of each extension for that CA without having to > write a bunch of mails to ask them to produce them in the right format. > > 2) I don't personally have concerns about the dictionary size and would > prefer to include every CA. However, if someone were to have strong > feelings about this then using CT to measure popularity is much fairer than > say scanning popular domains from the Tranco list or whatever. > > In the long term, I hope this could just be removed and ideally the CA's > themselves provide a fixed size binary blob via CCADB that they'd like > compressed out of their certs. > Thanks for the explanation. It sounds like we agree that it would be best not to have this piece and we just have different assessments of how hard it will be to get CCADB populated with this data. My sense is that we would be better off getting the data from CCADB, as CAs will have a clear incentive to populate it, as their customers will get better performance. However, I think this is a question the WG is well suited to resolve and that we could adopt the document as-is and sort this out later. -Ekr Best, > Dennis > > > 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
