draft-ietf-trans-rfc6962-bis-21.txt   draft-ietf-trans-rfc6962-bis-22.txt 
TRANS (Public Notary Transparency) B. Laurie TRANS (Public Notary Transparency) B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Intended status: Standards Track E. Kasper Obsoletes: 6962 (if approved) E. Kasper
Expires: May 28, 2017 E. Messeri Intended status: Standards Track E. Messeri
Google Expires: June 17, 2017 Google
R. Stradling R. Stradling
Comodo Comodo
November 24, 2016 December 14, 2016
Certificate Transparency Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-21 draft-ietf-trans-rfc6962-bis-22
Abstract Abstract
This document describes a protocol for publicly logging the existence This document describes version 2.0 of the Certificate Transparency
of Transport Layer Security (TLS) server certificates as they are (CT) protocol for publicly logging the existence of Transport Layer
issued or observed, in a manner that allows anyone to audit Security (TLS) server certificates as they are issued or observed, in
certification authority (CA) activity and notice the issuance of a manner that allows anyone to audit certification authority (CA)
suspect certificates as well as to audit the certificate logs activity and notice the issuance of suspect certificates as well as
themselves. The intent is that eventually clients would refuse to to audit the certificate logs themselves. The intent is that
honor certificates that do not appear in a log, effectively forcing eventually clients would refuse to honor certificates that do not
CAs to add all issued certificates to the logs. appear in a log, effectively forcing CAs to add all issued
certificates to the logs.
Logs are network services that implement the protocol operations for Logs are network services that implement the protocol operations for
submissions and queries that are defined in this document. submissions and queries that are defined in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 28, 2017. This Internet-Draft will expire on June 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 5 1.3. Major Differences from CT 1.0 . . . . . . . . . . . . . . 5
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 5 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 7
2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 6 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 7 2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 8
2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 9
2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 10 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 10
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 11
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 10 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 10 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 12
4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 11 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 12
4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 11 4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 13
4.2. Using a Name-Constrained Intermediate CA . . . . . . . . 11 4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 13
5. Log Format and Operation . . . . . . . . . . . . . . . . . . 12 4.2. Using a Name-Constrained Intermediate CA . . . . . . . . 13
5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 13 5. Log Format and Operation . . . . . . . . . . . . . . . . . . 14
5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 15
5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 15 5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 16 5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 17
5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 17 5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 18
5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 18 5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 19
5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 19 5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 20
5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 20 5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 21
5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 20 5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 22
5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 21 5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 22
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 21 5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 23
6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 23 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23
6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 24 6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 25
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 24 6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 26
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 26
6.4. Retrieve Merkle Consistency Proof between Two Signed Tree 6.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 25 6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 27
6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and 6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 26 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 28
6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 28 6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 30
6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 29 6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 31
7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 32
7.2. TransItemList Structure . . . . . . . . . . . . . . . . . 31 7.2. TransItemList Structure . . . . . . . . . . . . . . . . . 33
7.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 31 7.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 33
7.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 32 7.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 34
7.5. transparency_info TLS Extension . . . . . . . . . . . . . 32 7.5. transparency_info TLS Extension . . . . . . . . . . . . . 34
7.6. cached_info TLS Extension . . . . . . . . . . . . . . . . 32 7.6. cached_info TLS Extension . . . . . . . . . . . . . . . . 34
8. Certification Authorities . . . . . . . . . . . . . . . . . . 32 8. Certification Authorities . . . . . . . . . . . . . . . . . . 34
8.1. Transparency Information X.509v3 Extension . . . . . . . 33 8.1. Transparency Information X.509v3 Extension . . . . . . . 35
8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 33 8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 35
8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 33 8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 35
8.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 33 8.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 35
9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 35 9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 37
9.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 35 9.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 37
9.2.2. Reconstructing the TBSCertificate . . . . . . . . . . 35 9.2.2. Reconstructing the TBSCertificate . . . . . . . . . . 37
9.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 35 9.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 37
9.2.4. Validating inclusion proofs . . . . . . . . . . . . . 36 9.2.4. Validating inclusion proofs . . . . . . . . . . . . . 38
9.2.5. Evaluating compliance . . . . . . . . . . . . . . . . 36 9.2.5. Evaluating compliance . . . . . . . . . . . . . . . . 38
9.2.6. TLS Feature Extension . . . . . . . . . . . . . . . . 36 9.2.6. TLS Feature Extension . . . . . . . . . . . . . . . . 38
9.2.7. cached_info TLS Extension . . . . . . . . . . . . . . 36 9.2.7. cached_info TLS Extension . . . . . . . . . . . . . . 38
9.2.8. Handling of Non-compliance . . . . . . . . . . . . . 37 9.2.8. Handling of Non-compliance . . . . . . . . . . . . . 39
9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 38 9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 40
9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 39 9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 41
9.4.2. Verifying consistency between two STHs . . . . . . . 40 9.4.2. Verifying consistency between two STHs . . . . . . . 42
9.4.3. Verifying root hash given entries . . . . . . . . . . 40 9.4.3. Verifying root hash given entries . . . . . . . . . . 42
10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 41 10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 42 11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 44
11.2. New Entry to the TLS CachedInformationType registry . . 42 11.2. New Entry to the TLS CachedInformationType registry . . 44
11.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 42 11.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44
11.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 42 11.3.1. Expert Review guidelines . . . . . . . . . . . . . . 44
11.5. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 43 11.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 45
11.6. STH Extensions . . . . . . . . . . . . . . . . . . . . . 43 11.4.1. Expert Review guidelines . . . . . . . . . . . . . . 45
11.7. Object Identifiers . . . . . . . . . . . . . . . . . . . 43 11.5. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45
11.7.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 43 11.5.1. Expert Review guidelines . . . . . . . . . . . . . . 46
11.7.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 44 11.6. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 47
12. Security Considerations . . . . . . . . . . . . . . . . . . . 44 11.6.1. Expert Review guidelines . . . . . . . . . . . . . . 47
12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 44
12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 45 11.7. STH Extensions . . . . . . . . . . . . . . . . . . . . . 47
12.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 45 11.7.1. Expert Review guidelines . . . . . . . . . . . . . . 47
12.4. Deterministic Signatures . . . . . . . . . . . . . . . . 45 11.8. Object Identifiers . . . . . . . . . . . . . . . . . . . 48
12.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 46 11.8.1. Log ID Registry . . . . . . . . . . . . . . . . . . 48
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 11.8.2. Expert Review guidelines . . . . . . . . . . . . . . 48
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 12. Security Considerations . . . . . . . . . . . . . . . . . . . 49
14.1. Normative References . . . . . . . . . . . . . . . . . . 46 12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49
14.2. Informative References . . . . . . . . . . . . . . . . . 48 12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 49 12.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 12.4. Deterministic Signatures . . . . . . . . . . . . . . . . 50
12.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
14.1. Normative References . . . . . . . . . . . . . . . . . . 51
14.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Certificate transparency aims to mitigate the problem of misissued Certificate transparency aims to mitigate the problem of misissued
certificates by providing append-only logs of issued certificates. certificates by providing append-only logs of issued certificates.
The logs do not need to be trusted because they are publicly The logs do not need to be trusted because they are publicly
auditable. Anyone may verify the correctness of each log and monitor auditable. Anyone may verify the correctness of each log and monitor
when new certificates are added to it. The logs do not themselves when new certificates are added to it. The logs do not themselves
prevent misissue, but they ensure that interested parties prevent misissue, but they ensure that interested parties
(particularly those named in certificates) can detect such (particularly those named in certificates) can detect such
skipping to change at page 5, line 39 skipping to change at page 5, line 48
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Data Structures 1.2. Data Structures
Data structures are defined according to the conventions laid out in Data structures are defined according to the conventions laid out in
Section 4 of [RFC5246]. Section 4 of [RFC5246].
1.3. Major Differences from CT 1.0
This document revises and obsoletes the experimental CT 1.0 [RFC6962]
protocol, drawing on insights gained from CT 1.0 deployments and on
feedback from the community. The major changes are:
o Hash and signature algorithm agility: permitted algorithms are now
specified in IANA registries.
o Precertificate format: precertificates are now CMS objects rather
than X.509 certificates, which avoids violating the certificate
serial number uniqueness requirement in Section 4.1.2.2 of
[RFC5280].
o Removed precertificate signing certificates and the precertificate
poison extension: the change of precertificate format means that
these are no longer needed.
o Private domain name labels: added a mechanism for logging a name-
constrained intermediate in place of end-entity certificates
issued by that CA.
o Logs IDs: each log is now identified by an OID rather than by the
hash of its public key. OID allocations are managed by an IANA
registry.
o "TransItem" structure: this new data structure is used to
encapsulate most types of CT data. A "TransItemList", consisting
of one or more "TransItem" structures, can be used anywhere that
"SignedCertificateTimestampList" was used in [RFC6962].
o Merkle tree leaves: the "MerkleTreeLeaf" structure has been
replaced by the "TransItem" structure, which eases extensibility
and simplifies the leaf structure by removing one layer of
abstraction.
o Unified leaf format: the structure for both certificate and
precertificate entries now includes only the TBSCertificate
(whereas certificate entries in [RFC6962] included the entire
certificate).
o SCT extensions: these are now typed and managed by an IANA
registry.
o STH extensions: STHs can now contain extensions, which are typed
and managed by an IANA registry.
o API outputs: complete "TransItem" structures are returned, rather
than the constituent parts of each structure.
o get-all-by-hash: new client API for obtaining an inclusion proof
and the corresponding consistency proof at the same time.
o Presenting SCTs with proofs: TLS servers may present SCTs together
with the corresponding inclusion proofs using any of the
mechanisms that [RFC6962] defined for presenting SCTs only.
(Presenting SCTs only is still supported).
o CT TLS extension: the "signed_certificate_timestamp" TLS extension
has been replaced by the "transparency_info" TLS extension.
o Other TLS extensions: "status_request_v2" may be used (in the same
manner as "status_request"); "cached_info" may be used to avoid
sending the same complete SCTs and inclusion proofs to the same
TLS clients multiple times.
o TLS Feature extension: this certificate extension may be used by a
CA to indicate that CT compliance is required.
o Verification algorithms: added detailed algorithms for verifying
inclusion proofs, for verifying consistency between two STHs, and
for verifying a root hash given a complete list of the relevant
leaf input entries.
o Extensive clarifications and editorial work.
2. Cryptographic Components 2. Cryptographic Components
2.1. Merkle Hash Trees 2.1. Merkle Hash Trees
Logs use a binary Merkle Hash Tree for efficient auditing. The Logs use a binary Merkle Hash Tree for efficient auditing. The
hashing algorithm used by each log is expected to be specified as hashing algorithm used by each log is expected to be specified as
part of the metadata relating to that log (see Section 9.1). We have part of the metadata relating to that log (see Section 9.1). We have
established a registry of acceptable algorithms, see Section 11.3. established a registry of acceptable algorithms, see Section 11.3.
The hashing algorithm in use is referred to as HASH throughout this The hashing algorithm in use is referred to as HASH throughout this
document and the size of its output in bytes as HASH_SIZE. The input document and the size of its output in bytes as HASH_SIZE. The input
skipping to change at page 7, line 10 skipping to change at page 8, line 46
Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., Given an ordered list of n inputs to the tree, D[n] = {d(0), ...,
d(n-1)}, the Merkle inclusion proof PATH(m, D[n]) for the (m+1)th d(n-1)}, the Merkle inclusion proof PATH(m, D[n]) for the (m+1)th
input d(m), 0 <= m < n, is defined as follows: input d(m), 0 <= m < n, is defined as follows:
The proof for the single leaf in a tree with a one-element input list The proof for the single leaf in a tree with a one-element input list
D[1] = {d(0)} is empty: D[1] = {d(0)} is empty:
PATH(0, {d(0)}) = {} PATH(0, {d(0)}) = {}
For n > 1, let k be the largest power of two smaller than n. The For n > 1, let k be the largest power of two smaller than n. The
proof for the (m+1)th element d(m) in a list of n > m elements is proof for the (m+1)th element d(m) in a list of n > m elements is
then defined recursively as then defined recursively as
PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and
PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k, PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k,
where : is concatenation of lists and D[k1:k2] denotes the length (k2 where : is concatenation of lists and D[k1:k2] denotes the length (k2
- k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before.
2.1.2. Merkle Consistency Proofs 2.1.2. Merkle Consistency Proofs
Merkle consistency proofs prove the append-only property of the tree. Merkle consistency proofs prove the append-only property of the tree.
A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a
previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n, previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n,
is the list of nodes in the Merkle Tree required to verify that the is the list of nodes in the Merkle Tree required to verify that the
first m inputs D[0:m] are equal in both trees. Thus, a consistency first m inputs D[0:m] are equal in both trees. Thus, a consistency
skipping to change at page 8, line 4 skipping to change at page 9, line 38
MTH(D[0:m]) is known. The initial call to SUBPROOF sets this to be MTH(D[0:m]) is known. The initial call to SUBPROOF sets this to be
true, and SUBPROOF is then defined as follows: true, and SUBPROOF is then defined as follows:
The subproof for m = n is empty if m is the value for which PROOF was The subproof for m = n is empty if m is the value for which PROOF was
originally requested (meaning that the subtree created from D[0:m] is originally requested (meaning that the subtree created from D[0:m] is
a complete subtree of the Merkle Tree created from the original D[n] a complete subtree of the Merkle Tree created from the original D[n]
for which PROOF was requested, and the subtree Merkle Tree Hash for which PROOF was requested, and the subtree Merkle Tree Hash
MTH(D[0:m]) is known): MTH(D[0:m]) is known):
SUBPROOF(m, D[m], true) = {} SUBPROOF(m, D[m], true) = {}
Otherwise, the subproof for m = n is the Merkle Tree Hash committing Otherwise, the subproof for m = n is the Merkle Tree Hash committing
inputs D[0:m]: inputs D[0:m]:
SUBPROOF(m, D[m], false) = {MTH(D[m])} SUBPROOF(m, D[m], false) = {MTH(D[m])}
For m < n, let k be the largest power of two smaller than n. The For m < n, let k be the largest power of two smaller than n. The
subproof is then defined recursively. subproof is then defined recursively.
If m <= k, the right subtree entries D[k:n] only exist in the current If m <= k, the right subtree entries D[k:n] only exist in the current
tree. We prove that the left subtree entries D[0:k] are consistent tree. We prove that the left subtree entries D[0:k] are consistent
and add a commitment to D[k:n]: and add a commitment to D[k:n]:
SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n]) SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])
If m > k, the left subtree entries D[0:k] are identical in both If m > k, the left subtree entries D[0:k] are identical in both
trees. We prove that the right subtree entries D[k:n] are consistent trees. We prove that the right subtree entries D[k:n] are consistent
and add a commitment to D[0:k]. and add a commitment to D[0:k].
SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k]) SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k])
Here, : is a concatenation of lists, and D[k1:k2] denotes the length Here, : is a concatenation of lists, and D[k1:k2] denotes the length
(k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before.
The number of nodes in the resulting proof is bounded above by The number of nodes in the resulting proof is bounded above by
skipping to change at page 12, line 46 skipping to change at page 14, line 36
} }
} }
} }
} }
5. Log Format and Operation 5. Log Format and Operation
A log is a single, append-only Merkle Tree of submitted certificate A log is a single, append-only Merkle Tree of submitted certificate
and precertificate entries. and precertificate entries.
When it receives a valid submission, the log MUST return an SCT that When it receives and accepts a valid submission, the log MUST return
corresponds to the submitted certificate or precertificate. If the an SCT that corresponds to the submitted certificate or
log has previously seen this valid submission, it SHOULD return the precertificate. If the log has previously seen this valid
same SCT as it returned before (to reduce the ability to track submission, it SHOULD return the same SCT as it returned before (to
clients as described in Section 12.4). If different SCTs are reduce the ability to track clients as described in Section 12.4).
produced for the same submission, multiple log entries will have to If different SCTs are produced for the same submission, multiple log
be created, one for each SCT (as the timestamp is a part of the leaf entries will have to be created, one for each SCT (as the timestamp
structure). Note that if a certificate was previously logged as a is a part of the leaf structure). Note that if a certificate was
precertificate, then the precertificate's SCT of type previously logged as a precertificate, then the precertificate's SCT
"precert_sct_v2" would not be appropriate; instead, a fresh SCT of of type "precert_sct_v2" would not be appropriate; instead, a fresh
type "x509_sct_v2" should be generated. SCT of type "x509_sct_v2" should be generated.
An SCT is the log's promise to incorporate the submitted entry in its An SCT is the log's promise to incorporate the submitted entry in its
Merkle Tree no later than a fixed amount of time, known as the Merkle Tree no later than a fixed amount of time, known as the
Maximum Merge Delay (MMD), after the issuance of the SCT. Maximum Merge Delay (MMD), after the issuance of the SCT.
Periodically, the log MUST append all its new entries to its Merkle Periodically, the log MUST append all its new entries to its Merkle
Tree and sign the root of the tree. Tree and sign the root of the tree.
Log operators MUST NOT impose any conditions on retrieving or sharing Log operators MUST NOT impose any conditions on retrieving or sharing
data from the log. data from the log.
5.1. Accepting Submissions 5.1. Accepting Submissions
Logs MUST verify that each submitted certificate or precertificate Before accepting a submitted certificate or precertificate, the log
has a valid signature chain to an accepted trust anchor, using the MUST verify that it has a valid signature chain to an accepted trust
chain of intermediate CA certificates provided by the submitter. anchor, using the chain of intermediate CA certificates provided by
Logs SHOULD accept certificates and precertificates that are fully the submitter. Logs SHOULD accept certificates and precertificates
valid according to RFC 5280 [RFC5280] verification rules and are that are fully valid according to RFC 5280 [RFC5280] verification
submitted with such a chain (A log may decide, for example, to rules and are submitted with such a chain (A log may decide, for
temporarily reject valid submissions to protect itself against example, to temporarily reject valid submissions to protect itself
denial-of-service attacks). against denial-of-service attacks).
Logs MAY accept certificates and precertificates that have expired, Logs MAY accept certificates and precertificates that have expired,
are not yet valid, have been revoked, or are otherwise not fully are not yet valid, have been revoked, or are otherwise not fully
valid according to RFC 5280 verification rules in order to valid according to RFC 5280 verification rules in order to
accommodate quirks of CA certificate-issuing software. However, logs accommodate quirks of CA certificate-issuing software. However, logs
MUST reject submissions without a valid signature chain to an MUST reject submissions without a valid signature chain to an
accepted trust anchor. Logs MUST also reject precertificates that do accepted trust anchor. Logs MUST also reject precertificates that do
not conform to the requirements in Section 3.2. not conform to the requirements in Section 3.2.
Logs SHOULD limit the length of chain they will accept. The maximum Logs SHOULD limit the length of chain they will accept. The maximum
skipping to change at page 14, line 50 skipping to change at page 16, line 43
certificates required to verify "pre_certificate". The first certificates required to verify "pre_certificate". The first
certificate MUST certify "pre_certificate". Each following certificate MUST certify "pre_certificate". Each following
certificate MUST directly certify the one preceding it. The final certificate MUST directly certify the one preceding it. The final
certificate MUST be a trust anchor accepted by the log. certificate MUST be a trust anchor accepted by the log.
5.3. Log ID 5.3. Log ID
Each log is identified by an OID, which is specified in the log's Each log is identified by an OID, which is specified in the log's
metadata and which MUST NOT be used to identify any other log. A metadata and which MUST NOT be used to identify any other log. A
log's operator MUST either allocate the OID themselves or request an log's operator MUST either allocate the OID themselves or request an
OID from one of the two Log ID Registries (see Section 11.7.1 and OID from the Log ID Registry (see Section 11.8.1. Various data
Section 11.7.2). Various data structures include the DER encoding of structures include the DER encoding of this OID, excluding the ASN.1
this OID, excluding the ASN.1 tag and length bytes, in an opaque tag and length bytes, in an opaque vector:
vector:
opaque LogID<2..127>; opaque LogID<2..127>;
Note that the ASN.1 length and the opaque vector length are identical Note that the ASN.1 length and the opaque vector length are identical
in size (1 byte) and value, so the DER encoding of the OID can be in size (1 byte) and value, so the DER encoding of the OID can be
reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to
the opaque vector length and contents. the opaque vector length and contents.
OIDs used to identify logs are limited such that the DER encoding of OIDs used to identify logs are limited such that the DER encoding of
their value is less than or equal to 127 octets. their value is less than or equal to 127 octets.
skipping to change at page 15, line 48 skipping to change at page 17, line 39
case x509_sct_v2: SignedCertificateTimestampDataV2; case x509_sct_v2: SignedCertificateTimestampDataV2;
case precert_sct_v2: SignedCertificateTimestampDataV2; case precert_sct_v2: SignedCertificateTimestampDataV2;
case signed_tree_head_v2: SignedTreeHeadDataV2; case signed_tree_head_v2: SignedTreeHeadDataV2;
case consistency_proof_v2: ConsistencyProofDataV2; case consistency_proof_v2: ConsistencyProofDataV2;
case inclusion_proof_v2: InclusionProofDataV2; case inclusion_proof_v2: InclusionProofDataV2;
case x509_sct_with_proof_v2: SCTWithProofDataV2; case x509_sct_with_proof_v2: SCTWithProofDataV2;
case precert_sct_with_proof_v2: SCTWithProofDataV2; case precert_sct_with_proof_v2: SCTWithProofDataV2;
} data; } data;
} TransItem; } TransItem;
"versioned_type" is the type of the encapsulated data structure and "versioned_type" is a value from the IANA registry in Section 11.5
the earliest version of this protocol to which it conforms. This that identifies the type of the encapsulated data structure and the
earliest version of this protocol to which it conforms. This
document is v2. document is v2.
"data" is the encapsulated data structure. The various structures "data" is the encapsulated data structure. The various structures
named with the "DataV2" suffix are defined in later sections of this named with the "DataV2" suffix are defined in later sections of this
document. document.
Note that "VersionedTransType" combines the v1 [RFC6962] type Note that "VersionedTransType" combines the v1 [RFC6962] type
enumerations "Version", "LogEntryType", "SignatureType" and enumerations "Version", "LogEntryType", "SignatureType" and
"MerkleLeafType". Note also that v1 did not define "TransItem", but "MerkleLeafType". Note also that v1 did not define "TransItem", but
this document provides guidelines (see Appendix A) on how v2 this document provides guidelines (see Appendix A) on how v2
skipping to change at page 17, line 45 skipping to change at page 19, line 37
} SignedCertificateTimestampDataV2; } SignedCertificateTimestampDataV2;
"log_id" is this log's unique ID, encoded in an opaque vector as "log_id" is this log's unique ID, encoded in an opaque vector as
described in Section 5.3. described in Section 5.3.
"timestamp" is equal to the timestamp from the "timestamp" is equal to the timestamp from the
"TimestampedCertificateEntryDataV2" structure encapsulated in the "TimestampedCertificateEntryDataV2" structure encapsulated in the
"timestamped_entry". "timestamped_entry".
"sct_extension_type" identifies a single extension from the IANA "sct_extension_type" identifies a single extension from the IANA
registry in Section 11.5. At the time of writing, no extensions are registry in Section 11.6. At the time of writing, no extensions are
specified. specified.
The interpretation of the "sct_extension_data" field is determined The interpretation of the "sct_extension_data" field is determined
solely by the value of the "sct_extension_type" field. Each document solely by the value of the "sct_extension_type" field. Each document
that registers a new "sct_extension_type" must describe how to that registers a new "sct_extension_type" must describe how to
interpret the corresponding "sct_extension_data". interpret the corresponding "sct_extension_data".
"sct_extensions" is a vector of 0 or more SCT extensions. This "sct_extensions" is a vector of 0 or more SCT extensions. This
vector MUST NOT include more than one extension with the same vector MUST NOT include more than one extension with the same
"sct_extension_type". The extensions in the vector MUST be ordered "sct_extension_type". The extensions in the vector MUST be ordered
skipping to change at page 18, line 44 skipping to change at page 20, line 36
struct { struct {
uint64 timestamp; uint64 timestamp;
uint64 tree_size; uint64 tree_size;
NodeHash root_hash; NodeHash root_hash;
SthExtension sth_extensions<0..2^16-1>; SthExtension sth_extensions<0..2^16-1>;
} TreeHeadDataV2; } TreeHeadDataV2;
The length of NodeHash MUST match HASH_SIZE of the log. The length of NodeHash MUST match HASH_SIZE of the log.
"sth_extension_type" identifies a single extension from the IANA "sth_extension_type" identifies a single extension from the IANA
registry in Section 11.6. At the time of writing, no extensions are registry in Section 11.7. At the time of writing, no extensions are
specified. specified.
The interpretation of the "sth_extension_data" field is determined The interpretation of the "sth_extension_data" field is determined
solely by the value of the "sth_extension_type" field. Each document solely by the value of the "sth_extension_type" field. Each document
that registers a new "sth_extension_type" must describe how to that registers a new "sth_extension_type" must describe how to
interpret the corresponding "sth_extension_data". interpret the corresponding "sth_extension_data".
"timestamp" is the current NTP Time [RFC5905], measured in "timestamp" is the current NTP Time [RFC5905], measured in
milliseconds since the epoch (January 1, 1970, 00:00 UTC), ignoring milliseconds since the epoch (January 1, 1970, 00:00 UTC), ignoring
leap seconds. leap seconds.
skipping to change at page 21, line 42 skipping to change at page 23, line 36
o Keep the log running until the certificates in all of its entries o Keep the log running until the certificates in all of its entries
have expired or exist in other logs (this can be determined by have expired or exist in other logs (this can be determined by
scanning other logs or connecting to domains mentioned in the scanning other logs or connecting to domains mentioned in the
certificates and inspecting the SCTs served). certificates and inspecting the SCTs served).
6. Log Client Messages 6. Log Client Messages
Messages are sent as HTTPS GET or POST requests. Parameters for Messages are sent as HTTPS GET or POST requests. Parameters for
POSTs and all responses are encoded as JavaScript Object Notation POSTs and all responses are encoded as JavaScript Object Notation
(JSON) objects [RFC4627]. Parameters for GETs are encoded as order- (JSON) objects [RFC7159]. Parameters for GETs are encoded as order-
independent key/value URL parameters, using the "application/x-www- independent key/value URL parameters, using the "application/x-www-
form-urlencoded" format described in the "HTML 4.01 Specification" form-urlencoded" format described in the "HTML 4.01 Specification"
[HTML401]. Binary data is base64 encoded [RFC4648] as specified in [HTML401]. Binary data is base64 encoded [RFC4648] as specified in
the individual messages. the individual messages.
Note that JSON objects and URL parameters may contain fields not Note that JSON objects and URL parameters may contain fields not
specified here. These extra fields should be ignored. specified here. These extra fields should be ignored.
The <log server> prefix, which is part of the log's metadata, MAY The <log server> prefix, which is part of the log's metadata, MAY
include a path as well as a server name and a port. include a path as well as a server name and a port.
skipping to change at page 22, line 25 skipping to change at page 24, line 19
For example, when a consistency proof between two STHs is requested, For example, when a consistency proof between two STHs is requested,
the front-end reached may not yet be aware of one or both STHs. In the front-end reached may not yet be aware of one or both STHs. In
the case where it is unaware of both, it will return the latest STH the case where it is unaware of both, it will return the latest STH
it is aware of. Where it is aware of the first but not the second, it is aware of. Where it is aware of the first but not the second,
it will return the latest STH it is aware of and a consistency proof it will return the latest STH it is aware of and a consistency proof
from the first STH to the returned STH. The case where it knows the from the first STH to the returned STH. The case where it knows the
second but not the first should not arise (see the "no gaps" second but not the first should not arise (see the "no gaps"
requirement above). requirement above).
If the log is unable to process a client's request, it MUST return an If the log is unable to process a client's request, it MUST return an
HTTP response code of 4xx/5xx (see [RFC2616]), and, in place of the HTTP response code of 4xx/5xx (see [RFC7231]), and, in place of the
responses outlined in the subsections below, the body SHOULD be a responses outlined in the subsections below, the body SHOULD be a
JSON structure containing at least the following field: JSON structure containing at least the following field:
error_message: A human-readable string describing the error which error_message: A human-readable string describing the error which
prevented the log from processing the request. prevented the log from processing the request.
In the case of a malformed request, the string SHOULD provide In the case of a malformed request, the string SHOULD provide
sufficient detail for the error to be rectified. sufficient detail for the error to be rectified.
error_code: An error code readable by the client. Some codes are error_code: An error code readable by the client. Some codes are
skipping to change at page 23, line 8 skipping to change at page 24, line 51
response code with a body similar to the following: response code with a body similar to the following:
{ {
"error_message": "'start' cannot be greater than 'end'", "error_message": "'start' cannot be greater than 'end'",
"error_code": "not compliant", "error_code": "not compliant",
} }
Clients SHOULD treat "500 Internal Server Error" and "503 Service Clients SHOULD treat "500 Internal Server Error" and "503 Service
Unavailable" responses as transient failures and MAY retry the same Unavailable" responses as transient failures and MAY retry the same
request without modification at a later date. Note that as per request without modification at a later date. Note that as per
[RFC2616], in the case of a 503 response the log MAY include a [RFC7231], in the case of a 503 response the log MAY include a
"Retry-After:" header in order to request a minimum time for the "Retry-After:" header in order to request a minimum time for the
client to wait before retrying the request. client to wait before retrying the request.
6.1. Add Chain to Log 6.1. Add Chain to Log
POST https://<log server>/ct/v2/add-chain POST https://<log server>/ct/v2/add-chain
Inputs: Inputs:
chain: An array of base64 encoded certificates. The first chain: An array of base64 encoded certificates. The first
skipping to change at page 42, line 9 skipping to change at page 44, line 9
this document. this document.
If it should become necessary to deprecate an algorithm used by a If it should become necessary to deprecate an algorithm used by a
live log, then the log should be frozen as specified in Section 9.1 live log, then the log should be frozen as specified in Section 9.1
and a new log should be started. Certificates in the frozen log that and a new log should be started. Certificates in the frozen log that
have not yet expired and require new SCTs SHOULD be submitted to the have not yet expired and require new SCTs SHOULD be submitted to the
new log and the SCTs from that log used instead. new log and the SCTs from that log used instead.
11. IANA Considerations 11. IANA Considerations
The assignment policy criteria mentioned in this section refer to the
policies outlined in [RFC5226].
11.1. TLS Extension Type 11.1. TLS Extension Type
IANA is asked to allocate an RFC 5246 ExtensionType value for the IANA is asked to allocate an RFC 5246 ExtensionType value for the
"transparency_info" TLS extension. IANA should update this extension "transparency_info" TLS extension. IANA should update this extension
type to point at this document. type to point at this document.
11.2. New Entry to the TLS CachedInformationType registry 11.2. New Entry to the TLS CachedInformationType registry
IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS
CachedInformationType Values" registry that was defined in [RFC7924]. CachedInformationType Values" registry that was defined in [RFC7924].
11.3. Hash Algorithms 11.3. Hash Algorithms
IANA is asked to establish a registry of hash algorithm values, IANA is asked to establish a registry of hash algorithm values, named
initially consisting of: "CT Hash Algorithms", that initially consists of:
+-------+---------------------+ +------------+---------------+--------------------------------------+
| Index | Hash | | Value | Hash | Reference / Assignment Policy |
+-------+---------------------+ | | Algorithm | |
| 0 | SHA-256 [FIPS180-4] | +------------+---------------+--------------------------------------+
| | | | 0x00 | SHA-256 | [RFC4634] |
| 255 | reserved | | | | |
+-------+---------------------+ | 0x01 - | Unassigned | Specification Required and Expert |
| 0xDF | | Review |
| | | |
| 0xE0 - | Reserved | Experimental Use |
| 0xEF | | |
| | | |
| 0xF0 - | Reserved | Private Use |
| 0xFF | | |
+------------+---------------+--------------------------------------+
11.3.1. Expert Review guidelines
The appointed Expert should ensure that the proposed algorithm has a
public specification and is suitable for use as a cryptographic hash
algorithm with no known preimage or collision attacks. These attacks
can damage the integrity of the log.
11.4. Signature Algorithms 11.4. Signature Algorithms
IANA is asked to establish a registry of signature algorithm values, IANA is asked to establish a registry of signature algorithm values,
initially consisting of: named "CT Signature Algorithms", that initially consists of:
+-------+-----------------------------------------------------------+ +---------+-------------------------------+-------------------------+
| Index | Signature Algorithm | | Value | Signature Algorithm | Reference / Assignment |
+-------+-----------------------------------------------------------+ | | | Policy |
| 0 | deterministic ECDSA [RFC6979] using the NIST P-256 curve | +---------+-------------------------------+-------------------------+
| | (Section D.1.2.3 of the Digital Signature Standard [DSS]) | | 0x00 | Deterministic ECDSA (NIST | [RFC6979] |
| | and HMAC-SHA256. | | | P-256) with HMAC-SHA256 | |
| | | | | | |
| 1 | RSA signatures (RSASSA-PKCS1-v1_5 with SHA-256, Section | | 0x01 | RSA (RSASSA-PKCS1-v1_5, key | [RFC8017] |
| | 8.2 of [RFC3447]) using a key of at least 2048 bits. | | | >= 2048 bits) with SHA-256 | |
+-------+-----------------------------------------------------------+ | | | |
| 0x02 - | Unassigned | Specification Required |
| 0xDF | | and Expert Review |
| | | |
| 0xE0 - | Reserved | Experimental Use |
| 0xEF | | |
| | | |
| 0xF0 - | Reserved | Private Use |
| 0xFF | | |
+---------+-------------------------------+-------------------------+
11.5. SCT Extensions 11.4.1. Expert Review guidelines
IANA is asked to establish a registry of SCT extensions, initially The appointed Expert should ensure that the proposed algorithm has a
consisting of: public specification and is suitable for use as a cryptographic
signature algorithm that always generates signatures
deterministically (for the reasons listed in Section 12.4).
+-------+-----------+ 11.5. VersionedTransTypes
| Type | Extension |
+-------+-----------+
| 65535 | reserved |
+-------+-----------+
TBD: policy for adding to the registry IANA is asked to establish a registry of "VersionedTransType" values,
named "CT VersionedTransTypes", that initially consists of:
11.6. STH Extensions +------------+---------------------------+--------------------------+
| Value | Type and Version | Reference / Assignment |
| | | Policy |
+------------+---------------------------+--------------------------+
| 0x0000 | Reserved | [RFC6962] (*) |
| | | |
| 0x0001 | x509_entry_v2 | RFCXXXX |
| | | |
| 0x0002 | precert_entry_v2 | RFCXXXX |
| | | |
| 0x0003 | x509_sct_v2 | RFCXXXX |
| | | |
| 0x0004 | precert_sct_v2 | RFCXXXX |
| | | |
| 0x0005 | signed_tree_head_v2 | RFCXXXX |
| | | |
| 0x0006 | consistency_proof_v2 | RFCXXXX |
| | | |
| 0x0007 | inclusion_proof_v2 | RFCXXXX |
| | | |
| 0x0008 | x509_sct_with_proof_v2 | RFCXXXX |
| | | |
| 0x0009 | precert_sct_with_proof_v2 | RFCXXXX |
| | | |
| 0x0010 - | Unassigned | Specification Required |
| 0xDFFF | | and Expert Review |
| | | |
| 0xE000 - | Reserved | Experimental Use |
| 0xEFFF | | |
| | | |
| 0xF000 - | Reserved | Private Use |
| 0xFFFF | | |
+------------+---------------------------+--------------------------+
IANA is asked to establish a registry of STH extensions, initially (*) The 0x0000 value is reserved so that v1 SCTs are distinguishable
consisting of: from v2 SCTs and other "TransItem" structures.
+-------+-----------+ [RFC Editor: please update 'RFCXXXX' to refer to this document, once
| Type | Extension | its RFC number is known.]
+-------+-----------+
| 65535 | reserved |
+-------+-----------+
TBD: policy for adding to the registry 11.5.1. Expert Review guidelines
11.7. Object Identifiers The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability.
11.6. SCT Extensions
IANA is asked to establish a registry of SCT extensions, named "CT
Extension Types for SCT", that initially consists of:
+----------------+------------+-------------------------------------+
| Value | Extension | Reference / Assignment Policy |
+----------------+------------+-------------------------------------+
| 0x0000 - | Unassigned | Specification Required and Expert |
| 0xDFFF | | Review |
| | | |
| 0xE000 - | Reserved | Experimental Use |
| 0xEFFF | | |
| | | |
| 0xF000 - | Reserved | Private Use |
| 0xFFFF | | |
+----------------+------------+-------------------------------------+
11.6.1. Expert Review guidelines
The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability.
11.7. STH Extensions
IANA is asked to establish a registry of STH extensions, named "CT
Extension Types for STH", that initially consists of:
+----------------+------------+-------------------------------------+
| Value | Extension | Reference / Assignment Policy |
+----------------+------------+-------------------------------------+
| 0x0000 - | Unassigned | Specification Required and Expert |
| 0xDFFF | | Review |
| | | |
| 0xE000 - | Reserved | Experimental Use |
| 0xEFFF | | |
| | | |
| 0xF000 - | Reserved | Private Use |
| 0xFFFF | | |
+----------------+------------+-------------------------------------+
11.7.1. Expert Review guidelines
The appointed Expert should review the public specification to ensure
that it is detailed enough to ensure implementation interoperability.
11.8. Object Identifiers
This document uses object identifiers (OIDs) to identify Log IDs (see This document uses object identifiers (OIDs) to identify Log IDs (see
Section 5.3), the precertificate CMS "eContentType" (see Section 5.3), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see Section 4.2 Section 3.2), and X.509v3 extensions in certificates (see Section 4.2
and Section 8.1.2) and OCSP responses (see Section 8.1.1). The OIDs and Section 8.1.2) and OCSP responses (see Section 8.1.1). The OIDs
are defined in an arc that was selected due to its short encoding. are defined in an arc that was selected due to its short encoding.
11.7.1. Log ID Registry 1 11.8.1. Log ID Registry
IANA is asked to establish a registry of Log IDs, named "CT Log ID
Registry", that initially consists of:
+-------------------------+------------+----------------------------+
| Value | Log | Reference / Assignment |
| | | Policy |
+-------------------------+------------+----------------------------+
| 1.3.101.8192 - | Unassigned | Metadata Required and |
| 1.3.101.16383 | | Expert Review |
| | | |
| 1.3.101.80.0 - | Unassigned | Metadata Required and |
| 1.3.101.80.127 | | Expert Review |
| | | |
| 1.3.101.80.128 - | Unassigned | First Come First Served |
| 1.3.101.80.* | | |
+-------------------------+------------+----------------------------+
All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
reserved. This is a limited resource of 8,192 OIDs, each of which reserved. This is a limited resource of 8,192 OIDs, each of which
has an encoded length of 4 octets. has an encoded length of 4 octets.
IANA is requested to establish a registry that will allocate Log IDs
from this range.
TBD: policy for adding to the registry. Perhaps "Expert Review"?
11.7.2. Log ID Registry 2
The 1.3.101.80 arc has been delegated. This is an unlimited The 1.3.101.80 arc has been delegated. This is an unlimited
resource, but only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127 resource, but only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127
have an encoded length of only 4 octets. have an encoded length of only 4 octets.
IANA is requested to establish a registry that will allocate Log IDs Each application for the allocation of a Log ID should be accompanied
from this arc. by all of the required metadata (except for the Log ID) listed in
Section 9.1.
TBD: policy for adding to the registry. Perhaps "Expert Review"? 11.8.2. Expert Review guidelines
Since the Log IDs with the shortest encodings are a limited resource,
the appointed Expert should review the submitted metadata and judge
whether or not the applicant is requesting a Log ID in good faith
(with the intention of actually running a CT log that will be
identified by the allocated Log ID).
12. Security Considerations 12. Security Considerations
With CAs, logs, and servers performing the actions described here, With CAs, logs, and servers performing the actions described here,
TLS clients can use logs and signed timestamps to reduce the TLS clients can use logs and signed timestamps to reduce the
likelihood that they will accept misissued certificates. If a server likelihood that they will accept misissued certificates. If a server
presents a valid signed timestamp for a certificate, then the client presents a valid signed timestamp for a certificate, then the client
knows that a log has committed to publishing the certificate. From knows that a log has committed to publishing the certificate. From
this, the client knows that monitors acting for the subject of the this, the client knows that monitors acting for the subject of the
certificate have had some time to notice the misissue and take some certificate have had some time to notice the misissue and take some
skipping to change at page 46, line 32 skipping to change at page 51, line 14
Phaneuf, Melinda Shore, Ryan Sleevi, Martin Smith, Carl Wallace and Phaneuf, Melinda Shore, Ryan Sleevi, Martin Smith, Carl Wallace and
Paul Wouters for their valuable contributions. Paul Wouters for their valuable contributions.
A big thank you to Symantec for kindly donating the OIDs from the A big thank you to Symantec for kindly donating the OIDs from the
1.3.101 arc that are used in this document. 1.3.101 arc that are used in this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 2009,
<http://csrc.nist.gov/publications/fips/fips186-3/
fips_186-3.pdf>.
[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/
RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487
/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, DOI 10.17487 Extensions: Extension Definitions", RFC 6066,
/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <http://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>. <http://www.rfc-editor.org/info/rfc6961>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Algorithm (DSA) and Elliptic Curve Digital Signature Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2014, <http://www.rfc-editor.org/info/rfc7159>.
2013, <http://www.rfc-editor.org/info/rfc6979>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>. October 2015, <http://www.rfc-editor.org/info/rfc7633>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, DOI (TLS) Cached Information Extension", RFC 7924,
10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>. <http://www.rfc-editor.org/info/rfc7924>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<http://www.rfc-editor.org/info/rfc8017>.
14.2. Informative References 14.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/ Log Policy", 2014, <http://www.chromium.org/Home/chromium-
chromium-security/certificate-transparency/log-policy>. security/certificate-transparency/log-policy>.
[Chromium.Policy] [Chromium.Policy]
The Chromium Projects, "Chromium Certificate The Chromium Projects, "Chromium Certificate
Transparency", 2014, <http://www.chromium.org/Home/ Transparency", 2014, <http://www.chromium.org/Home/
chromium-security/certificate-transparency>. chromium-security/certificate-transparency>.
[CrosbyWallach] [CrosbyWallach]
Crosby, S. and D. Wallach, "Efficient Data Structures for Crosby, S. and D. Wallach, "Efficient Data Structures for
Tamper-Evident Logging", Proceedings of the 18th USENIX Tamper-Evident Logging", Proceedings of the 18th USENIX
Security Symposium, Montreal, August 2009, Security Symposium, Montreal, August 2009,
skipping to change at page 49, line 33 skipping to change at page 53, line 38
[I-D.ietf-trans-threat-analysis] [I-D.ietf-trans-threat-analysis]
Kent, S., "Attack and Threat Model for Certificate Kent, S., "Attack and Threat Model for Certificate
Transparency", draft-ietf-trans-threat-analysis-10 (work Transparency", draft-ietf-trans-threat-analysis-10 (work
in progress), October 2016. in progress), October 2016.
[JSON.Metadata] [JSON.Metadata]
The Chromium Projects, "Chromium Log Metadata JSON The Chromium Projects, "Chromium Log Metadata JSON
Schema", 2014, <http://www.certificate-transparency.org/ Schema", 2014, <http://www.certificate-transparency.org/
known-logs/log_list_schema.json>. known-logs/log_list_schema.json>.
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July
2006, <http://www.rfc-editor.org/info/rfc4634>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <http://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>.
Appendix A. Supporting v1 and v2 simultaneously Appendix A. Supporting v1 and v2 simultaneously
Certificate Transparency logs have to be either v1 (conforming to Certificate Transparency logs have to be either v1 (conforming to
[RFC6962]) or v2 (conforming to this document), as the data [RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid structures are incompatible and so a v2 log could not issue a valid
v1 SCT. v1 SCT.
CT clients, however, can support v1 and v2 SCTs, for the same CT clients, however, can support v1 and v2 SCTs, for the same
certificate, simultaneously, as v1 SCTs are delivered in different certificate, simultaneously, as v1 SCTs are delivered in different
TLS, X.509 and OCSP extensions than v2 SCTs. TLS, X.509 and OCSP extensions than v2 SCTs.
 End of changes. 52 change blocks. 
224 lines changed or deleted 425 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/