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.

       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?

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.

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