With the exponential growth of global certificate issuance, the CT ecosystem is evolving toward a more efficient, lightweight static architecture. To foster a healthy transition of industry technical standards, TrustAsia has established the following roadmap:

Deprecation Plan for Legacy RFC 6962 Logs

In accordance with our technical operations roadmap, TrustAsia will cease launching new RFC 6962-compliant CT logs in 2028. Existing RFC 6962 log shards will continue to be stably maintained until the end of their designated lifecycles.

To address the high-concurrency performance bottlenecks of traditional RFC 6962 APIs during data synchronization and audit retrieval, we have deployed static-ct-api endpoints in parallel for our existing RFC 6962 logs. This significantly reduces network overhead and improves ingestion throughput. For technical details, please refer to the community discussion: https://groups.google.com/a/chromium.org/g/ct-policy/c/LNvmpQUsKF8

Traffic Management and Rate Limiting Policies

CT log services operate as high-concurrency global public infrastructure. To ensure the availability and stability of our log nodes and prevent service degradation caused by traffic spikes, we have implemented targeted tiered traffic scheduling and rate limiting policies:

1. Well-Aligned, High-Priority Requests (Per-IP Rate Limiting)

Client requests that adhere to efficient fetching best practices are granted dedicated per-IP rate limit quotas. Requests must meet the following criteria:

• Header Requirement: The request headers must explicitly include Accept-Encoding.
• RFC 6962 Batching and Alignment Requirement: The start and end parameters of the request must satisfy one of the following conditions:
  • (start % 32 == 0) && (end - start >= 31) && (end - start != 255)
  • (start % 256 == 0) && (end - start == 255)

2. Unaligned / General Requests (Shared Degraded Rate Limiting)

Requests that do not meet the above criteria will be subject not only to baseline per-IP rate limits, but also to a global Shared Rate Limit pool.

This shared rate limit is dynamically adjusted based on real-time cluster load and may experience stricter throttling during peak periods. We strongly recommend that all monitors and fetching clients follow the alignment and compression guidelines above to achieve optimal performance.

3. Policy Updates and Communication Channels

Any future adjustments to our rate limiting rules or thresholds will be announced promptly in the official Google Groups discussion forum:
https://groups.google.com/a/chromium.org/g/ct-policy

TrustAsia CT Log Operations Team