draft-ietf-trans-rfc6962-bis-12.txt   draft-ietf-trans-rfc6962-bis-13.txt 
Public Notary Transparency Working Group B. Laurie Public Notary Transparency Working Group B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Intended status: Standards Track E. Kasper Intended status: Standards Track E. Kasper
Expires: July 31, 2016 E. Messeri Expires: September 22, 2016 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
January 28, 2016 March 21, 2016
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-12 draft-ietf-trans-rfc6962-bis-13
Abstract Abstract
This document describes a protocol for publicly logging the existence This document describes a protocol for publicly logging the existence
of Transport Layer Security (TLS) certificates as they are issued or of Transport Layer Security (TLS) certificates as they are issued or
observed, in a manner that allows anyone to audit certification observed, in a manner that allows anyone to audit certification
authority (CA) activity and notice the issuance of suspect authority (CA) activity and notice the issuance of suspect
certificates as well as to audit the certificate logs themselves. certificates as well as to audit the certificate logs themselves.
The intent is that eventually clients would refuse to honor The intent is that eventually clients would refuse to honor
certificates that do not appear in a log, effectively forcing CAs to certificates that do not appear in a log, effectively forcing CAs to
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 July 31, 2016. This Internet-Draft will expire on September 22, 2016.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 5
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 5 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 6 2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 6
2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 7 2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 7
2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 9 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 9
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 10 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 10
4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 11 4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 11
4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 11 4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 11
4.2. Redacting Domain Name Labels in Precertificates . . . . . 11 4.2. Redacting Domain Name Labels in Precertificates . . . . . 11
4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 12 4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 12
5. Log Format and Operation . . . . . . . . . . . . . . . . . . 13 5. Log Format and Operation . . . . . . . . . . . . . . . . . . 13
5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 14 5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 14
5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. The TransItem Structure . . . . . . . . . . . . . . . . . 16 5.4. The TransItem Structure . . . . . . . . . . . . . . . . . 16
5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 18 5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 17
5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 19 5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 18
5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 20 5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 19
5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 21 5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 19
5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 22 5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 21
5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 23 5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 21
5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 22
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23
6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 25 6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 24
6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 26 6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 25
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 26 6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 25
6.4. Retrieve Merkle Consistency Proof between Two Signed Tree 6.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 27 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 . . . . . . . . . . . . . 28 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 27
6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29 6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29
6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 31 6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 30
7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. TLS Extension . . . . . . . . . . . . . . . . . . . . . . 32 7.1. Multiple SCTs or inclusion proofs . . . . . . . . . . . . 31
7.2. TLS Extension . . . . . . . . . . . . . . . . . . . . . . 32
8. Certification Authorities . . . . . . . . . . . . . . . . . . 32 8. Certification Authorities . . . . . . . . . . . . . . . . . . 32
8.1. Transparency Information X.509v3 Extension . . . . . . . 32 8.1. Transparency Information X.509v3 Extension . . . . . . . 32
8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 33 8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 33
8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 33 8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 33
8.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 33
9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 34 9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 35
9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2.1. Receiving SCTs or inclusion proofs . . . . . . . . . 35
9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 36 9.2.2. Reconstructing the TBSCertificate . . . . . . . . . . 35
9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 37 9.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 35
9.4.2. Verifying consistency between two STHs . . . . . . . 37 9.2.4. Validating inclusion proofs . . . . . . . . . . . . . 36
9.4.3. Verifying root hash given entries . . . . . . . . . . 38 9.2.5. Evaluating compliance . . . . . . . . . . . . . . . . 36
10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 39 9.2.6. TLS Feature Extension . . . . . . . . . . . . . . . . 36
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9.2.7. Handling of Non-compliance . . . . . . . . . . . . . 36
11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 39 9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 39 9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 38
11.3. TransItem Extensions . . . . . . . . . . . . . . . . . . 39 9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 38
11.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 40 9.4.2. Verifying consistency between two STHs . . . . . . . 39
11.5. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 40 9.4.3. Verifying root hash given entries . . . . . . . . . . 40
11.6. STH Extensions . . . . . . . . . . . . . . . . . . . . . 40 10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 41
12. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 41 11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 41
12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 41 11.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 41
12.3. Redaction of Public Domain Name Labels . . . . . . . . . 41 11.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 42
12.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 41 11.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 42
12.5. Deterministic Signatures . . . . . . . . . . . . . . . . 42 11.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 42
12.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 42 11.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 42
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 11.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 43
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 43
14.1. Normative References . . . . . . . . . . . . . . . . . . 43 12. Security Considerations . . . . . . . . . . . . . . . . . . . 43
14.2. Informative References . . . . . . . . . . . . . . . . . 44 12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 44
Appendix A. TransItemV1 . . . . . . . . . . . . . . . . . . . . 46 12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 44
12.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 44
12.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 44
12.5. Deterministic Signatures . . . . . . . . . . . . . . . . 45
12.6. Multiple SCTs or inclusion proofs . . . . . . . . . . . 45
12.7. Threat Analysis . . . . . . . . . . . . . . . . . . . . 45
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.1. Normative References . . . . . . . . . . . . . . . . . . 46
14.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 49
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 4, line 24 skipping to change at page 4, line 37
holders can also contribute their own certificate chains, as can holders can also contribute their own certificate chains, as can
third parties. In order to avoid logs being rendered useless by the third parties. In order to avoid logs being rendered useless by the
submission of large numbers of spurious certificates, it is required submission of large numbers of spurious certificates, it is required
that each chain ends with a trust anchor that is accepted by the log. that each chain ends with a trust anchor that is accepted by the log.
When a chain is accepted by a log, a signed timestamp is returned, When a chain is accepted by a log, a signed timestamp is returned,
which can later be used to provide evidence to TLS clients that the which can later be used to provide evidence to TLS clients that the
chain has been submitted. TLS clients can thus require that all chain has been submitted. TLS clients can thus require that all
certificates they accept as valid are accompanied by signed certificates they accept as valid are accompanied by signed
timestamps. timestamps.
Those who are concerned about misissue can monitor the logs, asking Those who are concerned about misissuance can monitor the logs,
them regularly for all new entries, and can thus check whether asking them regularly for all new entries, and can thus check whether
domains they are responsible for have had certificates issued that domains they are responsible for have had certificates issued that
they did not expect. What they do with this information, they did not expect. What they do with this information,
particularly when they find that a misissuance has happened, is particularly when they find that a misissuance has happened, is
beyond the scope of this document, but broadly speaking, they can beyond the scope of this document, but broadly speaking, they can
invoke existing business mechanisms for dealing with misissued invoke existing business mechanisms for dealing with misissued
certificates, such as working with the CA to get the certificate certificates, such as working with the CA to get the certificate
revoked, or with maintainers of trust anchor lists to get the CA revoked, or with maintainers of trust anchor lists to get the CA
removed. Of course, anyone who wants can monitor the logs and, if removed. Of course, anyone who wants can monitor the logs and, if
they believe a certificate is incorrectly issued, take action as they they believe a certificate is incorrectly issued, take action as they
see fit. see fit.
Similarly, those who have seen signed timestamps from a particular Similarly, those who have seen signed timestamps from a particular
log can later demand a proof of inclusion from that log. If the log log can later demand a proof of inclusion from that log. If the log
is unable to provide this (or, indeed, if the corresponding is unable to provide this (or, indeed, if the corresponding
certificate is absent from monitors' copies of that log), that is certificate is absent from monitors' copies of that log), that is
evidence of the incorrect operation of the log. The checking evidence of the incorrect operation of the log. The checking
operation is asynchronous to allow TLS connections to proceed without operation is asynchronous to allow clients to proceed without delay,
delay, despite network connectivity issues and the vagaries of despite possible issues such as network connectivity and the vagaries
firewalls. of firewalls.
The append-only property of each log is technically achieved using The append-only property of each log is technically achieved using
Merkle Trees, which can be used to show that any particular instance Merkle Trees, which can be used to show that any particular instance
of the log is a superset of any particular previous instance. of the log is a superset of any particular previous instance.
Likewise, Merkle Trees avoid the need to blindly trust logs: if a log Likewise, Merkle Trees avoid the need to blindly trust logs: if a log
attempts to show different things to different people, this can be attempts to show different things to different people, this can be
efficiently detected by comparing tree roots and consistency proofs. efficiently detected by comparing tree roots and consistency proofs.
Similarly, other misbehaviors of any log (e.g., issuing signed Similarly, other misbehaviors of any log (e.g., issuing signed
timestamps for certificates they then don't log) can be efficiently timestamps for certificates they then don't log) can be efficiently
detected and proved to the world at large. detected and proved to the world at large.
1.1. Requirements Language 1.1. Requirements Language
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].
skipping to change at page 7, line 23 skipping to change at page 7, line 29
inputs) sufficient to verify MTH(D[n]), such that (a subset of) the inputs) sufficient to verify MTH(D[n]), such that (a subset of) the
same nodes can be used to verify MTH(D[0:m]). We define an algorithm same nodes can be used to verify MTH(D[0:m]). We define an algorithm
that outputs the (unique) minimal consistency proof. that outputs the (unique) minimal consistency proof.
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 consistency proof PROOF(m, D[n]) for a previous d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous
Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as: Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as:
PROOF(m, D[n]) = SUBPROOF(m, D[n], true) PROOF(m, D[n]) = SUBPROOF(m, D[n], true)
In SUBPROOF, the boolean value represents whether the subtree created
from D[0:m] is a complete subtree of the Merkle Tree created from
D[n], and, consequently, whether the subtree Merkle Tree Hash
MTH(D[0:m]) is known. The initial call to SUBPROOF sets this to be
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 Merkle Tree Hash 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]
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) = {}
The subproof for m = n is the Merkle Tree Hash committing inputs Otherwise, the subproof for m = n is the Merkle Tree Hash committing
D[0:m]; otherwise: 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]:
skipping to change at page 9, line 47 skipping to change at page 9, line 47
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l. hash can be verified using hash1=k and l.
The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i,
j, k]. k, i are used to verify hash2, and j is additionally used to j, k]. k, i are used to verify hash2, and j is additionally used to
show hash is consistent with hash2. show hash is consistent with hash2.
2.1.4. Signatures 2.1.4. Signatures
Various data structures are signed. A log MUST use one of the Various data structures are signed. A log MUST use one of the
signature algorithms defined in the Section 11.4 section. signature algorithms defined in the Section 11.3 section.
3. Submitters 3. Submitters
Submitters submit certificates or precertificates to logs for public Submitters submit certificates or preannouncements of certificates
auditing, as described below. In order to enable attribution of each prior to issuance (precertificates) to logs for public auditing, as
logged certificate or precertificate to its issuer, each submission described below. In order to enable attribution of each logged
MUST be accompanied by all additional certificates required to verify certificate or precertificate to its issuer, each submission MUST be
the chain up to an accepted trust anchor. The trust anchor (a root accompanied by all additional certificates required to verify the
or intermediate CA certificate) MAY be omitted from the submission. chain up to an accepted trust anchor. The trust anchor (a root or
intermediate CA certificate) MAY be omitted from the submission.
If a log accepts a submission, it will return a Signed Certificate If a log accepts a submission, it will return a Signed Certificate
Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the
returned SCT as described in Section 9.2 if they understand its returned SCT as described in Section 9.2 if they understand its
format and they intend to use it directly in a TLS handshake or to format and they intend to use it directly in a TLS handshake or to
construct a certificate. construct a certificate. If the submitter does not need the SCT (for
example, the certificate is being submitted simply to make it
available in the log), it MAY validate the SCT.
3.1. Certificates 3.1. Certificates
Anyone can submit a certificate (Section 6.1) to a log. Since Any entity can submit a certificate (Section 6.1) to a log. Since
certificates may not be accepted by TLS clients unless logged, it is certificates may not be accepted by TLS clients unless logged, it is
expected that certificate owners or their CAs will usually submit expected that certificate owners or their CAs will usually submit
them. them.
3.2. Precertificates 3.2. Precertificates
Alternatively, (root as well as intermediate) CAs may preannounce a Alternatively, (root as well as intermediate) CAs may preannounce a
certificate prior to issuance by submitting a precertificate certificate prior to issuance by submitting a precertificate
(Section 6.2) that the log can use to create an entry that will be (Section 6.2) that the log can use to create an entry that will be
valid against the issued certificate. The CA MAY incorporate the valid against the issued certificate. The CA MAY incorporate the
returned SCT in the issued certificate. returned SCT in the issued certificate. Examples of situations where
the returned SCT is not incorporated into the issued certificate
would be when a CA sends the precertificate to multiple logs, but
only incorporates the SCTs that are returned first, or the CA is
using domain name redaction and intends to use another mechanism to
publish SCTs (such as an OCSP response (Section 8.1.1) or the TLS
extension (Section 7.2)).
A precertificate is a CMS [RFC5652] "signed-data" object that A precertificate is a CMS [RFC5652] "signed-data" object that
conforms to the following requirements: conforms to the following requirements:
o It MUST be DER encoded. o It MUST be DER encoded.
o "SignedData.encapContentInfo.eContentType" MUST be the OID <TBD>. o "SignedData.encapContentInfo.eContentType" MUST be the OID
1.3.101.78.
o "SignedData.encapContentInfo.eContent" MUST contain a o "SignedData.encapContentInfo.eContent" MUST contain a
TBSCertificate [RFC5280], which MAY redact certain domain name TBSCertificate [RFC5280], which MAY redact certain domain name
labels that will be present in the issued certificate (see labels that will be present in the issued certificate (see
Section 4.2) and MUST NOT contain any SCTs, but which will be Section 4.2) and MUST NOT contain any SCTs, but which will be
otherwise identical to the TBSCertificate in the issued otherwise identical to the TBSCertificate in the issued
certificate. certificate.
o "SignedData.signerInfos" MUST contain a signature from the same o "SignedData.signerInfos" MUST contain a signature from the same
(root or intermediate) CA that will ultimately issue the (root or intermediate) CA that will ultimately issue the
skipping to change at page 11, line 30 skipping to change at page 11, line 41
private labels to not appear in public logs. private labels to not appear in public logs.
4.1. Wildcard Certificates 4.1. Wildcard Certificates
A certificate containing a DNS-ID [RFC6125] of "*.example.com" could A certificate containing a DNS-ID [RFC6125] of "*.example.com" could
be used to secure the domain "topsecret.example.com", without be used to secure the domain "topsecret.example.com", without
revealing the string "topsecret" publicly. revealing the string "topsecret" publicly.
Since TLS clients only match the wildcard character to the complete Since TLS clients only match the wildcard character to the complete
leftmost label of the DNS domain name (see Section 6.4.3 of leftmost label of the DNS domain name (see Section 6.4.3 of
[RFC6125]), this approach would not work for a DNS-ID such as [RFC6125]), a different approach is needed when more than one of the
"top.secret.example.com". Also, wildcard certificates are prohibited leftmost labels in a DNS-ID are considered private (e.g.
in some cases, such as Extended Validation Certificates "top.secret.example.com"). Also, wildcard certificates are
prohibited in some cases, such as Extended Validation Certificates
[EVSSLGuidelines]. [EVSSLGuidelines].
4.2. Redacting Domain Name Labels in Precertificates 4.2. Redacting Domain Name Labels in Precertificates
When creating a precertificate, the CA MAY substitute one or more When creating a precertificate, the CA MAY substitute one or more
labels in each DNS-ID with a corresponding number of "?" labels. labels in each DNS-ID with a corresponding number of "?" labels.
Every label to the left of a "?" label MUST also be redacted. For Every label to the left of a "?" label MUST also be redacted. For
example, if a certificate contains a DNS-ID of example, if a certificate contains a DNS-ID of
"top.secret.example.com", then the corresponding precertificate could "top.secret.example.com", then the corresponding precertificate could
contain "?.?.example.com" instead, but not "top.?.example.com" contain "?.?.example.com" instead, but not "top.?.example.com"
skipping to change at page 12, line 6 skipping to change at page 12, line 17
Wildcard "*" labels MUST NOT be redacted. However, if the complete Wildcard "*" labels MUST NOT be redacted. However, if the complete
leftmost label of a DNS-ID is "*", it is considered redacted for the leftmost label of a DNS-ID is "*", it is considered redacted for the
purposes of determining if the label to the right may be redacted. purposes of determining if the label to the right may be redacted.
For example, if a certificate contains a DNS-ID of For example, if a certificate contains a DNS-ID of
"*.top.secret.example.com", then the corresponding precertificate "*.top.secret.example.com", then the corresponding precertificate
could contain "*.?.?.example.com" instead, but not could contain "*.?.?.example.com" instead, but not
"?.?.?.example.com" instead. "?.?.?.example.com" instead.
When a precertificate contains one or more redacted labels, a non- When a precertificate contains one or more redacted labels, a non-
critical extension (OID 1.3.6.1.4.1.11129.2.4.6, whose extnValue critical extension (OID 1.3.101.77, whose extnValue OCTET STRING
OCTET STRING contains an ASN.1 SEQUENCE OF INTEGERs) MUST be added to contains an ASN.1 SEQUENCE OF INTEGERs) MUST be added to the
the corresponding certificate: the first INTEGER indicates the total corresponding certificate: the first INTEGER indicates the total
number of redacted labels and wildcard "*" labels in the number of "?" labels in the precertificate's first DNS-ID; the second
precertificate's first DNS-ID; the second INTEGER does the same for INTEGER does the same for the precertificate's second DNS-ID; etc.
the precertificate's second DNS-ID; etc. There MUST NOT be more There MUST NOT be more INTEGERs than there are DNS-IDs. If there are
INTEGERs than there are DNS-IDs. If there are fewer INTEGERs than fewer INTEGERs than there are DNS-IDs, the shortfall is made up by
there are DNS-IDs, the shortfall is made up by implicitly repeating implicitly repeating the last INTEGER. Each INTEGER MUST have a
the last INTEGER. Each INTEGER MUST have a value of zero or more. value of zero or more. The purpose of this extension is to enable
The purpose of this extension is to enable TLS clients to accurately TLS clients to reconstruct the TBSCertificate component of the
reconstruct the TBSCertificate component of the precertificate from precertificate from the certificate, as described in Section 9.2.2.
the certificate without having to perform any guesswork.
When a precertificate contains that extension and contains a CN-ID When a precertificate contains that extension and contains a CN-ID
[RFC6125], the CN-ID MUST match the first DNS-ID and have the same [RFC6125], the CN-ID MUST match the first DNS-ID and have the same
labels redacted. TLS clients will use the first entry in the labels redacted. TLS clients will use the first entry in the
SEQUENCE OF INTEGERs to reconstruct both the first DNS-ID and the CN- SEQUENCE OF INTEGERs to reconstruct both the first DNS-ID and the CN-
ID. ID.
4.3. Using a Name-Constrained Intermediate CA 4.3. Using a Name-Constrained Intermediate CA
An intermediate CA certificate or intermediate CA precertificate that An intermediate CA certificate or intermediate CA precertificate that
contains the critical or non-critical Name Constraints [RFC5280] contains the critical or non-critical Name Constraints [RFC5280]
extension MAY be logged in place of end-entity certificates issued by extension MAY be logged in place of end-entity certificates issued by
that intermediate CA, as long as all of the following conditions are that intermediate CA, as long as all of the following conditions are
met: met:
o there MUST be a non-critical extension (OID o there MUST be a non-critical extension (OID 1.3.101.76, whose
1.3.6.1.4.1.11129.2.4.7, whose extnValue OCTET STRING contains extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)).
ASN.1 NULL data (0x05 0x00)). This extension is an explicit This extension is an explicit indication that it is acceptable to
indication that it is acceptable to not log certificates issued by not log certificates issued by this intermediate CA.
this intermediate CA.
o permittedSubtrees MUST specify one or more dNSNames. o permittedSubtrees MUST specify one or more dNSNames.
o excludedSubtrees MUST specify the entire IPv4 and IPv6 address o excludedSubtrees MUST specify the entire IPv4 and IPv6 address
ranges. ranges.
Below is an example Name Constraints extension that meets these Below is an example Name Constraints extension that meets these
conditions: conditions:
SEQUENCE { SEQUENCE {
skipping to change at page 13, line 38 skipping to change at page 13, line 38
} }
} }
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 a valid submission, the log MUST return an SCT that
corresponds to the submitted certificate or precertificate. If the corresponds to the submitted certificate or precertificate. If the
log has previously seen this valid submission, it MAY return the same log has previously seen this valid submission, it SHOULD return the
SCT as it returned before. (Note that if a certificate was same SCT as it returned before (to reduce the ability to track
previously logged as a precertificate, then the precertificate's SCT clients as described in Section 12.5). Note that if a certificate
of type "precert_sct" would not be appropriate; instead, a fresh SCT was previously logged as a precertificate, then the precertificate's
of type "x509_sct" should be generated). SCT of type "precert_sct" would not be appropriate; instead, a fresh
SCT of type "x509_sct" 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.
skipping to change at page 15, line 44 skipping to change at page 15, line 44
accepted by the log. accepted by the log.
"precertificate_chain" is a vector of 1 or more additional "precertificate_chain" is a vector of 1 or more additional
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's operator allocates an OID for the purpose of uniquely Each log is uniquely identified by an OID. A log's operator MUST
identifying that log. This OID is specified in the log's metadata. either allocate the OID themselves or request an OID from one of the
Various data structures include the DER encoding of this OID, two Log ID Registries (see Section 11.6.1 and Section 11.6.2). The
excluding the ASN.1 tag and length bytes, in an opaque vector: OID is specified in the log's metadata. Various data structures
include the DER encoding of this OID, excluding the ASN.1 tag and
length bytes, in an opaque 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.
5.4. The TransItem Structure 5.4. The TransItem Structure
Various data structures produced by logs are encapsulated in the Various data structures produced by logs are encapsulated in the
"TransItem" structure to ensure that the type and version of each one "TransItem" structure to ensure that the type and version of each one
is identified in a common fashion: is identified in a common fashion:
enum { enum {
v1(0), v2(1), (255) v1(0), v2(1), (255)
} Version; } Version;
enum { enum {
x509_entry(0), precert_entry(1), x509_sct(2), precert_sct(3), x509_entry(0), precert_entry(1), x509_sct(2), precert_sct(3),
skipping to change at page 17, line 18 skipping to change at page 16, line 26
enum { enum {
v1(0), v2(1), (255) v1(0), v2(1), (255)
} Version; } Version;
enum { enum {
x509_entry(0), precert_entry(1), x509_sct(2), precert_sct(3), x509_entry(0), precert_entry(1), x509_sct(2), precert_sct(3),
tree_head(4), signed_tree_head(5), consistency_proof(6), tree_head(4), signed_tree_head(5), consistency_proof(6),
inclusion_proof(7), (65535) inclusion_proof(7), (65535)
} TransType; } TransType;
enum {
reserved(65535)
} ItemExtensionType;
struct {
ItemExtensionType item_extension_type;
opaque item_extension_data<0..2^16-1>;
} ItemExtension;
struct { struct {
Version version;
TransType type; TransType type;
select (type) { select (type) {
case x509_entry: TimestampedCertificateEntryDataV2; case x509_entry: TimestampedCertificateEntryDataV2;
case precert_entry: TimestampedCertificateEntryDataV2; case precert_entry: TimestampedCertificateEntryDataV2;
case x509_sct: SignedCertificateTimestampDataV2; case x509_sct: SignedCertificateTimestampDataV2;
case precert_sct: SignedCertificateTimestampDataV2; case precert_sct: SignedCertificateTimestampDataV2;
case tree_head: TreeHeadDataV2; case tree_head: TreeHeadDataV2;
case signed_tree_head: SignedTreeHeadDataV2; case signed_tree_head: SignedTreeHeadDataV2;
case consistency_proof: ConsistencyProofDataV2; case consistency_proof: ConsistencyProofDataV2;
case inclusion_proof: InclusionProofDataV2; case inclusion_proof: InclusionProofDataV2;
} data; } data;
ItemExtension item_extensions<0..2^16-1>;
} TransItemV2;
struct {
Version version;
select (version) {
case v1: TransItemV1;
case v2: TransItemV2;
}
} TransItem; } TransItem;
"version" is the earliest version of this protocol to which the "version" is the earliest version of this protocol to which the
encapsulated data structure conforms. This document is v2. Note encapsulated data structure conforms. This document is v2. Note
that v1 [RFC6962] did not define "TransItem", but this document that v1 [RFC6962] did not define "TransItem", but this document
specifies a mechanism (see Appendix A) for v2 implementations to provides guidelines (see Appendix A) on how v2 implementations can
encapsulate existing v1 objects in the "TransItem" structure. Note co-exist with v1 implementations. Note also that, since each
also that, since each "TransItem" object is individually versioned, "TransItem" object is individually versioned, the version should be
future revisions to this protocol could conceivably update some increased only if changes to it are made that are not backwards-
encapsulated data structures without having to update all of them. compatible. The addition of encapsulated data structures can be done
by adding "TransType" values without increasing the version.
"type" is the type of the encapsulated data structure. (Note that "type" is the type of the encapsulated data structure. (Note that
"TransType" combines the v1 type enumerations "LogEntryType", "TransType" combines the v1 type enumerations "LogEntryType",
"SignatureType" and "MerkleLeafType"). Future revisions of this "SignatureType" and "MerkleLeafType"). Future revisions of this
protocol may add new "TransType" values. protocol may add new "TransType" values.
"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.
"item_extension_type" identifies a single extension from the IANA
registry in Section 11.3.
The interpretation of the "item_extension_data" field is determined
solely by the value of the "item_extension_type" field. Each
document that registers a new "item_extension_type" must describe how
to interpret the corresponding "item_extension_data".
"item_extensions" is a vector of 0 or more item extensions. This
vector MUST NOT include more than one extension with the same
"item_extension_type". The extensions in the vector MUST be ordered
by the value of the "item_extension_type" field, smallest value
first.
5.5. Merkle Tree Leaves 5.5. Merkle Tree Leaves
The leaves of a log's Merkle Tree correspond to the log's entries The leaves of a log's Merkle Tree correspond to the log's entries
(see Section 5.2). Each leaf is the leaf hash (Section 2.1) of a (see Section 5.2). Each leaf is the leaf hash (Section 2.1) of a
"TransItem" structure of type "x509_entry" or "precert_entry", which "TransItem" structure of type "x509_entry" or "precert_entry", which
in this version (v2) encapsulates a in this version (v2) encapsulates a
"TimestampedCertificateEntryDataV2" structure. Note that leaf hashes "TimestampedCertificateEntryDataV2" structure. Note that leaf hashes
are calculated as HASH(0x00 || TransItem), where the hashing are calculated as HASH(0x00 || TransItem), where the hashing
algorithm is specified in the log's metadata. algorithm is specified in the log's metadata.
skipping to change at page 19, line 8 skipping to change at page 17, line 33
struct { struct {
uint64 timestamp; uint64 timestamp;
opaque issuer_key_hash[HASH_SIZE]; opaque issuer_key_hash[HASH_SIZE];
TBSCertificate tbs_certificate; TBSCertificate tbs_certificate;
SctExtension sct_extensions<0..2^16-1>; SctExtension sct_extensions<0..2^16-1>;
} TimestampedCertificateEntryDataV2; } TimestampedCertificateEntryDataV2;
"timestamp" is the NTP Time [RFC5905] at which the certificate or "timestamp" is the NTP Time [RFC5905] at which the certificate or
precertificate was accepted by the log, measured in milliseconds precertificate was accepted by the log, measured in milliseconds
since the epoch (January 1, 1970, 00:00), ignoring leap seconds. since the epoch (January 1, 1970, 00:00), ignoring leap seconds.
Note that the leaves of a log's Merkle Tree are not required to be in
strict chronological order.
"issuer_key_hash" is the HASH of the public key of the CA that issued "issuer_key_hash" is the HASH of the public key of the CA that issued
the certificate or precertificate, calculated over the DER encoding the certificate or precertificate, calculated over the DER encoding
of the key represented as SubjectPublicKeyInfo [RFC5280]. This is of the key represented as SubjectPublicKeyInfo [RFC5280]. This is
needed to bind the CA to the certificate or precertificate, making it needed to bind the CA to the certificate or precertificate, making it
impossible for the corresponding SCT to be valid for any other impossible for the corresponding SCT to be valid for any other
certificate or precertificate whose TBSCertificate matches certificate or precertificate whose TBSCertificate matches
"tbs_certificate". "tbs_certificate".
"tbs_certificate" is the DER encoded TBSCertificate from either the "tbs_certificate" is the DER encoded TBSCertificate from either the
"leaf_certificate" (in the case of an "X509ChainEntry") or the "leaf_certificate" (in the case of an "X509ChainEntry") or the
"pre_certificate" (in the case of a "PrecertChainEntryV2"). (Note "pre_certificate" (in the case of a "PrecertChainEntryV2"). (Note
that a precertificate's TBSCertificate can be reconstructed from the that a precertificate's TBSCertificate can be reconstructed from the
issued certificate's TBSCertificate by redacting the domain name corresponding certificate as described in Section 9.2.2).
labels indicated by the redacted labels extension, and deleting the
SCT list extension and redacted labels extension).
"sct_extensions" matches the SCT extensions of the corresponding SCT. "sct_extensions" matches the SCT extensions of the corresponding SCT.
5.6. Signed Certificate Timestamp (SCT) 5.6. Signed Certificate Timestamp (SCT)
An SCT is a "TransItem" structure of type "x509_sct" or An SCT is a "TransItem" structure of type "x509_sct" or
"precert_sct", which in this version (v2) encapsulates a "precert_sct", which in this version (v2) encapsulates a
"SignedCertificateTimestampDataV2" structure: "SignedCertificateTimestampDataV2" structure:
enum { enum {
skipping to change at page 20, line 10 skipping to change at page 18, 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.4. 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 22, line 12 skipping to change at page 20, line 44
Each subsequent timestamp MUST be more recent than the timestamp of Each subsequent timestamp MUST be more recent than the timestamp of
the previous update. the previous update.
"tree_size" is equal to the tree size from the "TreeHeadDataV2" "tree_size" is equal to the tree size from the "TreeHeadDataV2"
structure encapsulated in "merkle_tree_head". structure encapsulated in "merkle_tree_head".
"root_hash" is equal to the root hash from the "TreeHeadDataV2" "root_hash" is equal to the root hash from the "TreeHeadDataV2"
structure encapsulated in "merkle_tree_head". structure encapsulated in "merkle_tree_head".
"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.5. 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".
"sth_extensions" is a vector of 0 or more STH extensions. This "sth_extensions" is a vector of 0 or more STH extensions. This
vector MUST NOT include more than one extension with the same vector MUST NOT include more than one extension with the same
"sth_extension_type". The extensions in the vector MUST be ordered "sth_extension_type". The extensions in the vector MUST be ordered
skipping to change at page 23, line 34 skipping to change at page 22, line 28
"tree_size" is the size of the tree on which this inclusion proof is "tree_size" is the size of the tree on which this inclusion proof is
based. based.
"leaf_index" is the 0-based index of the log entry corresponding to "leaf_index" is the 0-based index of the log entry corresponding to
this inclusion proof. this inclusion proof.
"inclusion_path" is a vector of Merkle Tree nodes proving the "inclusion_path" is a vector of Merkle Tree nodes proving the
inclusion of the chosen certificate or precertificate. inclusion of the chosen certificate or precertificate.
5.11. Shutting down a log
Log operators may decide to shut down a log for various reasons, such
as deprecation of the signature algorithm. If there are entries in
the log for certificates that have not yet expired, simply making TLS
clients stop recognizing that log will have the effect of
invalidating SCTs from that log. To avoid that, the following
actions are suggested:
o Make it known to clients and monitors that the log will be frozen.
o Stop accepting new submissions (the error code "shutdown" should
be returned for such requests).
o Once MMD from the last accepted submission has passed and all
pending submissions are incorporated, issue a final STH and
publish it as a part of the log's metadata. Having an STH with a
timestamp that is after the MMD has passed from the last SCT
issuance allows clients to audit this log regularly without
special handling for the final STH. At this point the log's
private key is no longer needed and can be destroyed.
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
scanning other logs or connecting to domains mentioned in the
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 [RFC4627]. 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.
skipping to change at page 25, line 32 skipping to change at page 25, line 5
unknown anchor The last certificate in the chain both is not, and unknown anchor The last certificate in the chain both is not, and
is not certified by, an accepted trust anchor. is not certified by, an accepted trust anchor.
bad chain The alleged chain is not actually a chain of bad chain The alleged chain is not actually a chain of
certificates. certificates.
bad certificate One or more certificates in the chain are not bad certificate One or more certificates in the chain are not
valid (e.g. not properly encoded). valid (e.g. not properly encoded).
shutdown The log has ceased operation and is not accepting new
submissions.
If the version of "sct" is not v2, then a v2 client may be unable to If the version of "sct" is not v2, then a v2 client may be unable to
verify the signature. It MUST NOT construe this as an error. This verify the signature. It MUST NOT construe this as an error. This
is to avoid forcing an upgrade of compliant v2 clients that do not is to avoid forcing an upgrade of compliant v2 clients that do not
use the returned SCTs. use the returned SCTs.
If a log detects bad encoding in a chain that otherwise verifies If a log detects bad encoding in a chain that otherwise verifies
correctly then the log MAY still log the certificate but SHOULD NOT correctly then the log MAY still log the certificate but SHOULD NOT
return an SCT. It should instead return the "bad certificate" error. return an SCT. It should instead return the "bad certificate" error.
Logging the certificate is useful, because monitors (Section 9.3) can Logging the certificate is useful, because monitors (Section 9.3) can
then detect these encoding errors, which may be accepted by some TLS then detect these encoding errors, which may be accepted by some TLS
skipping to change at page 27, line 38 skipping to change at page 27, line 11
See Section 9.4.2 for an outline of how to use the "consistency" See Section 9.4.2 for an outline of how to use the "consistency"
output. output.
6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash 6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash
GET https://<log server>/ct/v2/get-proof-by-hash GET https://<log server>/ct/v2/get-proof-by-hash
Inputs: Inputs:
hash: A base64 encoded v1 leaf hash. hash: A base64 encoded v2 leaf hash.
tree_size: The tree_size of the tree on which to base the proof, tree_size: The tree_size of the tree on which to base the proof,
in decimal. in decimal.
The "hash" must be calculated as defined in Section 5.5. The The "hash" must be calculated as defined in Section 5.5. The
"tree_size" must designate an existing v2 STH. Because of skew, "tree_size" must designate an existing v2 STH. Because of skew,
the front-end may not know the requested STH. In that case, it the front-end may not know the requested STH. In that case, it
will return the latest STH it knows, along with an inclusion proof will return the latest STH it knows, along with an inclusion proof
to that STH. If the front-end knows the requested STH then only to that STH. If the front-end knows the requested STH then only
"inclusion" is returned. "inclusion" is returned.
skipping to change at page 28, line 34 skipping to change at page 28, line 5
See Section 9.4.1 for an outline of how to use the "inclusion" See Section 9.4.1 for an outline of how to use the "inclusion"
output. output.
6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and Consistency 6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and Consistency
Proof by Leaf Hash Proof by Leaf Hash
GET https://<log server>/ct/v2/get-all-by-hash GET https://<log server>/ct/v2/get-all-by-hash
Inputs: Inputs:
hash: A base64 encoded v1 leaf hash. hash: A base64 encoded v2 leaf hash.
tree_size: The tree_size of the tree on which to base the proofs, tree_size: The tree_size of the tree on which to base the proofs,
in decimal. in decimal.
The "hash" must be calculated as defined in Section 5.5. The The "hash" must be calculated as defined in Section 5.5. The
"tree_size" must designate an existing v2 STH. "tree_size" must designate an existing v2 STH.
Because of skew, the front-end may not know the requested STH or Because of skew, the front-end may not know the requested STH or
the requested hash, which leads to a number of cases. the requested hash, which leads to a number of cases.
skipping to change at page 30, line 18 skipping to change at page 29, line 38
"precert_sct" corresponding to this log entry. Note that "precert_sct" corresponding to this log entry. Note that
more than one SCT may have been returned for the same entry more than one SCT may have been returned for the same entry
- only one of those is returned in this field. It may not - only one of those is returned in this field. It may not
be possible to retrieve others. be possible to retrieve others.
sth: A base64 encoded "TransItem" of type "signed_tree_head", sth: A base64 encoded "TransItem" of type "signed_tree_head",
signed by this log. signed by this log.
Note that this message is not signed -- the "entries" data can be Note that this message is not signed -- the "entries" data can be
verified by constructing the Merkle Tree Hash corresponding to a verified by constructing the Merkle Tree Hash corresponding to a
retrieved STH. All leaves MUST be v1 or v2. However, a compliant v1 retrieved STH. All leaves MUST be v2. However, a compliant v2
client MUST NOT construe an unrecognized LogEntryType value as an client MUST NOT construe an unrecognized TransItem type as an error.
error. This means it may be unable to parse some entries, but note This means it may be unable to parse some entries, but note that each
that each client can inspect the entries it does recognize as well as client can inspect the entries it does recognize as well as verify
verify the integrity of the data by treating unrecognized leaves as the integrity of the data by treating unrecognized leaves as opaque
opaque input to the tree. input to the tree.
The "start" and "end" parameters SHOULD be within the range 0 <= x < The "start" and "end" parameters SHOULD be within the range 0 <= x <
"tree_size" as returned by "get-sth" in Section 6.3. "tree_size" as returned by "get-sth" in Section 6.3.
The "start" parameter MUST be less than or equal to the "end" The "start" parameter MUST be less than or equal to the "end"
parameter. parameter.
Log servers MUST honor requests where 0 <= "start" < "tree_size" and Log servers MUST honor requests where 0 <= "start" < "tree_size" and
"end" >= "tree_size" by returning a partial response covering only "end" >= "tree_size" by returning a partial response covering only
the valid entries in the specified range. "end" >= "tree_size" could the valid entries in the specified range. "end" >= "tree_size" could
skipping to change at page 31, line 30 skipping to change at page 30, line 49
7. TLS Servers 7. TLS Servers
TLS servers MUST use at least one of the three mechanisms listed TLS servers MUST use at least one of the three mechanisms listed
below to present one or more SCTs or inclusion proofs from one or below to present one or more SCTs or inclusion proofs from one or
more logs to each TLS client during TLS handshakes, where each SCT or more logs to each TLS client during TLS handshakes, where each SCT or
inclusion proof corresponds to the server certificate or to a name- inclusion proof corresponds to the server certificate or to a name-
constrained intermediate the server certificate chains to. Three constrained intermediate the server certificate chains to. Three
mechanisms are provided because they have different tradeoffs. mechanisms are provided because they have different tradeoffs.
o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type
"transparency_info" (see Section 7.1). This mechanism allows TLS "transparency_info" (see Section 7.2). This mechanism allows TLS
servers to participate in CT without the cooperation of CAs, servers to participate in CT without the cooperation of CAs,
unlike the other two mechanisms. It also allows SCTs and unlike the other two mechanisms. It also allows SCTs and
inclusion proofs to be updated on the fly. inclusion proofs to be updated on the fly.
o An Online Certificate Status Protocol (OCSP) [RFC6960] response o An Online Certificate Status Protocol (OCSP) [RFC6960] response
extension (see Section 8.1.1), where the OCSP response is provided extension (see Section 8.1.1), where the OCSP response is provided
in the "CertificateStatus" message, provided that the TLS client in the "CertificateStatus" message, provided that the TLS client
included the "status_request" extension in the (extended) included the "status_request" extension in the (extended)
"ClientHello" (Section 8 of [RFC6066]). This mechanism, popularly "ClientHello" (Section 8 of [RFC6066]). This mechanism, popularly
known as OCSP stapling, is already widely (but not universally) known as OCSP stapling, is already widely (but not universally)
skipping to change at page 32, line 5 skipping to change at page 31, line 25
o An X509v3 certificate extension (see Section 8.1.2). This o An X509v3 certificate extension (see Section 8.1.2). This
mechanism allows the use of unmodified TLS servers, but the SCTs mechanism allows the use of unmodified TLS servers, but the SCTs
and inclusion proofs cannot be updated on the fly. Since the logs and inclusion proofs cannot be updated on the fly. Since the logs
from where the SCTs and inclusion proofs originated won't from where the SCTs and inclusion proofs originated won't
necessarily be accepted by TLS clients for the full lifetime of necessarily be accepted by TLS clients for the full lifetime of
the certificate, there is a risk that TLS clients will the certificate, there is a risk that TLS clients will
subsequently consider the certificate to be non-compliant and in subsequently consider the certificate to be non-compliant and in
need of re-issuance. need of re-issuance.
Additionally, a TLS server which supports presenting SCTs using an
OCSP response MAY provide it when the TLS client included the
"status_request_v2" extension ([RFC6961]) in the (extended)
"ClientHello", but only in addition to at least one of the three
mechanisms listed above.
7.1. Multiple SCTs or inclusion proofs
TLS servers SHOULD send SCTs or inclusion proofs from multiple logs TLS servers SHOULD send SCTs or inclusion proofs from multiple logs
in case one or more logs are not acceptable to the TLS client (for in case one or more logs are not acceptable to the TLS client (for
example, if a log has been struck off for misbehavior, has had a key example, if a log has been struck off for misbehavior, has had a key
compromise, or is not known to the TLS client). compromise, or is not known to the TLS client). For example:
o If a CA and a log collude, it is possible to temporarily hide
misissuance from clients. Including SCTs or inclusion proofs from
different logs makes it more difficult to mount this attack.
o If a log misbehaves, a consequence may be that clients cease to
trust it. Since the time an SCT or inclusion proof may be in use
can be considerable (several years is common in current practice
when embedded in a certificate), servers may wish to reduce the
probability of their certificates being rejected as a result by
including SCTs or inclusion proofs from different logs.
o TLS clients may have policies related to the above risks requiring
servers to present multiple SCTs or inclusion proofs. For
example, at the time of writing, Chromium [Chromium.Log.Policy]
requires multiple SCTs to be presented with EV certificates in
order for the EV indicator to be shown.
To select the logs from which to obtain SCTs, a TLS server can, for
example, examine the set of logs popular TLS clients accept and
recognize.
Multiple SCTs, inclusion proofs, and indeed "TransItem" structures of Multiple SCTs, inclusion proofs, and indeed "TransItem" structures of
any type, are combined into a list as follows: any type, are combined into a list as follows:
opaque SerializedTransItem<1..2^16-1>; opaque SerializedTransItem<1..2^16-1>;
struct { struct {
SerializedTransItem trans_item_list<1..2^16-1>; SerializedTransItem trans_item_list<1..2^16-1>;
} TransItemList; } TransItemList;
Here, "SerializedTransItem" is an opaque byte string that contains Here, "SerializedTransItem" is an opaque byte string that contains
the serialized "TransItem" structure. This encoding ensures that TLS the serialized "TransItem" structure. This encoding ensures that TLS
clients can decode each "TransItem" individually (so, for example, if clients can decode each "TransItem" individually (so, for example, if
there is a version upgrade, out-of-date clients can still parse old there is a version upgrade, out-of-date clients can still parse old
"TransItem" structures while skipping over new "TransItem" structures "TransItem" structures while skipping over new "TransItem" structures
whose versions they don't understand). whose versions they don't understand).
TODO: We need to define at least one ItemExtensionType for 7.2. TLS Extension
associating SCT and inclusion proof TransItems with the relevant
certificate.
7.1. TLS Extension
If a TLS client includes the "transparency_info" extension type in Provided that a TLS client includes the "transparency_info" extension
the ClientHello, the TLS server MAY include the "transparency_info" type in the ClientHello, the TLS server MAY include the
extension in the ServerHello with "extension_data" set to a "transparency_info" extension in the ServerHello with
"TransItemList". The TLS server is not expected to process or "extension_data" set to a "TransItemList". The TLS server SHOULD
include this extension when a TLS session is resumed, since session ignore any "extension_data" sent by the TLS client. Additionally,
resumption uses the original session information. the TLS server MUST NOT process or include this extension when a TLS
session is resumed, since session resumption uses the original
session information.
8. Certification Authorities 8. Certification Authorities
8.1. Transparency Information X.509v3 Extension 8.1. Transparency Information X.509v3 Extension
The Transparency Information X.509v3 extension, which has OID
One or more "TransItem" structures can be embedded in the 1.3.101.75 and SHOULD be non-critical, contains one or more
Transparency Information X.509v3 extension, which has OID <TBD> and "TransItem" structures in a "TransItemList". This extension MAY be
SHOULD be non-critical. This extension can be included in OCSP included in OCSP responses (see Section 8.1.1) and certificates (see
responses and certificates. Since RFC5280 requires the "extnValue" Section 8.1.2). Since RFC5280 requires the "extnValue" field (an
field (an OCTET STRING) of each X.509v3 extension to include the DER OCTET STRING) of each X.509v3 extension to include the DER encoding
encoding of an ASN.1 value, we cannot embed a "TransItemList" of an ASN.1 value, a "TransItemList" MUST NOT be included directly.
directly. Instead, we have to wrap it inside an additional OCTET Instead, it MUST be wrapped inside an additional OCTET STRING, which
STRING, which we then put into the "extnValue" field: is then put into the "extnValue" field:
TransparencyInformationSyntax ::= OCTET STRING TransparencyInformationSyntax ::= OCTET STRING
"TransparencyInformationSyntax" contains a "TransItemList". "TransparencyInformationSyntax" contains a "TransItemList".
8.1.1. OCSP Response Extension 8.1.1. OCSP Response Extension
A certification authority may include a Transparency Information A certification authority MAY include a Transparency Information
X.509v3 extension in the "singleExtensions" of a "SingleResponse" in X.509v3 extension in the "singleExtensions" of a "SingleResponse" in
an OCSP response. The included SCTs or inclusion proofs MUST be for an OCSP response. The included SCTs or inclusion proofs MUST be for
the certificate identified by the "certID" of that "SingleResponse", the certificate identified by the "certID" of that "SingleResponse",
or for a precertificate that corresponds to that certificate, or for or for a precertificate that corresponds to that certificate, or for
a name-constrained intermediate to which that certificate chains. a name-constrained intermediate to which that certificate chains.
8.1.2. Certificate Extension 8.1.2. Certificate Extension
A certification authority may include a Transparency Information A certification authority MAY include a Transparency Information
X.509v3 extension in a certificate. Any included SCTs or inclusion X.509v3 extension in a certificate. Any included SCTs or inclusion
proofs MUST be either for a precertificate that corresponds to this proofs MUST be either for a precertificate that corresponds to this
certificate, or for a name-constrained intermediate to which this certificate, or for a name-constrained intermediate to which this
certificate chains. certificate chains.
8.2. TLS Feature Extension
A certification authority MAY include the transparency_info
(Section 7.2) TLS extension identifier in the TLS Feature [RFC7633]
certificate extension in root, intermediate and end-entity
certificates. When a certificate chain includes such a certificate,
this indicates that CT compliance is required.
9. Clients 9. Clients
There are various different functions clients of logs might perform. There are various different functions clients of logs might perform.
We describe here some typical clients and how they should function. We describe here some typical clients and how they should function.
Any inconsistency may be used as evidence that a log has not behaved Any inconsistency may be used as evidence that a log has not behaved
correctly, and the signatures on the data structures prevent the log correctly, and the signatures on the data structures prevent the log
from denying that misbehavior. from denying that misbehavior.
All clients need various metadata in order to communicate with logs All clients need various metadata in order to communicate with logs
and verify their responses. This metadata is described below, but and verify their responses. This metadata is described below, but
skipping to change at page 34, line 34 skipping to change at page 35, line 7
Final STH If a log has been closed down (i.e. no longer accepts new Final STH If a log has been closed down (i.e. no longer accepts new
entries), existing entries may still be valid. In this case, the entries), existing entries may still be valid. In this case, the
client should know the final valid STH in the log to ensure no new client should know the final valid STH in the log to ensure no new
entries can be added without detection. entries can be added without detection.
[JSON.Metadata] is an example of a metadata format which includes the [JSON.Metadata] is an example of a metadata format which includes the
above elements. above elements.
9.2. TLS Client 9.2. TLS Client
TLS clients receive SCTs alongside or in certificates, either for the 9.2.1. Receiving SCTs or inclusion proofs
server certificate itself or for a name-constrained intermediate the
server certificate chains to. TLS clients MUST implement all of the
three mechanisms by which TLS servers may present SCTs (see
Section 7). TLS clients that support the "transparency_info" TLS
extension SHOULD include it in ClientHello messages, with
"extension_data" set to <TBD>.
TODO: What should the TLS client communicate in the extension_data? TLS clients receive SCTs or inclusion proofs alongside or in
Version(s) of CT that it supports? Certain types of TransItem that certificates. TLS clients MUST implement all of the three mechanisms
it can handle? Whether or not it wants to gossip? by which TLS servers may present SCTs (see Section 7). TLS clients
MAY also accept SCTs via the "status_request_v2" extension
([RFC6961]). TLS clients that support the "transparency_info" TLS
extension SHOULD include it in ClientHello messages, with empty
"extension_data".
In addition to normal validation of the certificate and its chain, 9.2.2. Reconstructing the TBSCertificate
TLS clients SHOULD validate each supplied SCT by computing the
signature input from the SCT data as well as the certificate and
verifying the signature, using the corresponding log's public key.
TLS clients MUST reject SCTs whose timestamp is in the future.
TLS clients SHOULD also validate each supplied inclusion proof (see To reconstruct the TBSCertificate component of a precertificate from
Section 9.4.1), in order to audit the log. If no inclusion proof was a certificate, TLS clients should:
supplied by the TLS server, the TLS client MAY request one directly
from the corresponding log using "get-proof-by-hash" (Section 6.5) or
"get-all-by-hash" (Section 6.6), and then validate it.
To be considered compliant, a certificate MUST be accompanied by at o Remove the non-critical extension mentioned in Section 4.2
least one valid SCT or at least one valid inclusion proof. A
certificate not accompanied by any valid SCTs or any valid inclusion o Replace leftmost labels of each DNS-ID with "?", based on the
proofs MUST NOT be considered compliant by TLS clients. However, INTEGER value corresponding to that DNS-ID in the extension.
specifying the TLS clients' behavior once compliance or non-
compliance has been determined (for example, whether a certificate A certificate with redacted labels where one of the redacted labels
should be rejected due to non-compliance) is outside the scope of is "*" MUST NOT be considered compliant.
this document.
If the SCT checked is for a Precertificate (where the "type" of the
"TransItem" is "precert_sct"), then the client SHOULD also remove
embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (See
Section 3.3. of [RFC6962]), in the process of reconstructing the
TBSCertificate. That is to allow embedded v1 and v2 SCTs to co-exist
in a certificate (See Appendix A).
9.2.3. Validating SCTs
In addition to normal validation of the server certificate and its
chain, TLS clients SHOULD validate each received SCT for which they
have the corresponding log's metadata. To validate an SCT, a TLS
client computes the signature input from the SCT data and the
corresponding certificate, and then verifies the signature using the
corresponding log's public key. TLS clients MUST NOT consider valid
any SCT whose timestamp is in the future.
Before considering any SCT to be invalid, the TLS client MUST attempt
to validate it against the server certificate and against each of the
zero or more suitable name-constrained intermediates (Section 4.3) in
the chain. These certificates may be evaluated in the order they
appear in the chain, or, indeed, in any order.
9.2.4. Validating inclusion proofs
TLS clients SHOULD also verify each received inclusion proof (see
Section 9.4.1) for which they have the corresponding log's metadata,
to audit the log and gain confidence that the certificate is logged.
Before considering any inclusion proof to be invalid, the TLS client
MUST attempt to validate it against the server certificate and
against each of the zero or more suitable name-constrained
intermediates (Section 4.3) in the chain. These certificates may be
evaluated in the order they appear in the chain, or, indeed, in any
order.
After validating a received SCT, a TLS client MAY request a
corresponding inclusion proof (if one is not already available) and
then verify it. An inclusion proof can be requested directly from a
log using "get-proof-by-hash" (Section 6.5) or "get-all-by-hash"
(Section 6.6), but note that this will disclose to the log which TLS
server the client has been communicating with.
If the TLS client holds an STH that predates the SCT, it MAY, in the If the TLS client holds an STH that predates the SCT, it MAY, in the
process of auditing, request a new STH from the log (Section 6.3), process of auditing, request a new STH from the log (Section 6.3),
then verify it by requesting a consistency proof (Section 6.4). Note then verify it by requesting a consistency proof (Section 6.4). Note
that if the TLS client uses "get-all-by-hash", then it will already that if the TLS client uses "get-all-by-hash", then it will already
have the new STH. have the new STH.
9.2.5. Evaluating compliance
To be considered compliant, a certificate MUST be accompanied by at
least one valid SCT or at least one valid inclusion proof. A
certificate not accompanied by any valid SCTs or any valid inclusion
proofs MUST NOT be considered compliant by TLS clients.
9.2.6. TLS Feature Extension
If any certificate in a chain includes the transparency_info
(Section 7.2) TLS extension identifier in the TLS Feature [RFC7633]
certificate extension, then CT compliance (using any of the
mechanisms from Section 7) is required.
TLS clients MUST treat certificates which fail this requirement as
non-compliant.
9.2.7. Handling of Non-compliance
If a TLS server presents a certificate chain that is non-compliant,
there are two possibilities.
o In the case that use of TLS with a valid certificate is mandated
by explicit security policy, application protocol specification,
or other means, the TLS client MUST refuse the connection.
o If the use of TLS with a valid certificate is optional, the TLS
client MAY accept the connection but MUST NOT treat the
certificate as valid.
9.3. Monitor 9.3. Monitor
Monitors watch logs and check that they behave correctly. Monitors Monitors watch logs to check that they behave correctly, for
may additionally watch for certificates of interest. For example, a certificates of interest, or both. For example, a monitor may be
monitor may be configured to report on all certificates that apply to configured to report on all certificates that apply to a specific
a specific domain name when fetching new entries for consistency domain name when fetching new entries for consistency validation.
validation.
A monitor needs to, at least, inspect every new entry in each log it A monitor needs to, at least, inspect every new entry in each log it
watches. It may also want to keep copies of entire logs. In order watches. It may also want to keep copies of entire logs. In order
to do this, it should follow these steps for each log: to do this, it should follow these steps for each log:
1. Fetch the current STH (Section 6.3). 1. Fetch the current STH (Section 6.3).
2. Verify the STH signature. 2. Verify the STH signature.
3. Fetch all the entries in the tree corresponding to the STH 3. Fetch all the entries in the tree corresponding to the STH
skipping to change at page 36, line 29 skipping to change at page 38, line 14
2. Verify the consistency proof. 2. Verify the consistency proof.
3. Verify that the new entries generate the corresponding 3. Verify that the new entries generate the corresponding
elements in the consistency proof. elements in the consistency proof.
9. Go to Step 5. 9. Go to Step 5.
9.4. Auditing 9.4. Auditing
Auditing is taking partial information about a log as input and Auditing ensures that the current published state of a log is
verifying that this information is consistent with other partial reachable from previously published states that are known to be good,
information held. All clients described above may perform auditing and that the promises made by the log in the form of SCTs have been
as an additional function. The action taken by the client if audit kept. Audits are performed by monitors or TLS clients.
fails is not specified, but note that in general if audit fails, the
client is in possession of signed proof of the log's misbehavior. A benign, conformant log publishes a series of STHs over time, each
derived from the previous STH and the submitted entries incorporated
into the log since publication of the previous STH. This can be
proven through auditing of STHs. SCTs returned to TLS clients can be
audited by verifying against the accompanying certificate, and using
Merkle Inclusion Proofs, against the log's Merkle tree.
The action taken by the auditor if an audit fails is not specified,
but note that in general if audit fails, the auditor is in possession
of signed proof of the log's misbehavior.
A monitor (Section 9.3) can audit by verifying the consistency of A monitor (Section 9.3) can audit by verifying the consistency of
STHs it receives, ensure that each entry can be fetched and that the STHs it receives, ensure that each entry can be fetched and that the
STH is indeed the result of making a tree from all fetched entries. STH is indeed the result of making a tree from all fetched entries.
A TLS client (Section 9.2) can audit by verifying an SCT against any A TLS client (Section 9.2) can audit by verifying an SCT against any
STH dated after the SCT timestamp + the Maximum Merge Delay by STH dated after the SCT timestamp + the Maximum Merge Delay by
requesting a Merkle inclusion proof (Section 6.5). It can also requesting a Merkle inclusion proof (Section 6.5). It can also
verify that the SCT corresponds to the certificate it arrived with verify that the SCT corresponds to the certificate it arrived with
(i.e. the log entry is that certificate, is a precertificate for that (i.e. the log entry is that certificate, is a precertificate for that
skipping to change at page 37, line 12 skipping to change at page 39, line 5
The following algorithm outlines may be useful for clients that wish The following algorithm outlines may be useful for clients that wish
to perform various audit operations. to perform various audit operations.
9.4.1. Verifying an inclusion proof 9.4.1. Verifying an inclusion proof
When a client has received a "TransItem" of type "inclusion_proof" When a client has received a "TransItem" of type "inclusion_proof"
and wishes to verify inclusion of an input "hash" for an STH with a and wishes to verify inclusion of an input "hash" for an STH with a
given "tree_size" and "root_hash", the following algorithm may be given "tree_size" and "root_hash", the following algorithm may be
used to prove the "hash" was included in the "root_hash": used to prove the "hash" was included in the "root_hash":
1. Set "fn" to "leaf_index" and "sn" to "tree_size - 1". 1. Compare "leaf_index" against "tree_size". If "leaf_index" is
greater than or equal to "tree_size" fail the proof verification.
2. Set "r" to "hash". 2. Set "fn" to "leaf_index" and "sn" to "tree_size - 1".
3. For each value "p" in the "inclusion_path" array: 3. Set "r" to "hash".
4. For each value "p" in the "inclusion_path" array:
If "LSB(fn)" is set, or if "fn" is equal to "sn", then: If "LSB(fn)" is set, or if "fn" is equal to "sn", then:
1. Set "r" to "HASH(0x01 || p || r)" 1. Set "r" to "HASH(0x01 || p || r)"
2. If "LSB(fn)" is not set, then right-shift both "fn" and "sn" 2. If "LSB(fn)" is not set, then right-shift both "fn" and "sn"
equally until either "LSB(fn)" is set or "fn" is "0". equally until either "LSB(fn)" is set or "fn" is "0".
Otherwise: Otherwise:
Set "r" to "HASH(0x01 || r || p)" Set "r" to "HASH(0x01 || r || p)"
Finally, right-shift both "fn" and "sn" one time. Finally, right-shift both "fn" and "sn" one time.
4. Compare "r" against the "root_hash". If they are equal, then the 5. Compare "sn" to 0. Compare "r" against the "root_hash". If "sn"
log has proven the inclusion of "hash". is equal to 0, and "r" and the "root_hash" are equal, then the
log has proven the inclusion of "hash". Otherwise, fail the
proof verification.
9.4.2. Verifying consistency between two STHs 9.4.2. Verifying consistency between two STHs
When a client has an STH "first_hash" for tree size "first", an STH When a client has an STH "first_hash" for tree size "first", an STH
"second_hash" for tree size "second" where "0 < first < second", and "second_hash" for tree size "second" where "0 < first < second", and
has received a "TransItem" of type "consistency_proof" that they wish has received a "TransItem" of type "consistency_proof" that they wish
to use to verify both hashes, the following algorithm may be used: to use to verify both hashes, the following algorithm may be used:
1. If "first" is an exact power of 2, then prepend "first_hash" to 1. If "first" is an exact power of 2, then prepend "first_hash" to
the "consistency_path" array. the "consistency_path" array.
skipping to change at page 39, line 16 skipping to change at page 41, line 12
merge procedure (Step 2.3 above) until only a single element merge procedure (Step 2.3 above) until only a single element
remains. remains.
4. The remaining element in "stack" is the Merkle Tree hash for the 4. The remaining element in "stack" is the Merkle Tree hash for the
given "tree_size" and should be compared by equality against the given "tree_size" and should be compared by equality against the
supplied "root_hash". supplied "root_hash".
10. Algorithm Agility 10. Algorithm Agility
It is not possible for a log to change any of its algorithms part way It is not possible for a log to change any of its algorithms part way
through its lifetime. If it should become necessary to deprecate an through its lifetime:
algorithm used by a live log, then the log should be frozen as
specified in Section 9.1 and a new log should be started. If Signature algorithm: SCT signatures must remain valid so signature
necessary, the new log can contain existing entries from the frozen algorithms can only be added, not removed.
log, which monitors can verify are an exact match.
Hash algorithm: A log would have to support the old and new hash
algorithms to allow backwards-compatibility with clients that are
not aware of a hash algorithm change.
Allowing multiple signature or hash algorithms for a log would
require that all data structures support it and would significantly
complicate client implementation, which is why it is not supported by
this document.
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
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
new log and the SCTs from that log used instead.
11. IANA Considerations 11. IANA Considerations
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. Hash Algorithms 11.2. Hash Algorithms
IANA is asked to establish a registry of hash values, initially IANA is asked to establish a registry of hash values, initially
consisting of: consisting of:
+-------+----------------------+ +-------+----------------------+
| Index | Hash | | Index | Hash |
+-------+----------------------+ +-------+----------------------+
| 0 | SHA-256 [FIPS.180-4] | | 0 | SHA-256 [FIPS.180-4] |
+-------+----------------------+ +-------+----------------------+
11.3. TransItem Extensions 11.3. Signature Algorithms
IANA is asked to establish a registry of TransItem extensions,
initially consisting of:
+-------+-----------+
| Type | Extension |
+-------+-----------+
| 65535 | reserved |
+-------+-----------+
TBD: policy for adding to the registry
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: initially consisting of:
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Index | Signature Algorithm | | Index | Signature Algorithm |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 0 | deterministic ECDSA [RFC6979] using the NIST P-256 curve | | 0 | deterministic ECDSA [RFC6979] using the NIST P-256 curve |
| | (Section D.1.2.3 of the Digital Signature Standard [DSS]) | | | (Section D.1.2.3 of the Digital Signature Standard [DSS]) |
| | and HMAC-SHA256 | | | and HMAC-SHA256 |
| 1 | RSA signatures (RSASSA-PKCS1-v1_5 with SHA-256, Section | | 1 | RSA signatures (RSASSA-PKCS1-v1_5 with SHA-256, Section |
| | 8.2 of [RFC3447]) using a key of at least 2048 bits. | | | 8.2 of [RFC3447]) using a key of at least 2048 bits. |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
11.5. SCT Extensions 11.4. SCT Extensions
IANA is asked to establish a registry of SCT extensions, initially IANA is asked to establish a registry of SCT extensions, initially
consisting of: consisting of:
+-------+-----------+ +-------+-----------+
| Type | Extension | | Type | Extension |
+-------+-----------+ +-------+-----------+
| 65535 | reserved | | 65535 | reserved |
+-------+-----------+ +-------+-----------+
TBD: policy for adding to the registry TBD: policy for adding to the registry
11.6. STH Extensions 11.5. STH Extensions
IANA is asked to establish a registry of STH extensions, initially IANA is asked to establish a registry of STH extensions, initially
consisting of: consisting of:
+-------+-----------+ +-------+-----------+
| Type | Extension | | Type | Extension |
+-------+-----------+ +-------+-----------+
| 65535 | reserved | | 65535 | reserved |
+-------+-----------+ +-------+-----------+
TBD: policy for adding to the registry TBD: policy for adding to the registry
11.6. Object Identifiers
This document uses object identifiers (OIDs) to identify Log IDs (see
Section 5.3), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see
Section 4.2, Section 4.3 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.
11.6.1. Log ID Registry 1
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
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.6.2. Log ID Registry 2
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
have an encoded length of only 4 octets.
IANA is requested to establish a registry that will allocate Log IDs
from this arc.
TBD: policy for adding to the registry. Perhaps "Expert Review"?
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
action, such as asking a CA to revoke a misissued certificate, or action, such as asking a CA to revoke a misissued certificate, or
skipping to change at page 41, line 33 skipping to change at page 44, line 21
the Maximum Merge Delay, assuming the log is operating correctly. the Maximum Merge Delay, assuming the log is operating correctly.
Thus, the maximum period of time during which a misissued certificate Thus, the maximum period of time during which a misissued certificate
can be used without being available for audit is the MMD. can be used without being available for audit is the MMD.
12.2. Detection of Misissue 12.2. Detection of Misissue
The logs do not themselves detect misissued certificates; they rely The logs do not themselves detect misissued certificates; they rely
instead on interested parties, such as domain owners, to monitor them instead on interested parties, such as domain owners, to monitor them
and take corrective action when a misissue is detected. and take corrective action when a misissue is detected.
12.3. Redaction of Public Domain Name Labels 12.3. Avoiding Overly Redacting Domain Name Labels
CAs SHOULD NOT redact domain name labels in precertificates such that Redaction of domain name labels carries the same risks as the use of
the entirety of the domain space below the unredacted part of the wildcards (See Section 7.2 of [RFC6125], for example). If the
domain name is not owned or controlled by a single entity (e.g. entirety of the domain space below the unredacted part of a domain
"?.com" and "?.co.uk" would both be problematic). Logs MUST NOT name is not controlled by a single entity (e.g. "?.com", "?.co.uk"
reject any precertificate that is overly redacted but which is and other public suffixes [Public.Suffix.List]), then the domain name
otherwise considered compliant. It is expected that monitors will may be considered by clients to be overly redacted.
treat overly redacted precertificates as potentially misissued. TLS
clients MAY reject a certificate whose corresponding precertificate CAs should take care to avoid overly redacting domain names in
would be overly redacted, perhaps using the same mechanism for precertificates. It is expected that monitors will treat
determining whether a wildcard in a domain name of a certificate is precertificates that contain overly redacted domain names as
too broad. potentially misissued. TLS clients MAY consider a certificate to be
non-compliant if the reconstructed TBSCertificate (Section 9.2.2)
contains any overly redacted domain names.
12.4. Misbehaving Logs 12.4. Misbehaving Logs
A log can misbehave in two ways: (1) by failing to incorporate a A log can misbehave in several ways. Examples include failing to
certificate with an SCT in the Merkle Tree within the MMD and (2) by incorporate a certificate with an SCT in the Merkle Tree within the
violating its append-only property by presenting two different, MMD or by presenting different, conflicting views of the Merkle Tree
conflicting views of the Merkle Tree at different times and/or to at different times and/or to different parties. Such misbehavior is
different parties. Both forms of violation will be promptly and detectable and the [I-D.ietf-trans-threat-analysis] provides more
publicly detectable. details on how this can be done.
Violation of the MMD contract is detected by log clients requesting a Violation of the MMD contract is detected by log clients requesting a
Merkle audit proof for each observed SCT. These checks can be Merkle inclusion proof (Section 6.5) for each observed SCT. These
asynchronous and need only be done once per each certificate. In checks can be asynchronous and need only be done once per each
order to protect the clients' privacy, these checks need not reveal certificate. In order to protect the clients' privacy, these checks
the exact certificate to the log. Clients can instead request the need not reveal the exact certificate to the log. Clients can
proof from a trusted auditor (since anyone can compute the audit instead request the proof from a trusted auditor (since anyone can
proofs from the log) or request Merkle proofs for a batch of compute the proofs from the log) or request Merkle inclusion proofs
certificates around the SCT timestamp. for a batch of certificates around the SCT timestamp.
Violation of the append-only property can be detected by clients Violation of the append-only property can be detected by clients
comparing their instances of the Signed Tree Heads. As soon as two comparing their instances of the Signed Tree Heads. As soon as two
conflicting Signed Tree Heads for the same log are detected, this is conflicting Signed Tree Heads for the same log are detected, this is
cryptographic proof of that log's misbehavior. There are various cryptographic proof of that log's misbehavior. There are various
ways this could be done, for example via gossip (see http:// ways this could be done, for example via gossip (see
trac.tools.ietf.org/id/draft-linus-trans-gossip-00.txt) or peer-to- [I-D.ietf-trans-gossip]) or peer-to-peer communications or by sending
peer communications or by sending STHs to monitors (who could then STHs to monitors (who could then directly check against their own
directly check against their own copy of the relevant log). copy of the relevant log).
12.5. Deterministic Signatures 12.5. Deterministic Signatures
Logs are required to use deterministic signatures for the following Logs are required to use deterministic signatures for the following
reasons: reasons:
o Using non-deterministic ECDSA with a predictable source of o Using non-deterministic ECDSA with a predictable source of
randomness means that each signature can potentially expose the randomness means that each signature can potentially expose the
secret material of the signing key. secret material of the signing key.
o Clients that gossip STHs or report back SCTs can be tracked or o Clients that gossip STHs or report back SCTs can be tracked or
traced if a log was to produce multiple STHs or SCTs with the same traced if a log was to produce multiple STHs or SCTs with the same
timestamp and data but different signatures. timestamp and data but different signatures.
12.6. Multiple SCTs 12.6. Multiple SCTs or inclusion proofs
TLS servers may wish to offer multiple SCTs, each from a different
log.
o If a CA and a log collude, it is possible to temporarily hide By offering multiple SCTs or inclusion proofs, each from a different
misissuance from clients. Including SCTs from different logs log, TLS servers reduce the effectiveness of an attack where a CA and
makes it more difficult to mount this attack. a log collude (see Section 7.1).
o If a log misbehaves, a consequence may be that clients cease to 12.7. Threat Analysis
trust it. Since the time an SCT may be in use can be considerable
(several years is common in current practice when the SCT is
embedded in a certificate), servers may wish to reduce the
probability of their certificates being rejected as a result by
including SCTs from different logs.
o TLS clients may have policies related to the above risks requiring [I-D.ietf-trans-threat-analysis] provides a more detailed threat
servers to present multiple SCTs. For example Chromium analysis of the Certificate Transparency architecture.
[Chromium.Log.Policy] currently requires multiple SCTs to be
presented with EV certificates in order for the EV indicator to be
shown.
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Erwann Abelea, Robin Alden, Al The authors would like to thank Erwann Abelea, Robin Alden, Al
Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn
Gillmor, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Gillmor, Paul Hadfield, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey
Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer, Hutzelman, Kat Joyce, Stephen Kent, SM, Alexey Melnikov, Linus
Trevor Perrin, Pierre Phaneuf, Melinda Shore, Ryan Sleevi, Carl Nordberg, Chris Palmer, Trevor Perrin, Pierre Phaneuf, Melinda Shore,
Wallace and Paul Wouters for their valuable contributions. Ryan Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their
valuable contributions.
A big thank you to Symantec for kindly donating the OIDs from the
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 [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 2009, Signature Standard (DSS)", FIPS 186-3, June 2009,
<http://csrc.nist.gov/publications/fips/fips186-3/ <http://csrc.nist.gov/publications/fips/fips186-3/
fips_186-3.pdf>. fips_186-3.pdf>.
skipping to change at page 44, line 42 skipping to change at page 47, line 24
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, March 2011. Security (TLS)", RFC 6125, March 2011.
[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)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>. 2013, <http://www.rfc-editor.org/info/rfc6979>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>.
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-security/certificate-transparency/log-policy>. chromium-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/
skipping to change at page 45, line 23 skipping to change at page 48, line 18
Security Symposium, Montreal, August 2009, Security Symposium, Montreal, August 2009,
<http://static.usenix.org/event/sec09/tech/full_papers/ <http://static.usenix.org/event/sec09/tech/full_papers/
crosby.pdf>. crosby.pdf>.
[EVSSLGuidelines] [EVSSLGuidelines]
CA/Browser Forum, "Guidelines For The Issuance And CA/Browser Forum, "Guidelines For The Issuance And
Management Of Extended Validation Certificates", 2007, Management Of Extended Validation Certificates", 2007,
<https://cabforum.org/wp-content/uploads/ <https://cabforum.org/wp-content/uploads/
EV_Certificate_Guidelines.pdf>. EV_Certificate_Guidelines.pdf>.
[I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-01 (work in progress),
October 2015.
[I-D.ietf-trans-threat-analysis]
Kent, S., "Attack Model and Threat for Certificate
Transparency", draft-ietf-trans-threat-analysis-03 (work
in progress), October 2015.
[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>.
[Public.Suffix.List]
Mozilla Foundation, "Public Suffix List", 2016, <https://
publicsuffix.org>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013. Transparency", RFC 6962, June 2013.
Appendix A. TransItemV1 Appendix A. Supporting v1 and v2 simultaneously
TODO: Finish writing this section. Or should it be in a separate Certificate Transparency logs have to be either v1 (conforming to
document? [RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid
v1 SCT.
struct { CT clients, however, can support v1 and v2 SCTs, for the same
TransType type; certificate, simultaneously, as v1 SCTs are delivered in different
select (type) { TLS, X.509 and OCSP extensions than v2 SCTs.
case x509_sct: SignedCertificateTimestampV1;
case precert_sct: SignedCertificateTimestampV1;
case signed_tree_head: SignedTreeHeadDataV1;
case consistency_proof: ConsistencyProofDataV1;
case inclusion_proof: InclusionProofDataV1;
} data;
} TransItemV1;
opaque SHA256Hash[32]; v1 and v2 SCTs for X.509 certificates can be validated independently.
For precertificates, v2 SCTs should be embedded in the TBSCertificate
before submission of the TBSCertificate (inside a v1 precertificate,
as described in Section 3.1. of [RFC6962]) to a v1 log so that TLS
clients conforming to [RFC6962] but not this document are oblivious
to the embedded v2 SCTs. An issuer can follow these steps to produce
an X.509 certificate with embedded v1 and v2 SCTs:
struct { o Create a CMS precertificate as described in Section 3.2 and submit
Version version = v1; it to v2 logs.
SHA256Hash log_id;
uint64 timestamp;
SctExtensions extensions;
digitally-signed struct {
Version version = v1;
uint8 signature_type = 0; /* "certificate_timestamp" */
uint64 timestamp;
TransType type; /* x509_entry(0) or precert_entry(1) */
select (type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
SctExtensions extensions;
} signature;
} SignedCertificateTimestampV1;
struct { o Embed the obtained v2 SCTs in the TBSCertificate, as described in
SHA256Hash log_id; Section 8.1.2.
uint64 timestamp;
uint64 tree_size;
SHA256Hash sha256_root_hash;
digitally-signed struct {
Version version = v1;
uint8 signature_type = 1; /* "tree_hash" */
uint64 timestamp;
uint64 tree_size;
SHA256Hash sha256_root_hash;
} signature;
} SignedTreeHeadDataV1; o Use that TBSCertificate to create a v1 precertificate, as
described in Section 3.1. of [RFC6962] and submit it to v1 logs.
struct { o Embed the v1 SCTs in the TBSCertificate, as described in
SHA256Hash log_id; Section 3.3. of [RFC6962].
uint64 tree_size_1;
uint64 tree_size_2;
SHA256Hash consistency_path<1..2^8-1>;
} ConsistencyProofDataV1;
struct { o Sign that TBSCertificate (which now contains v1 and v2 SCTs) to
SHA256Hash log_id; issue the final X.509 certificate.
uint64 tree_size;
uint64 leaf_index;
SHA256Hash inclusion_path<1..2^8-1>;
} InclusionProofDataV1;
Authors' Addresses Authors' Addresses
Ben Laurie Ben Laurie
Google UK Ltd. Google UK Ltd.
EMail: benl@google.com EMail: benl@google.com
Adam Langley Adam Langley
Google Inc. Google Inc.
 End of changes. 94 change blocks. 
344 lines changed or deleted 507 lines changed or added

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