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.

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 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