Hi Pierre, This is pretty far afield from TLS. I would suggest the secdispatch mailing list.
Best, -Ekr On Sun, Jun 29, 2025 at 3:45 AM Pierre Barre <pie...@barre.sh> wrote: > Hi all, > > I've just submitted a new individual draft that extends RFC6962 > Certificate > Transparency with a page-based retrieval mechanism: > > https://datatracker.ietf.org/doc/html/draft-trans-pages-00 > > This proposal offers a simpler alternative to the "Static API" approach > while maintaining full RFC 6962 compatibility. Unlike the Static API which > requires significant client changes and complexity, this is just an > incremental extension that adds optional endpoints to existing CT logs. > > The draft addresses several operational challenges with the current > CT get-entries API: > > 1. Arbitrary range requests make caching effectively impossible > 2. Base64 encoding adds ~33% bandwidth overhead > 3. Certificate chains are duplicated for every entry > 4. Variable response sizes complicate resource planning > > The extension introduces: > - Fixed-size pages (e.g., 1000 entries) that are immutable once full > - Binary format eliminating base64 overhead > - Certificate deduplication via SHA-256 references > - Simple discovery mechanism > - Full backward compatibility - existing RFC 6962 clients continue to work > > Key advantages over Static API: > - Much simpler for clients to implement > - No breaking changes to existing CT infrastructure > - Allows incremental adoption > - Enables CDN deployment while keeping the familiar CT log model > > I'm particularly interested in feedback from: > - CT log operators on operational benefits > - Client implementers on the API design > - Anyone with Static API implementation experience for comparison > > I've implemented this in my CT log: https://github.com/Barre/compact_log > > > Performance comparison on a real log with 279,332 entries shows the Pages > Extension is more efficient than Static CT API: > > Pages Extension: > - 280 requests (vs 1,092 for Static CT) > - 212 MB transfer (vs 243 MB for Static CT) > - 756 bytes/entry (vs 869 bytes/entry) > - Sequential read test: 109 seconds (vs 143 seconds) > - Uses only 87.2% of Static CT bandwidth > > The binary format also compresses well with standard HTTP compression: > - Brotli: 56% size reduction > - Gzip: 58% size reduction > > Since the trans WG has concluded, I'm bringing this to TLS as the most > relevant venue for CT implementation discussions. > > Thanks, > Pierre > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
