Hi Eric, Thank you, I'll post there too!
Best, Pierre On Sun, Jun 29, 2025, at 19:08, Eric Rescorla wrote: > 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 <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
