Static Certificate Transparency
MerkleMap will not be supporting the static Certificate Transparency API. After careful evaluation, we believe it represents a step backward for the CT ecosystem.
The Cost Problem
Static CT implementations cost significantly more to operate than RFC 6962 systems. Our benchmarks show 90x higher bandwidth costs per monitor and 22x more storage operations. For log operators, this translates directly to higher infrastructure bills with no corresponding benefit.
The architecture marketed as "database-free" actually requires multiple databases in practice. Sunlight, the de-facto reference implementation, uses two SQLite databases for deduplication and checkpoints. Google's version requires Badger. The difference is these databases can't be used efficiently for serving data, forcing expensive direct file access instead.
Missing Functionality
The static CT API cannot perform basic operations that RFC 6962 handles trivially. Proof by hash-the most fundamental CT operation-is architecturally impossible. Range queries require clients to download multiple files and reconstruct data themselves. These aren't oversights; they're deliberate design choices that prioritize architectural purity over practical functionality.
Process Concerns
Rather than working through the IETF or other standards bodies, static CT is being promoted through Chrome's market position. This bypasses the review and consensus-building that made Certificate Transparency successful in the first place. Open standards shouldn't be dictated by browser market share.
Security Considerations
Even if we were to support static CT in the future, MerkleMap will not monitor any logs using the Sunlight implementation. We consider these logs untrustworthy due to multiple security failures:
Predictable Cryptographic Keys: Sunlight accepts any 32-byte input as a cryptographic seed, including 32 spaces or null bytes. A corrupted seed file (e.g., filesystem corruption to nulls) generates valid but predictable private keys. The service operates normally with no indication of compromise; a silent failure that could persist for years.
No Permission Checks: The software performs no security validation on critical files:
- Seed files can be world-readable (anyone can derive the private keys)
- Config files can be world-writable (anyone can modify operational parameters)
- No checks against running as root (operates with full system privileges)
User-Agent Authentication: Sunlight uses easily-spoofable User-Agent headers for client authentication and rate limiting. This is security theater, not actual authentication.
When we privately reported these issues, the Sunlight author forwarded our confidential security report to a public mailing list without consent, dismissing predictable key generation as "not a vulnerability." When we attempted to respond on that public forum, Google banned MerkleMap employees from the discussion, preventing us from defending our position or correcting mischaracterizations.
We then shared the same reports with Chrome's security team, who ignored all subsequent emails detailing additional attack vectors. Their position remains that accepting 32 null bytes as cryptographic seed material is acceptable for PKI infrastructure. This combination of public disclosure without consent, followed by silencing the reporter, represents a serious breach of responsible security disclosure practices.
Our Path Forward
MerkleMap continues to support RFC 6962, which provides complete CT functionality at reasonable cost. The protocol has proven itself in production for over a decade. Where improvements are needed, we support evolutionary changes that maintain compatibility and undergo proper standardization.
We are actively monitoring the CT ecosystem. Currently, very few logs support static CT. Should it become the leading standard with widespread adoption, we will reconsider our position-though any Sunlight-based logs will remain excluded from our monitoring due to security concerns. Until then, we remain focused on providing reliable, cost-effective Certificate Transparency services using proven technology.
For technical details, please contact our engineering team.