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]
