draft-ietf-trans-rfc6962-bis-11.txt   draft-ietf-trans-rfc6962-bis-12.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: May 23, 2016 E. Messeri Expires: July 31, 2016 E. Messeri
Google Google
R. Stradling R. Stradling
Comodo Comodo
November 20, 2015 January 28, 2016
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-11 draft-ietf-trans-rfc6962-bis-12
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 May 23, 2016. This Internet-Draft will expire on July 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 10 skipping to change at page 3, line 10
6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23 6. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 23
6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 25 6.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 25
6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 26 6.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 26
6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 26 6.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 26
6.4. Retrieve Merkle Consistency Proof between Two Signed Tree 6.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 27 6.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 27
6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and 6.6. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 28 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 28
6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29 6.7. Retrieve Entries and STH from Log . . . . . . . . . . . . 29
6.8. Retrieve Accepted Root Certificates . . . . . . . . . . . 31 6.8. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 31
7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. TLS Extension . . . . . . . . . . . . . . . . . . . . . . 32 7.1. TLS Extension . . . . . . . . . . . . . . . . . . . . . . 32
8. Certification Authorities . . . . . . . . . . . . . . . . . . 32 8. Certification Authorities . . . . . . . . . . . . . . . . . . 32
8.1. Transparency Information X.509v3 Extension . . . . . . . 32 8.1. Transparency Information X.509v3 Extension . . . . . . . 32
8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 33 8.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 33
8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 33 8.1.2. Certificate Extension . . . . . . . . . . . . . . . . 33
9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Metadata . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 34 9.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 34
9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 36 9.4. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 36
9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 37 9.4.1. Verifying an inclusion proof . . . . . . . . . . . . 37
9.4.2. Verifying consistency between two STHs . . . . . . . 37 9.4.2. Verifying consistency between two STHs . . . . . . . 37
9.4.3. Verifying root hash given entries . . . . . . . . . . 38 9.4.3. Verifying root hash given entries . . . . . . . . . . 38
10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 39 10. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 39 11.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 39
11.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 39 11.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 39
11.3. TransItem Extensions . . . . . . . . . . . . . . . . . . 39 11.3. TransItem Extensions . . . . . . . . . . . . . . . . . . 39
11.4. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 40 11.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 40
11.5. STH Extensions . . . . . . . . . . . . . . . . . . . . . 40 11.5. SCT Extensions . . . . . . . . . . . . . . . . . . . . . 40
11.6. STH Extensions . . . . . . . . . . . . . . . . . . . . . 40
12. Security Considerations . . . . . . . . . . . . . . . . . . . 40 12. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 41 12.1. Misissued Certificates . . . . . . . . . . . . . . . . . 41
12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 41 12.2. Detection of Misissue . . . . . . . . . . . . . . . . . 41
12.3. Redaction of Public Domain Name Labels . . . . . . . . . 41 12.3. Redaction of Public Domain Name Labels . . . . . . . . . 41
12.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 41 12.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 41
12.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 42 12.5. Deterministic Signatures . . . . . . . . . . . . . . . . 42
13. Efficiency Considerations . . . . . . . . . . . . . . . . . . 42 12.6. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 42
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.1. Normative References . . . . . . . . . . . . . . . . . . 43 14.1. Normative References . . . . . . . . . . . . . . . . . . 43
15.2. Informative References . . . . . . . . . . . . . . . . . 45 14.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. TransItemV1 . . . . . . . . . . . . . . . . . . . . 46 Appendix A. TransItemV1 . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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 append-only logs of issued certificates.
logs of all issued certificates. The logs are publicly auditable so The logs do not need to be trusted because they are publicly
that it is possible for anyone to verify the correctness of each log auditable. Anyone may verify the correctness of each log and monitor
and to monitor when new certificates are added to it. The logs do when new certificates are added to it. The logs do not themselves
not themselves prevent misissue, but they ensure that interested prevent misissue, but they ensure that interested parties
parties (particularly those named in certificates) can detect such (particularly those named in certificates) can detect such
misissuance. Note that this is a general mechanism, but in this misissuance. Note that this is a general mechanism, but in this
document, we only describe its use for public TLS server certificates document, we only describe its use for public TLS server certificates
issued by public certification authorities (CAs). issued by public certification authorities (CAs).
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 the
submitting large numbers of spurious certificates, it is required submission of large numbers of spurious certificates, it is required
that each chain is rooted in a CA certificate accepted by the log. that each chain ends with a trust anchor that is accepted by the log.
When a chain is submitted to a log, a signed timestamp is returned, When a chain is accepted by a log, a signed timestamp is returned,
which can later be used to provide evidence to TLS clients that the which can later be used to provide evidence to TLS clients that the
chain has been submitted. TLS clients can thus require that all chain has been submitted. TLS clients can thus require that all
certificates they accept as valid are accompanied by signed certificates they accept as valid are accompanied by signed
timestamps. timestamps.
Those who are concerned about misissue can monitor the logs, asking Those who are concerned about 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
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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 34 skipping to change at page 7, line 34
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 9, line 46 skipping to change at page 9, line 46
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l. hash can be verified using hash1=k and l.
The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i,
j, k]. k, i are used to verify hash2, and j is additionally used to j, k]. k, i are used to verify hash2, and j is additionally used to
show hash is consistent with hash2. show hash is consistent with hash2.
2.1.4. Signatures 2.1.4. Signatures
Various data structures are signed. A log MUST use either Various data structures are signed. A log MUST use one of the
deterministic ECDSA [RFC6979] using the NIST P-256 curve signature algorithms defined in the Section 11.4 section.
(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
of [RFC3447]) using a key of at least 2048 bits.
3. Submitters 3. Submitters
Submitters submit certificates or precertificates to logs for public Submitters submit certificates or precertificates to logs for public
auditing, as described below. In order to enable attribution of each auditing, as described below. In order to enable attribution of each
logged certificate or precertificate to its issuer, each submission logged certificate or precertificate to its issuer, each submission
MUST be accompanied by all additional certificates required to verify MUST be accompanied by all additional certificates required to verify
the chain up to an accepted root certificate. The root certificate the chain up to an accepted trust anchor. The trust anchor (a root
itself MAY be omitted from the submission. or intermediate CA certificate) MAY be omitted from the submission.
If a log accepts a submission, it will return a Signed Certificate If a log accepts a submission, it will return a Signed Certificate
Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the Timestamp (SCT) (see Section 5.6). The submitter SHOULD validate the
returned SCT as described in Section 9.2 if they understand its returned SCT as described in Section 9.2 if they understand its
format and they intend to use it directly in a TLS handshake or to format and they intend to use it directly in a TLS handshake or to
construct a certificate. construct a certificate.
3.1. Certificates 3.1. Certificates
Anyone can submit a certificate (Section 6.1) to a log. Since Anyone can submit a certificate (Section 6.1) to a log. Since
skipping to change at page 13, line 48 skipping to change at page 13, line 48
log has previously seen this valid submission, it MAY return the same log has previously seen this valid submission, it MAY return the same
SCT as it returned before. (Note that if a certificate was SCT as it returned before. (Note that if a certificate was
previously logged as a precertificate, then the precertificate's SCT previously logged as a precertificate, then the precertificate's SCT
of type "precert_sct" would not be appropriate; instead, a fresh SCT of type "precert_sct" would not be appropriate; instead, a fresh SCT
of type "x509_sct" should be generated). of type "x509_sct" should be generated).
An SCT is the log's promise to incorporate the submitted entry in its An SCT is the log's promise to incorporate the submitted entry in its
Merkle Tree no later than a fixed amount of time, known as the Merkle Tree no later than a fixed amount of time, known as the
Maximum Merge Delay (MMD), after the issuance of the SCT. Maximum Merge Delay (MMD), after the issuance of the SCT.
Periodically, the log MUST append all its new entries to its Merkle Periodically, the log MUST append all its new entries to its Merkle
Tree and sign the root of the tree. This provides auditable evidence Tree and sign the root of the tree.
that the log kept all its promises.
Log operators MUST NOT impose any conditions on retrieving or sharing Log operators MUST NOT impose any conditions on retrieving or sharing
data from the log. data from the log.
5.1. Accepting Submissions 5.1. Accepting Submissions
Logs MUST verify that each submitted certificate or precertificate Logs MUST verify that each submitted certificate or precertificate
has a valid signature chain to an accepted root certificate, using has a valid signature chain to an accepted trust anchor, using the
the chain of intermediate CA certificates provided by the submitter. chain of intermediate CA certificates provided by the submitter.
Logs MUST accept certificates and precertificates that are fully Logs MUST accept certificates and precertificates that are fully
valid according to RFC 5280 [RFC5280] verification rules and are valid according to RFC 5280 [RFC5280] verification rules and are
submitted with such a chain. Logs MAY accept certificates and submitted with such a chain. Logs MAY accept certificates and
precertificates that have expired, are not yet valid, have been precertificates that have expired, are not yet valid, have been
revoked, or are otherwise not fully valid according to RFC 5280 revoked, or are otherwise not fully valid according to RFC 5280
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 root certificate. Logs MUST valid signature chain to an accepted trust anchor. Logs MUST also
also reject precertificates that do not conform to the requirements reject precertificates that do not conform to the requirements in
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 root The log SHALL allow retrieval of its list of accepted trust anchors
certificates (see Section 6.8). This list might usefully be the (see Section 6.8), each of which is a root or intermediate CA
union of root certificates trusted by major browser vendors. certificate. This list might usefully be the union of root
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 root intermediate CA certificates provided by the submitter, and the trust
certificate 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
submission). The log MUST present this chain for auditing upon submission). The log MUST present this chain for auditing upon
request (see Section 6.7). This chain is required to prevent a CA request (see Section 6.7). This chain is required to prevent a CA
from avoiding blame by logging a partial or empty chain. from avoiding blame by logging a partial or empty chain.
Each certificate entry in a log MUST include a "X509ChainEntry" Each certificate entry in a log MUST include a "X509ChainEntry"
structure, and each precertificate entry MUST include a structure, and each precertificate entry MUST include a
"PrecertChainEntryV2" structure: "PrecertChainEntryV2" structure:
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
skipping to change at page 15, line 29 skipping to change at page 15, line 29
CMSPrecert pre_certificate; CMSPrecert pre_certificate;
ASN.1Cert precertificate_chain<1..2^24-1>; ASN.1Cert precertificate_chain<1..2^24-1>;
} PrecertChainEntryV2; } PrecertChainEntryV2;
"leaf_certificate" is a submitted certificate that has been accepted "leaf_certificate" is a submitted certificate that has been accepted
by the log. by the log.
"certificate_chain" is a vector of 0 or more additional certificates "certificate_chain" is a vector of 0 or more additional certificates
required to verify "leaf_certificate". The first certificate MUST required to verify "leaf_certificate". The first certificate MUST
certify "leaf_certificate". Each following certificate MUST directly certify "leaf_certificate". Each following certificate MUST directly
certify the one preceding it. The final certificate MUST be a root certify the one preceding it. The final certificate MUST be a trust
certificate accepted by the log. If "leaf_certificate" is a root anchor accepted by the log. If "leaf_certificate" is an accepted
certificate, then this vector is empty. trust anchor, then this vector is empty.
"pre_certificate" is a submitted precertificate that has been "pre_certificate" is a submitted precertificate that has been
accepted by the log. accepted by the log.
"precertificate_chain" is a vector of 1 or more additional "precertificate_chain" is a vector of 1 or more additional
certificates required to verify "pre_certificate". The first certificates required to verify "pre_certificate". The first
certificate MUST certify "pre_certificate". Each following certificate MUST certify "pre_certificate". Each following
certificate MUST directly certify the one preceding it. The final certificate MUST directly certify the one preceding it. The final
certificate MUST be a root certificate accepted by the log. certificate MUST be a trust anchor accepted by the log.
5.3. Log ID 5.3. Log ID
Each log's operator allocates an OID for the purpose of uniquely Each log's operator allocates an OID for the purpose of uniquely
identifying that log. This OID is specified in the log's metadata. identifying that log. This OID is specified in the log's metadata.
Various data structures include the DER encoding of this OID, Various data structures include the DER encoding of this OID,
excluding the ASN.1 tag and length bytes, in an opaque vector: excluding the ASN.1 tag and length bytes, in an opaque vector:
opaque LogID<2..127>; opaque LogID<2..127>;
skipping to change at page 20, line 10 skipping to change at page 20, line 10
} SignedCertificateTimestampDataV2; } SignedCertificateTimestampDataV2;
"log_id" is this log's unique ID, encoded in an opaque vector as "log_id" is this log's unique ID, encoded in an opaque vector as
described in Section 5.3. described in Section 5.3.
"timestamp" is equal to the timestamp from the "timestamp" is equal to the timestamp from the
"TimestampedCertificateEntryDataV2" structure encapsulated in the "TimestampedCertificateEntryDataV2" structure encapsulated in the
"timestamped_entry". "timestamped_entry".
"sct_extension_type" identifies a single extension from the IANA "sct_extension_type" identifies a single extension from the IANA
registry in Section 11.4. At the time of writing, no extensions are registry in Section 11.5. At the time of writing, no extensions are
specified. specified.
The interpretation of the "sct_extension_data" field is determined The interpretation of the "sct_extension_data" field is determined
solely by the value of the "sct_extension_type" field. Each document solely by the value of the "sct_extension_type" field. Each document
that registers a new "sct_extension_type" must describe how to that registers a new "sct_extension_type" must describe how to
interpret the corresponding "sct_extension_data". interpret the corresponding "sct_extension_data".
"sct_extensions" is a vector of 0 or more SCT extensions. This "sct_extensions" is a vector of 0 or more SCT extensions. This
vector MUST NOT include more than one extension with the same vector MUST NOT include more than one extension with the same
"sct_extension_type". The extensions in the vector MUST be ordered "sct_extension_type". The extensions in the vector MUST be ordered
skipping to change at page 22, line 12 skipping to change at page 22, line 12
Each subsequent timestamp MUST be more recent than the timestamp of Each subsequent timestamp MUST be more recent than the timestamp of
the previous update. the previous update.
"tree_size" is equal to the tree size from the "TreeHeadDataV2" "tree_size" is equal to the tree size from the "TreeHeadDataV2"
structure encapsulated in "merkle_tree_head". structure encapsulated in "merkle_tree_head".
"root_hash" is equal to the root hash from the "TreeHeadDataV2" "root_hash" is equal to the root hash from the "TreeHeadDataV2"
structure encapsulated in "merkle_tree_head". structure encapsulated in "merkle_tree_head".
"sth_extension_type" identifies a single extension from the IANA "sth_extension_type" identifies a single extension from the IANA
registry in Section 11.5. At the time of writing, no extensions are registry in Section 11.6. At the time of writing, no extensions are
specified. specified.
The interpretation of the "sth_extension_data" field is determined The interpretation of the "sth_extension_data" field is determined
solely by the value of the "sth_extension_type" field. Each document solely by the value of the "sth_extension_type" field. Each document
that registers a new "sth_extension_type" must describe how to that registers a new "sth_extension_type" must describe how to
interpret the corresponding "sth_extension_data". interpret the corresponding "sth_extension_data".
"sth_extensions" is a vector of 0 or more STH extensions. This "sth_extensions" is a vector of 0 or more STH extensions. This
vector MUST NOT include more than one extension with the same vector MUST NOT include more than one extension with the same
"sth_extension_type". The extensions in the vector MUST be ordered "sth_extension_type". The extensions in the vector MUST be ordered
skipping to change at page 24, line 37 skipping to change at page 24, line 37
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 25, line 13 skipping to change at page 25, line 13
client to wait before retrying the request. client to wait before retrying the request.
6.1. Add Chain to Log 6.1. Add Chain to Log
POST https://<log server>/ct/v2/add-chain POST https://<log server>/ct/v2/add-chain
Inputs: Inputs:
chain: An array of base64 encoded certificates. The first chain: An array of base64 encoded certificates. The first
element is the certificate for which the submitter desires an element is the certificate for which the submitter desires an
SCT; the second chains to the first and so on to the last, SCT; the second certifies the first and so on to the last,
which is either an accepted root certificate or a certificate which either is, or is certified by, an accepted trust anchor.
that chains to an accepted root certificate.
Outputs: Outputs:
sct: A base64 encoded "TransItem" of type "x509_sct", signed by sct: A base64 encoded "TransItem" of type "x509_sct", signed by
this log, that corresponds to the submitted certificate. this log, that corresponds to the submitted certificate.
Error codes: Error codes:
unknown root The root of the chain is not one accepted by the unknown anchor The last certificate in the chain both is not, and
log. is not certified by, an accepted trust anchor.
bad chain The alleged chain is not actually a chain of bad chain The alleged chain is not actually a chain of
certificates. certificates.
bad certificate One or more certificates in the chain are not bad certificate One or more certificates in the chain are not
valid (e.g. not properly encoded). valid (e.g. not properly encoded).
If the version of "sct" is not v2, then a v2 client may be unable to If the version of "sct" is not v2, then a v2 client may be unable to
verify the signature. It MUST NOT construe this as an error. This verify the signature. It MUST NOT construe this as an error. This
is to avoid forcing an upgrade of compliant v2 clients that do not is to avoid forcing an upgrade of compliant v2 clients that do not
skipping to change at page 26, line 14 skipping to change at page 26, line 14
6.2. Add PreCertChain to Log 6.2. Add PreCertChain to Log
POST https://<log server>/ct/v2/add-pre-chain POST https://<log server>/ct/v2/add-pre-chain
Inputs: Inputs:
precertificate: The base64 encoded precertificate. precertificate: The base64 encoded precertificate.
chain: An array of base64 encoded CA certificates. The first chain: An array of base64 encoded CA certificates. The first
element is the signer of the precertificate; the second chains element is the signer of the precertificate; the second
to the first and so on to the last, which is either an accepted certifies the first and so on to the last, which either is, or
root certificate or a certificate that chains to an accepted is certified by, an accepted trust anchor.
root certificate.
Outputs: Outputs:
sct: A base64 encoded "TransItem" of type "precert_sct", signed sct: A base64 encoded "TransItem" of type "precert_sct", signed
by this log, that corresponds to the submitted precertificate. by this log, that corresponds to the submitted precertificate.
Errors are the same as in Section 6.1. Errors are the same as in Section 6.1.
6.3. Retrieve Latest Signed Tree Head 6.3. Retrieve Latest Signed Tree Head
skipping to change at page 31, line 5 skipping to change at page 31, line 5
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 9.4.3 for an outline of how to use a complete list of See Section 9.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. Retrieve Accepted Root Certificates 6.8. Retrieve Accepted Trust Anchors
GET https://<log server>/ct/v2/get-roots GET https://<log server>/ct/v2/get-anchors
No inputs. No inputs.
Outputs: Outputs:
certificates: An array of base64 encoded root certificates that certificates: An array of base64 encoded trust anchors that are
are acceptable to the log. acceptable to the log.
max_chain: If the server has chosen to limit the length of chains max_chain: If the server has chosen to limit the length of chains
it accepts, this is the maximum number of certificates in the it accepts, this is the maximum number of certificates in the
chain, in decimal. If there is no limit, this is omitted. chain, in decimal. If there is no limit, this is omitted.
7. TLS Servers 7. TLS Servers
TLS servers MUST use at least one of the three mechanisms listed TLS servers MUST use at least one of the three mechanisms listed
below to present one or more SCTs or inclusion proofs from one or below to present one or more SCTs or inclusion proofs from one or
more logs to each TLS client during TLS handshakes, where each SCT or more logs to each TLS client during TLS handshakes, where each SCT or
skipping to change at page 31, line 37 skipping to change at page 31, line 37
mechanisms are provided because they have different tradeoffs. mechanisms are provided because they have different tradeoffs.
o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type
"transparency_info" (see Section 7.1). This mechanism allows TLS "transparency_info" (see Section 7.1). This mechanism allows TLS
servers to participate in CT without the cooperation of CAs, servers to participate in CT without the cooperation of CAs,
unlike the other two mechanisms. It also allows SCTs and unlike the other two mechanisms. It also allows SCTs and
inclusion proofs to be updated on the fly. inclusion proofs to be updated on the fly.
o An Online Certificate Status Protocol (OCSP) [RFC6960] response o An Online Certificate Status Protocol (OCSP) [RFC6960] response
extension (see Section 8.1.1), where the OCSP response is provided extension (see Section 8.1.1), where the OCSP response is provided
in the "certificate_status" TLS extension (Section 8 of in the "CertificateStatus" message, provided that the TLS client
[RFC6066]), also known as OCSP stapling. This mechanism is included the "status_request" extension in the (extended)
already widely (but not universally) implemented. It also allows "ClientHello" (Section 8 of [RFC6066]). This mechanism, popularly
SCTs and inclusion proofs to be updated on the fly. known as OCSP stapling, is already widely (but not universally)
implemented. It also allows SCTs and inclusion proofs to be
updated on the fly.
o An X509v3 certificate extension (see Section 8.1.2). This o An X509v3 certificate extension (see Section 8.1.2). This
mechanism allows the use of unmodified TLS servers, but the SCTs mechanism allows the use of unmodified TLS servers, but the SCTs
and inclusion proofs cannot be updated on the fly. Since the logs and inclusion proofs cannot be updated on the fly. Since the logs
from where the SCTs and inclusion proofs originated won't from where the SCTs and inclusion proofs originated won't
necessarily be accepted by TLS clients for the full lifetime of necessarily be accepted by TLS clients for the full lifetime of
the certificate, there is a risk that TLS clients will the certificate, there is a risk that TLS clients will
subsequently consider the certificate to be non-compliant and in subsequently consider the certificate to be non-compliant and in
need of re-issuance. need of re-issuance.
skipping to change at page 38, line 5 skipping to change at page 38, line 5
2. Set "fn" to "first - 1" and "sn" to "second - 1". 2. Set "fn" to "first - 1" and "sn" to "second - 1".
3. If "LSB(fn)" is set, then right-shift both "fn" and "sn" equally 3. If "LSB(fn)" is set, then right-shift both "fn" and "sn" equally
until "LSB(fn)" is not set. until "LSB(fn)" is not set.
4. Set both "fr" and "sr" to the first value in the 4. Set both "fr" and "sr" to the first value in the
"consistency_path" array. "consistency_path" array.
5. For each subsequent value "c" in the "consistency_path" array: 5. For each subsequent value "c" in the "consistency_path" array:
If "sn" is 0, stop the iteration and fail the proof verification.
If "LSB(fn)" is set, or if "fn" is equal to "sn", then: If "LSB(fn)" is set, or if "fn" is equal to "sn", then:
1. Set "fr" to "HASH(0x01 || c || fr)" 1. Set "fr" to "HASH(0x01 || c || fr)"
Set "sr" to "HASH(0x01 || c || sr)" Set "sr" to "HASH(0x01 || c || sr)"
2. If "LSB(fn)" is not set, then right-shift both "fn" and "sn" 2. If "LSB(fn)" is not set, then right-shift both "fn" and "sn"
equally until either "LSB(fn)" is set or "fn" is "0". equally until either "LSB(fn)" is set or "fn" is "0".
Otherwise: Otherwise:
Set "sr" to "HASH(0x01 || sr || c)" Set "sr" to "HASH(0x01 || sr || c)"
Finally, right-shift both "fn" and "sn" one time. Finally, right-shift both "fn" and "sn" one time.
6. After completing iterating through the "consistency_path" array 6. After completing iterating through the "consistency_path" array
as described above, verify that the "fr" calculated is equal to as described above, verify that the "fr" calculated is equal to
the "first_hash" supplied and that the "sr" calculated is equal the "first_hash" supplied, that the "sr" calculated is equal to
to the "second_hash" supplied. the "second_hash" supplied and that "sn" is 0.
9.4.3. Verifying root hash given entries 9.4.3. Verifying root hash given entries
When a client has a complete list of leaf input "entries" from "0" up When a client has a complete list of leaf input "entries" from "0" up
to "tree_size - 1" and wishes to verify this list against an STH to "tree_size - 1" and wishes to verify this list against an STH
"root_hash" returned by the log for the same "tree_size", the "root_hash" returned by the log for the same "tree_size", the
following algorithm may be used: following algorithm may be used:
1. Set "stack" to an empty stack. 1. Set "stack" to an empty stack.
skipping to change at page 40, line 5 skipping to change at page 40, line 5
initially consisting of: initially consisting of:
+-------+-----------+ +-------+-----------+
| Type | Extension | | Type | Extension |
+-------+-----------+ +-------+-----------+
| 65535 | reserved | | 65535 | reserved |
+-------+-----------+ +-------+-----------+
TBD: policy for adding to the registry TBD: policy for adding to the registry
11.4. SCT Extensions 11.4. Signature Algorithms
IANA is asked to establish a registry of signature algorithm values,
initially consisting of:
+-------+-----------------------------------------------------------+
| Index | Signature Algorithm |
+-------+-----------------------------------------------------------+
| 0 | deterministic ECDSA [RFC6979] using the NIST P-256 curve |
| | (Section D.1.2.3 of the Digital Signature Standard [DSS]) |
| | and HMAC-SHA256 |
| 1 | RSA signatures (RSASSA-PKCS1-v1_5 with SHA-256, Section |
| | 8.2 of [RFC3447]) using a key of at least 2048 bits. |
+-------+-----------------------------------------------------------+
11.5. SCT Extensions
IANA is asked to establish a registry of SCT extensions, initially IANA is asked to establish a registry of SCT extensions, initially
consisting of: consisting of:
+-------+-----------+ +-------+-----------+
| Type | Extension | | Type | Extension |
+-------+-----------+ +-------+-----------+
| 65535 | reserved | | 65535 | reserved |
+-------+-----------+ +-------+-----------+
TBD: policy for adding to the registry TBD: policy for adding to the registry
11.5. STH Extensions 11.6. STH Extensions
IANA is asked to establish a registry of STH extensions, initially IANA is asked to establish a registry of STH extensions, initially
consisting of: consisting of:
+-------+-----------+ +-------+-----------+
| Type | Extension | | Type | Extension |
+-------+-----------+ +-------+-----------+
| 65535 | reserved | | 65535 | reserved |
+-------+-----------+ +-------+-----------+
TBD: policy for adding to the registry TBD: policy for adding to the registry
12. Security Considerations 12. Security Considerations
With CAs, logs, and servers performing the actions described here, With CAs, logs, and servers performing the actions described here,
TLS clients can use logs and signed timestamps to reduce the TLS clients can use logs and signed timestamps to reduce the
likelihood that they will accept misissued certificates. If a server likelihood that they will accept misissued certificates. If a server
presents a valid signed timestamp for a certificate, then the client presents a valid signed timestamp for a certificate, then the client
knows that a log has committed to publishing the certificate. From knows that a log has committed to publishing the certificate. From
this, the client knows that the subject of the certificate has had this, the client knows that monitors acting for the subject of the
some time to notice the misissue and take some action, such as asking certificate have had some time to notice the misissue and take some
a CA to revoke a misissued certificate, or that the log has action, such as asking a CA to revoke a misissued certificate, or
misbehaved, which will be discovered when the SCT is audited. A that the log has misbehaved, which will be discovered when the SCT is
signed timestamp is not a guarantee that the certificate is not audited. A signed timestamp is not a guarantee that the certificate
misissued, since the subject of the certificate might not have is not misissued, since appropriate monitors might not have checked
checked the logs or the CA might have refused to revoke the the logs or the CA might have refused to revoke the 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.
12.1. Misissued Certificates 12.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, are not considered compliant (so TLS clients do not have a valid SCT, are not considered compliant (so TLS clients
skipping to change at page 42, line 9 skipping to change at page 42, line 21
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 ways this could be done, for example via gossip (see http://
http://trac.tools.ietf.org/id/draft-linus-trans-gossip-00.txt) or trac.tools.ietf.org/id/draft-linus-trans-gossip-00.txt) or peer-to-
peer-to-peer communications or by sending STHs to monitors (who could peer communications or by sending STHs to monitors (who could then
then directly check against their own copy of the relevant log). directly check against their own copy of the relevant log).
12.5. Multiple SCTs 12.5. Deterministic Signatures
Logs are required to use deterministic signatures for the following
reasons:
o Using non-deterministic ECDSA with a predictable source of
randomness means that each signature can potentially expose the
secret material of the signing key.
o Clients that gossip STHs or report back SCTs can be tracked or
traced if a log was to produce multiple STHs or SCTs with the same
timestamp and data but different signatures.
12.6. 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.
o If a log misbehaves, a consequence may be that clients cease to o If a log misbehaves, a consequence may be that clients cease to
trust it. Since the time an SCT may be in use can be considerable trust it. Since the time an SCT may be in use can be considerable
skipping to change at page 42, line 36 skipping to change at page 43, line 13
embedded in a certificate), servers may wish to reduce the embedded in a certificate), servers may wish to reduce the
probability of their certificates being rejected as a result by probability of their certificates being rejected as a result by
including SCTs from different logs. including SCTs from different logs.
o TLS clients may have policies related to the above risks requiring o TLS clients may have policies related to the above risks requiring
servers to present multiple SCTs. For example Chromium servers to present multiple SCTs. For example Chromium
[Chromium.Log.Policy] currently requires multiple SCTs to be [Chromium.Log.Policy] currently requires multiple SCTs to be
presented with EV certificates in order for the EV indicator to be presented with EV certificates in order for the EV indicator to be
shown. shown.
13. Efficiency Considerations 13. Acknowledgements
The Merkle Tree design serves the purpose of keeping communication
overhead low.
Auditing logs for integrity does not require third parties to
maintain a copy of each entire log. The Signed Tree Heads can be
updated as new entries become available, without recomputing entire
trees. Third-party auditors need only fetch the Merkle consistency
proofs against a log's existing STH to efficiently verify the append-
only property of updates to their Merkle Trees, without auditing the
entire tree.
14. Acknowledgements
The authors would like to thank Erwann Abelea, Robin Alden, Al The authors would like to thank Erwann Abelea, Robin Alden, Al
Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn Cutter, Francis Dupont, Adam Eijdenberg, Stephen Farrell, Daniel Kahn
Gillmor, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Gillmor, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman,
Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer, Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer,
Trevor Perrin, Pierre Phaneuf, Melinda Shore, Ryan Sleevi, Carl Trevor Perrin, Pierre Phaneuf, Melinda Shore, Ryan Sleevi, Carl
Wallace and Paul Wouters for their valuable contributions. Wallace and Paul Wouters for their valuable contributions.
15. References 14. References
15.1. Normative References 14.1. Normative References
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 2009, Signature Standard (DSS)", FIPS 186-3, June 2009,
<http://csrc.nist.gov/publications/fips/fips186-3/ <http://csrc.nist.gov/publications/fips/fips186-3/
fips_186-3.pdf>. fips_186-3.pdf>.
[FIPS.180-4] [FIPS.180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, March 1997.
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, DOI 10.17487/ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
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, DOI JavaScript Object Notation (JSON)", RFC 4627, July 2006.
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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
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, DOI Extension Definitions", RFC 6066, January 2011.
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>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>. 2013, <http://www.rfc-editor.org/info/rfc6979>.
15.2. Informative References 14.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/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 45, line 41 skipping to change at page 45, line 29
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, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, June 2013.
<http://www.rfc-editor.org/info/rfc6962>.
Appendix A. TransItemV1 Appendix A. TransItemV1
TODO: Finish writing this section. Or should it be in a separate TODO: Finish writing this section. Or should it be in a separate
document? document?
struct { struct {
TransType type; TransType type;
select (type) { select (type) {
case x509_sct: SignedCertificateTimestampV1; case x509_sct: SignedCertificateTimestampV1;
 End of changes. 55 change blocks. 
136 lines changed or deleted 133 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/