draft-ietf-trans-rfc6962-bis-13.txt   draft-ietf-trans-rfc6962-bis-14.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: September 22, 2016 E. Messeri Expires: October 13, 2016 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
March 21, 2016 April 11, 2016
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-13 draft-ietf-trans-rfc6962-bis-14
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 September 22, 2016. This Internet-Draft will expire on October 13, 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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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. Redaction of Domain Name Labels . . . . . . . . . . . . . 11
4.2.1. Redacting Labels in Precertificates . . . . . . . . . 12
4.2.2. Redacted Labels Certificate Extension . . . . . . . . 12
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. TransItem Structure . . . . . . . . . . . . . . . . . . . 16
5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 17 5.5. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 17
5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 18 5.6. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 18
5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 19 5.7. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 19
5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 19 5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 19
5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 21 5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 21
5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 21 5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 21
5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 22 5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 22
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 22
6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 24 6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 24
6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 25 6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 25
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . 27 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 28
6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29 6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29
6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 30 6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 30
7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Multiple SCTs or inclusion proofs . . . . . . . . . . . . 31 7.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 31
7.2. TLS Extension . . . . . . . . . . . . . . . . . . . . . . 32 7.2. TransItemList Structure . . . . . . . . . . . . . . . . . 32
8. Certification Authorities . . . . . . . . . . . . . . . . . . 32 7.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 32
8.1. Transparency Information X.509v3 Extension . . . . . . . 32 7.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 33
8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 33 7.5. transparency_info TLS Extension . . . . . . . . . . . . . 33
8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 33 8. Certification Authorities . . . . . . . . . . . . . . . . . . 33
8.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 33 8.1. Transparency Information X.509v3 Extension . . . . . . . 34
9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 34
9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 34
9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 34
9.2.1. Receiving SCTs or inclusion proofs . . . . . . . . . 35 9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2.2. Reconstructing the TBSCertificate . . . . . . . . . . 35 9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 35 9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 36
9.2.4. Validating inclusion proofs . . . . . . . . . . . . . 36 9.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 36
9.2.5. Evaluating compliance . . . . . . . . . . . . . . . . 36 9.2.2. Reconstructing the TBSCertificate . . . . . . . . . . 36
9.2.6. TLS Feature Extension . . . . . . . . . . . . . . . . 36 9.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 36
9.2.7. Handling of Non-compliance . . . . . . . . . . . . . 36 9.2.4. Validating inclusion proofs . . . . . . . . . . . . . 37
9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.2.5. Evaluating compliance . . . . . . . . . . . . . . . . 37
9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 38 9.2.6. TLS Feature Extension . . . . . . . . . . . . . . . . 37
9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 38 9.2.7. Handling of Non-compliance . . . . . . . . . . . . . 37
9.4.2. Verifying consistency between two STHs . . . . . . . 39 9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4.3. Verifying root hash given entries . . . . . . . . . . 40 9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 39
10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 41 9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 9.4.2. Verifying consistency between two STHs . . . . . . . 40
11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 41 9.4.3. Verifying root hash given entries . . . . . . . . . . 41
11.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 41 10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 42
11.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 42 11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 43
11.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 42 11.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 43
11.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 42 11.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 43
11.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 43 11.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 43
11.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 43 11.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 44
12. Security Considerations . . . . . . . . . . . . . . . . . . . 43 11.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 44
12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 44 11.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 44
12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 44 11.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 44
12.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 44 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45
12.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 44 12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 45
12.5. Deterministic Signatures . . . . . . . . . . . . . . . . 45 12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 45
12.6. Multiple SCTs or inclusion proofs . . . . . . . . . . . 45 12.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 45
12.7. Threat Analysis . . . . . . . . . . . . . . . . . . . . 45 12.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 46
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 12.5. Deterministic Signatures . . . . . . . . . . . . . . . . 46
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 12.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 47
14.1. Normative References . . . . . . . . . . . . . . . . . . 46 12.7. Threat Analysis . . . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . 47 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 49 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Normative References . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 51
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 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.3 section. signature algorithms defined in the Section 11.3.
3. Submitters 3. Submitters
Submitters submit certificates or preannouncements of certificates Submitters submit certificates or preannouncements of certificates
prior to issuance (precertificates) to logs for public auditing, as prior to issuance (precertificates) to logs for public auditing, as
described below. In order to enable attribution of each logged described below. In order to enable attribution of each logged
certificate or precertificate to its issuer, each submission MUST be certificate or precertificate to its issuer, each submission MUST be
accompanied by all additional certificates required to verify the accompanied by all additional certificates required to verify the
chain up to an accepted trust anchor. The trust anchor (a root or chain up to an accepted trust anchor. The trust anchor (a root or
intermediate CA certificate) MAY be omitted from the submission. intermediate CA certificate) MAY be omitted from the submission.
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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. Examples of situations where returned SCT in the issued certificate. Examples of situations where
the returned SCT is not incorporated into the issued certificate the returned SCT is not incorporated into the issued certificate
would be when a CA sends the precertificate to multiple logs, but would be when a CA sends the precertificate to multiple logs, but
only incorporates the SCTs that are returned first, or the CA is only incorporates the SCTs that are returned first, or the CA is
using domain name redaction and intends to use another mechanism to using domain name redaction (Section 4.2) and intends to use another
publish SCTs (such as an OCSP response (Section 8.1.1) or the TLS mechanism to publish SCTs (such as an OCSP response (Section 8.1.1)
extension (Section 7.2)). or the TLS extension (Section 7.5)).
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 o "SignedData.encapContentInfo.eContentType" MUST be the OID
1.3.101.78. 1.3.101.78.
o "SignedData.encapContentInfo.eContent" MUST contain a o "SignedData.encapContentInfo.eContent" MUST contain a
skipping to change at page 11, line 47 skipping to change at page 11, line 47
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]), a different approach is needed when more than one of the [RFC6125]), a different approach is needed when more than one of the
leftmost labels in a DNS-ID are considered private (e.g. leftmost labels in a DNS-ID are considered private (e.g.
"top.secret.example.com"). Also, wildcard certificates are "top.secret.example.com"). Also, wildcard certificates are
prohibited in some cases, such as Extended Validation Certificates prohibited in some cases, such as Extended Validation Certificates
[EVSSLGuidelines]. [EVSSLGuidelines].
4.2. Redacting Domain Name Labels in Precertificates 4.2. Redaction of Domain Name Labels
4.2.1. Redacting 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 and CN-ID [RFC6125] with a corresponding number
Every label to the left of a "?" label MUST also be redacted. For of "?" labels. Every label to the left of a "?" label MUST also be
example, if a certificate contains a DNS-ID of redacted. For 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 DNS-ID in the
contain "?.?.example.com" instead, but not "top.?.example.com" precertificate could contain "?.?.example.com" instead, but not
instead. "top.?.example.com" instead.
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 or CN-ID is "*", it is considered redacted
purposes of determining if the label to the right may be redacted. for the purposes of determining if the label to the right may be
For example, if a certificate contains a DNS-ID of redacted. 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 DNS-ID in the
could contain "*.?.?.example.com" instead, but not precertificate could contain "*.?.?.example.com" instead, but not
"?.?.?.example.com" instead. "?.?.?.example.com" instead.
When a precertificate contains one or more redacted labels, a non- 4.2.2. Redacted Labels Certificate Extension
critical extension (OID 1.3.101.77, whose extnValue OCTET STRING
contains an ASN.1 SEQUENCE OF INTEGERs) MUST be added to the
corresponding certificate: the first INTEGER indicates the total
number of "?" labels in the precertificate's first DNS-ID; the second
INTEGER does the same for the precertificate's second DNS-ID; etc.
There MUST NOT be more INTEGERs than there are DNS-IDs. If there are
fewer INTEGERs than there are DNS-IDs, the shortfall is made up by
implicitly repeating the last INTEGER. Each INTEGER MUST have a
value of zero or more. The purpose of this extension is to enable
TLS clients to reconstruct the TBSCertificate component of the
precertificate from the certificate, as described in Section 9.2.2.
When a precertificate contains that extension and contains a CN-ID When a precertificate contains one or more "?" labels, a non-critical
[RFC6125], the CN-ID MUST match the first DNS-ID and have the same extension (OID 1.3.101.77, whose extnValue OCTET STRING contains an
labels redacted. TLS clients will use the first entry in the ASN.1 SEQUENCE OF INTEGERs) MUST be added to the corresponding
SEQUENCE OF INTEGERs to reconstruct both the first DNS-ID and the CN- certificate. The purpose of this extension is to enable TLS clients
ID. to reconstruct the TBSCertificate component of the precertificate
from the certificate, as described in Section 9.2.2.
Each INTEGER MUST have a value of zero or more. The first INTEGER
indicates the total number of "?" labels in the precertificate's
first DNS-ID; the second INTEGER does the same for the
precertificate's second DNS-ID; etc. The last INTEGER does the same
for the precertificate's zero or more CN-IDs. There MUST NOT be more
INTEGERs than there are DNS-IDs (plus one, if any CN-IDs are
present); if there are fewer INTEGERs than this, the shortfall is
made up by implicitly repeating the last INTEGER.
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 1.3.101.76, whose o there MUST be a non-critical extension (OID 1.3.101.76, whose
skipping to change at page 13, line 42 skipping to change at page 13, line 47
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 SHOULD return the log has previously seen this valid submission, it SHOULD return the
same SCT as it returned before (to reduce the ability to track same SCT as it returned before (to reduce the ability to track
clients as described in Section 12.5). Note that if a certificate clients as described in Section 12.5). Note that if a certificate
was previously logged as a precertificate, then the precertificate's was previously logged as a precertificate, then the precertificate's
SCT of type "precert_sct" would not be appropriate; instead, a fresh SCT of type "precert_sct_v2" would not be appropriate; instead, a
SCT of type "x509_sct" should be generated. fresh SCT of type "x509_sct_v2" should be generated.
An SCT is the log's promise to incorporate the submitted entry in its An SCT is the log's promise to incorporate the submitted entry in its
Merkle Tree no later than a fixed amount of time, known as the Merkle Tree no later than a fixed amount of time, known as the
Maximum Merge Delay (MMD), after the issuance of the SCT. Maximum Merge Delay (MMD), after the issuance of the SCT.
Periodically, the log MUST append all its new entries to its Merkle Periodically, the log MUST append all its new entries to its Merkle
Tree and sign the root of the tree. Tree and sign the root of the tree.
Log operators MUST NOT impose any conditions on retrieving or sharing Log operators MUST NOT impose any conditions on retrieving or sharing
data from the log. data from the log.
5.1. Accepting Submissions 5.1. Accepting Submissions
Logs MUST verify that each submitted certificate or precertificate Logs MUST verify that each submitted certificate or precertificate
has a valid signature chain to an accepted trust anchor, using the has a valid signature chain to an accepted trust anchor, using the
skipping to change at page 16, line 10 skipping to change at page 16, line 10
include the DER encoding of this OID, excluding the ASN.1 tag and include the DER encoding of this OID, excluding the ASN.1 tag and
length bytes, in an opaque vector: 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. TransItem Structure
Various data structures produced by logs are encapsulated in the
"TransItem" structure to ensure that the type and version of each one
is identified in a common fashion:
enum { Various data structures are encapsulated in the "TransItem" structure
v1(0), v2(1), (255) to ensure that the type and version of each one is identified in a
} Version; common fashion:
enum { enum {
x509_entry(0), precert_entry(1), x509_sct(2), precert_sct(3), reserved(0),
tree_head(4), signed_tree_head(5), consistency_proof(6), x509_entry_v2(1), precert_entry_v2(2),
inclusion_proof(7), (65535) x509_sct_v2(3), precert_sct_v2(4),
} TransType; tree_head_v2(5), signed_tree_head_v2(6),
consistency_proof_v2(7), inclusion_proof_v2(8),
x509_sct_with_proof_v2(9), precert_sct_with_proof_v2(10),
(65535)
} VersionedTransType;
struct { struct {
Version version; VersionedTransType versioned_type;
TransType type; select (versioned_type) {
select (type) { case x509_entry_v2: TimestampedCertificateEntryDataV2;
case x509_entry: TimestampedCertificateEntryDataV2; case precert_entry_v2: TimestampedCertificateEntryDataV2;
case precert_entry: TimestampedCertificateEntryDataV2; case x509_sct_v2: SignedCertificateTimestampDataV2;
case x509_sct: SignedCertificateTimestampDataV2; case precert_sct_v2: SignedCertificateTimestampDataV2;
case precert_sct: SignedCertificateTimestampDataV2; case tree_head_v2: TreeHeadDataV2;
case tree_head: TreeHeadDataV2; case signed_tree_head_v2: SignedTreeHeadDataV2;
case signed_tree_head: SignedTreeHeadDataV2; case consistency_proof_v2: ConsistencyProofDataV2;
case consistency_proof: ConsistencyProofDataV2; case inclusion_proof_v2: InclusionProofDataV2;
case inclusion_proof: InclusionProofDataV2; case x509_sct_with_proof_v2: SCTWithProofDataV2;
case precert_sct_with_proof_v2: SCTWithProofDataV2;
} data; } data;
} TransItem; } TransItem;
"version" is the earliest version of this protocol to which the "versioned_type" is the type of the encapsulated data structure and
encapsulated data structure conforms. This document is v2. Note the earliest version of this protocol to which it conforms. This
that v1 [RFC6962] did not define "TransItem", but this document document is v2.
provides guidelines (see Appendix A) on how v2 implementations can
co-exist with v1 implementations. Note also that, since each
"TransItem" object is individually versioned, the version should be
increased only if changes to it are made that are not backwards-
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
"TransType" combines the v1 type enumerations "LogEntryType",
"SignatureType" and "MerkleLeafType"). Future revisions of this
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.
Note that "VersionedTransType" combines the v1 [RFC6962] type
enumerations "Version", "LogEntryType", "SignatureType" and
"MerkleLeafType". Note also that v1 did not define "TransItem", but
this document provides guidelines (see Appendix A) on how v2
implementations can co-exist with v1 implementations.
Future versions of this protocol may reuse "VersionedTransType"
values defined in this document as long as the corresponding data
structures are not modified, and may add new "VersionedTransType"
values for new or modified data structures.
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_v2" or "precert_entry_v2",
in this version (v2) encapsulates a which encapsulates a "TimestampedCertificateEntryDataV2" structure.
"TimestampedCertificateEntryDataV2" structure. Note that leaf hashes Note that leaf hashes are calculated as HASH(0x00 || TransItem),
are calculated as HASH(0x00 || TransItem), where the hashing where the hashing algorithm is specified in the log's metadata.
algorithm is specified in the log's metadata.
opaque TBSCertificate<1..2^24-1>; opaque TBSCertificate<1..2^24-1>;
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;
skipping to change at page 18, line 7 skipping to change at page 18, line 7
"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
corresponding certificate as described in Section 9.2.2). corresponding certificate as described in Section 9.2.2).
"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_v2" or
"precert_sct", which in this version (v2) encapsulates a "precert_sct_v2", which encapsulates a
"SignedCertificateTimestampDataV2" structure: "SignedCertificateTimestampDataV2" structure:
enum { enum {
reserved(65535) reserved(65535)
} SctExtensionType; } SctExtensionType;
struct { struct {
SctExtensionType sct_extension_type; SctExtensionType sct_extension_type;
opaque sct_extension_data<0..2^16-1>; opaque sct_extension_data<0..2^16-1>;
} SctExtension; } SctExtension;
skipping to change at page 19, line 8 skipping to change at page 19, line 8
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
by the value of the "sct_extension_type" field, smallest value first. by the value of the "sct_extension_type" field, smallest value first.
If an implementation sees an extension that it does not understand, If an implementation sees an extension that it does not understand,
it SHOULD ignore that extension. Furthermore, an implementation MAY it SHOULD ignore that extension. Furthermore, an implementation MAY
choose to ignore any extension(s) that it does understand. choose to ignore any extension(s) that it does understand.
The encoding of the digitally-signed element is defined in [RFC5246]. The encoding of the digitally-signed element is defined in [RFC5246].
"timestamped_entry" is a "TransItem" structure that MUST be of type "timestamped_entry" is a "TransItem" structure that MUST be of type
"x509_entry" or "precert_entry" (see Section 5.5) and MUST have an "x509_entry_v2" or "precert_entry_v2" (see Section 5.5).
empty "item_extensions" vector.
5.7. Merkle Tree Head 5.7. Merkle Tree Head
The log stores information about its Merkle Tree in a "TransItem" The log stores information about its Merkle Tree in a "TransItem"
structure of type "tree_head", which in this version (v2) structure of type "tree_head_v2", which encapsulates a
encapsulates a "TreeHeadDataV2" structure: "TreeHeadDataV2" structure:
opaque NodeHash[HASH_SIZE]; opaque NodeHash[HASH_SIZE];
struct { struct {
uint64 timestamp; uint64 timestamp;
uint64 tree_size; uint64 tree_size;
NodeHash root_hash; NodeHash root_hash;
SthExtension sth_extensions<0..2^16-1>; SthExtension sth_extensions<0..2^16-1>;
} TreeHeadDataV2; } TreeHeadDataV2;
skipping to change at page 20, line 5 skipping to change at page 20, line 5
(see Section 5.7) to produce an STH. When a client requests a log's (see Section 5.7) to produce an STH. When a client requests a log's
latest STH (see Section 6.3), the log MUST return an STH that is no latest STH (see Section 6.3), the log MUST return an STH that is no
older than the log's MMD. However, STHs could be used to mark older than the log's MMD. However, STHs could be used to mark
individual clients (by producing a new one for each query), so logs individual clients (by producing a new one for each query), so logs
MUST NOT produce them more frequently than is declared in their MUST NOT produce them more frequently than is declared in their
metadata. In general, there is no need to produce a new STH unless metadata. In general, there is no need to produce a new STH unless
there are new entries in the log; however, in the unlikely event that there are new entries in the log; however, in the unlikely event that
it receives no new submissions during an MMD period, the log SHALL it receives no new submissions during an MMD period, the log SHALL
sign the same Merkle Tree Hash with a fresh timestamp. sign the same Merkle Tree Hash with a fresh timestamp.
An STH is a "TransItem" structure of type "signed_tree_head", which An STH is a "TransItem" structure of type "signed_tree_head_v2",
in this version (v2) encapsulates a "SignedTreeHeadDataV2" structure: which encapsulates a "SignedTreeHeadDataV2" structure:
enum { enum {
reserved(65535) reserved(65535)
} SthExtensionType; } SthExtensionType;
struct { struct {
SthExtensionType sth_extension_type; SthExtensionType sth_extension_type;
opaque sth_extension_data<0..2^16-1>; opaque sth_extension_data<0..2^16-1>;
} SthExtension; } SthExtension;
skipping to change at page 21, line 14 skipping to change at page 21, line 14
"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
by the value of the "sth_extension_type" field, smallest value first. by the value of the "sth_extension_type" field, smallest value first.
If an implementation sees an extension that it does not understand, If an implementation sees an extension that it does not understand,
it SHOULD ignore that extension. Furthermore, an implementation MAY it SHOULD ignore that extension. Furthermore, an implementation MAY
choose to ignore any extension(s) that it does understand. choose to ignore any extension(s) that it does understand.
"merkle_tree_head" is a "TransItem" structure that MUST be of type "merkle_tree_head" is a "TransItem" structure that MUST be of type
"tree_head" (see Section 5.7) and MUST have an empty "tree_head_v2" (see Section 5.7).
"item_extensions" vector.
5.9. Merkle Consistency Proofs 5.9. Merkle Consistency Proofs
To prepare a Merkle Consistency Proof for distribution to clients, To prepare a Merkle Consistency Proof for distribution to clients,
the log produces a "TransItem" structure of type "consistency_proof", the log produces a "TransItem" structure of type
which in this version (v2) encapsulates a "ConsistencyProofDataV2" "consistency_proof_v2", which encapsulates a "ConsistencyProofDataV2"
structure: structure:
struct { struct {
LogID log_id; LogID log_id;
uint64 tree_size_1; uint64 tree_size_1;
uint64 tree_size_2; uint64 tree_size_2;
NodeHash consistency_path<1..2^8-1>; NodeHash consistency_path<1..2^8-1>;
} ConsistencyProofDataV2; } ConsistencyProofDataV2;
"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
skipping to change at page 22, line 4 skipping to change at page 21, line 41
described in Section 5.3. described in Section 5.3.
"tree_size_1" is the size of the older tree. "tree_size_1" is the size of the older tree.
"tree_size_2" is the size of the newer tree. "tree_size_2" is the size of the newer tree.
"consistency_path" is a vector of Merkle Tree nodes proving the "consistency_path" is a vector of Merkle Tree nodes proving the
consistency of two STHs. consistency of two STHs.
5.10. Merkle Inclusion Proofs 5.10. Merkle Inclusion Proofs
To prepare a Merkle Inclusion Proof for distribution to clients, the To prepare a Merkle Inclusion Proof for distribution to clients, the
log produces a "TransItem" structure of type "inclusion_proof", which log produces a "TransItem" structure of type "inclusion_proof_v2",
in this version (v2) encapsulates an "InclusionProofDataV2" which encapsulates an "InclusionProofDataV2" structure:
structure:
struct { struct {
LogID log_id; LogID log_id;
uint64 tree_size; uint64 tree_size;
uint64 leaf_index; uint64 leaf_index;
NodeHash inclusion_path<1..2^8-1>; NodeHash inclusion_path<1..2^8-1>;
} InclusionProofDataV2; } InclusionProofDataV2;
"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.
skipping to change at page 24, line 40 skipping to change at page 24, line 34
Inputs: Inputs:
chain: An array of base64 encoded certificates. The first chain: An array of base64 encoded certificates. The first
element is the certificate for which the submitter desires an element is the certificate for which the submitter desires an
SCT; the second certifies the first and so on to the last, SCT; the second certifies the first and so on to the last,
which either is, or is certified by, an accepted trust anchor. which either is, or is certified by, an accepted trust anchor.
Outputs: Outputs:
sct: A base64 encoded "TransItem" of type "x509_sct", signed by sct: A base64 encoded "TransItem" of type "x509_sct_v2", signed
this log, that corresponds to the submitted certificate. by this log, that corresponds to the submitted certificate.
Error codes: Error codes:
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
skipping to change at page 25, line 40 skipping to change at page 25, line 34
precertificate: The base64 encoded precertificate. precertificate: The base64 encoded precertificate.
chain: An array of base64 encoded CA certificates. The first chain: An array of base64 encoded CA certificates. The first
element is the signer of the precertificate; the second element is the signer of the precertificate; the second
certifies the first and so on to the last, which either is, or certifies the first and so on to the last, which either is, or
is certified by, an accepted trust anchor. is certified by, an accepted trust anchor.
Outputs: Outputs:
sct: A base64 encoded "TransItem" of type "precert_sct", signed sct: A base64 encoded "TransItem" of type "precert_sct_v2",
by this log, that corresponds to the submitted precertificate. signed by this log, that corresponds to the submitted
precertificate.
Errors are the same as in Section 6.1. Errors are the same as in Section 6.1.
6.3. Retrieve Latest Signed Tree Head 6.3. Retrieve Latest Signed Tree Head
GET https://<log server>/ct/v2/get-sth GET https://<log server>/ct/v2/get-sth
No inputs. No inputs.
Outputs: Outputs:
sth: A base64 encoded "TransItem" of type "signed_tree_head", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log, that is no older than the log's MMD. signed by this log, that is no older than the log's MMD.
6.4. Retrieve Merkle Consistency Proof between Two Signed Tree Heads 6.4. Retrieve Merkle Consistency Proof between Two Signed Tree Heads
GET https://<log server>/ct/v2/get-sth-consistency GET https://<log server>/ct/v2/get-sth-consistency
Inputs: Inputs:
first: The tree_size of the older tree, in decimal. first: The tree_size of the older tree, in decimal.
skipping to change at page 26, line 30 skipping to change at page 26, line 27
existing STHs. If both are known, then only the "consistency" existing STHs. If both are known, then only the "consistency"
output is returned. If the first is known but the second is not output is returned. If the first is known but the second is not
(or has been omitted), then the latest known STH is returned, (or has been omitted), then the latest known STH is returned,
along with a consistency proof between the first STH and the along with a consistency proof between the first STH and the
latest. If neither are known, then the latest known STH is latest. If neither are known, then the latest known STH is
returned without a consistency proof. returned without a consistency proof.
Outputs: Outputs:
consistency: A base64 encoded "TransItem" of type consistency: A base64 encoded "TransItem" of type
"consistency_proof", whose "tree_size_1" MUST match the "first" "consistency_proof_v2", whose "tree_size_1" MUST match the
input. If the "sth" output is omitted, then "tree_size_2" MUST "first" input. If the "sth" output is omitted, then
match the "second" input. "tree_size_2" MUST match the "second" input.
sth: A base64 encoded "TransItem" of type "signed_tree_head", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
Note that no signature is required for the "consistency" output as Note that no signature is required for the "consistency" output as
it is used to verify the consistency between two STHs, which are it is used to verify the consistency between two STHs, which are
signed. signed.
Error codes: Error codes:
first unknown "first" is before the latest known STH but is not first unknown "first" is before the latest known STH but is not
from an existing STH. from an existing STH.
skipping to change at page 27, line 25 skipping to change at page 27, line 25
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.
Outputs: Outputs:
inclusion: A base64 encoded "TransItem" of type "inclusion_proof" inclusion: A base64 encoded "TransItem" of type
whose "inclusion_path" array of Merkle Tree nodes proves the "inclusion_proof_v2" whose "inclusion_path" array of Merkle
inclusion of the chosen certificate in the selected STH. Tree nodes proves the inclusion of the chosen certificate in
the selected STH.
sth: A base64 encoded "TransItem" of type "signed_tree_head", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
Note that no signature is required for the "inclusion" output as Note that no signature is required for the "inclusion" output as
it is used to verify inclusion in the selected STH, which is it is used to verify inclusion in the selected STH, which is
signed. signed.
Error codes: Error codes:
hash unknown "hash" is not the hash of a known leaf (may be hash unknown "hash" is not the hash of a known leaf (may be
caused by skew or by a known certificate not yet merged). caused by skew or by a known certificate not yet merged).
skipping to change at page 28, line 30 skipping to change at page 28, line 37
index of requested hash < latest STH Return "inclusion". index of requested hash < latest STH Return "inclusion".
Note that more than one case can be true, in which case the Note that more than one case can be true, in which case the
returned data is their concatenation. It is also possible for returned data is their concatenation. It is also possible for
none to be true, in which case the front-end MUST return an empty none to be true, in which case the front-end MUST return an empty
response. response.
Outputs: Outputs:
inclusion: A base64 encoded "TransItem" of type "inclusion_proof" inclusion: A base64 encoded "TransItem" of type
whose "inclusion_path" array of Merkle Tree nodes proves the "inclusion_proof_v2" whose "inclusion_path" array of Merkle
inclusion of the chosen certificate in the selected STH. Tree nodes proves the inclusion of the chosen certificate in
the selected STH.
sth: A base64 encoded "TransItem" of type "signed_tree_head", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
consistency: A base64 encoded "TransItem" of type consistency: A base64 encoded "TransItem" of type
"consistency_proof" that proves the consistency of the "consistency_proof_v2" that proves the consistency of the
requested STH and the returned STH. requested STH and the returned STH.
Note that no signature is required for the "inclusion" or Note that no signature is required for the "inclusion" or
"consistency" outputs as they are used to verify inclusion in and "consistency" outputs as they are used to verify inclusion in and
consistency of STHs, which are signed. consistency of STHs, which are signed.
Errors are the same as in Section 6.5. Errors are the same as in Section 6.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, and see Section 9.4.2 for an outline of how to use the output, and see Section 9.4.2 for an outline of how to use the
skipping to change at page 29, line 20 skipping to change at page 29, line 30
start: 0-based index of first entry to retrieve, in decimal. start: 0-based index of first entry to retrieve, in decimal.
end: 0-based index of last entry to retrieve, in decimal. end: 0-based index of last entry to retrieve, in decimal.
Outputs: Outputs:
entries: An array of objects, each consisting of entries: An array of objects, each consisting of
leaf_input: The base64 encoded "TransItem" structure of type leaf_input: The base64 encoded "TransItem" structure of type
"x509_entry" or "precert_entry" (see Section 5.5). "x509_entry_v2" or "precert_entry_v2" (see Section 5.5).
log_entry: The base64 encoded log entry (see Section 5.2). In log_entry: The base64 encoded log entry (see Section 5.2). In
the case of an "x509_entry" entry, this is the whole the case of an "x509_entry_v2" entry, this is the whole
"X509ChainEntry"; and in the case of a "precert_entry", this "X509ChainEntry"; and in the case of a "precert_entry_v2",
is the whole "PrecertChainEntryV2". this is the whole "PrecertChainEntryV2".
sct: A base64 encoded "TransItem" of type "x509_sct" or sct: A base64 encoded "TransItem" of type "x509_sct_v2" or
"precert_sct" corresponding to this log entry. Note that "precert_sct_v2" 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_v2",
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 v2. However, a compliant v2 retrieved STH. All leaves MUST be v2. However, a compliant v2
client MUST NOT construe an unrecognized TransItem type as an error. client MUST NOT construe an unrecognized TransItem type as an error.
This means it may be unable to parse some entries, but note that each This means it may be unable to parse some entries, but note that each
client can inspect the entries it does recognize as well as verify client can inspect the entries it does recognize as well as verify
the integrity of the data by treating unrecognized leaves as opaque the integrity of the data by treating unrecognized leaves as opaque
input to the tree. input to the tree.
skipping to change at page 30, line 42 skipping to change at page 31, line 8
certificates: An array of base64 encoded trust anchors that are certificates: An array of base64 encoded trust anchors that are
acceptable to the log. acceptable to the log.
max_chain: If the server has chosen to limit the length of chains max_chain: If the server has chosen to limit the length of chains
it accepts, this is the maximum number of certificates in the it accepts, this is the maximum number of certificates in the
chain, in decimal. If there is no limit, this is omitted. chain, in decimal. If there is no limit, this is omitted.
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 from one or more logs to each TLS
more logs to each TLS client during TLS handshakes, where each SCT or client during full TLS handshakes, where each SCT corresponds to the
inclusion proof corresponds to the server certificate or to a name- server certificate or to a name-constrained intermediate the server
constrained intermediate the server certificate chains to. Three certificate chains to. TLS servers SHOULD also present corresponding
mechanisms are provided because they have different tradeoffs. inclusion proofs and STHs (see Section 7.3).
Three 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.2). This mechanism allows TLS "transparency_info" (see Section 7.5). 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 31, line 31 skipping to change at page 31, line 46
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 Additionally, a TLS server which supports presenting SCTs using an
OCSP response MAY provide it when the TLS client included the OCSP response MAY provide it when the TLS client included the
"status_request_v2" extension ([RFC6961]) in the (extended) "status_request_v2" extension ([RFC6961]) in the (extended)
"ClientHello", but only in addition to at least one of the three "ClientHello", but only in addition to at least one of the three
mechanisms listed above. mechanisms listed above.
7.1. Multiple SCTs or inclusion proofs 7.1. Multiple SCTs
TLS servers SHOULD send SCTs or inclusion proofs from multiple logs TLS servers SHOULD send SCTs from multiple logs in case one or more
in case one or more logs are not acceptable to the TLS client (for logs are not acceptable to the TLS client (for example, if a log has
example, if a log has been struck off for misbehavior, has had a key been struck off for misbehavior, has had a key compromise, or is not
compromise, or is not known to the TLS client). For example: known to the TLS client). For example:
o If a CA and a log collude, it is possible to temporarily hide o If a CA and a log collude, it is possible to temporarily hide
misissuance from clients. Including SCTs or inclusion proofs from misissuance from clients. Including SCTs from different logs
different logs makes it more difficult to mount this attack. makes it more difficult to mount this attack.
o If a log misbehaves, a consequence may be that clients cease to 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 trust it. Since the time an SCT may be in use can be considerable
can be considerable (several years is common in current practice (several years is common in current practice when embedded in a
when embedded in a certificate), servers may wish to reduce the certificate), servers may wish to reduce the probability of their
probability of their certificates being rejected as a result by certificates being rejected as a result by including SCTs from
including SCTs or inclusion proofs from different logs. different logs.
o TLS clients may have policies related to the above risks requiring o TLS clients may have policies related to the above risks requiring
servers to present multiple SCTs or inclusion proofs. For servers to present multiple SCTs. For example, at the time of
example, at the time of writing, Chromium [Chromium.Log.Policy] writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to
requires multiple SCTs to be presented with EV certificates in be presented with EV certificates in order for the EV indicator to
order for the EV indicator to be shown. be shown.
To select the logs from which to obtain SCTs, a TLS server can, for 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 example, examine the set of logs popular TLS clients accept and
recognize. recognize.
7.2. TransItemList Structure
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).
7.2. TLS Extension 7.3. Presenting SCTs, inclusion proofs and STHs
When constructing a "TransItemList" structure, a TLS server SHOULD
construct and include "TransItem" structures of type
"x509_sct_with_proof_v2" (for an SCT of type "x509_sct_v2") or
"precert_sct_with_proof_v2" (for an SCT of type "precert_sct_v2"),
both of which encapsulate a "SCTWithProofDataV2" structure:
struct {
SignedCertificateTimestampDataV2 sct;
SignedTreeHeadDataV2 sth;
InclusionProofDataV2 inclusion_proof;
} SCTWithProofDataV2;
"sct" is the encapsulated data structure from an SCT that corresponds
to the server certificate or to a name-constrained intermediate the
server certificate chains to.
"sth" is the encapsulated data structure from an STH that was signed
by the same log as "sct".
"inclusion_proof" is the encapsulated data structure from an
inclusion proof that corresponds to "sct" and can be used to compute
the root in "sth".
7.4. Presenting SCTs only
Presenting inclusion proofs and STHs in the TLS handshake helps to
protect the client's privacy (see Section 9.2.4) and reduces load on
log servers. However, if a TLS server is unable to obtain an
inclusion proof and STH that correspond to an SCT, then it MUST
include "TransItem" structures of type "x509_sct_v2" or
"precert_sct_v2" in the "TransItemList".
7.5. transparency_info TLS Extension
Provided that a TLS client includes the "transparency_info" extension Provided that a TLS client includes the "transparency_info" extension
type in the ClientHello, the TLS server MAY include the type in the ClientHello, the TLS server SHOULD include the
"transparency_info" extension in the ServerHello with "transparency_info" extension in the ServerHello with
"extension_data" set to a "TransItemList". The TLS server SHOULD "extension_data" set to a "TransItemList". The TLS server SHOULD
ignore any "extension_data" sent by the TLS client. Additionally, ignore any "extension_data" sent by the TLS client. Additionally,
the TLS server MUST NOT process or include this extension when a TLS the TLS server MUST NOT process or include this extension when a TLS
session is resumed, since session resumption uses the original session is resumed, since session resumption uses the original
session information. 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 The Transparency Information X.509v3 extension, which has OID
1.3.101.75 and SHOULD be non-critical, contains one or more 1.3.101.75 and SHOULD be non-critical, contains one or more
"TransItem" structures in a "TransItemList". This extension MAY be "TransItem" structures in a "TransItemList". This extension MAY be
included in OCSP responses (see Section 8.1.1) and certificates (see included in OCSP responses (see Section 8.1.1) and certificates (see
Section 8.1.2). Since RFC5280 requires the "extnValue" field (an Section 8.1.2). Since RFC5280 requires the "extnValue" field (an
OCTET STRING) of each X.509v3 extension to include the DER encoding OCTET STRING) of each X.509v3 extension to include the DER encoding
of an ASN.1 value, a "TransItemList" MUST NOT be included directly. of an ASN.1 value, a "TransItemList" MUST NOT be included directly.
Instead, it MUST be wrapped inside an additional OCTET STRING, which Instead, it MUST be wrapped inside an additional OCTET STRING, which
is then put into the "extnValue" field: is then put into the "extnValue" field:
skipping to change at page 33, line 38 skipping to change at page 34, line 40
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 8.2. TLS Feature Extension
A certification authority MAY include the transparency_info A certification authority MAY include the transparency_info
(Section 7.2) TLS extension identifier in the TLS Feature [RFC7633] (Section 7.5) TLS extension identifier in the TLS Feature [RFC7633]
certificate extension in root, intermediate and end-entity certificate extension in root, intermediate and end-entity
certificates. When a certificate chain includes such a certificate, certificates. When a certificate chain includes such a certificate,
this indicates that CT compliance is required. 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
skipping to change at page 35, line 7 skipping to change at page 36, 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
9.2.1. Receiving SCTs or inclusion proofs 9.2.1. Receiving SCTs
TLS clients receive SCTs or inclusion proofs alongside or in TLS clients receive SCTs alongside or in certificates. TLS clients
certificates. TLS clients MUST implement all of the three mechanisms MUST implement all of the three mechanisms by which TLS servers may
by which TLS servers may present SCTs (see Section 7). TLS clients present SCTs (see Section 7). TLS clients MAY also accept SCTs via
MAY also accept SCTs via the "status_request_v2" extension the "status_request_v2" extension ([RFC6961]). TLS clients that
([RFC6961]). TLS clients that support the "transparency_info" TLS support the "transparency_info" TLS extension SHOULD include it in
extension SHOULD include it in ClientHello messages, with empty ClientHello messages, with empty "extension_data". TLS clients may
"extension_data". also receive inclusion proofs in addition to SCTs, which should be
checked once the SCTs are validated.
9.2.2. Reconstructing the TBSCertificate 9.2.2. Reconstructing the TBSCertificate
To reconstruct the TBSCertificate component of a precertificate from To reconstruct the TBSCertificate component of a precertificate from
a certificate, TLS clients should: a certificate, TLS clients should:
o Remove the non-critical extension mentioned in Section 4.2 o Remove the Redacted Labels extension described in Section 4.2.2
o Replace leftmost labels of each DNS-ID with "?", based on the o Replace leftmost labels of each DNS-ID with "?", based on the
INTEGER value corresponding to that DNS-ID in the extension. INTEGER value corresponding to that DNS-ID in the extension.
A certificate with redacted labels where one of the redacted labels A certificate with redacted labels where one of the redacted labels
is "*" MUST NOT be considered compliant. is "*" MUST NOT be considered compliant.
If the SCT checked is for a Precertificate (where the "type" of the If the SCT checked is for a Precertificate (where the "type" of the
"TransItem" is "precert_sct"), then the client SHOULD also remove "TransItem" is "precert_sct_v2"), then the client SHOULD also remove
embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (See 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 Section 3.3. of [RFC6962]), in the process of reconstructing the
TBSCertificate. That is to allow embedded v1 and v2 SCTs to co-exist TBSCertificate. That is to allow embedded v1 and v2 SCTs to co-exist
in a certificate (See Appendix A). in a certificate (See Appendix A).
9.2.3. Validating SCTs 9.2.3. Validating SCTs
In addition to normal validation of the server certificate and its In addition to normal validation of the server certificate and its
chain, TLS clients SHOULD validate each received SCT for which they chain, TLS clients SHOULD validate each received SCT for which they
have the corresponding log's metadata. To validate an SCT, a TLS have the corresponding log's metadata. To validate an SCT, a TLS
skipping to change at page 36, line 7 skipping to change at page 37, line 7
any SCT whose timestamp is in the future. any SCT whose timestamp is in the future.
Before considering any SCT to be invalid, the TLS client MUST attempt Before considering any SCT to be invalid, the TLS client MUST attempt
to validate it against the server certificate and against each of the to validate it against the server certificate and against each of the
zero or more suitable name-constrained intermediates (Section 4.3) in zero or more suitable name-constrained intermediates (Section 4.3) in
the chain. These certificates may be evaluated in the order they the chain. These certificates may be evaluated in the order they
appear in the chain, or, indeed, in any order. appear in the chain, or, indeed, in any order.
9.2.4. Validating inclusion proofs 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 After validating a received SCT, a TLS client MAY request a
corresponding inclusion proof (if one is not already available) and corresponding inclusion proof (if one is not already available) and
then verify it. An inclusion proof can be requested directly from a 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" 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 (Section 6.6), but note that this will disclose to the log which TLS
server the client has been communicating with. server the client has been communicating with.
Alternatively, if the TLS client has received an inclusion proof (and
an STH) alongside the SCT, it can proceed to verifying the inclusion
proof to the provided STH. The client then has to verify consistency
between the provided STH and an STH it knows about, which is less
sensitive from a privacy perspective.
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.
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 9.2.5. Evaluating compliance
To be considered compliant, a certificate MUST be accompanied by at To be considered compliant, a certificate MUST be accompanied by at
least one valid SCT or at least one valid inclusion proof. A least one valid SCT. A certificate not accompanied by any valid SCTs
certificate not accompanied by any valid SCTs or any valid inclusion MUST NOT be considered compliant by TLS clients.
proofs MUST NOT be considered compliant by TLS clients.
9.2.6. TLS Feature Extension 9.2.6. TLS Feature Extension
If any certificate in a chain includes the transparency_info If any certificate in a chain includes the transparency_info
(Section 7.2) TLS extension identifier in the TLS Feature [RFC7633] (Section 7.5) TLS extension identifier in the TLS Feature [RFC7633]
certificate extension, then CT compliance (using any of the certificate extension, then CT compliance (using any of the
mechanisms from Section 7) is required. mechanisms from Section 7) is required.
TLS clients MUST treat certificates which fail this requirement as TLS clients MUST treat certificates which fail this requirement as
non-compliant. non-compliant.
9.2.7. Handling of Non-compliance 9.2.7. Handling of Non-compliance
If a TLS server presents a certificate chain that is non-compliant, If a TLS server presents a certificate chain that is non-compliant,
there are two possibilities. there are two possibilities.
skipping to change at page 38, line 19 skipping to change at page 39, line 19
9. Go to Step 5. 9. Go to Step 5.
9.4. Auditing 9.4. Auditing
Auditing ensures that the current published state of a log is Auditing ensures that the current published state of a log is
reachable from previously published states that are known to be good, reachable from previously published states that are known to be good,
and that the promises made by the log in the form of SCTs have been and that the promises made by the log in the form of SCTs have been
kept. Audits are performed by monitors or TLS clients. kept. Audits are performed by monitors or TLS clients.
In particular, there are four log behaviour properties that should be
checked:
o The Maximum Merge Delay (MMD).
o The STH Frequency Count.
o The append-only property.
o The consistency of the log view presented to all query sources.
A benign, conformant log publishes a series of STHs over time, each A benign, conformant log publishes a series of STHs over time, each
derived from the previous STH and the submitted entries incorporated derived from the previous STH and the submitted entries incorporated
into the log since publication of the previous STH. This can be into the log since publication of the previous STH. This can be
proven through auditing of STHs. SCTs returned to TLS clients can be proven through auditing of STHs. SCTs returned to TLS clients can be
audited by verifying against the accompanying certificate, and using audited by verifying against the accompanying certificate, and using
Merkle Inclusion Proofs, against the log's Merkle tree. Merkle Inclusion Proofs, against the log's Merkle tree.
The action taken by the auditor if an audit fails is not specified, 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 but note that in general if audit fails, the auditor is in possession
of signed proof of the log's misbehavior. of signed proof of the log's misbehavior.
skipping to change at page 38, line 42 skipping to change at page 40, line 5
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
certificate or is an appropriate name-constrained intermediate [see certificate or is an appropriate name-constrained intermediate [see
Section 4.3]). Section 4.3]).
Checking of the consistency of the log view presented to all entities
is more difficult to perform because it requires a way to share log
responses among a set of CT-aware entities, and is discussed in
Section 12.4.
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_v2"
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. Compare "leaf_index" against "tree_size". If "leaf_index" is 1. Compare "leaf_index" against "tree_size". If "leaf_index" is
greater than or equal to "tree_size" fail the proof verification. greater than or equal to "tree_size" fail the proof verification.
2. Set "fn" to "leaf_index" and "sn" to "tree_size - 1". 2. Set "fn" to "leaf_index" and "sn" to "tree_size - 1".
3. Set "r" to "hash". 3. Set "r" to "hash".
skipping to change at page 39, line 36 skipping to change at page 40, line 51
5. Compare "sn" to 0. Compare "r" against the "root_hash". If "sn" 5. Compare "sn" to 0. Compare "r" against the "root_hash". If "sn"
is equal to 0, and "r" and the "root_hash" are equal, then the is equal to 0, and "r" and the "root_hash" are equal, then the
log has proven the inclusion of "hash". Otherwise, fail the log has proven the inclusion of "hash". Otherwise, fail the
proof verification. 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_v2" that they
to use to verify both hashes, the following algorithm may be used: wish 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.
2. Set "fn" to "first - 1" and "sn" to "second - 1". 2. Set "fn" to "first - 1" and "sn" to "second - 1".
3. If "LSB(fn)" is set, then right-shift both "fn" and "sn" equally 3. If "LSB(fn)" is set, then right-shift both "fn" and "sn" equally
until "LSB(fn)" is not set. until "LSB(fn)" is not set.
4. Set both "fr" and "sr" to the first value in the 4. Set both "fr" and "sr" to the first value in the
skipping to change at page 42, line 51 skipping to change at page 44, line 23
| 65535 | reserved | | 65535 | reserved |
+-------+-----------+ +-------+-----------+
TBD: policy for adding to the registry TBD: policy for adding to the registry
11.6. Object Identifiers 11.6. Object Identifiers
This document uses object identifiers (OIDs) to identify Log IDs (see This document uses object identifiers (OIDs) to identify Log IDs (see
Section 5.3), the precertificate CMS "eContentType" (see Section 5.3), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see Section 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 4.2.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 Section 8.1.1). The OIDs are defined in an arc that was selected due
to its short encoding. to its short encoding.
11.6.1. Log ID Registry 1 11.6.1. Log ID Registry 1
All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
reserved. This is a limited resource of 8,192 OIDs, each of which reserved. This is a limited resource of 8,192 OIDs, each of which
has an encoded length of 4 octets. has an encoded length of 4 octets.
IANA is requested to establish a registry that will allocate Log IDs IANA is requested to establish a registry that will allocate Log IDs
skipping to change at page 44, line 41 skipping to change at page 46, line 12
precertificates. It is expected that monitors will treat precertificates. It is expected that monitors will treat
precertificates that contain overly redacted domain names as precertificates that contain overly redacted domain names as
potentially misissued. TLS clients MAY consider a certificate to be potentially misissued. TLS clients MAY consider a certificate to be
non-compliant if the reconstructed TBSCertificate (Section 9.2.2) non-compliant if the reconstructed TBSCertificate (Section 9.2.2)
contains any overly redacted domain names. contains any overly redacted domain names.
12.4. Misbehaving Logs 12.4. Misbehaving Logs
A log can misbehave in several ways. Examples include failing to A log can misbehave in several ways. Examples include failing to
incorporate a certificate with an SCT in the Merkle Tree within the incorporate a certificate with an SCT in the Merkle Tree within the
MMD or by presenting different, conflicting views of the Merkle Tree MMD, presenting different, conflicting views of the Merkle Tree at
at different times and/or to different parties. Such misbehavior is different times and/or to different parties and issuing STHs too
detectable and the [I-D.ietf-trans-threat-analysis] provides more frequently. Such misbehavior is detectable and the
details on how this can be done. [I-D.ietf-trans-threat-analysis] provides more 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 inclusion proof (Section 6.5) for each observed SCT. These Merkle inclusion proof (Section 6.5) for each observed SCT. These
checks can be asynchronous and need only be done once per each checks can be asynchronous and need only be done once per each
certificate. In order to protect the clients' privacy, these checks certificate. In order to protect the clients' privacy, these checks
need not reveal the exact certificate to the log. Clients can need not reveal the exact certificate to the log. Instead, clients
instead request the proof from a trusted auditor (since anyone can can request the proof from a trusted auditor (since anyone can
compute the proofs from the log) or request Merkle inclusion proofs compute the proofs from the log) or communicate with the log via
for a batch of certificates around the SCT timestamp. proxies.
Violation of the append-only property can be detected by clients Violation of the append-only property or the STH issuance rate limit
comparing their instances of the Signed Tree Heads. As soon as two can be detected by clients comparing their instances of the Signed
conflicting Signed Tree Heads for the same log are detected, this is Tree Heads. There are various ways this could be done, for example
cryptographic proof of that log's misbehavior. There are various via gossip (see [I-D.ietf-trans-gossip]) or peer-to-peer
ways this could be done, for example via gossip (see communications or by sending STHs to monitors (who could then
[I-D.ietf-trans-gossip]) or peer-to-peer communications or by sending directly check against their own copy of the relevant log). A proof
STHs to monitors (who could then directly check against their own of misbehavior in such cases would be a series of STHs that were
copy of the relevant log). issued too closely together, proving violation of the STH issuance
rate limit, or an STH with a root hash that does not match the one
calculated from a copy of the log, proving violation of the append-
only property.
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 or inclusion proofs 12.6. Multiple SCTs
By offering multiple SCTs or inclusion proofs, each from a different By offering multiple SCTs, each from a different log, TLS servers
log, TLS servers reduce the effectiveness of an attack where a CA and reduce the effectiveness of an attack where a CA and a log collude
a log collude (see Section 7.1). (see Section 7.1).
12.7. Threat Analysis 12.7. Threat Analysis
[I-D.ietf-trans-threat-analysis] provides a more detailed threat [I-D.ietf-trans-threat-analysis] provides a more detailed threat
analysis of the Certificate Transparency architecture. analysis of the Certificate Transparency architecture.
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
 End of changes. 78 change blocks. 
246 lines changed or deleted 310 lines changed or added

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