Support

We're here to help you get the most out of Truestamp. Find answers to common questions or get in touch with our support team.

Community & Updates

Share feedback, follow what we're building next, and see what just shipped. Each opens right here in a popup, so no separate account is needed.

Knowledge Base

Browse the concepts behind Truestamp. Pick a domain to explore, follow the links between concepts, or search across everything.

RFC 6962: Certificate Transparency

IETF Experimental RFC defining Certificate Transparency: publicly auditable append-only Merkle Hash Tree logs of TLS certificates, with SHA-256 leaf/node domain separation, inclusion and consistency proofs, SCTs, and Signed Tree Heads.

Open resource

Overview

RFC 6962, “Certificate Transparency,” is an IETF Experimental standard published in June 2013 by Ben Laurie, Adam Langley, and Emilia Kasper of Google. It defines a framework of publicly auditable, append-only, untrusted logs that record all issued TLS certificates so that misissued or malicious certificates can be detected by domain owners, monitors, and auditors without trusting the certificate authorities or the logs themselves. Its core data structure is a SHA-256 Merkle Hash Tree whose construction, inclusion (audit) proofs, and consistency (append-only) proofs became a widely reused blueprint for verifiable logs. RFC 6962 has since been obsoleted by RFC 9162 (CT version 2.0).

Key points

  • Defines a SHA-256 Merkle Hash Tree with byte-prefix domain separation: leaf hashes are computed as SHA-256(0x00 || entry) and interior node hashes as SHA-256(0x01 || left || right), preventing second-preimage attacks between leaves and nodes. The tree shape is uniquely determined by the leaf count.
  • Specifies inclusion (audit) proofs, the shortest set of sibling node hashes needed to recompute the root from a given leaf, bounded by roughly ceil(log2(n)) nodes, plus consistency proofs that prove an older tree is a prefix of a newer one (the append-only guarantee).
  • Introduces the Signed Certificate Timestamp (SCT), a log’s signed promise to incorporate a certificate within a Maximum Merge Delay (MMD); TLS clients require an SCT to trust a connection.
  • Introduces the Signed Tree Head (STH): tree size, timestamp, SHA-256 root hash, and a signature published after each log update. Logs sign with NIST P-256 ECDSA or RSA (>=2048-bit, RSASSA-PKCS1-v1_5) over SHA-256.
  • Defines four client roles: submitters add certificates, TLS clients validate SCTs, monitors watch all entries for misissuance, and auditors verify consistency between STHs. Misbehavior is cryptographically and publicly detectable rather than requiring a trusted log.

Relevance to Truestamp

RFC 6962 is the direct basis for Truestamp’s Merkle tree implementation, including the same 0x00 leaf / 0x01 node prefix domain separation and the same inclusion-proof structure. See Truestamp’s RFC 6962 Merkle tree, inclusion proofs, and hashing domain separation concepts for how these constructs are adapted for verifiable timestamping and submission-window proofs.

Citations

  1. RFC 6962: Certificate Transparency. Ben Laurie, Adam Langley, Emilia Kasper (Google), IETF Experimental RFC, June 2013; obsoleted by RFC 9162.

Get Help

API Documentation

Comprehensive guides for the REST and GraphQL APIs, including interactive documentation and code examples.

View API Docs

FAQ

Quick answers to the most commonly asked questions about timestamping and verification.

Browse FAQ

Email Support

Send us a message and our team will respond within 24 hours.

[email protected]

Security Issues

Report security vulnerabilities through our responsible disclosure program.

[email protected]