| Internet-Draft | CT Pages Extension | June 2025 |
| Pierre | Expires 30 December 2025 | [Page] |
This document specifies an extension to RFC 6962 Certificate Transparency (CT) logs that enables efficient caching and batch retrieval through page-based access patterns. The extension introduces a binary format that eliminates base64 encoding overhead and certificate chain duplication while maintaining full backward compatibility with existing RFC 6962 implementations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 December 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Certificate Transparency (CT) [RFC6962] 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.¶
The current RFC 6962 design presents several challenges:¶
This extension addresses these issues by introducing fixed-size pages with an efficient binary format, while maintaining full backward compatibility with existing CT infrastructure.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This extension introduces a page-based mechanism for retrieving log entries in fixed-size batches.¶
Clients request pages using the following HTTP GET request:¶
GET /ct-pages/v1/page/{page_number}
¶
Where:¶
Successful responses include the following HTTP headers:¶
Content-Type: application/octet-stream CT-Page-Size: 1000 CT-Entry-Range: 42000-42999 Cache-Control: public, max-age=31536000, immutable¶
For the last page (which may be partially filled):¶
CT-Entry-Range: 8765000-8765431 Cache-Control: no-store¶
Where:¶
The response body uses the following binary format, expressed using the TLS presentation language from [RFC8446]:¶
enum { v1(0), (255) } Version;
struct {
Version format_version;
uint64 entry_count;
uint64 first_entry_index;
PageEntry entries[entry_count];
} EntriesPage;
struct {
TimestampedEntry timestamped_entry;
uint16 chain_length;
opaque issuer_hashes[chain_length][32];
} PageEntry;
¶
Where:¶
To retrieve the actual certificate data for entries in the chain, clients make separate requests:¶
GET /ct-pages/v1/certificate/{base64url_sha256_hash}
¶
Where base64url_sha256_hash is the base64url encoding (without padding) of the SHA-256 hash of the certificate.¶
Successful responses return:¶
Content-Type: application/pkix-cert Cache-Control: public, max-age=31536000, immutable [binary certificate data]¶
This mechanism allows efficient deduplication of commonly used intermediate certificates across many log entries.¶
Logs implementing this extension MUST provide a discovery endpoint:¶
GET /ct-pages/v1/discover¶
The response is a JSON object:¶
Content-Type: application/json
{
"page_size": 1000,
"static_endpoint": "https://static.example.com"
}
¶
Where:¶
This extension maintains full backward compatibility with RFC 6962:¶
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.¶
Once a log begins serving pages with a particular page size, it MUST NOT change this size. Changing the page size would:¶
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.¶
Since pages become immutable once they are full (all entries except potentially the last page), logs can:¶
This extension does not alter the security properties of Certificate Transparency as defined in [RFC6962]. 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.¶
This document has no IANA actions.¶