draft-ietf-trans-rfc6962-bis-08.txt   draft-ietf-trans-rfc6962-bis-09.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: January 7, 2016 E. Messeri Expires: April 15, 2016 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
July 6, 2015 October 13, 2015
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-08 draft-ietf-trans-rfc6962-bis-09
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 January 7, 2016. This Internet-Draft will expire on April 15, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . 5 2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 6
2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 6 2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 6
2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 9 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 9
3. Log Format and Operation . . . . . . . . . . . . . . . . . . 10 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 10
3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12 3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 13
3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 13 3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 13
3.2.2. Redacting Domain Name Labels in Precertificates . . . 13 3.2.2. Redacting Domain Name Labels in Precertificates . . . 13
3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 14 3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 14
3.3. Structure of the Signed Certificate Timestamp . . . . . . 15 3.3. Structure of the Signed Certificate Timestamp . . . . . . 15
3.4. Including the Signed Certificate Timestamp in the TLS 3.4. Including the Signed Certificate Timestamp in the TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . . . 17 Handshake . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 18 3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 19
3.4.2. X.509v3 Extension . . . . . . . . . . . . . . . . . . 18 3.4.2. X.509v3 Extension . . . . . . . . . . . . . . . . . . 19
3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 20
3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 20 3.6. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 21
4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 20 3.6.1. Structure of the STH . . . . . . . . . . . . . . . . 21
4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 22 4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23
4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 23 4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 24
4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 23 4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 25
4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 25
4.4. Retrieve Merkle Consistency Proof between Two Signed Tree 4.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 25 4.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 26
4.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and 4.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 26 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 27
4.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29
4.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 27 4.8. Retrieve Accepted Root Certificates . . . . . . . . . . . 30
4.8. Retrieve Accepted Root Certificates . . . . . . . . . . . 28 5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. Submitters . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Submitters . . . . . . . . . . . . . . . . . . . . . . . 30 5.3. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 30 5.4. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.5. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5.1. Verifying an inclusion proof . . . . . . . . . . . . 34
5.5.1. Verifying an inclusion proof . . . . . . . . . . . . 32 5.5.2. Verifying consistency between two STHs . . . . . . . 34
5.5.2. Verifying consistency between two STHs . . . . . . . 32 5.5.3. Verifying root hash given entries . . . . . . . . . . 35
5.5.3. Verifying root hash given entries . . . . . . . . . . 33 6. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 36
6. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 36
7.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 34 7.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 36
7.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 34 7.3. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7.4. STH Extensions . . . . . . . . . . . . . . . . . . . . . 37
8.1. Misissued Certificates . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
8.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 35 8.1. Misissued Certificates . . . . . . . . . . . . . . . . . 37
8.3. Redaction of Public Domain Name Labels . . . . . . . . . 35 8.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 38
8.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 36 8.3. Redaction of Public Domain Name Labels . . . . . . . . . 38
8.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 36 8.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 38
9. Efficiency Considerations . . . . . . . . . . . . . . . . . . 37 8.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 39
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 9. Efficiency Considerations . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
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 publicly auditable, append-only, untrusted certificates by providing publicly auditable, append-only, untrusted
logs of all issued certificates. The logs are publicly auditable so logs of all issued certificates. The logs are publicly auditable so
that it is possible for anyone to verify the correctness of each log that it is possible for anyone to verify the correctness of each log
and to monitor when new certificates are added to it. The logs do and to monitor when new certificates are added to it. The logs do
not themselves prevent misissue, but they ensure that interested not themselves prevent misissue, but they ensure that interested
parties (particularly those named in certificates) can detect such parties (particularly those named in certificates) can detect such
skipping to change at page 4, line 6 skipping to change at page 4, line 10
Each log consists of certificate chains, which can be submitted by Each log consists of certificate chains, which can be submitted by
anyone. It is expected that public CAs will contribute all their anyone. It is expected that public CAs will contribute all their
newly issued certificates to one or more logs, however certificate newly issued certificates to one or more logs, however certificate
holders can also contribute their own certificate chains, as can holders can also contribute their own certificate chains, as can
third parties. In order to avoid logs being rendered useless by third parties. In order to avoid logs being rendered useless by
submitting large numbers of spurious certificates, it is required submitting large numbers of spurious certificates, it is required
that each chain is rooted in a CA certificate accepted by the log. that each chain is rooted in a CA certificate accepted by the log.
When a chain is submitted to a log, a signed timestamp is returned, When a chain is submitted to a log, a signed timestamp is returned,
which can later be used to provide evidence to TLS clients that the which can later be used to provide evidence to TLS clients that the
chain has been submitted. TLS clients can thus require that all chain has been submitted. TLS clients can thus require that all
certificates they accept as valid have been logged. certificates they accept as valid are accompanied by signed
timestamps.
Those who are concerned about misissue can monitor the logs, asking Those who are concerned about misissue can monitor the logs, asking
them regularly for all new entries, and can thus check whether them regularly for all new entries, and can thus check whether
domains they are responsible for have had certificates issued that domains they are responsible for have had certificates issued that
they did not expect. What they do with this information, they did not expect. What they do with this information,
particularly when they find that a misissuance has happened, is particularly when they find that a misissuance has happened, is
beyond the scope of this document, but broadly speaking, they can beyond the scope of this document, but broadly speaking, they can
invoke existing business mechanisms for dealing with misissued invoke existing business mechanisms for dealing with misissued
certificates, such as working with the CA to get the certificate certificates, such as working with the CA to get the certificate
revoked, or with maintainers of trust anchor lists to get the CA revoked, or with maintainers of trust anchor lists to get the CA
skipping to change at page 6, line 21 skipping to change at page 6, line 28
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 7, line 15 skipping to change at page 7, line 22
originally requested (meaning that the subtree Merkle Tree Hash originally requested (meaning that the subtree Merkle Tree Hash
MTH(D[0:m]) is known): MTH(D[0:m]) is known):
SUBPROOF(m, D[m], true) = {} SUBPROOF(m, D[m], true) = {}
The subproof for m = n is the Merkle Tree Hash committing inputs The subproof for m = n is the Merkle Tree Hash committing inputs
D[0:m]; otherwise: D[0:m]; otherwise:
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 10, line 10 skipping to change at page 10, line 10
deterministic ECDSA [RFC6979] using the NIST P-256 curve deterministic ECDSA [RFC6979] using the NIST P-256 curve
(Section D.1.2.3 of the Digital Signature Standard [DSS]) and HMAC- (Section D.1.2.3 of the Digital Signature Standard [DSS]) and HMAC-
SHA256 or RSA signatures (RSASSA-PKCS1-v1_5 with SHA-256, Section 8.2 SHA256 or RSA signatures (RSASSA-PKCS1-v1_5 with SHA-256, Section 8.2
of [RFC3447]) using a key of at least 2048 bits. of [RFC3447]) using a key of at least 2048 bits.
3. Log Format and Operation 3. Log Format and Operation
Anyone can submit certificates to certificate logs for public Anyone can submit certificates to certificate logs for public
auditing; however, since certificates will not be accepted by TLS auditing; however, since certificates will not be accepted by TLS
clients unless logged, it is expected that certificate owners or clients unless logged, it is expected that certificate owners or
their CAs will usually submit them. A log is a single, ever-growing, their CAs will usually submit them. A log is a single, append-only
append-only Merkle Tree of such certificates. Merkle Tree of such certificates.
When a valid certificate is submitted to a log, the log MUST return a When a valid certificate is submitted to a log, the log MUST return a
Signed Certificate Timestamp (SCT). The SCT is the log's promise to Signed Certificate Timestamp (SCT). The SCT is the log's promise to
incorporate the certificate in the Merkle Tree within a fixed amount incorporate the certificate in the Merkle Tree within a fixed amount
of time known as the Maximum Merge Delay (MMD). If the log has of time known as the Maximum Merge Delay (MMD). If the log has
previously seen the certificate, it MAY return the same SCT as it previously seen the certificate, it MAY return the same SCT as it
returned before (note that if a certificate was previously logged as returned before (note that if a certificate was previously logged as
a precertificate, then the precertificate's SCT would not be a precertificate, then the precertificate's SCT would not be
appropriate, instead a fresh SCT of type x509_entry should be appropriate, instead a fresh SCT of type x509_entry should be
generated). TLS servers MUST present an SCT from one or more logs to generated). TLS servers MUST present an SCT from one or more logs to
skipping to change at page 11, line 38 skipping to change at page 11, line 38
a valid signature chain to an accepted root certificate, using the a valid signature chain to an accepted root certificate, using the
chain of intermediate CA certificates provided by the submitter. chain of intermediate CA certificates provided by the submitter.
Logs MUST accept certificates that are fully valid according to RFC Logs MUST accept certificates that are fully valid according to RFC
5280 [RFC5280] verification rules and are submitted with such a 5280 [RFC5280] verification rules and are submitted with such a
chain. Logs MAY accept certificates and precertificates that have chain. Logs MAY accept certificates and precertificates that have
expired, are not yet valid, have been revoked, or are otherwise not expired, are not yet valid, have been revoked, or are otherwise not
fully valid according to RFC 5280 verification rules in order to fully valid according to RFC 5280 verification rules in order to
accommodate quirks of CA certificate-issuing software. However, logs accommodate quirks of CA certificate-issuing software. However, logs
MUST reject certificates without a valid signature chain to an MUST reject certificates without a valid signature chain to an
accepted root certificate. Logs MUST also reject precertificates accepted root certificate. Logs MUST also reject precertificates
that are not valid DER encoded CMS "signed-data" objects. If a that are not valid DER encoded CMS "signed-data" objects.
certificate is accepted and an SCT issued, the accepting log MUST
store the entire chain used for verification, including the If a certificate is accepted and an SCT issued, the accepting log
certificate or precertificate itself and including the root MUST store the entire chain used for verification. This chain MUST
include the certificate or precertificate itself, the zero or more
intermediate CA certificates provided by the submitter, and the root
certificate used to verify the chain (even if it was omitted from the certificate used to verify the chain (even if it was omitted from the
submission), and MUST present this chain for auditing upon request. submission). The log MUST present this chain for auditing upon
This chain is required to prevent a CA from avoiding blame by logging request. This chain is required to prevent a CA from avoiding blame
a partial or empty chain. (Note: This effectively excludes self- by logging a partial or empty chain.
signed and DANE-based certificates until some mechanism to limit the
submission of spurious certificates is found. The authors welcome
suggestions.)
Each certificate or precertificate entry in a log MUST include the Each certificate or precertificate entry in a log MUST include the
following components: following components:
enum { x509_entry(0), precert_entry_V2(2), (65535) } LogEntryType; enum {
x509_entry(0), precert_entry_V2(2), (65535)
} LogEntryType;
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
struct { struct {
ASN.1Cert leaf_certificate; ASN.1Cert leaf_certificate;
ASN.1Cert certificate_chain<0..2^24-1>; ASN.1Cert certificate_chain<0..2^24-1>;
} X509ChainEntry; } X509ChainEntry;
opaque CMSPrecert<1..2^24-1>; opaque CMSPrecert<1..2^24-1>;
struct { struct {
CMSPrecert pre_certificate; CMSPrecert pre_certificate;
ASN.1Cert precertificate_chain<0..2^24-1>; ASN.1Cert precertificate_chain<0..2^24-1>;
} PrecertChainEntryV2; } PrecertChainEntryV2;
Logs SHOULD limit the length of chain they will accept. Logs SHOULD limit the length of chain they will accept. The maximum
chain length is specified in the log's metadata.
"entry_type" is the type of this entry. Future revisions of this "entry_type" is the type of this entry. Future revisions of this
protocol may add new LogEntryType values. Section 4 explains how protocol may add new LogEntryType values. Section 4 explains how
clients should handle unknown entry types. clients should handle unknown entry types.
"leaf_certificate" is the end-entity certificate submitted for "leaf_certificate" is the end-entity certificate submitted for
auditing. auditing.
"certificate_chain" is an array of additional certificates required "certificate_chain" is an array of additional certificates required
to verify the end-entity certificate. The first certificate MUST to verify the end-entity certificate. The first certificate MUST
skipping to change at page 15, line 5 skipping to change at page 15, line 8
this intermediate CA. this intermediate CA.
o permittedSubtrees MUST specify one or more dNSNames. o permittedSubtrees MUST specify one or more dNSNames.
o excludedSubtrees MUST specify the entire IPv4 and IPv6 address o excludedSubtrees MUST specify the entire IPv4 and IPv6 address
ranges. ranges.
Below is an example Name Constraints extension that meets these Below is an example Name Constraints extension that meets these
conditions: conditions:
SEQUENCE {
OBJECT IDENTIFIER '2 5 29 30'
OCTET STRING, encapsulates {
SEQUENCE { SEQUENCE {
[0] { OBJECT IDENTIFIER '2 5 29 30'
SEQUENCE { OCTET STRING, encapsulates {
[2] 'example.com'
}
}
[1] {
SEQUENCE {
[7] 00 00 00 00 00 00 00 00
}
SEQUENCE { SEQUENCE {
[7] [0] {
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SEQUENCE {
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [2] 'example.com'
}
}
[1] {
SEQUENCE {
[7] 00 00 00 00 00 00 00 00
}
SEQUENCE {
[7]
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
}
}
} }
} }
} }
}
}
3.3. Structure of the Signed Certificate Timestamp 3.3. Structure of the Signed Certificate Timestamp
enum {
certificate_timestamp(0), tree_hash(1), (255)
} SignatureType;
enum { certificate_timestamp(0), tree_hash(1), (255) } enum {
SignatureType; v2(1), (255)
} Version;
enum { v2(1), (255) } struct {
Version; opaque key_id[HASH_SIZE];
} LogID;
struct { opaque TBSCertificate<1..2^24-1>;
opaque key_id[HASH_SIZE];
} LogID;
opaque TBSCertificate<1..2^24-1>; struct {
opaque issuer_key_hash[HASH_SIZE];
TBSCertificate tbs_certificate;
} CertInfo;
struct { enum {
opaque issuer_key_hash[HASH_SIZE]; reserved(65535)
TBSCertificate tbs_certificate; } SctExtensionType;
} CertInfo;
opaque CtExtensions<0..2^16-1>; struct {
SctExtensionType sct_extension_type;
opaque sct_extension_data<0..2^16-1>;
} SctExtension;
SctExtension SctExtensions<0..2^16-1>;
"key_id" is the HASH of the log's public key, calculated over the DER "key_id" is the HASH of the log's public key, calculated over the DER
encoding of the key represented as SubjectPublicKeyInfo. encoding of the key represented as SubjectPublicKeyInfo.
"issuer_key_hash" is the HASH of the certificate issuer's public key, "issuer_key_hash" is the HASH of the certificate issuer's public key,
calculated over the DER encoding of the key represented as calculated over the DER encoding of the key represented as
SubjectPublicKeyInfo. This is needed to bind the issuer to the final SubjectPublicKeyInfo. This is needed to bind the issuer to the final
certificate, making it impossible for the SCT to be valid for any certificate, making it impossible for the SCT to be valid for any
other certificate. other certificate.
"tbs_certificate" is the DER-encoded TBSCertificate component of the "tbs_certificate" is the DER-encoded TBSCertificate component of the
precertificate. Note that it is also possible to reconstruct this precertificate. Note that it is also possible to reconstruct this
TBSCertificate from the issued certificate by extracting the TBSCertificate from the issued certificate by extracting the
TBSCertificate from it, redacting the domain name labels indicated by TBSCertificate from it, redacting the domain name labels indicated by
the redacted labels extension, and deleting the SCT list extension the redacted labels extension, and deleting the SCT list extension
and redacted labels extension. and redacted labels extension.
"sct_extension_type" identifies a single extension from the IANA
registry in Section 7.3.
The interpretation of the "sct_extension_data" field is determined
solely by the value of the "sct_extension_type" field. Each document
that registers a new "sct_extension_type" must describe how to
interpret the corresponding "sct_extension_data".
The "SctExtensions" type is a vector of 0 or more extensions. This
vector MUST NOT include more than one extension with the same
"sct_extension_type". The extensions in the vector MUST be ordered
by the value of the "sct_extension_type" field, smallest value first.
struct { struct {
Version sct_version; Version sct_version;
LogID id; LogID id;
uint64 timestamp; uint64 timestamp;
CtExtensions extensions; SctExtensions extensions;
digitally-signed struct { digitally-signed struct {
Version sct_version; Version sct_version;
SignatureType signature_type = certificate_timestamp; SignatureType signature_type = certificate_timestamp;
uint64 timestamp; uint64 timestamp;
LogEntryType entry_type; LogEntryType entry_type;
select(entry_type) { select(entry_type) {
case x509_entry: CertInfo; case x509_entry: CertInfo;
case precert_entry_V2: CertInfo; case precert_entry_V2: CertInfo;
} signed_entry; } signed_entry;
CtExtensions extensions; SctExtensions extensions;
}; };
} SignedCertificateTimestamp; } SignedCertificateTimestamp;
The encoding of the digitally-signed element is defined in [RFC5246]. The encoding of the digitally-signed element is defined in [RFC5246].
"sct_version" is the version of the protocol to which the SCT "sct_version" is the version of the protocol to which the SCT
conforms. This version is v2. Note that SignedCertificateTimestamp conforms. This version is v2. Note that SignedCertificateTimestamp
v1 [RFC6962] had a different definition of "signed_entry". v1 [RFC6962] had a different definition of "signed_entry".
"timestamp" is the current NTP Time [RFC5905], measured since the "timestamp" is the current NTP Time [RFC5905], measured since the
skipping to change at page 17, line 6 skipping to change at page 17, line 51
milliseconds. milliseconds.
"entry_type" may be implicit from the context in which the SCT is "entry_type" may be implicit from the context in which the SCT is
presented. presented.
"signed_entry" includes the TBSCertificate from either the "signed_entry" includes the 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). "pre_certificate" (in the case of a PrecertChainEntryV2).
"extensions" are future extensions to SignedCertificateTimestamp v2. "extensions" are future extensions to SignedCertificateTimestamp v2.
Currently, no extensions are specified. Currently, no extensions are specified. If an implementation sees an
extension that it does not understand, it SHOULD ignore that
extension. Furthermore, an implementation MAY choose to ignore any
extension(s) that it does understand.
3.4. Including the Signed Certificate Timestamp in the TLS Handshake 3.4. Including the Signed Certificate Timestamp in the TLS Handshake
The SCT data corresponding to at least one certificate in the chain The SCT data corresponding to at least one certificate in the chain
from at least one log must be included in the TLS handshake by using from at least one log must be included in the TLS handshake by using
one or more of the mechanisms listed below. Three mechanisms are one or more of the mechanisms listed below. Three mechanisms are
provided because they have different tradeoffs. TLS clients MUST provided because they have different tradeoffs. TLS clients MUST
implement all three mechanisms. TLS servers MUST present SCTs using implement all three mechanisms. TLS servers MUST present SCTs using
at least one of the three mechanisms. at least one of the three mechanisms.
skipping to change at page 17, line 31 skipping to change at page 18, line 30
allows SCTs to be updated on the fly. allows SCTs 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 3.4.2.1), where the OCSP response is extension (see Section 3.4.2.1), where the OCSP response is
provided in the "certificate_status" TLS extension (Section 8 of provided in the "certificate_status" TLS extension (Section 8 of
[RFC6066]), also known as OCSP stapling. This mechanism is [RFC6066]), also known as OCSP stapling. This mechanism is
already widely (but not universally) implemented. It also allows already widely (but not universally) implemented. It also allows
SCTs to be updated on the fly. SCTs to be updated on the fly.
o An X509v3 certificate extension (see Section 3.4.2.2). This o An X509v3 certificate extension (see Section 3.4.2.2). This
mechanism allows the use of unmodified TLS servers, but, because mechanism allows the use of unmodified TLS servers, but the SCTs
the included SCTs cannot be changed without re-issuing the cannot be updated on the fly. Since the logs that signed the SCTs
certificate, increases the risk that the certificate will be won't necessarily be accepted by TLS clients for the full lifetime
refused if any of the SCTs become invalid. of the certificate, there is a risk that TLS clients will
subsequently consider the certificate to be non-compliant and in
need of re-issuance.
TLS servers SHOULD send SCTs from multiple logs in case one or more TLS servers SHOULD send SCTs from multiple logs in case one or more
logs are not acceptable to the TLS client (for example, if a log has logs are not acceptable to the TLS client (for example, if a log has
been struck off for misbehavior, has had a key compromise or is not been struck off for misbehavior, has had a key compromise or is not
known to the TLS client). Multiple SCTs are combined into an SCT known to the TLS client).
list as follows:
opaque SerializedSCT<1..2^16-1>; Multiple SCTs are combined into an SCT list as follows:
struct { opaque SerializedSCT<1..2^16-1>;
SerializedSCT sct_list <1..2^16-1>;
} SignedCertificateTimestampList; struct {
SerializedSCT sct_list<1..2^16-1>;
} SignedCertificateTimestampList;
Here, "SerializedSCT" is an opaque byte string that contains the Here, "SerializedSCT" is an opaque byte string that contains the
serialized SCT structure. This encoding ensures that TLS clients can serialized SCT structure. This encoding ensures that TLS clients can
decode each SCT individually (i.e., if there is a version upgrade, decode each SCT individually (i.e., if there is a version upgrade,
out-of-date clients can still parse old SCTs while skipping over new out-of-date clients can still parse old SCTs while skipping over new
SCTs whose versions they don't understand). SCTs whose versions they don't understand).
3.4.1. TLS Extension 3.4.1. TLS Extension
One or more SCTs can be sent during the TLS handshake using a TLS One or more SCTs can be sent during the TLS handshake using a TLS
skipping to change at page 18, line 40 skipping to change at page 19, line 43
to wrap it inside an additional OCTET STRING (see below), which we to wrap it inside an additional OCTET STRING (see below), which we
then put into the "extnValue" field. then put into the "extnValue" field.
3.4.2.1. OCSP Response Extension 3.4.2.1. OCSP Response Extension
A certification authority may embed one or more SCTs in OCSP A certification authority may embed one or more SCTs in OCSP
responses pertaining to the end-entity certificate, by including a responses pertaining to the end-entity certificate, by including a
non-critical "singleExtensions" extension with OID non-critical "singleExtensions" extension with OID
1.3.6.1.4.1.11129.2.4.5 whose "extnValue" contains: 1.3.6.1.4.1.11129.2.4.5 whose "extnValue" contains:
CertificateSCTList ::= OCTET STRING CertificateSCTList ::= OCTET STRING
"CertificateSCTList" contains a "SignedCertificateTimestampList" "CertificateSCTList" contains a "SignedCertificateTimestampList"
whose SCTs all have the "x509_entry" "LogEntryType". whose SCTs all have the "x509_entry" "LogEntryType".
3.4.2.2. Certificate Extension 3.4.2.2. Certificate Extension
A certification authority that has submitted a precertificate to one A certification authority that has submitted a precertificate to one
or more logs may embed the obtained SCTs in the "TBSCertificate" that or more logs may embed the obtained SCTs in the "TBSCertificate" that
will be signed to produce the certificate, by including a non- will be signed to produce the certificate, by including a non-
critical X.509v3 extension with OID 1.3.6.1.4.1.11129.2.4.2 whose critical X.509v3 extension with OID 1.3.6.1.4.1.11129.2.4.2 whose
"extnValue" contains: "extnValue" contains:
PrecertificateSCTList ::= OCTET STRING PrecertificateSCTList ::= OCTET STRING
"PrecertificateSCTList" contains a "SignedCertificateTimestampList" "PrecertificateSCTList" contains a "SignedCertificateTimestampList"
whose SCTs all have the "precert_entry_V2" "LogEntryType". whose SCTs all have the "precert_entry_V2" "LogEntryType".
Upon receiving the certificate, clients can reconstruct the original Upon receiving the certificate, clients can reconstruct the original
"TBSCertificate" to verify the SCT signatures. "TBSCertificate" to verify the SCT signatures.
3.5. Merkle Tree 3.5. Merkle Tree
The hashing algorithm for the Merkle Tree Hash is specified in the The hashing algorithm for the Merkle Tree Hash is specified in the
log's metadata. log's metadata.
Structure of the Merkle Tree input: Structure of the Merkle Tree input:
enum { v1(0), v2(1), (255) } enum {
LeafVersion; v1(0), v2(1), (255)
} LeafVersion;
struct { struct {
uint64 timestamp; uint64 timestamp;
LogEntryType entry_type; LogEntryType entry_type;
select(entry_type) { select(entry_type) {
case x509_entry: CertInfo; case x509_entry: CertInfo;
case precert_entry_V2: CertInfo; case precert_entry_V2: CertInfo;
} signed_entry; } signed_entry;
CtExtensions extensions; SctExtensions extensions;
} TimestampedEntry; } TimestampedEntry;
struct { struct {
LeafVersion version; LeafVersion version;
TimestampedEntry timestamped_entry; TimestampedEntry timestamped_entry;
} MerkleTreeLeaf; } MerkleTreeLeaf;
Here, "version" is the version of the MerkleTreeLeaf structure. This Here, "version" is the version of the MerkleTreeLeaf structure. This
version is v2. Note that MerkleTreeLeaf v1 [RFC6962] had another version is v2. Note that MerkleTreeLeaf v1 [RFC6962] had another
layer of indirection which is removed in v2. layer of indirection which is removed in v2.
skipping to change at page 19, line 52 skipping to change at page 21, line 12
"timestamp" is the timestamp of the corresponding SCT issued for this "timestamp" is the timestamp of the corresponding SCT issued for this
certificate. certificate.
"entry_type" is the type of entry stored in "signed_entry". New "entry_type" is the type of entry stored in "signed_entry". New
"LogEntryType" values may be added to "signed_entry" without "LogEntryType" values may be added to "signed_entry" without
increasing the "MerkleTreeLeaf" version. Section 4 explains how increasing the "MerkleTreeLeaf" version. Section 4 explains how
clients should handle unknown entry types. clients should handle unknown entry types.
"signed_entry" is the "signed_entry" of the corresponding SCT. "signed_entry" is the "signed_entry" of the corresponding SCT.
"extensions" are "extensions" of the corresponding SCT. "extensions" are the "extensions" of the corresponding SCT.
The leaves of the Merkle Tree are the leaf hashes of the The leaves of the Merkle Tree are the leaf hashes of the
corresponding "MerkleTreeLeaf" structures. Note that leaf hashes corresponding "MerkleTreeLeaf" structures. Note that leaf hashes
(Section 2.1) are calculated as HASH(0x00 || MerkleTreeLeaf). (Section 2.1) are calculated as HASH(0x00 || MerkleTreeLeaf).
3.6. Signed Tree Head 3.6. Signed Tree Head (STH)
Periodically the log SHOULD sign the corresponding tree hash and tree Periodically the log SHOULD sign the corresponding tree hash and tree
information (see the corresponding Signed Tree Head client message in information (see the corresponding Signed Tree Head client message in
Section 4.3). The signature for that data is structured as follows: Section 4.3).
enum { v1(0), (255) } TreeHeadVersion;
digitally-signed struct {
TreeHeadVersion version;
SignatureType signature_type = tree_hash;
uint64 timestamp;
uint64 tree_size;
opaque root_hash[HASH_SIZE];
} TreeHeadSignature;
"version" is the version of the TreeHeadSignature structure. This
version is v1.
"timestamp" is the current time. The timestamp MUST be at least as
recent as the most recent SCT timestamp in the tree. Each subsequent
timestamp MUST be more recent than the timestamp of the previous
update.
"tree_size" equals the number of entries in the new tree.
"root_hash" is the root of the Merkle Hash Tree.
Each log MUST produce on demand a Signed Tree Head that is no older Each log MUST produce on demand a Signed Tree Head that is no older
than the Maximum Merge Delay. However, Signed Tree Heads could be than the Maximum Merge Delay. However, Signed Tree Heads could be
used to mark individual clients (by producing a new one for each used to mark individual clients (by producing a new one for each
query), so logs MUST NOT produce them more frequently than is query), so logs MUST NOT produce them more frequently than is
declared in their metadata. In general, there is no need to produce declared in their metadata. In general, there is no need to produce
a new Signed Tree Head unless there are new entries in the log, a new Signed Tree Head unless there are new entries in the log,
however, in the unlikely event that it receives no new submissions however, in the unlikely event that it receives no new submissions
during an MMD period, the log SHALL sign the same Merkle Tree Hash during an MMD period, the log SHALL sign the same Merkle Tree Hash
with a fresh timestamp. with a fresh timestamp.
3.6.1. Structure of the STH
enum {
v2(1), (255)
} TreeHeadVersion;
enum {
reserved(65535)
} SthExtensionType;
struct {
SthExtensionType sth_extension_type;
opaque sth_extension_data<0..2^16-1>;
} SthExtension;
SthExtension SthExtensions<0..2^16-1>;
"sth_extension_type" identifies a single extension from the IANA
registry in Section 7.4.
The interpretation of the "sth_extension_data" field is determined
solely by the value of the "sth_extension_type" field. Each document
that registers a new "sth_extension_type" must describe how to
interpret the corresponding "sth_extension_data".
The "SthExtensions" type is a vector of 0 or more extensions. This
vector MUST NOT include more than one extension with the same
"sth_extension_type". The extensions in the vector MUST be ordered
by the value of the "sth_extension_type" field, smallest value first.
struct {
TreeHeadVersion version;
LogID id;
uint64 timestamp;
uint64 tree_size;
opaque root_hash[HASH_SIZE];
SthExtensions extensions;
digitally-signed struct {
TreeHeadVersion version;
SignatureType signature_type = tree_hash;
LogID id;
uint64 timestamp;
uint64 tree_size;
opaque root_hash[HASH_SIZE];
SthExtensions extensions;
};
} SignedTreeHead;
"version" is the version of the SignedTreeHead structure. This
version is v2. Note that TreeHeadSignature v1 [RFC6962] only
included the inner "digitally-signed struct" and did not include the
"id" or "extensions" fields.
"timestamp" is the current NTP Time [RFC5905], measured since the
epoch (January 1, 1970, 00:00), ignoring leap seconds, in
milliseconds. The timestamp MUST be at least as recent as the most
recent SCT timestamp in the tree. Each subsequent timestamp MUST be
more recent than the timestamp of the previous update.
"tree_size" equals the number of entries in the new tree.
"root_hash" is the root of the Merkle Hash Tree.
"extensions" are future extensions to SignedTreeHead v2. Currently,
no extensions are specified. If an implementation sees an extension
that it does not understand, it SHOULD ignore that extension.
Furthermore, an implementation MAY choose to ignore any extension(s)
that it does understand.
4. Log Client Messages 4. Log Client Messages
Messages are sent as HTTPS GET or POST requests. Parameters for Messages are sent as HTTPS GET or POST requests. Parameters for
POSTs and all responses are encoded as JavaScript Object Notation POSTs and all responses are encoded as JavaScript Object Notation
(JSON) objects [RFC4627]. Parameters for GETs are encoded as order- (JSON) objects [RFC4627]. Parameters for GETs are encoded as order-
independent key/value URL parameters, using the "application/x-www- independent key/value URL parameters, using the "application/x-www-
form-urlencoded" format described in the "HTML 4.01 Specification" form-urlencoded" format described in the "HTML 4.01 Specification"
[HTML401]. Binary data is base64 encoded [RFC4648] as specified in [HTML401]. Binary data is base64 encoded [RFC4648] as specified in
the individual messages. the individual messages.
skipping to change at page 22, line 5 skipping to change at page 24, line 11
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
request without modification at a later date. Note that as per request without modification at a later date. Note that as per
[RFC2616], in the case of a 503 response the log MAY include a [RFC2616], in the case of a 503 response the log MAY include a
"Retry-After:" header in order to request a minimum time for the "Retry-After:" header in order to request a minimum time for the
client to wait before retrying the request. client to wait before retrying the request.
4.1. Add Chain to Log 4.1. Add Chain to Log
skipping to change at page 23, line 35 skipping to change at page 25, line 43
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 chains element is the signer of the precertificate; the second chains
to the first and so on to the last, which is either the root to the first and so on to the last, which is either the root
certificate or a certificate that chains to an accepted root certificate or a certificate that chains to an accepted root
certificate. certificate.
Outputs and errors are the same as in Section 4.1. Outputs and errors are the same as in Section 4.1.
4.3. Retrieve Latest Signed Tree Head 4.3. Retrieve Latest Signed Tree Head
GET https://<log server>/ct/v1/get-sth GET https://<log server>/ct/v2/get-sth
No inputs. No inputs.
Outputs: Outputs:
tree_size: The size of the tree, in entries, in decimal. sth: A base64 encoded SignedTreeHead.
timestamp: The timestamp, in decimal.
root_hash: The base64 encoded Merkle Tree Hash of the tree.
tree_head_signature: A base64 encoded TreeHeadSignature for
"tree_size", "timestamp" and "root_hash".
4.4. Retrieve Merkle Consistency Proof between Two Signed Tree Heads 4.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.
second: The tree_size of the newer tree, in decimal (optional). second: The tree_size of the newer tree, in decimal (optional).
Both tree sizes must be from existing v1 STHs (Signed Tree Heads). Both tree sizes must be from existing v2 STHs (Signed Tree Heads).
However, because of skew, the receiving front-end may not know one However, because of skew, the receiving front-end may not know one
or both of the existing STHs. If both are known, then only the or both of the existing STHs. If both are known, then only the
"consistency" output is returned. If the first is known but the "consistency" output is returned. If the first is known but the
second is not (or has been omitted), then the latest known STH is second is not (or has been omitted), then the latest known STH is
returned, along with a consistency proof between the first STH and returned, along with a consistency proof between the first STH and
the latest. If neither are known, then the latest known STH is the latest. If neither are known, then the latest known STH is
returned without a consistency proof. returned without a consistency proof.
Outputs: Outputs:
consistency: An array of base64 encoded Merkle Tree nodes. consistency: An array of base64 encoded Merkle Tree nodes.
tree_size: The size of the tree, in entries, in decimal. sth: A base64 encoded SignedTreeHead.
timestamp: The timestamp, in decimal.
root_hash: The base64 encoded Merkle Tree Hash of the tree.
tree_head_signature: A base64 encoded TreeHeadSignature for
"tree_size", "timestamp" and "root_hash".
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 an STH, which is signed. it is used to verify "sth", which is 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.
second unknown "second" is before the latest known STH but is not second unknown "second" is before the latest known STH but is not
from an existing STH. from an existing STH.
See Section 5.5.2 for an outline of how to use the "consistency" See Section 5.5.2 for an outline of how to use the "consistency"
skipping to change at page 25, line 17 skipping to change at page 27, line 9
GET https://<log server>/ct/v2/get-proof-by-hash GET https://<log server>/ct/v2/get-proof-by-hash
Inputs: Inputs:
hash: A base64 encoded v1 leaf hash. hash: A base64 encoded v1 leaf hash.
tree_size: The tree_size of the tree on which to base the proof, tree_size: The tree_size of the tree on which to base the proof,
in decimal. in decimal.
The "hash" must be calculated as defined in Section 3.5. The The "hash" must be calculated as defined in Section 3.5. The
"tree_size" must designate an existing v1 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
"leaf_index" and "audit_path" are returned. "leaf_index" and "audit_path" are returned.
Outputs: Outputs:
leaf_index: The 0-based index of the entry corresponding to the leaf_index: The 0-based index of the entry corresponding to the
"hash" parameter. "hash" parameter.
audit_path: An array of base64 encoded Merkle Tree nodes proving audit_path: An array of base64 encoded Merkle Tree nodes proving
the inclusion of the chosen certificate. the inclusion of the chosen certificate.
tree_size: The size of the tree, in entries, in decimal. sth: A base64 encoded SignedTreeHead.
timestamp: The timestamp, in decimal.
root_hash: The base64 encoded Merkle Tree Hash of the tree.
tree_head_signature: A base64 encoded TreeHeadSignature for
"tree_size", "timestamp" and "root_hash".
Note that no signature is required for the "leaf_index" or Note that no signature is required for the "leaf_index" or
"audit_path" output as this is used to verify inclusion in an STH, "audit_path" outputs as they are used to verify inclusion in
which is signed. "sth", which is 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).
tree_size unknown "hash" is before the latest known STH but is tree_size unknown "hash" is before the latest known STH but is
not from an existing STH. not from an existing STH.
See Section 5.5.1 for an outline of how to use the "audit_path" See Section 5.5.1 for an outline of how to use the "audit_path"
skipping to change at page 26, line 21 skipping to change at page 28, line 6
GET https://<log server>/ct/v2/get-all-by-hash GET https://<log server>/ct/v2/get-all-by-hash
Inputs: Inputs:
hash: A base64 encoded v1 leaf hash. hash: A base64 encoded v1 leaf hash.
tree_size: The tree_size of the tree on which to base the proofs, tree_size: The tree_size of the tree on which to base the proofs,
in decimal. in decimal.
The "hash" must be calculated as defined in Section 3.5. The The "hash" must be calculated as defined in Section 3.5. The
"tree_size" must designate an existing v1 STH. "tree_size" must designate an existing v2 STH.
Because of skew, the front-end may not know the requested STH or Because of skew, the front-end may not know the requested STH or
the requested hash, which leads to a number of cases. the requested hash, which leads to a number of cases.
latest STH < requested STH Return latest STH. latest STH < requested STH Return latest STH.
latest STH > requested STH Return latest STH and a consistency latest STH > requested STH Return latest STH and a consistency
proof between it and the requested STH (see Section 4.4). proof between it and the requested STH (see Section 4.4).
index of requested hash < latest STH Return "leaf_index" and index of requested hash < latest STH Return "leaf_index" and
skipping to change at page 26, line 47 skipping to change at page 28, line 32
response. response.
Outputs: Outputs:
leaf_index: The 0-based index of the entry corresponding to the leaf_index: The 0-based index of the entry corresponding to the
"hash" parameter. "hash" parameter.
audit_path: An array of base64 encoded Merkle Tree nodes proving audit_path: An array of base64 encoded Merkle Tree nodes proving
the inclusion of the chosen certificate. the inclusion of the chosen certificate.
tree_size: The size of the tree, in entries, in decimal. sth: A base64 encoded SignedTreeHead.
timestamp: The timestamp, in decimal.
root_hash: The base64 encoded Merkle Tree Hash of the tree.
tree_head_signature: A base64 encoded TreeHeadSignature for
"tree_size", "timestamp" and "root_hash".
consistency: An array of base64 encoded Merkle Tree nodes proving consistency: An array of base64 encoded Merkle Tree nodes proving
the consistency of the requested STH and the returned STH. the consistency of the requested STH and the returned STH.
Note that no signature is required for the "leaf_index", Note that no signature is required for the "leaf_index",
"audit_path" or "consistency" output as this is used to verify "audit_path" or "consistency" outputs as they are used to verify
inclusion in and consistency of an STH, which is signed. inclusion in and consistency of "sth", which is signed.
Errors are the same as in Section 4.5. Errors are the same as in Section 4.5.
See Section 5.5.1 for an outline of how to use the "audit_path" array See Section 5.5.1 for an outline of how to use the "audit_path" array
and see Section 5.5.2 for an outline of how to use the "consistency" and see Section 5.5.2 for an outline of how to use the "consistency"
array. array.
4.7. Retrieve Entries and STH from Log 4.7. Retrieve Entries and STH from Log
GET https://<log server>/ct/v2/get-entries GET https://<log server>/ct/v2/get-entries
Inputs: Inputs:
skipping to change at page 27, line 48 skipping to change at page 29, line 32
log entry. In the case of an X509ChainEntry, this is the log entry. In the case of an X509ChainEntry, this is the
whole "X509ChainEntry". In the case of a whole "X509ChainEntry". In the case of a
PrecertChainEntryV2, this is the whole PrecertChainEntryV2, this is the whole
"PrecertChainEntryV2". "PrecertChainEntryV2".
sct: A base64 encoded "SignedCertificateTimestamp" for this sct: A base64 encoded "SignedCertificateTimestamp" for this
entry. Note that more than one SCT may have been returned entry. Note that more than one SCT may have been returned
for the same entry - only one of those is returned in this for the same entry - only one of those is returned in this
field. It may not be possible to retrieve others. field. It may not be possible to retrieve others.
tree_size: The size of the tree, in entries, in decimal. sth: A base64 encoded SignedTreeHead.
timestamp: The timestamp, in decimal.
root_hash: The base64 encoded Merkle Tree Hash of the tree.
tree_head_signature: A base64 encoded TreeHeadSignature for
"tree_size", "timestamp" and "root_hash".
Note that this message is not signed -- the "entries" data can be Note that this message is not signed -- the "entries" data can be
verified by constructing the Merkle Tree Hash corresponding to a verified by constructing the Merkle Tree Hash corresponding to a
retrieved STH. All leaves MUST be v1 or v2. However, a compliant v1 retrieved STH. All leaves MUST be v1 or v2. However, a compliant v1
client MUST NOT construe an unrecognized LogEntryType value as an client MUST NOT construe an unrecognized LogEntryType value as an
error. This means it may be unable to parse some entries, but note error. 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 that each client can inspect the entries it does recognize as well as
verify the integrity of the data by treating unrecognized leaves as verify the integrity of the data by treating unrecognized leaves as
opaque input to the tree. opaque input to the tree.
skipping to change at page 29, line 15 skipping to change at page 30, line 41
certificates: An array of base64 encoded root certificates that certificates: An array of base64 encoded root certificates that
are acceptable to the log. are 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.
5. Clients 5. 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 could function. We describe here some typical clients and how they should function.
Any inconsistency may be used as evidence that a log has not behaved Any inconsistency may be used as evidence that a log has not behaved
correctly, and the signatures on the data structures prevent the log correctly, and the signatures on the data structures prevent the log
from denying that misbehavior. from denying that misbehavior.
All clients need various metadata in order to communicate with logs All clients need various metadata in order to communicate with logs
and verify their responses. This metadata is described below, but and verify their responses. This metadata is described below, but
note that this document does not describe how the metadata is note that this document does not describe how the metadata is
obtained, which is implementation dependent (see, for example, obtained, which is implementation dependent (see, for example,
[Chromium.Policy]). [Chromium.Policy]).
skipping to change at page 29, line 50 skipping to change at page 31, line 29
Signing Algorithm The signing algorithm used (see Section 2.1.4). Signing Algorithm The signing algorithm used (see Section 2.1.4).
Public Key The public key used for signing. Public Key The public key used for signing.
Maximum Merge Delay The MMD the log has committed to. Maximum Merge Delay The MMD the log has committed to.
Version The version of the protocol supported by the log (currently Version The version of the protocol supported by the log (currently
1 or 2). 1 or 2).
Maximum Chain Length The longest chain submission the log is willing
to accept, if the log chose to limit it.
STH Frequency Count The maximum number of STHs the log may produce STH Frequency Count The maximum number of STHs the log may produce
in any period equal to the "Maximum Merge Delay" (see in any period equal to the "Maximum Merge Delay" (see
Section 3.6). Section 3.6).
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
skipping to change at page 30, line 28 skipping to change at page 32, line 12
SHOULD validate the SCT as described in Section 5.3 if they SHOULD validate the SCT as described in Section 5.3 if they
understand its format. understand its format.
5.3. TLS Client 5.3. TLS Client
TLS clients receive SCTs alongside or in certificates, either for the TLS clients receive SCTs alongside or in certificates, either for the
server certificate itself or for intermediate CA precertificates. In server certificate itself or for intermediate CA precertificates. In
addition to normal validation of the certificate and its chain, TLS addition to normal validation of the certificate and its chain, TLS
clients SHOULD validate the SCT by computing the signature input from clients SHOULD validate the SCT by computing the signature input from
the SCT data as well as the certificate and verifying the signature, the SCT data as well as the certificate and verifying the signature,
using the corresponding log's public key. using the corresponding log's public key. By validating SCTs, TLS
clients can thus determine whether certificates are compliant.
However, specifying the TLS clients' behaviour once compliance or
non-compliance has been determined (for example, whether a
certificate should be rejected due to the lack of valid SCTs) is
outside the scope of this document.
A TLS client MAY audit the corresponding log by requesting, and A TLS client MAY audit the corresponding log by requesting, and
verifying, a Merkle audit proof for said certificate. If the TLS verifying, a Merkle audit proof for said certificate. If the TLS
client holds an STH that predates the SCT, it MAY, in the process of client holds an STH that predates the SCT, it MAY, in the process of
auditing, request a new STH from the log (Section 4.3), then verify auditing, request a new STH from the log (Section 4.3), then verify
it by requesting a consistency proof (Section 4.4). it by requesting a consistency proof (Section 4.4).
TLS clients MUST reject SCTs whose timestamp is in the future. TLS clients MUST reject SCTs whose timestamp is in the future.
5.4. Monitor 5.4. Monitor
skipping to change at page 34, line 47 skipping to change at page 36, line 37
IANA is asked to establish a registry of hash values, initially IANA is asked to establish a registry of hash values, initially
consisting of: consisting of:
+-------+----------------------+ +-------+----------------------+
| Index | Hash | | Index | Hash |
+-------+----------------------+ +-------+----------------------+
| 0 | SHA-256 [FIPS.180-4] | | 0 | SHA-256 [FIPS.180-4] |
+-------+----------------------+ +-------+----------------------+
7.3. SCT Extensions
IANA is asked to establish a registry of SCT extensions, initially
consisting of:
+-------+-----------+
| Type | Extension |
+-------+-----------+
| 65535 | reserved |
+-------+-----------+
TBD: policy for adding to the registry
7.4. STH Extensions
IANA is asked to establish a registry of STH extensions, initially
consisting of:
+-------+-----------+
| Type | Extension |
+-------+-----------+
| 65535 | reserved |
+-------+-----------+
TBD: policy for adding to the registry
8. Security Considerations 8. Security Considerations
With CAs, logs, and servers performing the actions described here, With CAs, logs, and servers performing the actions described here,
TLS clients can use logs and signed timestamps to reduce the TLS clients can use logs and signed timestamps to reduce the
likelihood that they will accept misissued certificates. If a server likelihood that they will accept misissued certificates. If a server
presents a valid signed timestamp for a certificate, then the client presents a valid signed timestamp for a certificate, then the client
knows that a log has committed to publishing the certificate. From knows that a log has committed to publishing the certificate. From
this, the client knows that the subject of the certificate has had this, the client knows that the subject of the certificate has had
some time to notice the misissue and take some action, such as asking some time to notice the misissue and take some action, such as asking
a CA to revoke a misissued certificate, or that the log has a CA to revoke a misissued certificate, or that the log has
skipping to change at page 35, line 22 skipping to change at page 37, line 42
certificate. certificate.
In addition, if TLS clients will not accept unlogged certificates, In addition, if TLS clients will not accept unlogged certificates,
then site owners will have a greater incentive to submit certificates then site owners will have a greater incentive to submit certificates
to logs, possibly with the assistance of their CA, increasing the to logs, possibly with the assistance of their CA, increasing the
overall transparency of the system. overall transparency of the system.
8.1. Misissued Certificates 8.1. Misissued Certificates
Misissued certificates that have not been publicly logged, and thus Misissued certificates that have not been publicly logged, and thus
do not have a valid SCT, will be rejected by TLS clients. Misissued do not have a valid SCT, are not considered compliant (so TLS clients
certificates that do have an SCT from a log will appear in that may decide, for example, to reject them). Misissued certificates
public log within the Maximum Merge Delay, assuming the log is that do have an SCT from a log will appear in that public log within
operating correctly. Thus, the maximum period of time during which a the Maximum Merge Delay, assuming the log is operating correctly.
misissued certificate can be used without being available for audit Thus, the maximum period of time during which a misissued certificate
is the MMD. can be used without being available for audit is the MMD.
8.2. Detection of Misissue 8.2. Detection of Misissue
The logs do not themselves detect misissued certificates; they rely The logs do not themselves detect misissued certificates; they rely
instead on interested parties, such as domain owners, to monitor them instead on interested parties, such as domain owners, to monitor them
and take corrective action when a misissue is detected. and take corrective action when a misissue is detected.
8.3. Redaction of Public Domain Name Labels 8.3. Redaction of Public Domain Name Labels
CAs SHOULD NOT redact domain name labels in precertificates such that CAs SHOULD NOT redact domain name labels in precertificates such that
skipping to change at page 36, line 27 skipping to change at page 38, line 47
order to protect the clients' privacy, these checks need not reveal order to protect the clients' privacy, these checks need not reveal
the exact certificate to the log. Clients can instead request the the exact certificate to the log. Clients can instead request the
proof from a trusted auditor (since anyone can compute the audit proof from a trusted auditor (since anyone can compute the audit
proofs from the log) or request Merkle proofs for a batch of proofs from the log) or request Merkle proofs for a batch of
certificates around the SCT timestamp. certificates around the SCT timestamp.
Violation of the append-only property can be detected by clients Violation of the append-only property can be detected by clients
comparing their instances of the Signed Tree Heads. As soon as two comparing their instances of the Signed Tree Heads. As soon as two
conflicting Signed Tree Heads for the same log are detected, this is conflicting Signed Tree Heads for the same log are detected, this is
cryptographic proof of that log's misbehavior. There are various cryptographic proof of that log's misbehavior. There are various
ways this could be done, for example via gossip (see http:// ways this could be done, for example via gossip (see
trac.tools.ietf.org/id/draft-linus-trans-gossip-00.txt) or peer-to- http://trac.tools.ietf.org/id/draft-linus-trans-gossip-00.txt) or
peer communications or by sending STHs to monitors (who could then peer-to-peer communications or by sending STHs to monitors (who could
directly check against their own copy of the relevant log). then directly check against their own copy of the relevant log).
8.5. Multiple SCTs 8.5. Multiple SCTs
TLS servers may wish to offer multiple SCTs, each from a different TLS servers may wish to offer multiple SCTs, each from a different
log. log.
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 from different logs misissuance from clients. Including SCTs from different logs
makes it more difficult to mount this attack. makes it more difficult to mount this attack.
skipping to change at page 37, line 21 skipping to change at page 39, line 43
maintain a copy of each entire log. The Signed Tree Heads can be maintain a copy of each entire log. The Signed Tree Heads can be
updated as new entries become available, without recomputing entire updated as new entries become available, without recomputing entire
trees. Third-party auditors need only fetch the Merkle consistency trees. Third-party auditors need only fetch the Merkle consistency
proofs against a log's existing STH to efficiently verify the append- proofs against a log's existing STH to efficiently verify the append-
only property of updates to their Merkle Trees, without auditing the only property of updates to their Merkle Trees, without auditing the
entire tree. entire tree.
10. Acknowledgements 10. 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, Stephen Farrell, Brad Hill, Jeff Hodges, Paul Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn
Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor Gillmor, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman,
Perrin, Ryan Sleevi and Carl Wallace for their valuable Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer,
contributions. Trevor Perrin, Pierre Phaneuf, Melinda Shore, Ryan Sleevi, Carl
Wallace and Paul Wouters for their valuable contributions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 2009, Signature Standard (DSS)", FIPS 186-3, June 2009,
<http://csrc.nist.gov/publications/fips/fips186-3/ <http://csrc.nist.gov/publications/fips/fips186-3/
fips_186-3.pdf>. fips_186-3.pdf>.
skipping to change at page 37, line 47 skipping to change at page 40, 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, March 1997. Requirement Levels", BCP 14, RFC 2119, 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, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/
RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [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, February 2003. Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, DOI
10.17487/RFC4627, July 2006,
<http://www.rfc-editor.org/info/rfc4627>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, 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, August 2008. (TLS) Protocol Version 1.2", RFC 5246, 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, May 2008. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, 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, September 2009. RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extension Definitions", RFC 6066, January 2011. Extensions: Extension Definitions", RFC 6066, 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, March 2011. Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
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, June 2013. RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, August 2013. Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>.
11.2. Informative References 11.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/ Log Policy", 2014, <http://www.chromium.org/Home/chromium-
chromium-security/certificate-transparency/log-policy>. security/certificate-transparency/log-policy>.
[Chromium.Policy] [Chromium.Policy]
The Chromium Projects, "Chromium Certificate The Chromium Projects, "Chromium Certificate
Transparency", 2014, <http://www.chromium.org/Home/ Transparency", 2014, <http://www.chromium.org/Home/
chromium-security/certificate-transparency>. chromium-security/certificate-transparency>.
[CrosbyWallach] [CrosbyWallach]
Crosby, S. and D. Wallach, "Efficient Data Structures for Crosby, S. and D. Wallach, "Efficient Data Structures for
Tamper-Evident Logging", Proceedings of the 18th USENIX Tamper-Evident Logging", Proceedings of the 18th USENIX
Security Symposium, Montreal, August 2009, Security Symposium, Montreal, August 2009,
skipping to change at page 39, line 34 skipping to change at page 42, line 34
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>.
[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>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013. Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>.
Authors' Addresses Authors' Addresses
Ben Laurie Ben Laurie
Google UK Ltd. Google UK Ltd.
EMail: benl@google.com EMail: benl@google.com
Adam Langley Adam Langley
Google Inc. Google Inc.
 End of changes. 86 change blocks. 
236 lines changed or deleted 338 lines changed or added

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