draft-ietf-trans-rfc6962-bis-15.txt   draft-ietf-trans-rfc6962-bis-16.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: November 27, 2016 E. Messeri Expires: November 28, 2016 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
May 26, 2016 May 27, 2016
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-15 draft-ietf-trans-rfc6962-bis-16
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 November 27, 2016. This Internet-Draft will expire on November 28, 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 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 10
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 11 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 10
4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 12 4. Private Domain Name Labels . . . . . . . . . . . . . . . . . 11
4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 12 4.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 11
4.2. Redaction of Domain Name Labels . . . . . . . . . . . . . 12 4.2. Redaction of Domain Name Labels . . . . . . . . . . . . . 12
4.2.1. Redacting Labels in Precertificates . . . . . . . . . 13 4.2.1. Redacting Labels in Precertificates . . . . . . . . . 12
4.2.2. Redacted Labels Certificate Extension . . . . . . . . 13 4.2.2. Redacted Labels Certificate Extension . . . . . . . . 12
4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 13 4.3. Using a Name-Constrained Intermediate CA . . . . . . . . 12
5. Log Format and Operation . . . . . . . . . . . . . . . . . . 14 5. Log Format and Operation . . . . . . . . . . . . . . . . . . 13
5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 15 5.1. Accepting Submissions . . . . . . . . . . . . . . . . . . 14
5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. TransItem Structure . . . . . . . . . . . . . . . . . . . 17 5.4. 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) . . . . . . . . . . . . . . . . . 20 5.8. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 19
5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 22 5.9. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 21
5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 22 5.10. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 21
5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 23 5.11. Shutting down a log . . . . . . . . . . . . . . . . . . . 22
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 27 6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 26
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 . . . . . . . . . . . . 28
6.8. Get Entry Number for SCT . . . . . . . . . . . . . . . . 31 6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 30
6.9. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 31 7. Optional Client Messages . . . . . . . . . . . . . . . . . . 30
7. Optional Client Messages . . . . . . . . . . . . . . . . . . 32 7.1. Get Entry Number for SCT . . . . . . . . . . . . . . . . 30
7.1. Get Entry Number for SCT . . . . . . . . . . . . . . . . 32 7.2. Get Entry Numbers for Certificate . . . . . . . . . . . . 31
7.2. Get Entry Numbers for Certificate . . . . . . . . . . . . 32 8. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 34 8.2. TransItemList Structure . . . . . . . . . . . . . . . . . 33
8.2. TransItemList Structure . . . . . . . . . . . . . . . . . 34 8.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 33
8.3. Presenting SCTs, inclusion proofs and STHs . . . . . . . 35 8.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 34
8.4. Presenting SCTs only . . . . . . . . . . . . . . . . . . 35 8.5. transparency_info TLS Extension . . . . . . . . . . . . . 34
8.5. transparency_info TLS Extension . . . . . . . . . . . . . 35 9. Certification Authorities . . . . . . . . . . . . . . . . . . 34
9. Certification Authorities . . . . . . . . . . . . . . . . . . 36 9.1. Transparency Information X.509v3 Extension . . . . . . . 34
9.1. Transparency Information X.509v3 Extension . . . . . . . 36 9.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 34
9.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 36 9.1.2. Certificate Extension . . . . . . . . . . . . . . . . 35
9.1.2. Certificate Extension . . . . . . . . . . . . . . . . 36 9.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 35
9.2. TLS Feature Extension . . . . . . . . . . . . . . . . . . 36 10. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 36
10.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38 10.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 36
10.2.1. Receiving SCTs . . . . . . . . . . . . . . . . . . . 38 10.2.2. Reconstructing the TBSCertificate . . . . . . . . . 36
10.2.2. Reconstructing the TBSCertificate . . . . . . . . . 38 10.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . 37
10.2.3. Validating SCTs . . . . . . . . . . . . . . . . . . 38 10.2.4. Validating inclusion proofs . . . . . . . . . . . . 37
10.2.4. Validating inclusion proofs . . . . . . . . . . . . 39 10.2.5. Evaluating compliance . . . . . . . . . . . . . . . 38
10.2.5. Evaluating compliance . . . . . . . . . . . . . . . 39 10.2.6. TLS Feature Extension . . . . . . . . . . . . . . . 38
10.2.6. TLS Feature Extension . . . . . . . . . . . . . . . 39 10.2.7. Handling of Non-compliance . . . . . . . . . . . . . 38
10.2.7. Handling of Non-compliance . . . . . . . . . . . . . 40 10.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . 40 10.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 39
10.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 41 10.4.1. Verifying an inclusion proof . . . . . . . . . . . . 40
10.4.1. Verifying an inclusion proof . . . . . . . . . . . . 42 10.4.2. Verifying consistency between two STHs . . . . . . . 41
10.4.2. Verifying consistency between two STHs . . . . . . . 43 10.4.3. Verifying root hash given entries . . . . . . . . . 42
10.4.3. Verifying root hash given entries . . . . . . . . . 44 11. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43
11. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 12.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 43
12.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 45 12.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 43
12.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 45 12.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 43
12.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 45 12.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 44
12.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 45 12.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 44
12.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 46 12.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 44
12.6. Object Identifiers . . . . . . . . . . . . . . . . . . . 46 12.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 45
12.6.1. Log ID Registry 1 . . . . . . . . . . . . . . . . . 46 12.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 45
12.6.2. Log ID Registry 2 . . . . . . . . . . . . . . . . . 46 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45
13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 13.1. Misissued Certificates . . . . . . . . . . . . . . . . . 45
13.1. Misissued Certificates . . . . . . . . . . . . . . . . . 47 13.2. Detection of Misissue . . . . . . . . . . . . . . . . . 46
13.2. Detection of Misissue . . . . . . . . . . . . . . . . . 47 13.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 46
13.3. Avoiding Overly Redacting Domain Name Labels . . . . . . 47 13.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 46
13.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 48 13.5. Deterministic Signatures . . . . . . . . . . . . . . . . 47
13.5. Deterministic Signatures . . . . . . . . . . . . . . . . 48 13.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 47
13.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 49 13.7. Threat Analysis . . . . . . . . . . . . . . . . . . . . 47
13.7. Threat Analysis . . . . . . . . . . . . . . . . . . . . 49 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 15.1. Normative References . . . . . . . . . . . . . . . . . . 48
15.1. Normative References . . . . . . . . . . . . . . . . . . 49 15.2. Informative References . . . . . . . . . . . . . . . . . 49
15.2. Informative References . . . . . . . . . . . . . . . . . 51 Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 51
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 7, line 14 skipping to change at page 7, line 10
Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., Given an ordered list of n inputs to the tree, D[n] = {d(0), ...,
d(n-1)}, the Merkle inclusion proof PATH(m, D[n]) for the (m+1)th d(n-1)}, the Merkle inclusion proof PATH(m, D[n]) for the (m+1)th
input d(m), 0 <= m < n, is defined as follows: input d(m), 0 <= m < n, is defined as follows:
The proof for the single leaf in a tree with a one-element input list The proof for the single leaf in a tree with a one-element input list
D[1] = {d(0)} is empty: D[1] = {d(0)} is empty:
PATH(0, {d(0)}) = {} PATH(0, {d(0)}) = {}
For n > 1, let k be the largest power of two smaller than n. The For n > 1, let k be the largest power of two smaller than n. The
proof for the (m+1)th element d(m) in a list of n > m elements is proof for the (m+1)th element d(m) in a list of n > m elements is
then defined recursively as then defined recursively as
PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and
PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k, PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k,
where : is concatenation of lists and D[k1:k2] denotes the length (k2 where : is concatenation of lists and D[k1:k2] denotes the length (k2
- k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before.
skipping to change at page 8, line 8 skipping to change at page 8, line 4
MTH(D[0:m]) is known. The initial call to SUBPROOF sets this to be MTH(D[0:m]) is known. The initial call to SUBPROOF sets this to be
true, and SUBPROOF is then defined as follows: true, and SUBPROOF is then defined as follows:
The subproof for m = n is empty if m is the value for which PROOF was The subproof for m = n is empty if m is the value for which PROOF was
originally requested (meaning that the subtree created from D[0:m] is originally requested (meaning that the subtree created from D[0:m] is
a complete subtree of the Merkle Tree created from the original D[n] a complete subtree of the Merkle Tree created from the original D[n]
for which PROOF was requested, and the subtree Merkle Tree Hash for which PROOF was requested, and the subtree Merkle Tree Hash
MTH(D[0:m]) is known): MTH(D[0:m]) is known):
SUBPROOF(m, D[m], true) = {} SUBPROOF(m, D[m], true) = {}
Otherwise, the subproof for m = n is the Merkle Tree Hash committing Otherwise, the subproof for m = n is the Merkle Tree Hash committing
inputs D[0:m]: inputs D[0:m]:
SUBPROOF(m, D[m], false) = {MTH(D[m])} SUBPROOF(m, D[m], false) = {MTH(D[m])}
For m < n, let k be the largest power of two smaller than n. The For m < n, let k be the largest power of two smaller than n. The
subproof is then defined recursively. subproof is then defined recursively.
If m <= k, the right subtree entries D[k:n] only exist in the current If m <= k, the right subtree entries D[k:n] only exist in the current
tree. We prove that the left subtree entries D[0:k] are consistent tree. We prove that the left subtree entries D[0:k] are consistent
and add a commitment to D[k:n]: and add a commitment to D[k:n]:
SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n]) SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])
If m > k, the left subtree entries D[0:k] are identical in both If m > k, the left subtree entries D[0:k] are identical in both
trees. We prove that the right subtree entries D[k:n] are consistent trees. We prove that the right subtree entries D[k:n] are consistent
skipping to change at page 15, line 34 skipping to change at page 14, line 36
verification rules in order to accommodate quirks of CA certificate- verification rules in order to accommodate quirks of CA certificate-
issuing software. However, logs MUST reject submissions without a issuing software. However, logs MUST reject submissions without a
valid signature chain to an accepted trust anchor. Logs MUST also valid signature chain to an accepted trust anchor. Logs MUST also
reject precertificates that do not conform to the requirements in reject precertificates that do not conform to the requirements in
Section 3.2. Section 3.2.
Logs SHOULD limit the length of chain they will accept. The maximum Logs SHOULD limit the length of chain they will accept. The maximum
chain length is specified in the log's metadata. chain length is specified in the log's metadata.
The log SHALL allow retrieval of its list of accepted trust anchors The log SHALL allow retrieval of its list of accepted trust anchors
(see Section 6.9), each of which is a root or intermediate CA (see Section 6.8), each of which is a root or intermediate CA
certificate. This list might usefully be the union of root certificate. This list might usefully be the union of root
certificates trusted by major browser vendors. certificates trusted by major browser vendors.
5.2. Log Entries 5.2. Log Entries
If a submission is accepted and an SCT issued, the accepting log MUST If a submission is accepted and an SCT issued, the accepting log MUST
store the entire chain used for verification. This chain MUST store the entire chain used for verification. This chain MUST
include the certificate or precertificate itself, the zero or more include the certificate or precertificate itself, the zero or more
intermediate CA certificates provided by the submitter, and the trust intermediate CA certificates provided by the submitter, and the trust
anchor used to verify the chain (even if it was omitted from the anchor used to verify the chain (even if it was omitted from the
skipping to change at page 25, line 5 skipping to change at page 24, line 5
In the case of a malformed request, the string SHOULD provide In the case of a malformed request, the string SHOULD provide
sufficient detail for the error to be rectified. sufficient detail for the error to be rectified.
error_code: An error code readable by the client. Some codes are error_code: An error code readable by the client. Some codes are
generic and are detailed here. Others are detailed in the generic and are detailed here. Others are detailed in the
individual requests. Error codes are fixed text strings. individual requests. Error codes are fixed text strings.
not compliant The request is not compliant with this RFC. not compliant The request is not compliant with this RFC.
e.g. In response to a request of "/ct/v2/get- e.g. In response to a request of "/ct/v2/get-
entries?start=100&end=99", the log would return a "400 Bad Request" entries?start=100&end=99", the log would return a "400 Bad Request"
response code with a body similar to the following: response code with a body similar to the following:
{ {
"error_message": "'start' cannot be greater than 'end'", "error_message": "'start' cannot be greater than 'end'",
"error_code": "not compliant", "error_code": "not compliant",
} }
Clients SHOULD treat "500 Internal Server Error" and "503 Service Clients SHOULD treat "500 Internal Server Error" and "503 Service
Unavailable" responses as transient failures and MAY retry the same Unavailable" responses as transient failures and MAY retry the same
skipping to change at page 31, line 15 skipping to change at page 30, line 15
Because of skew, it is possible the log server will not have any Because of skew, it is possible the log server will not have any
entries between "start" and "end". In this case it MUST return an entries between "start" and "end". In this case it MUST return an
empty "entries" array. empty "entries" array.
In any case, the log server MUST return the latest STH it knows In any case, the log server MUST return the latest STH it knows
about. about.
See Section 10.4.3 for an outline of how to use a complete list of See Section 10.4.3 for an outline of how to use a complete list of
"leaf_input" entries to verify the "root_hash". "leaf_input" entries to verify the "root_hash".
6.8. Get Entry Number for SCT 6.8. Retrieve Accepted Trust Anchors
GET https://<log server>/ct/v2/get-entry-for-sct
Inputs:
sct: A base64 encoded "TransItem" of type "x509_sct_v2" or
"precert_sct_v2" allegedly from this log.
Outputs:
entry: 0-based index of the log entry corresponding to the
supplied SCT.
Error codes:
bad signature "sct" is not signed by this log.
not found "sct" does not correspond to an entry that is currently
available.
Note that any SCT with a valid signature MUST have a corresponding
entry in the log, but it may not be retrievable until the MMD has
passed since the SCT was issued.
6.9. Retrieve Accepted Trust Anchors
GET https://<log server>/ct/v2/get-anchors GET https://<log server>/ct/v2/get-anchors
No inputs. No inputs.
Outputs: Outputs:
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.
skipping to change at page 50, line 11 skipping to change at page 48, line 26
Hash Standard", FIPS PUB 180-4, March 2012, Hash Standard", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February Version 2.1", RFC 3447, February 2003.
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627, July 2006.
DOI 10.17487/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, October 2006.
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246, August 2008.
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, May 2008.
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <http://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
"Network Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, June 2010.
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extensions: Extension Definitions", RFC 6066, Extension Definitions", RFC 6066, January 2011.
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, March 2011.
2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <http://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
skipping to change at page 51, line 46 skipping to change at page 49, line 42
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) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>. October 2015, <http://www.rfc-editor.org/info/rfc7633>.
15.2. Informative References 15.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/chromium- Log Policy", 2014, <http://www.chromium.org/Home/
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/
chromium-security/certificate-transparency>. chromium-security/certificate-transparency>.
[CrosbyWallach] [CrosbyWallach]
Crosby, S. and D. Wallach, "Efficient Data Structures for Crosby, S. and D. Wallach, "Efficient Data Structures for
Tamper-Evident Logging", Proceedings of the 18th USENIX Tamper-Evident Logging", Proceedings of the 18th USENIX
Security Symposium, Montreal, August 2009, Security Symposium, Montreal, August 2009,
skipping to change at page 52, line 20 skipping to change at page 50, line 20
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] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-02 (work in progress), March CT", draft-ietf-trans-gossip-01 (work in progress),
2016. October 2015.
[I-D.ietf-trans-threat-analysis] [I-D.ietf-trans-threat-analysis]
Kent, S., "Attack Model and Threat for Certificate Kent, S., "Attack Model and Threat for Certificate
Transparency", draft-ietf-trans-threat-analysis-05 (work Transparency", draft-ietf-trans-threat-analysis-03 (work
in progress), April 2016. 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] [Public.Suffix.List]
Mozilla Foundation, "Public Suffix List", 2016, Mozilla Foundation, "Public Suffix List", 2016, <https://
<https://publicsuffix.org>. publicsuffix.org>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, June 2013.
<http://www.rfc-editor.org/info/rfc6962>.
Appendix A. Supporting v1 and v2 simultaneously Appendix A. Supporting v1 and v2 simultaneously
Certificate Transparency logs have to be either v1 (conforming to Certificate Transparency logs have to be either v1 (conforming to
[RFC6962]) or v2 (conforming to this document), as the data [RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid structures are incompatible and so a v2 log could not issue a valid
v1 SCT. v1 SCT.
CT clients, however, can support v1 and v2 SCTs, for the same CT clients, however, can support v1 and v2 SCTs, for the same
certificate, simultaneously, as v1 SCTs are delivered in different certificate, simultaneously, as v1 SCTs are delivered in different
 End of changes. 29 change blocks. 
156 lines changed or deleted 112 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/