draft-ietf-trans-rfc6962-bis-04.txt   draft-ietf-trans-rfc6962-bis-05.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 11, 2015 Google Expires: July 31, 2015 E. Messeri
Google
R. Stradling R. Stradling
Comodo Comodo
July 10, 2014 January 27, 2015
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-03 draft-ietf-trans-rfc6962-bis-05
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 certificate observed, in a manner that allows anyone to audit certificate
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 43 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 11, 2015. This Internet-Draft will expire on July 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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. Informal Introduction . . . . . . . . . . . . . . . . . . . . 3 1. Informal Introduction . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 4 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 4 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 4
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 4 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Merkle Audit Paths . . . . . . . . . . . . . . . . . 5 2.1.1. Merkle Inclusion Proofs . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 8
3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9
3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12 3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12
3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 12 3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 12
3.2.2. Redacting Domain Name Labels in Precertificates . . . 12 3.2.2. Redacting Domain Name Labels in Precertificates . . . 12
3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 13 3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 13
3.3. Structure of the Signed Certificate Timestamp . . . . . . 14 3.3. Structure of the Signed Certificate Timestamp . . . . . . 14
3.4. Including the Signed Certificate Timestamp in the TLS 3.4. Including the Signed Certificate Timestamp in the TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15 Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 17 3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 16
3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 17 3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 18 3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 17
4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 19 4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 18
4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 20 4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 19
4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 21 4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 20
4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 21 4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 21
4.4. Retrieve Merkle Consistency Proof between Two Signed Tree 4.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash . . . . 22 4.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 21
4.6. Retrieve Entries from Log . . . . . . . . . . . . . . . . 22 4.6. Retrieve Entries from Log . . . . . . . . . . . . . . . . 22
4.7. Retrieve Accepted Root Certificates . . . . . . . . . . . 23 4.7. Retrieve Accepted Root Certificates . . . . . . . . . . . 23
4.8. Retrieve Entry+Merkle Audit Proof from Log . . . . . . . 24 4.8. Retrieve Entry+Merkle Inclusion Proof from Log . . . . . 23
5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Submitters . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Submitters . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4. Auditor . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. Auditor . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 26 6.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 26
6.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 26 6.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Misissued Certificates . . . . . . . . . . . . . . . . . 27 7.1. Misissued Certificates . . . . . . . . . . . . . . . . . 27
7.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 27 7.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 27
7.3. Redaction of Public Domain Name Labels . . . . . . . . . 27 7.3. Redaction of Public Domain Name Labels . . . . . . . . . 27
7.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 28 7.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 27
8. Efficiency Considerations . . . . . . . . . . . . . . . . . . 28 8. Efficiency Considerations . . . . . . . . . . . . . . . . . . 28
9. Future Changes . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 29
1. Informal Introduction 1. Informal 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 5, line 33 skipping to change at page 5, line 37
calculations for leaves and nodes differ. This domain separation is calculations for leaves and nodes differ. This domain separation is
required to give second preimage resistance.) required to give second preimage resistance.)
Note that we do not require the length of the input list to be a Note that we do not require the length of the input list to be a
power of two. The resulting Merkle Tree may thus not be balanced; power of two. The resulting Merkle Tree may thus not be balanced;
however, its shape is uniquely determined by the number of leaves. however, its shape is uniquely determined by the number of leaves.
(Note: This Merkle Tree is essentially the same as the history tree (Note: This Merkle Tree is essentially the same as the history tree
[CrosbyWallach] proposal, except our definition handles non-full [CrosbyWallach] proposal, except our definition handles non-full
trees differently.) trees differently.)
2.1.1. Merkle Audit Paths 2.1.1. Merkle Inclusion Proofs
A Merkle audit path for a leaf in a Merkle Hash Tree is the shortest A Merkle inclusion proof for a leaf in a Merkle Hash Tree is the
list of additional nodes in the Merkle Tree required to compute the shortest list of additional nodes in the Merkle Tree required to
Merkle Tree Hash for that tree. Each node in the tree is either a compute the Merkle Tree Hash for that tree. Each node in the tree is
leaf node or is computed from the two nodes immediately below it either a leaf node or is computed from the two nodes immediately
(i.e., towards the leaves). At each step up the tree (towards the below it (i.e., towards the leaves). At each step up the tree
root), a node from the audit path is combined with the node computed (towards the root), a node from the inclusion proof is combined with
so far. In other words, the audit path consists of the list of the node computed so far. In other words, the inclusion proof
missing nodes required to compute the nodes leading from a leaf to consists of the list of missing nodes required to compute the nodes
the root of the tree. If the root computed from the audit path leading from a leaf to the root of the tree. If the root computed
matches the true root, then the audit path is proof that the leaf from the inclusion proof matches the true root, then the inclusion
exists in the tree. proof proves that the leaf exists in the tree.
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 audit path PATH(m, D[n]) for the (m+1)th input d(n-1)}, the Merkle inclusion proof PATH(m, D[n]) for the (m+1)th
d(m), 0 <= m < n, is defined as follows: input d(m), 0 <= m < n, is defined as follows:
The path 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 path For n > 1, let k be the largest power of two smaller than n. The
for the (m+1)th element d(m) in a list of n > m elements is then proof for the (m+1)th element d(m) in a list of n > m elements is
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.
2.1.2. Merkle Consistency Proofs 2.1.2. Merkle Consistency Proofs
skipping to change at page 7, line 43 skipping to change at page 7, line 45
k l k l
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
g h i j g h i j
/ \ / \ / \ | / \ / \ / \ |
a b c d e f d6 a b c d e f d6
| | | | | | | | | | | |
d0 d1 d2 d3 d4 d5 d0 d1 d2 d3 d4 d5
The audit path for d0 is [b, h, l]. The inclusion proof for d0 is [b, h, l].
The audit path for d3 is [c, g, l]. The inclusion proof for d3 is [c, g, l].
The audit path for d4 is [f, j, k]. The inclusion proof for d4 is [f, j, k].
The audit path for d6 is [i, k]. The inclusion proof for d6 is [i, k].
The same tree, built incrementally in four steps: The same tree, built incrementally in four steps:
hash0 hash1=k hash0 hash1=k
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
g c g h g c g h
/ \ | / \ / \ / \ | / \ / \
a b d2 a b c d a b d2 a b c d
skipping to change at page 9, line 41 skipping to change at page 9, line 41
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.
3.1. Log Entries 3.1. Log Entries
In order to enable attribution of each logged certificate to its In order to enable attribution of each logged certificate to its
issuer, each submitted certificate MUST be accompanied by all issuer, each submitted certificate MUST be accompanied by all
additional certificates required to verify the certificate chain up additional certificates required to verify the certificate chain up
to an accepted root certificate. The root certificate itself MAY be to an accepted root certificate. The root certificate itself MAY be
omitted from the chain submitted to the log server. The log SHALL omitted from the chain submitted to the log server. The log SHALL
allow retrieval of a list of acceptable root certificates (this list allow retrieval of a list of accepted root certificates (this list
might usefully be the union of root certificates trusted by major might usefully be the union of root certificates trusted by major
browser vendors). browser vendors).
Alternatively, (root as well as intermediate) certificate authorities Alternatively, (root as well as intermediate) certificate authorities
may submit a certificate to logs prior to issuance in order to may preannounce a certificate to logs prior to issuance in order to
incorporate the SCT in the issued certificate. To do so, the CA incorporate the SCT in the issued certificate. To do this, the CA
submits a Precertificate that the log can use to create an entry that submits a Precertificate that the log can use to create an entry that
will be valid against the issued certificate. The Precertificate is will be valid against the issued certificate. A Precertificate is a
an X.509v3 certificate for simplicity, but, since it isn't used for CMS [RFC5652] "signed-data" object that contains a TBSCertificate
anything but logging, could equally be some other data structure. [RFC5280] in its "SignedData.encapContentInfo.eContent" field,
The Precertificate is constructed from the certificate to be issued identified by the OID <TBD> in the
by adding a special critical poison extension (OID "SignedData.encapContentInfo.eContentType" field. This
1.3.6.1.4.1.11129.2.4.3, whose extnValue OCTET STRING contains ASN.1 TBSCertificate MAY redact certain domain name labels that will be
NULL data (0x05 0x00)) to the end-entity TBSCertificate, minus the present in the issued certificate (see Section 3.2.2) and MUST NOT
SCT extension, which is obviously unknown until after the contain any SCTs, but it will be otherwise identical to the
Precertificate has been submitted to the log. The poison extension TBSCertificate in the issued certificate. "SignedData.signerInfos"
is to ensure that the Precertificate cannot be validated by a MUST contain a signature from the same (root or intermediate) CA that
standard X.509v3 client. The Precertificate MAY redact certain will ultimately issue the certificate. This signature indicates the
domain name labels that will be present in the final certificate (see certificate authority's intent to issue the certificate. This intent
Section 3.2.2). The resulting TBSCertificate [RFC5280] is then
signed with either
o a special-purpose (CA:true, Extended Key Usage: Certificate
Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
Certificate. The Precertificate Signing Certificate MUST be
directly certified by the (root or intermediate) CA certificate
that will ultimately sign the end-entity TBSCertificate yielding
the end-entity certificate (note that the log may relax standard
validation rules to allow this, so long as the issued certificate
will be valid),
o or, the CA certificate that will sign the final certificate.
As above, the Precertificate submission MUST be accompanied by the
Precertificate Signing Certificate, if used, and all additional
certificates required to verify the chain up to an accepted root
certificate. The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate. This intent
is considered binding (i.e., misissuance of the Precertificate is is considered binding (i.e., misissuance of the Precertificate is
considered equal to misissuance of the final certificate). Each log considered equivalent to misissuance of the certificate). As above,
verifies the Precertificate signature chain and issues a Signed the Precertificate submission MUST be accompanied by all the
Certificate Timestamp on the corresponding TBSCertificate. additional certificates required to verify the chain up to an
accepted root certificate. This does not involve using the
"SignedData.certificates" field, so that field SHOULD be omitted.
Logs MUST verify that the submitted end-entity certificate or Logs MUST verify that the submitted certificate or Precertificate has
Precertificate has a valid signature chain leading back to a trusted a valid signature chain to an accepted root certificate, using the
root CA certificate, using the chain of intermediate CA certificates chain of intermediate CA certificates provided by the submitter.
provided by the submitter. Logs MAY accept certificates that have Logs MAY accept certificates and Precertificates that have expired,
expired, are not yet valid, have been revoked, or are otherwise not are not yet valid, have been revoked, or are otherwise not fully
fully valid according to X.509 verification rules in order to valid according to X.509 verification rules in order to accommodate
accommodate quirks of CA certificate-issuing software. However, logs quirks of CA certificate-issuing software. However, logs MUST reject
MUST refuse to publish certificates without a valid chain to a known certificates without a valid signature chain to an accepted root
root CA. If a certificate is accepted and an SCT issued, the certificate. If a certificate is accepted and an SCT issued, the
accepting log MUST store the entire chain used for verification, accepting log MUST store the entire chain used for verification,
including the certificate or Precertificate itself and including the including the certificate or Precertificate itself and including the
root certificate used to verify the chain (even if it was omitted root certificate used to verify the chain (even if it was omitted
from the submission), and MUST present this chain for auditing upon from the submission), and MUST present this chain for auditing upon
request. This chain is required to prevent a CA from avoiding blame request. This chain is required to prevent a CA from avoiding blame
by logging a partial or empty chain. (Note: This effectively by logging a partial or empty chain. (Note: This effectively
excludes self-signed and DANE-based certificates until some mechanism excludes self-signed and DANE-based certificates until some mechanism
to limit the submission of spurious certificates is found. The to limit the submission of spurious certificates is found. The
authors welcome suggestions.) authors welcome suggestions.)
Each certificate entry in a log MUST include the following Each certificate or Precertificate entry in a log MUST include the
components: following components:
enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; enum { x509_entry(0), precert_entry_V2(3), (65535) } LogEntryType;
struct { struct {
LogEntryType entry_type; LogEntryType entry_type;
select (entry_type) { select (entry_type) {
case x509_entry: X509ChainEntry; case x509_entry: X509ChainEntry;
case precert_entry: PrecertChainEntry; case precert_entry_V2: PrecertChainEntryV2;
} entry; } entry;
} LogEntry; } LogEntry;
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;
struct { opaque CMSPrecert<1..2^24-1>;
ASN.1Cert pre_certificate;
ASN.1Cert precertificate_chain<0..2^24-1>; struct {
} PrecertChainEntry; CMSPrecert pre_certificate;
ASN.1Cert precertificate_chain<0..2^24-1>;
} PrecertChainEntryV2;
Logs SHOULD limit the length of chain they will accept. Logs SHOULD limit the length of chain they will accept.
"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 a chain of additional certificates required to "certificate_chain" is a chain of additional certificates required to
verify the end-entity certificate. The first certificate MUST verify the end-entity certificate. The first certificate MUST
certify the end-entity certificate. Each following certificate MUST certify the end-entity 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
either be, or be issued by, a root certificate accepted by the log. either be, or be issued by, a root certificate accepted by the log.
"pre_certificate" is the Precertificate submitted for auditing. "pre_certificate" is the Precertificate submitted for auditing.
"precertificate_chain" is a chain of additional certificates required "precertificate_chain" is a chain of additional certificates required
to verify the Precertificate submission. The first certificate MAY to verify the Precertificate submission. The first certificate MUST
be a valid Precertificate Signing Certificate and MUST certify the certify the Precertificate. Each following certificate MUST directly
first certificate. Each following certificate MUST directly certify certify the one preceding it. The final certificate MUST be a root
the one preceding it. The final certificate MUST be a root
certificate accepted by the log. certificate accepted by the log.
3.2. Private Domain Name Labels 3.2. Private Domain Name Labels
Some regard some DNS domain name labels within their registered Some regard some DNS domain name labels within their registered
domain space as private and security sensitive. Even though these domain space as private and security sensitive. Even though these
domains are often only accessible within the domain owner's private domains are often only accessible within the domain owner's private
network, it's common for them to be secured using publicly trusted network, it's common for them to be secured using publicly trusted
TLS server certificates. We define a mechanism to allow these TLS server certificates. We define a mechanism to allow these
private labels to not appear in public logs. private labels to not appear in public logs.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
INTEGER does the same for the Precertificate's second DNS-ID; etc. INTEGER does the same for the Precertificate's second DNS-ID; etc.
There MUST NOT be more INTEGERs than there are DNS-IDs. If there are There MUST NOT be more INTEGERs than there are DNS-IDs. If there are
fewer INTEGERs than there are DNS-IDs, the shortfall is made up by fewer INTEGERs than there are DNS-IDs, the shortfall is made up by
implicitly repeating the last INTEGER. Each INTEGER MUST have a implicitly repeating the last INTEGER. Each INTEGER MUST have a
value of zero or more. The purpose of this extension is to enable value of zero or more. The purpose of this extension is to enable
TLS clients to accurately reconstruct the Precertificate from the TLS clients to accurately reconstruct the Precertificate from the
certificate without having to perform any guesswork. certificate without having to perform any guesswork.
3.2.3. Using a Name-Constrained Intermediate CA 3.2.3. Using a Name-Constrained Intermediate CA
An intermediate CA certificate or Precertificate that contains the An intermediate CA certificate or intermediate CA Precertificate that
critical or non-critical Name Constraints [RFC5280] extension MAY be contains the critical or non-critical Name Constraints [RFC5280]
logged in place of end-entity certificates issued by that extension MAY be logged in place of end-entity certificates issued by
intermediate CA, as long as all of the following conditions are met: that intermediate CA, as long as all of the following conditions are
met:
o there MUST be a non-critical extension (OID o there MUST be a non-critical extension (OID
1.3.6.1.4.1.11129.2.4.7, whose extnValue OCTET STRING contains 1.3.6.1.4.1.11129.2.4.7, whose extnValue OCTET STRING contains
ASN.1 NULL data (0x05 0x00)). This extension is an explicit ASN.1 NULL data (0x05 0x00)). This extension is an explicit
indication that it is acceptable to not log certificates issued by indication that it is acceptable to not log certificates issued by
this intermediate CA. this intermediate CA.
o permittedSubtrees MUST specify one or more dNSNames. o permittedSubtrees MUST specify one or more dNSNames.
o excludedSubtrees MUST specify the entire IPv4 and IPv6 address o excludedSubtrees MUST specify the entire IPv4 and IPv6 address
skipping to change at page 14, line 10 skipping to change at page 14, line 10
} }
} }
} }
} }
3.3. Structure of the Signed Certificate Timestamp 3.3. Structure of the Signed Certificate Timestamp
enum { certificate_timestamp(0), tree_hash(1), (255) } enum { certificate_timestamp(0), tree_hash(1), (255) }
SignatureType; SignatureType;
enum { v1(0), (255) } enum { v1(0), v2(1), (255) }
Version; Version;
struct { struct {
opaque key_id[32]; opaque key_id[32];
} LogID; } LogID;
opaque TBSCertificate<1..2^24-1>; opaque TBSCertificate<1..2^24-1>;
struct {
opaque issuer_key_hash[32];
TBSCertificate tbs_certificate;
} PreCert;
opaque CtExtensions<0..2^16-1>; opaque CtExtensions<0..2^16-1>;
"key_id" is the SHA-256 hash of the log's public key, calculated over "key_id" is the SHA-256 hash of the log's public key, calculated over
the DER encoding of the key represented as SubjectPublicKeyInfo. the DER encoding of the key represented as SubjectPublicKeyInfo.
"issuer_key_hash" is the SHA-256 hash of the certificate issuer's "tbs_certificate" is the DER-encoded TBSCertificate component of the
public key, calculated over the DER encoding of the key represented Precertificate. Note that it is also possible to reconstruct this
as SubjectPublicKeyInfo. This is needed to bind the issuer to the TBSCertificate from the issued certificate by extracting the
final certificate. TBSCertificate from it, redacting the domain name labels indicated by
the redacted labels extension, and deleting the SCT list extension
"tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280]) and redacted labels extension.
component of the Precertificate -- that is, without the signature and
the poison extension. If the Precertificate is not signed with the
CA certificate that will issue the final certificate, then the
TBSCertificate also has its issuer changed to that of the CA that
will issue the final certificate. Note that it is also possible to
reconstruct this TBSCertificate from the final certificate by
extracting the TBSCertificate from it and deleting the SCT extension.
Also note that since the TBSCertificate contains an
AlgorithmIdentifier that must match both the Precertificate signature
algorithm and final certificate signature algorithm, they must be
signed with the same algorithm and parameters. If the Precertificate
is issued using a Precertificate Signing Certificate and an Authority
Key Identifier extension is present in the TBSCertificate, the
corresponding extension must also be present in the Precertificate
Signing Certificate -- in this case, the TBSCertificate also has its
Authority Key Identifier changed to match the final issuer.
struct { struct {
Version sct_version; Version sct_version;
LogID id; LogID id;
uint64 timestamp; uint64 timestamp;
CtExtensions extensions; CtExtensions 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: ASN.1Cert; case x509_entry: ASN.1Cert;
case precert_entry: PreCert; case precert_entry_V2: TBSCertificate;
} signed_entry; } signed_entry;
CtExtensions extensions; CtExtensions 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 v1. conforms. This version is v2.
"timestamp" is the current NTP Time [RFC5905], measured since the "timestamp" is the current NTP Time [RFC5905], measured since the
epoch (January 1, 1970, 00:00), ignoring leap seconds, in epoch (January 1, 1970, 00:00), ignoring leap seconds, in
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" is the "leaf_certificate" (in the case of an "signed_entry" is the "leaf_certificate" (in the case of an
X509ChainEntry) or is the PreCert (in the case of a X509ChainEntry) or is the TBSCertificate (in the case of a
PrecertChainEntry), as described above. PrecertChainEntryV2), as described above.
"extensions" are future extensions to this protocol version (v1). "extensions" are future extensions to SignedCertificateTimestamp v2.
Currently, no extensions are specified. Currently, no extensions are specified.
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, either from at least one log must be included in the TLS handshake, either
by using an X509v3 certificate extension as described below, by using by using an X509v3 certificate extension as described below, by using
a TLS extension (Section 7.4.1.4 of [RFC5246]) with type a TLS extension (Section 7.4.1.4 of [RFC5246]) with type
"signed_certificate_timestamp", or by using Online Certificate Status "signed_certificate_timestamp", or by using Online Certificate Status
Protocol (OCSP) Stapling (also known as the "Certificate Status Protocol (OCSP) Stapling (also known as the "Certificate Status
skipping to change at page 16, line 15 skipping to change at page 15, line 41
SignedCertificateTimestampList ::= OCTET STRING SignedCertificateTimestampList ::= OCTET STRING
in the singleExtensions component of the SingleResponse pertaining to in the singleExtensions component of the SingleResponse pertaining to
the end-entity certificate. the end-entity certificate.
At least one SCT MUST be included. Server operators MAY include more At least one SCT MUST be included. Server operators MAY include more
than one SCT. than one SCT.
Similarly, a certificate authority MAY submit a Precertificate to Similarly, a certificate authority MAY submit a Precertificate to
more than one log, and all obtained SCTs can be directly embedded in more than one log, and all obtained SCTs can be directly embedded in
the final certificate, by encoding the SignedCertificateTimestampList the issued certificate, by encoding the
structure as an ASN.1 OCTET STRING and inserting the resulting data SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and
in the TBSCertificate as a non-critical X.509v3 certificate extension inserting the resulting data in the TBSCertificate as a non-critical
(OID 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, X.509v3 certificate extension (OID 1.3.6.1.4.1.11129.2.4.2). Upon
clients can reconstruct the original TBSCertificate to verify the SCT receiving the certificate, clients can reconstruct the original
signature. TBSCertificate to verify the SCT signature.
The contents of the ASN.1 OCTET STRING embedded in an OCSP extension The contents of the ASN.1 OCTET STRING embedded in an OCSP extension
or X509v3 certificate extension are as follows: or X509v3 certificate extension are as follows:
opaque SerializedSCT<1..2^16-1>; opaque SerializedSCT<1..2^16-1>;
struct { struct {
SerializedSCT sct_list <1..2^16-1>; SerializedSCT sct_list <1..2^16-1>;
} SignedCertificateTimestampList; } SignedCertificateTimestampList;
skipping to change at page 17, line 37 skipping to change at page 17, line 13
Structure of the Merkle Tree input: Structure of the Merkle Tree input:
enum { v1(0), v2(1), (255) } enum { v1(0), v2(1), (255) }
LeafVersion; LeafVersion;
struct { struct {
uint64 timestamp; uint64 timestamp;
LogEntryType entry_type; LogEntryType entry_type;
select(entry_type) { select(entry_type) {
case x509_entry: ASN.1Cert; case x509_entry: ASN.1Cert;
case precert_entry: PreCert; case precert_entry_V2: PreCert;
} signed_entry; } signed_entry;
CtExtensions extensions; CtExtensions 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
skipping to change at page 21, line 11 skipping to change at page 20, line 36
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 v1 clients that do not is to avoid forcing an upgrade of compliant v1 clients that do not
use the returned SCTs. use the returned SCTs.
4.2. Add PreCertChain to Log 4.2. Add PreCertChain to Log
POST https://<log server>/ct/v1/add-pre-chain POST https://<log server>/ct/v1/add-pre-chain
Inputs: Inputs:
chain: An array of base64-encoded Precertificates. The first precertificate: The base64-encoded Precertificate.
element is the end-entity certificate; the second chains to the
first and so on to the last, which is either the root chain: An array of base64-encoded CA certificates. The first
certificate or a certificate that chains to a known root element is the signer of the Precertificate; the second chains
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. certificate.
Outputs are the same as in Section 4.1. Outputs 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/v1/get-sth
No inputs. No inputs.
skipping to change at page 22, line 12 skipping to change at page 21, line 40
Both tree sizes must be from existing v1 STHs (Signed Tree Heads). Both tree sizes must be from existing v1 STHs (Signed Tree Heads).
Outputs: Outputs:
consistency: An array of Merkle Tree nodes, base64 encoded. consistency: An array of Merkle Tree nodes, base64 encoded.
Note that no signature is required on this data, as it is used to Note that no signature is required on this data, as it is used to
verify an STH, which is signed. verify an STH, which is signed.
4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash 4.5. Retrieve Merkle Inclusion Proof from Log by Leaf Hash
GET https://<log server>/ct/v1/get-proof-by-hash GET https://<log server>/ct/v1/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.
skipping to change at page 23, line 11 skipping to change at page 22, line 39
end: 0-based index of last entry to retrieve, in decimal. end: 0-based index of last entry to retrieve, in decimal.
Outputs: Outputs:
entries: An array of objects, each consisting of entries: An array of objects, each consisting of
leaf_input: The base64-encoded MerkleTreeLeaf structure. leaf_input: The base64-encoded MerkleTreeLeaf structure.
extra_data: The base64-encoded unsigned data pertaining to the extra_data: The base64-encoded unsigned data pertaining to the
log entry. In the case of an X509ChainEntry, this is the log entry. In the case of an X509ChainEntry, this is the
"certificate_chain". In the case of a PrecertChainEntry, "certificate_chain". In the case of a PrecertChainEntryV2,
this is the whole "PrecertChainEntry". this is the whole "PrecertChainEntryV2".
Note that this message is not signed -- the retrieved data can be Note that this message is not signed -- the retrieved 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 24, line 5 skipping to change at page 23, line 33
GET https://<log server>/ct/v1/get-roots GET https://<log server>/ct/v1/get-roots
No inputs. No inputs.
Outputs: Outputs:
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.
4.8. Retrieve Entry+Merkle Audit Proof from Log 4.8. Retrieve Entry+Merkle Inclusion Proof from Log
GET https://<log server>/ct/v1/get-entry-and-proof GET https://<log server>/ct/v1/get-entry-and-proof
Inputs: Inputs:
leaf_index: The index of the desired entry. leaf_index: The index of the desired entry.
tree_size: The tree_size of the tree for which the proof is tree_size: The tree_size of the tree for which the proof is
desired. desired.
skipping to change at page 24, line 38 skipping to change at page 24, line 23
This API is probably only useful for debugging. This API is probably only useful for debugging.
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 could 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 should gossip with each other, exchanging STHs at least; Clients should somehow exchange STHs they see, or make them available
this is all that is required to ensure that they all have a for scrutiny, in order to ensure that they all have a consistent
consistent view. The exact mechanism for gossip will be described in view. The exact mechanisms will be in separate documents, but it is
a separate document, but it is expected there will be a variety. expected there will be a variety.
5.1. Submitters 5.1. Submitters
Submitters submit certificates or Precertificates to the log as Submitters submit certificates or Precertificates to the log as
described above. When a Submitter intends to use the returned SCT described above. When a Submitter intends to use the returned SCT
directly in a TLS handshake or to construct a certificate, they directly in a TLS handshake or to construct a certificate, they
SHOULD validate the SCT as described in Section 5.2 if they SHOULD validate the SCT as described in Section 5.2 if they
understand its format. understand its format.
5.2. TLS Client 5.2. TLS Client
TLS clients receive SCTs alongside or in server certificates. In TLS clients receive SCTs alongside or in certificates, either for the
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. TLS clients MAY audit the using the corresponding log's public key. TLS clients MAY audit the
corresponding log by requesting, and verifying, a Merkle audit proof corresponding log by requesting, and verifying, a Merkle audit proof
for said certificate. Note that this document does not describe how for said certificate. Note that this document does not describe how
clients obtain the logs' public keys or URLs. clients obtain the logs' public keys or URLs.
TLS clients MUST reject SCTs whose timestamp is in the future. TLS clients MUST reject SCTs whose timestamp is in the future.
skipping to change at page 26, line 33 skipping to change at page 26, line 18
that this information is consistent with other partial information that this information is consistent with other partial information
they have. An auditor might be an integral component of a TLS they have. An auditor might be an integral component of a TLS
client; it might be a standalone service; or it might be a secondary client; it might be a standalone service; or it might be a secondary
function of a monitor. function of a monitor.
Any pair of STHs from the same log can be verified by requesting a Any pair of STHs from the same log can be verified by requesting a
consistency proof (Section 4.4). consistency proof (Section 4.4).
A certificate accompanied by an SCT can be verified against any STH A certificate accompanied by an SCT can be verified against any STH
dated after the SCT timestamp + the Maximum Merge Delay by requesting dated after the SCT timestamp + the Maximum Merge Delay by requesting
a Merkle audit proof (Section 4.5). a Merkle inclusion proof (Section 4.5).
Auditors can fetch STHs from time to time of their own accord, of Auditors can fetch STHs from time to time of their own accord, of
course (Section 4.3). course (Section 4.3).
6. IANA Considerations 6. IANA Considerations
6.1. TLS Extension Type 6.1. TLS Extension Type
IANA has allocated an RFC 5246 ExtensionType value (18) for the SCT IANA has allocated an RFC 5246 ExtensionType value (18) for the SCT
TLS extension. The extension name is "signed_certificate_timestamp". TLS extension. The extension name is "signed_certificate_timestamp".
skipping to change at page 28, line 29 skipping to change at page 28, line 11
Violation of the MMD contract is detected by log clients requesting a Violation of the MMD contract is detected by log clients requesting a
Merkle audit proof for each observed SCT. These checks can be Merkle audit proof for each observed SCT. These checks can be
asynchronous and need only be done once per each certificate. In asynchronous and need only be done once per each certificate. In
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 is detected by global Violation of the append-only property can be detected by clients
gossiping, i.e., everyone auditing logs comparing their instances of comparing their instances of the Signed Tree Heads. As soon as two
the latest Signed Tree Heads. As soon as two conflicting Signed Tree conflicting Signed Tree Heads for the same log are detected, this is
Heads for the same log are detected, this is cryptographic proof of cryptographic proof of that log's misbehavior. There are various
that log's misbehavior. ways this could be done, for example via gossip (see http://
trac.tools.ietf.org/id/draft-linus-trans-gossip-00.txt) or peer-to-
peer communications or by sending STHs to monitors (who could then
directly check against their own copy of the relevant log).
8. Efficiency Considerations 8. Efficiency Considerations
The Merkle Tree design serves the purpose of keeping communication The Merkle Tree design serves the purpose of keeping communication
overhead low. overhead low.
Auditing logs for integrity does not require third parties to Auditing logs for integrity does not require third parties to
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.
9. Future Changes 9. Acknowledgements
This section lists things we might address in a Standards Track
version of this document.
o Rather than forcing a log operator to create a new log in order to
change the log signing key, we may allow some key roll mechanism.
o We may add hash and signing algorithm agility.
o We may describe some gossip protocols.
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, Stephen Farrell, Brad Hill, Jeff Hodges, Paul
Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor
Perrin, Ryan Sleevi and Carl Wallace for their valuable Perrin, Ryan Sleevi and Carl Wallace for their valuable
contributions. contributions.
11. References 10. References
11.1. Normative Reference 10.1. Normative Reference
[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, March 1997.
11.2. Informative References 10.2. Informative References
[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,
<http://static.usenix.org/event/sec09/tech/full_papers/ <http://static.usenix.org/event/sec09/tech/full_papers/
crosby.pdf>. crosby.pdf>.
[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,
skipping to change at page 30, line 36 skipping to change at page 30, line 13
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[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, August 2008.
[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, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[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
skipping to change at page 31, line 21 skipping to change at page 31, line 4
Adam Langley Adam Langley
Google Inc. Google Inc.
EMail: agl@google.com EMail: agl@google.com
Emilia Kasper Emilia Kasper
Google Switzerland GmbH Google Switzerland GmbH
EMail: ekasper@google.com EMail: ekasper@google.com
Eran Messeri
Google UK Ltd.
EMail: eranm@google.com
Rob Stradling Rob Stradling
Comodo CA, Ltd. Comodo CA, Ltd.
EMail: rob.stradling@comodo.com EMail: rob.stradling@comodo.com
 End of changes. 59 change blocks. 
193 lines changed or deleted 158 lines changed or added

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