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

Let's Encrypt recently cited cost as justification for abandoning RFC 6962, claiming annual costs "approaching seven figures." Their logs contain 14-20TB of data annually (7-10TB per six-month shard). At AWS RDS's published rate of $0.115 per GB-month, 20TB costs just $27,600 annually for storage. To reach "seven figures," they're claiming to pay over 35x the actual storage cost. Even with large compute instances and multiple replicas, database infrastructure for this workload shouldn't exceed $100,000-200,000 on AWS, and would cost under $20,000 on dedicated hardware. Even generously assuming $200,000 for database infrastructure on AWS, reaching "seven figures" requires $800,000 in additional costs - which at AWS rates would be egress fees for transferring their dataset hundreds of times. Yet they claim storage is "the biggest contributor" while never mentioning bandwidth. Either storage isn't the biggest cost (contradicting their article), or they aren't actually paying seven figures (contradicting their justification).

Anyone familiar with cloud pricing knows that egress and bandwidth charges - not storage - dominate costs for frequently-accessed data. Cloudflare's analysis shows AWS charges 8000x more than some providers. Yet their entire cost justification contains zero mentions of "egress" or "bandwidth". Let's Encrypt fails to disclose that AWS is a "Diamond sponsor" in this article while making these cost arguments, "Diamond sponsor" level is a minimum $500,000 donation. This creates a clear conflict of interest: they're advocating for an architecture that drives traffic to their sponsor's services (S3 and CloudFront) while comparing database costs on that same sponsor's platform ; costs which are completely artificial and known to be amongst the most expensive across the industry. If Let's Encrypt is paying AWS's notoriously high fees, the obvious solution would be migrating away from AWS, not redesigning the entire CT protocol. If AWS is subsidizing their infrastructure, then they're comparing theoretical costs they don't pay - making the entire cost comparison meaningless for organizations that must pay retail prices.

For perspective: MerkleMap operates a PostgreSQL database containing the full CT history since 2013 - over 18 billion certificates - without sharding and at nowhere near seven figures in infrastructure costs.

The availability claims

Let's Encrypt claims:

The second issue with RFC 6962 logs is the potential for problems and non-compliance when the period called a Maximum Merge Delay (“MMD”) is exceeded

This is implementation-dependent. Merklemap's own implementation has an MMD of 0 seconds, which Static CT, in its "golden deployment model," cannot achieve due to the decoupling of the read and the write path.

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.