Certificate Transparency Pages Extension

Introduction Certificate Transparency (CT) provides a framework for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed. The current specification defines a "get-entries" endpoint that accepts arbitrary start and end parameters for retrieving log entries.

Motivation The current RFC 6962 design presents several challenges:

Arbitrary range requests make caching difficult or impossible, as responses for overlapping ranges cannot be efficiently cached or reused.
Base64 encoding of certificates adds approximately 33% overhead to response sizes.
Certificate chains are duplicated in full for each entry, even when many entries share the same intermediate certificates.
Variable response sizes complicate client implementation and server resource planning.

This extension addresses these issues by introducing fixed-size pages with an efficient binary format, while maintaining full backward compatibility with existing CT infrastructure.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Page-Based Entry Retrieval This extension introduces a page-based mechanism for retrieving log entries in fixed-size batches.

Request Format Clients request pages using the following HTTP GET request: Where:

page_number: A non-negative integer representing the zero-indexed page number.

Response Format

HTTP Headers Successful responses include the following HTTP headers: For the last page (which may be partially filled): Where:

CT-Page-Size: The fixed number of entries per page for this log.
CT-Entry-Range: The inclusive range of log entry indices contained in this page.
Cache-Control: Full pages are immutable and can be cached indefinitely. The last page must not be cached as it may grow.

Binary Response Structure The response body uses the following binary format, expressed using the TLS presentation language from : Where:

format_version: Set to v1(0) for this specification.
entry_count: The number of entries in this page.
first_entry_index: The log index of the first entry in this page.
timestamped_entry: The TimestampedEntry structure as defined in Section 3.4 of .
chain_length: The number of certificates in the chain (excluding the leaf certificate, which is included in timestamped_entry).
issuer_hashes: SHA-256 hashes of the DER-encoded issuer certificates in the chain, ordered from the leaf's issuer to the root.

Certificate Resolution To retrieve the actual certificate data for entries in the chain, clients make separate requests: Where base64url_sha256_hash is the base64url encoding (without padding) of the SHA-256 hash of the certificate. Successful responses return: This mechanism allows efficient deduplication of commonly used intermediate certificates across many log entries.

Discovery Mechanism Logs implementing this extension MUST provide a discovery endpoint: The response is a JSON object: Where:

page_size: The fixed number of entries per complete page.
static_endpoint: (OPTIONAL) An alternative base URL for fetching pages and certificates. If provided, clients MUST use this endpoint for all page and certificate requests.

Backward Compatibility This extension maintains full backward compatibility with RFC 6962:

All original RFC 6962 endpoints remain unchanged and continue to function.
The extension introduces new endpoints under the "/ct-pages/v1/" path prefix.
Clients unaware of this extension continue to work with the original endpoints.
Logs can implement this extension without breaking existing clients.

Unless a separate static_endpoint is specified in the discovery response, the pages endpoints MUST be served on the same host as the main log endpoints.

Operational Considerations

Page Size Stability Once a log begins serving pages with a particular page size, it MUST NOT change this size. Changing the page size would:

Invalidate all cached responses
Break client assumptions about page boundaries
Complicate client implementation significantly

Logs SHOULD choose a page size that balances response size with the number of requests needed to retrieve large ranges of entries. A page size of 1000 entries is RECOMMENDED as a reasonable default.

Static Deployment Since pages become immutable once they are full (all entries except potentially the last page), logs can:

Pre-generate page files for all complete pages
Serve pages from static file hosting or CDN infrastructure
Significantly reduce computational load on log servers
Improve response times and reliability

Security Considerations This extension does not alter the security properties of Certificate Transparency as defined in . The cryptographic proofs and append-only properties of the log remain unchanged. Clients MUST verify that certificate hashes match the actual certificates retrieved. This ensures that a compromised CDN or static hosting provider cannot substitute different certificates. The use of SHA-256 for certificate identification is consistent with its use in RFC 6962 for Merkle tree operations.

IANA Considerations This document has no IANA actions.