Internet Engineering Task Force (IETF) B. Laurie
Request for Comments: 6962 A. Langley
Category: Experimental E. Kasper
ISSN: 2070-1721 Google
June 2013
Internet Engineering Task Force (IETF) B. Laurie
Request for Comments: 6962 A. Langley
Category: Experimental E. Kasper
ISSN: 2070-1721 Google
June 2013
Certificate Transparency
证书透明度
Abstract
摘要
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.
本文档描述了一种实验性协议，用于公开记录传输层安全（TLS）证书的颁发或遵守情况，其方式允许任何人审计证书颁发机构（CA）活动、通知可疑证书的颁发以及审计证书日志本身。这样做的目的是，最终客户机将拒绝接受未出现在日志中的证书，从而有效地迫使CAs将所有已颁发的证书添加到日志中。
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.
日志是实现本文档中定义的提交和查询协议操作的网络服务。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6962.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6962.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Informal Introduction ...........................................3
1.1. Requirements Language ......................................4
1.2. Data Structures ............................................4
2. Cryptographic Components ........................................4
2.1. Merkle Hash Trees ..........................................4
2.1.1. Merkle Audit Paths ..................................5
2.1.2. Merkle Consistency Proofs ...........................6
2.1.3. Example .............................................7
2.1.4. Signatures ..........................................8
3. Log Format and Operation ........................................9
3.1. Log Entries ................................................9
3.2. Structure of the Signed Certificate Timestamp .............12
3.3. Including the Signed Certificate Timestamp in the
TLS Handshake .............................................13
3.3.1. TLS Extension ......................................15
3.4. Merkle Tree ...............................................15
3.5. Signed Tree Head ..........................................16
4. Log Client Messages ............................................17
4.1. Add Chain to Log ..........................................17
4.2. Add PreCertChain to Log ...................................18
4.3. Retrieve Latest Signed Tree Head ..........................18
4.4. Retrieve Merkle Consistency Proof between Two
Signed Tree Heads .........................................19
4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash .........19
4.6. Retrieve Entries from Log .................................20
4.7. Retrieve Accepted Root Certificates .......................21
4.8. Retrieve Entry+Merkle Audit Proof from Log ................21
5. Clients ........................................................21
5.1. Submitters ................................................22
5.2. TLS Client ................................................22
5.3. Monitor ...................................................22
1. Informal Introduction ...........................................3
1.1. Requirements Language ......................................4
1.2. Data Structures ............................................4
2. Cryptographic Components ........................................4
2.1. Merkle Hash Trees ..........................................4
2.1.1. Merkle Audit Paths ..................................5
2.1.2. Merkle Consistency Proofs ...........................6
2.1.3. Example .............................................7
2.1.4. Signatures ..........................................8
3. Log Format and Operation ........................................9
3.1. Log Entries ................................................9
3.2. Structure of the Signed Certificate Timestamp .............12
3.3. Including the Signed Certificate Timestamp in the
TLS Handshake .............................................13
3.3.1. TLS Extension ......................................15
3.4. Merkle Tree ...............................................15
3.5. Signed Tree Head ..........................................16
4. Log Client Messages ............................................17
4.1. Add Chain to Log ..........................................17
4.2. Add PreCertChain to Log ...................................18
4.3. Retrieve Latest Signed Tree Head ..........................18
4.4. Retrieve Merkle Consistency Proof between Two
Signed Tree Heads .........................................19
4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash .........19
4.6. Retrieve Entries from Log .................................20
4.7. Retrieve Accepted Root Certificates .......................21
4.8. Retrieve Entry+Merkle Audit Proof from Log ................21
5. Clients ........................................................21
5.1. Submitters ................................................22
5.2. TLS Client ................................................22
5.3. Monitor ...................................................22
5.4. Auditor ...................................................23
6. IANA Considerations ............................................23
7. Security Considerations ........................................23
7.1. Misissued Certificates ....................................24
7.2. Detection of Misissue .....................................24
7.3. Misbehaving Logs ..........................................24
8. Efficiency Considerations ......................................25
9. Future Changes .................................................25
10. Acknowledgements ..............................................25
11. References ....................................................25
11.1. Normative Reference ......................................25
11.2. Informative References ...................................26
5.4. Auditor ...................................................23
6. IANA Considerations ............................................23
7. Security Considerations ........................................23
7.1. Misissued Certificates ....................................24
7.2. Detection of Misissue .....................................24
7.3. Misbehaving Logs ..........................................24
8. Efficiency Considerations ......................................25
9. Future Changes .................................................25
10. Acknowledgements ..............................................25
11. References ....................................................25
11.1. Normative Reference ......................................25
11.2. Informative References ...................................26
Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates. The logs are publicly auditable so 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 not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance. Note that this is a general mechanism, but in this document, we only describe its use for public TLS server certificates issued by public certificate authorities (CAs).
证书透明性旨在通过提供所有已颁发证书的可公开审核、仅附加且不受信任的日志来缓解错误颁发证书的问题。日志是可公开审核的，因此任何人都可以验证每个日志的正确性，并在向其中添加新证书时进行监视。日志本身并不能防止错误发布，但它们可以确保相关方（特别是证书中指定的方）能够检测到此类错误发布。请注意，这是一种通用机制，但在本文档中，我们仅描述它对公共证书颁发机构（CA）颁发的公共TLS服务器证书的使用。
Each log consists of certificate chains, which can be submitted by anyone. It is expected that public CAs will contribute all their newly issued certificates to one or more logs; it is also expected that certificate holders will contribute their own certificate chains. In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known CA certificate. When a chain is submitted to a log, a signed timestamp is returned, which can later be used to provide evidence to clients that the chain has been submitted. TLS clients can thus require that all certificates they see have been logged.
每个日志由证书链组成，任何人都可以提交。预计公共CA将把其所有新颁发的证书贡献给一个或多个日志；此外，预计证书持有人将贡献自己的证书链。为了避免日志被垃圾处理而变得无用，要求每个链都以一个已知的CA证书为根。当链提交到日志时，将返回一个签名的时间戳，该时间戳可用于向客户端提供链已提交的证据。因此，TLS客户端可以要求他们看到的所有证书都已记录。
Those who are concerned about misissue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect. What they do with this information, particularly when they find that a misissuance has happened, is beyond the scope of this document, but broadly speaking, they can invoke existing business mechanisms for dealing with misissued certificates. Of course, anyone who wants can monitor the logs and, if they believe a certificate is incorrectly issued, take action as they see fit.
那些担心错误发布的人可以监控日志，定期询问日志中的所有新条目，从而可以检查他们负责的域是否已经发布了他们意想不到的证书。他们如何处理这些信息，特别是当他们发现发生了错误颁发时，超出了本文档的范围，但从广义上讲，他们可以调用现有的业务机制来处理错误颁发的证书。当然，任何想要监视日志的人都可以监视日志，如果他们认为证书的颁发不正确，可以采取他们认为合适的措施。
Similarly, those who have seen signed timestamps from a particular log can later demand a proof of inclusion from that log. If the log is unable to provide this (or, indeed, if the corresponding certificate is absent from monitors' copies of that log), that is evidence of the incorrect operation of the log. The checking operation is asynchronous to allow TLS connections to proceed without delay, despite network connectivity issues and the vagaries of firewalls.
类似地，那些从特定日志中看到签名时间戳的人稍后可以要求从该日志中获得包含的证明。如果日志无法提供此信息（或者，如果监控器的日志副本中没有相应的证书），则这是日志操作不正确的证据。检查操作是异步的，以允许TLS连接毫不延迟地进行，尽管存在网络连接问题和防火墙的异常情况。
The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for certificates they then don't log) can be efficiently detected and proved to the world at large.
每个日志的append-only属性在技术上是使用Merkle树实现的，Merkle树可用于显示日志的任何特定版本是任何特定以前版本的超集。类似地，Merkle树避免了盲目信任日志的需要：如果日志试图向不同的人显示不同的内容，可以通过比较树根和一致性证明有效地检测到这一点。类似地，任何日志的其他错误行为（例如，为未记录的证书颁发签名时间戳）都可以被有效检测并向全世界证明。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Data structures are defined according to the conventions laid out in Section 4 of [RFC5246].
数据结构根据[RFC5246]第4节规定的约定定义。
Logs use a binary Merkle Hash Tree for efficient auditing. The
hashing algorithm is SHA-256 [FIPS.180-4] (note that this is fixed
for this experiment, but it is anticipated that each log would be
able to specify a hash algorithm). The input to the Merkle Tree Hash
is a list of data entries; these entries will be hashed to form the
leaves of the Merkle Hash Tree. The output is a single 32-byte
Merkle Tree Hash. Given an ordered list of n inputs, D[n] = {d(0),
d(1), ..., d(n-1)}, the Merkle Tree Hash (MTH) is thus defined as
follows:
Logs use a binary Merkle Hash Tree for efficient auditing. The
hashing algorithm is SHA-256 [FIPS.180-4] (note that this is fixed
for this experiment, but it is anticipated that each log would be
able to specify a hash algorithm). The input to the Merkle Tree Hash
is a list of data entries; these entries will be hashed to form the
leaves of the Merkle Hash Tree. The output is a single 32-byte
Merkle Tree Hash. Given an ordered list of n inputs, D[n] = {d(0),
d(1), ..., d(n-1)}, the Merkle Tree Hash (MTH) is thus defined as
follows:
The hash of an empty list is the hash of an empty string:
空列表的哈希是空字符串的哈希：
MTH({}) = SHA-256().
MTH（{}）=SHA-256（）。
The hash of a list with one entry (also known as a leaf hash) is:
具有一个条目的列表的哈希（也称为叶哈希）为：
MTH({d(0)}) = SHA-256(0x00 || d(0)).
MTH（{d（0）}）=SHA-256（0x00 | | d（0））。
For n > 1, let k be the largest power of two smaller than n (i.e., k < n <= 2k). The Merkle Tree Hash of an n-element list D[n] is then defined recursively as
对于n>1，设k为小于n的两个的最大幂（即k<n<=2k）。然后递归地将n元素列表D[n]的Merkle树散列定义为
MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])),
MTH（D[n]）=SHA-256（0x01 | | MTH（D[0:k]）| | MTH（D[k:n]），
where || is concatenation and D[k1:k2] denotes the list {d(k1), d(k1+1),..., d(k2-1)} of length (k2 - k1). (Note that the hash calculations for leaves and nodes differ. This domain separation is required to give second preimage resistance.)
其中| |是串联，D[k1:k2]表示长度（k2-k1）的列表{D（k1），D（k1+1），…，D（k2-1）}。（请注意，叶和节点的散列计算不同。需要进行此域分离以提供第二个前映像阻力。）
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; however, its shape is uniquely determined by the number of leaves. (Note: This Merkle Tree is essentially the same as the history tree [CrosbyWallach] proposal, except our definition handles non-full trees differently.)
请注意，我们不要求输入列表的长度为2的幂。由此产生的Merkle树可能不平衡；然而，它的形状是由叶子的数量决定的。（注意：此Merkle树本质上与历史树[CrosbyWallach]方案相同，只是我们的定义处理非完整树的方式不同。）
A Merkle audit path for a leaf in a Merkle Hash Tree is the shortest list of additional nodes in the Merkle Tree required to compute the Merkle Tree Hash for that tree. Each node in the tree is either a leaf node or is computed from the two nodes immediately below it (i.e., towards the leaves). At each step up the tree (towards the root), a node from the audit path is combined with the node computed so far. In other words, the audit path consists of the list of missing nodes required to compute the nodes leading from a leaf to the root of the tree. If the root computed from the audit path matches the true root, then the audit path is proof that the leaf exists in the tree.
Merkle哈希树中某个叶的Merkle审核路径是Merkle树中计算该树的Merkle树哈希所需的其他节点的最短列表。树中的每个节点要么是叶节点，要么是从其正下方的两个节点（即，朝向叶）计算得到的。在树上的每一步（朝向根），审核路径中的一个节点都与迄今为止计算的节点相结合。换句话说，审核路径由计算从叶子到树根的节点所需的缺失节点列表组成。如果根据审核路径计算的根与真实根匹配，则审核路径证明树中存在叶。
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(m), 0 <= m < n, is defined as follows:
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(m), 0 <= m < n, is defined as follows:
The path for the single leaf in a tree with a one-element input list
D[1] = {d(0)} is empty:
The path for the single leaf in a tree with a one-element input list
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 the (m+1)th element d(m) in a list of n > m elements is then defined recursively as
对于n>1，设k为小于n的两个的最大幂。然后递归地将n>m个元素列表中的第（m+1）个元素d（m）的路径定义为
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,
路径（m，D[n]）=路径（m-k，D[k:n]）：m>=k时的MTH（D[0:k]），
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.
其中：是列表的串联，D[k1:k2]表示长度（k2-k1）列表{D（k1），D（k1+1），…，D（k2-1）}，如前所述。
Merkle consistency proofs prove the append-only property of the tree. A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n, is the list of nodes in the Merkle Tree required to verify that the first m inputs D[0:m] are equal in both trees. Thus, a consistency proof must contain a set of intermediate nodes (i.e., commitments to inputs) sufficient to verify MTH(D[n]), such that (a subset of) the same nodes can be used to verify MTH(D[0:m]). We define an algorithm that outputs the (unique) minimal consistency proof.
Merkle一致性证明证明了树的仅附加属性。Merkle树Hash MTH（D[n]）和前m个叶的先前公布的Hash MTH（D[0:m]）的Merkle一致性证明，m<=n是Merkle树中验证前m个输入D[0:m]在两个树中相等所需的节点列表。因此，一致性证明必须包含一组足以验证MTH（D[n]）的中间节点（即，对输入的承诺），以便相同节点的（子集）可用于验证MTH（D[0:m]）。我们定义了一个输出（唯一）最小一致性证明的算法。
Given an ordered list of n inputs to the tree, D[n] = {d(0), ...,
d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous
Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as:
Given an ordered list of n inputs to the tree, D[n] = {d(0), ...,
d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous
Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as:
PROOF(m, D[n]) = SUBPROOF(m, D[n], true)
PROOF(m, D[n]) = SUBPROOF(m, D[n], true)
The subproof for m = n is empty if m is the value for which PROOF was originally requested (meaning that the subtree Merkle Tree Hash MTH(D[0:m]) is known):
如果m是最初请求证明的值（表示子树Merkle树散列MTH（D[0:m]），则m=n的subof为空：
SUBPROOF(m, D[m], true) = {}
SUBPROOF(m, D[m], true) = {}
The subproof for m = n is the Merkle Tree Hash committing inputs D[0:m]; otherwise:
m=n的子函数是Merkle树散列提交输入D[0:m]；否则：
SUBPROOF(m, D[m], false) = {MTH(D[m])}
SUBPROOF(m, D[m], false) = {MTH(D[m])}
For m < n, let k be the largest power of two smaller than n. The subproof is then defined recursively.
对于m<n，设k为小于n的两个的最大幂。然后递归地定义subof。
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 and add a commitment to D[k:n]:
如果m<=k，则右子树条目D[k:n]仅存在于当前树中。我们证明了左子树条目D[0:k]是一致的，并向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 trees. We prove that the right subtree entries D[k:n] are consistent and add a commitment to D[0:k].
如果m>k，两棵树中的左子树条目D[0:k]是相同的。我们证明了右子树条目D[k:n]是一致的，并向D[0:k]添加了一个承诺。
SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k])
SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k])
Here, : is a concatenation of lists, and D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before.
这里，：是列表的串联，与前面一样，D[k1:k2]表示长度（k2-k1）列表{D（k1），D（k1+1），…，D（k2-1）}。
The number of nodes in the resulting proof is bounded above by ceil(log2(n)) + 1.
结果证明中的节点数以ceil（log2（n））+1为界。
The binary Merkle Tree with 7 leaves:
具有7片叶子的二叉Merkle树：
hash
/ \
/ \
/ \
/ \
/ \
k l
/ \ / \
/ \ / \
/ \ / \
g h i j
/ \ / \ / \ |
a b c d e f d6
| | | | | |
d0 d1 d2 d3 d4 d5
hash
/ \
/ \
/ \
/ \
/ \
k l
/ \ / \
/ \ / \
/ \ / \
g h i j
/ \ / \ / \ |
a b c d e f d6
| | | | | |
d0 d1 d2 d3 d4 d5
The audit path for d0 is [b, h, l].
d0的审核路径为[b，h，l]。
The audit path for d3 is [c, g, l].
d3的审核路径是[c，g，l]。
The audit path for d4 is [f, j, k].
d4的审核路径是[f，j，k]。
The audit path for d6 is [i, k].
d6的审核路径为[i，k]。
The same tree, built incrementally in four steps:
同一棵树，分四步递增构建：
hash0 hash1=k
/ \ / \
/ \ / \
/ \ / \
g c g h
/ \ | / \ / \
a b d2 a b c d
| | | | | |
d0 d1 d0 d1 d2 d3
hash0 hash1=k
/ \ / \
/ \ / \
/ \ / \
g c g h
/ \ | / \ / \
a b d2 a b c d
| | | | | |
d0 d1 d0 d1 d2 d3
hash2 hash
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
k i k l
/ \ / \ / \ / \
/ \ e f / \ / \
/ \ | | / \ / \
g h d4 d5 g h i j
/ \ / \ / \ / \ / \ |
a b c d a b c d e f d6
| | | | | | | | | |
d0 d1 d2 d3 d0 d1 d2 d3 d4 d5
hash2 hash
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
k i k l
/ \ / \ / \ / \
/ \ e f / \ / \
/ \ | | / \ / \
g h d4 d5 g h i j
/ \ / \ / \ / \ / \ |
a b c d a b c d e f d6
| | | | | | | | | |
d0 d1 d2 d3 d0 d1 d2 d3 d4 d5
The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c,
d, g, l]. c, g are used to verify hash0, and d, l are additionally
used to show hash is consistent with hash0.
The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c,
d, g, l]. c, g are used to verify hash0, and d, l are additionally
used to show hash is consistent with hash0.
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l.
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l.
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
show hash is consistent with hash2.
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
show hash is consistent with hash2.
Various data structures are signed. A log MUST use either elliptic curve signatures using the NIST P-256 curve (Section D.1.2.3 of the Digital Signature Standard [DSS]) or RSA signatures (RSASSA-PKCS1- V1_5 with SHA-256, Section 8.2 of [RFC3447]) using a key of at least 2048 bits.
对各种数据结构进行签名。日志必须使用使用NIST P-256曲线的椭圆曲线签名（数字签名标准[DSS]第D.1.2.3节）或使用至少2048位密钥的RSA签名（带SHA-256的RSASSA-PKCS1-V1_5，[RFC3447]第8.2节）。
Anyone can submit certificates to certificate logs for public auditing; however, since certificates will not be accepted by TLS clients unless logged, it is expected that certificate owners or their CAs will usually submit them. A log is a single, ever-growing, append-only Merkle Tree of such certificates.
任何人都可以向证书日志提交证书以供公共审核；但是，由于TLS客户端不会接受证书，除非已登录，因此预计证书所有者或其CA通常会提交证书。日志是此类证书的单一、不断增长、仅附加的Merkle树。
When a valid certificate is submitted to a log, the log MUST immediately return a Signed Certificate Timestamp (SCT). The SCT is the log's promise to incorporate the certificate in the Merkle Tree within a fixed amount of time known as the Maximum Merge Delay (MMD). If the log has previously seen the certificate, it MAY return the same SCT as it returned before. TLS servers MUST present an SCT from one or more logs to the TLS client together with the certificate. TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate.
向日志提交有效证书时，日志必须立即返回已签名的证书时间戳（SCT）。SCT是日志的承诺，它将在称为最大合并延迟（MMD）的固定时间内将证书合并到Merkle树中。如果日志以前看到过证书，它可能会返回与以前返回的相同的SCT。TLS服务器必须将一个或多个日志中的SCT与证书一起提供给TLS客户端。TLS客户端必须拒绝没有针对最终实体证书的有效SCT的证书。
Periodically, each log appends all its new entries to the Merkle Tree and signs the root of the tree. Auditors can thus verify that each certificate for which an SCT has been issued indeed appears in the log. The log MUST incorporate a certificate in its Merkle Tree within the Maximum Merge Delay period after the issuance of the SCT.
每个日志周期性地将其所有新条目追加到Merkle树，并对树的根进行签名。因此，审核员可以验证已签发SCT的每个证书是否确实出现在日志中。日志必须在SCT发布后的最大合并延迟期内将证书合并到其Merkle树中。
Log operators MUST NOT impose any conditions on retrieving or sharing data from the log.
日志操作员不得对从日志检索或共享数据施加任何条件。
Anyone can submit a certificate to any log. In order to enable attribution of each logged certificate to its issuer, the log SHALL publish a list of acceptable root certificates (this list might usefully be the union of root certificates trusted by major browser vendors). Each submitted certificate MUST be accompanied by all additional certificates required to verify the certificate chain up to an accepted root certificate. The root certificate itself MAY be omitted from the chain submitted to the log server.
任何人都可以向任何日志提交证书。为了使每个记录的证书能够归属于其颁发者，日志应发布可接受的根证书列表（该列表可能是主要浏览器供应商信任的根证书的联合）。每个提交的证书都必须附带验证证书链到已接受的根证书所需的所有附加证书。提交给日志服务器的链中可能会忽略根证书本身。
Alternatively, (root as well as intermediate) certificate authorities may submit a certificate to logs prior to issuance. To do so, the CA submits a Precertificate that the log can use to create an entry that will be valid against the issued certificate. The Precertificate is constructed from the certificate to be issued by adding a special critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the end-entity TBSCertificate (this extension is to ensure that the Precertificate cannot be validated by a standard X.509v3 client) and signing the resulting TBSCertificate [RFC5280] with either
或者，（root和intermediate）证书颁发机构可以在颁发证书之前向日志提交证书。为此，CA提交一个预证书，日志可以使用该证书创建一个对颁发的证书有效的条目。通过向终端实体TBSCertificate添加一个特殊的关键毒物扩展（OID 1.3.6.1.4.1.11129.2.4.3，其extnValue八位字节字符串包含ASN.1空数据（0x05 0x00））来构造预证书（此扩展用于确保预证书不能由标准X.509v3客户端验证）并在生成的TBSCertificate[RFC5280]上签名
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 一种特殊用途（CA:true，扩展密钥用法：证书透明性，OID 1.3.6.1.4.1.11129.2.4.4）证书前签名证书。证书前签名证书必须由（根证书或中间证书）CA证书直接认证，CA证书最终将对最终实体TBSCertificate进行签名，从而生成最终实体证书（请注意，只要颁发的证书有效，日志可能会放宽标准验证规则以允许此操作），
o or, the CA certificate that will sign the final certificate.
o 或者，将签署最终证书的CA证书。
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 considered equal to misissuance of the final certificate). Each log verifies the Precertificate signature chain and issues a Signed Certificate Timestamp on the corresponding TBSCertificate.
如上所述，预认证提交必须随附预认证签名证书（如果使用），以及验证链至可接受根证书所需的所有附加证书。TBSCertificate上的签名表示证书颁发机构颁发证书的意图。该意图被视为具有约束力（即，预证书的错误颁发被视为等同于最终证书的错误颁发）。每个日志都验证Precertificate签名链，并在相应的TBSCertificate上发布已签名证书时间戳。
Logs MUST verify that the submitted end-entity certificate or Precertificate has a valid signature chain leading back to a trusted root CA certificate, using the chain of intermediate CA certificates provided by the submitter. Logs MAY accept certificates that have expired, are not yet valid, have been revoked, or are otherwise not fully valid according to X.509 verification rules in order to accommodate quirks of CA certificate-issuing software. However, logs MUST refuse to publish certificates without a valid chain to a known root CA. If a certificate is accepted and an SCT issued, the accepting log MUST store the entire chain used for verification, including the certificate or Precertificate itself and including the root certificate used to verify the chain (even if it was omitted from the submission), and MUST present this chain for auditing upon request. This chain is required to prevent a CA from avoiding blame by logging a partial or empty chain. (Note: This effectively excludes self-signed and DANE-based certificates until some mechanism to control spam for those certificates is found. The authors welcome suggestions.)
日志必须使用提交者提供的中间CA证书链，验证提交的最终实体证书或预证书是否具有有效的签名链，该签名链指向受信任的根CA证书。根据X.509验证规则，日志可以接受已过期、尚未生效、已撤销或以其他方式不完全有效的证书，以适应CA证书颁发软件的特殊性。但是，日志必须拒绝将没有有效链的证书发布到已知根CA。如果接受证书并颁发SCT，则接受日志必须存储用于验证的整个链，包括证书或预证书本身，以及用于验证链的根证书（即使在提交文件中省略了该链接），并且必须在请求时提供此链以供审核。此链用于防止CA通过记录部分或空链来避免指责。（注意：这实际上排除了自签名和基于DANE的证书，直到找到某种机制来控制这些证书的垃圾邮件。作者欢迎建议。）
Each certificate entry in a log MUST include the following components:
日志中的每个证书条目必须包括以下组件：
enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;
enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;
struct {
LogEntryType entry_type;
select (entry_type) {
case x509_entry: X509ChainEntry;
case precert_entry: PrecertChainEntry;
} entry;
} LogEntry;
struct {
LogEntryType entry_type;
select (entry_type) {
case x509_entry: X509ChainEntry;
case precert_entry: PrecertChainEntry;
} entry;
} LogEntry;
opaque ASN.1Cert<1..2^24-1>;
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert leaf_certificate;
ASN.1Cert certificate_chain<0..2^24-1>;
} X509ChainEntry;
struct {
ASN.1Cert leaf_certificate;
ASN.1Cert certificate_chain<0..2^24-1>;
} X509ChainEntry;
struct {
ASN.1Cert pre_certificate;
ASN.1Cert precertificate_chain<0..2^24-1>;
} PrecertChainEntry;
struct {
ASN.1Cert pre_certificate;
ASN.1Cert precertificate_chain<0..2^24-1>;
} PrecertChainEntry;
Logs MAY limit the length of chain they will accept.
日志可能会限制他们将接受的链的长度。
"entry_type" is the type of this entry. Future revisions of this protocol version may add new LogEntryType values. Section 4 explains how clients should handle unknown entry types.
“条目类型”是此条目的类型。此协议版本的未来版本可能会添加新的LogEntryType值。第4节解释了客户端应该如何处理未知的条目类型。
"leaf_certificate" is the end-entity certificate submitted for auditing.
“leaf_证书”是提交审核的最终实体证书。
"certificate_chain" is a chain of additional certificates required to verify the end-entity certificate. The first certificate MUST certify the end-entity certificate. Each following certificate MUST directly certify the one preceding it. The final certificate MUST be a root certificate accepted by the log.
“证书链”是验证最终实体证书所需的附加证书链。第一个证书必须证明最终实体证书。下列证书必须直接证明其前面的证书。最终证书必须是日志接受的根证书。
"pre_certificate" is the Precertificate submitted for auditing.
“预认证”是提交审核的预认证。
"precertificate_chain" is a chain of additional certificates required to verify the Precertificate submission. The first certificate MAY be a valid Precertificate Signing Certificate and MUST certify the first certificate. Each following certificate MUST directly certify the one preceding it. The final certificate MUST be a root certificate accepted by the log.
“预认证链”是验证预认证提交所需的附加证书链。第一个证书可能是有效的证书前签名证书，并且必须对第一个证书进行认证。下列证书必须直接证明其前面的证书。最终证书必须是日志接受的根证书。
enum { certificate_timestamp(0), tree_hash(1), (255) }
SignatureType;
enum { certificate_timestamp(0), tree_hash(1), (255) }
SignatureType;
enum { v1(0), (255) }
Version;
enum { v1(0), (255) }
Version;
struct {
opaque key_id[32];
} LogID;
struct {
opaque key_id[32];
} LogID;
opaque TBSCertificate<1..2^24-1>;
opaque TBSCertificate<1..2^24-1>;
struct {
opaque issuer_key_hash[32];
TBSCertificate tbs_certificate;
} PreCert;
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 the DER encoding of the key represented as SubjectPublicKeyInfo.
“key_id”是日志公钥的SHA-256散列，通过表示为SubjectPublicKeyInfo的密钥的DER编码进行计算。
"issuer_key_hash" is the SHA-256 hash of the certificate issuer's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. This is needed to bind the issuer to the final certificate.
“issuer_key_hash”是证书颁发者公钥的SHA-256哈希，通过表示为SubjectPublicKeyInfo的密钥的DER编码计算。这是将颁发者绑定到最终证书所必需的。
"tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280]) 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.
“tbs_证书”是预证书的DER编码的TBSCertificate（请参见[RFC5280]）组件——也就是说，没有签名和毒药扩展。如果预证书未与将颁发最终证书的CA证书签署，则TBSCertificate还将其颁发者更改为将颁发最终证书的CA的颁发者。请注意，通过从最终证书中提取TBSCertificate并删除SCT扩展，也可以从最终证书中重构此TBSCertificate。还请注意，由于TBSCertificate包含一个算法标识符，该标识符必须与证书前签名算法和最终证书签名算法相匹配，因此必须使用相同的算法和参数对它们进行签名。如果预证书是使用预证书签名证书颁发的，并且TBSCertificate中存在授权密钥标识符扩展，则预证书签名证书中也必须存在相应的扩展——在这种情况下，TBSCertificate还更改了其授权密钥标识符，以匹配最终颁发者。
struct {
Version sct_version;
LogID id;
uint64 timestamp;
CtExtensions extensions;
digitally-signed struct {
Version sct_version;
SignatureType signature_type = certificate_timestamp;
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
};
} SignedCertificateTimestamp;
struct {
Version sct_version;
LogID id;
uint64 timestamp;
CtExtensions extensions;
digitally-signed struct {
Version sct_version;
SignatureType signature_type = certificate_timestamp;
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
};
} SignedCertificateTimestamp;
The encoding of the digitally-signed element is defined in [RFC5246].
数字签名元素的编码在[RFC5246]中定义。
"sct_version" is the version of the protocol to which the SCT conforms. This version is v1.
“sct_版本”是sct遵守的协议版本。这个版本是v1。
"timestamp" is the current NTP Time [RFC5905], measured since the epoch (January 1, 1970, 00:00), ignoring leap seconds, in milliseconds.
“timestamp”是当前NTP时间[RFC5905]，从历元（1970年1月1日，00:00）开始测量，忽略闰秒，以毫秒为单位。
"entry_type" may be implicit from the context in which the SCT is presented.
“条目类型”可能是SCT呈现的上下文中隐含的。
"signed_entry" is the "leaf_certificate" (in the case of an X509ChainEntry) or is the PreCert (in the case of a PrecertChainEntry), as described above.
如上所述，“已签名的\u项”是“叶\u证书”（对于X509ChainEntry）或是PreCert（对于PrecertChainEntry）。
"extensions" are future extensions to this protocol version (v1). Currently, no extensions are specified.
“扩展”是本协议版本（v1）的未来扩展。目前，没有指定扩展名。
The SCT data corresponding to the end-entity certificate from at least one log must be included in the TLS handshake, either by using an X509v3 certificate extension as described below, by using a TLS extension (Section 7.4.1.4 of [RFC5246]) with type "signed_certificate_timestamp", or by using Online Certificate Status Protocol (OCSP) Stapling (also known as the "Certificate Status
与来自至少一个日志的终端实体证书相对应的SCT数据必须包含在TLS握手中，可以使用如下所述的X509v3证书扩展，也可以使用类型为“已签名的证书\u时间戳”的TLS扩展（RFC5246的第7.4.1.4节），或者使用在线证书状态协议（OCSP）装订（也称为“证书状态”）
Request" TLS extension; see [RFC6066]), where the response includes an OCSP extension with OID 1.3.6.1.4.1.11129.2.4.5 (see [RFC2560]) and body:
请求“TLS扩展；见[RFC6066]），其中响应包括OCSP扩展，OID为1.3.6.1.4.1.11129.2.4.5（见[RFC2560]），正文：
SignedCertificateTimestampList ::= OCTET STRING
SignedCertificateTimestampList ::= OCTET STRING
At least one SCT MUST be included. Server operators MAY include more than one SCT.
必须至少包括一个SCT。服务器操作员可能包括多个SCT。
Similarly, a certificate authority MAY submit a Precertificate to more than one log, and all obtained SCTs can be directly embedded in the final certificate, by encoding the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and inserting the resulting data in the TBSCertificate as an X.509v3 certificate extension (OID 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, clients can reconstruct the original TBSCertificate to verify the SCT signature.
类似地，证书颁发机构可以向多个日志提交预证书，通过将SignedCertificateTimestampList结构编码为ASN.1八进制字符串，并将结果数据作为X.509v3证书扩展插入TBSCertificate，所有获得的SCT都可以直接嵌入到最终证书中（OID 1.3.6.1.4.1.11129.2.4.2）。收到证书后，客户可以重建原始TBSCertificate以验证SCT签名。
The contents of the ASN.1 OCTET STRING embedded in an OCSP extension or X509v3 certificate extension are as follows:
OCSP扩展或X509v3证书扩展中嵌入的ASN.1八位字节字符串的内容如下：
opaque SerializedSCT<1..2^16-1>;
opaque SerializedSCT<1..2^16-1>;
struct {
SerializedSCT sct_list <1..2^16-1>;
} SignedCertificateTimestampList;
struct {
SerializedSCT sct_list <1..2^16-1>;
} SignedCertificateTimestampList;
Here, "SerializedSCT" is an opaque byte string that contains the serialized TLS structure. This encoding ensures that TLS clients can decode each SCT individually (i.e., if there is a version upgrade, out-of-date clients can still parse old SCTs while skipping over new SCTs whose versions they don't understand).
这里，“SerializedSCT”是一个不透明的字节字符串，包含序列化的TLS结构。这种编码确保TLS客户端可以单独解码每个SCT（即，如果有版本升级，过时的客户端仍然可以解析旧的SCT，同时跳过他们不理解版本的新SCT）。
Likewise, SCTs can be embedded in a TLS extension. See below for details.
同样，SCT可以嵌入到TLS扩展中。详情见下文。
TLS clients MUST implement all three mechanisms. Servers MUST implement at least one of the three mechanisms. Note that existing TLS servers can generally use the certificate extension mechanism without modification.
TLS客户端必须实现这三种机制。服务器必须至少实现三种机制中的一种。请注意，现有的TLS服务器通常可以使用证书扩展机制，无需修改。
TLS servers should send SCTs from multiple logs in case one or more logs are not acceptable to the client (for example, if a log has been struck off for misbehavior or has had a key compromise).
TLS服务器应该从多个日志发送SCT，以防客户端不接受一个或多个日志（例如，如果某个日志因行为不当而被删除或出现密钥泄露）。
The SCT can be sent during the TLS handshake using a TLS extension with type "signed_certificate_timestamp".
在TLS握手期间，可以使用类型为“signed_certificate_timestamp”的TLS扩展发送SCT。
Clients that support the extension SHOULD send a ClientHello extension with the appropriate type and empty "extension_data".
支持该扩展的客户端应发送一个具有适当类型和空“extension_data”的ClientHello扩展。
Servers MUST only send SCTs to clients who have indicated support for the extension in the ClientHello, in which case the SCTs are sent by setting the "extension_data" to a "SignedCertificateTimestampList".
服务器必须仅向在ClientHello中表示支持扩展的客户端发送SCT，在这种情况下，通过将“扩展数据”设置为“SignedCertificateTimestampList”来发送SCT。
Session resumption uses the original session information: clients SHOULD include the extension type in the ClientHello, but if the session is resumed, the server is not expected to process it or include the extension in the ServerHello.
会话恢复使用原始会话信息：客户端应在ClientHello中包含扩展类型，但如果会话恢复，则服务器不需要处理它或在ServerHello中包含扩展。
The hashing algorithm for the Merkle Tree Hash is SHA-256.
Merkle树哈希的哈希算法是SHA-256。
Structure of the Merkle Tree input:
Merkle树输入的结构：
enum { timestamped_entry(0), (255) }
MerkleLeafType;
enum { timestamped_entry(0), (255) }
MerkleLeafType;
struct {
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
} TimestampedEntry;
struct {
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
} TimestampedEntry;
struct {
Version version;
MerkleLeafType leaf_type;
select (leaf_type) {
case timestamped_entry: TimestampedEntry;
}
} MerkleTreeLeaf;
struct {
Version version;
MerkleLeafType leaf_type;
select (leaf_type) {
case timestamped_entry: TimestampedEntry;
}
} MerkleTreeLeaf;
Here, "version" is the version of the protocol to which the MerkleTreeLeaf corresponds. This version is v1.
这里，“版本”是MerkletreeAF对应的协议版本。这个版本是v1。
"leaf_type" is the type of the leaf input. Currently, only "timestamped_entry" (corresponding to an SCT) is defined. Future revisions of this protocol version may add new MerkleLeafType types. Section 4 explains how clients should handle unknown leaf types.
“叶类型”是叶输入的类型。目前，仅定义了“时间戳_条目”（对应于SCT）。本协议版本的未来版本可能会添加新的MerkleLeafType类型。第4节解释了客户端应该如何处理未知叶类型。
"timestamp" is the timestamp of the corresponding SCT issued for this certificate.
“timestamp”是为该证书颁发的相应SCT的时间戳。
"signed_entry" is the "signed_entry" of the corresponding SCT.
“已签名的\u条目”是相应SCT的“已签名的\u条目”。
"extensions" are "extensions" of the corresponding SCT.
“扩展”是相应SCT的“扩展”。
The leaves of the Merkle Tree are the leaf hashes of the corresponding "MerkleTreeLeaf" structures.
Merkle树的叶子是对应的“Merkletreelaf”结构的叶子散列。
Every time a log appends new entries to the tree, the log SHOULD sign the corresponding tree hash and tree information (see the corresponding Signed Tree Head client message in Section 4.3). The signature for that data is structured as follows:
每次日志向树追加新条目时，日志都应该对相应的树哈希和树信息进行签名（请参阅第4.3节中相应的已签名树头客户端消息）。该数据的签名结构如下：
digitally-signed struct {
Version version;
SignatureType signature_type = tree_hash;
uint64 timestamp;
uint64 tree_size;
opaque sha256_root_hash[32];
} TreeHeadSignature;
digitally-signed struct {
Version version;
SignatureType signature_type = tree_hash;
uint64 timestamp;
uint64 tree_size;
opaque sha256_root_hash[32];
} TreeHeadSignature;
"version" is the version of the protocol to which the TreeHeadSignature conforms. This version is v1.
“版本”是树首签名符合的协议版本。这个版本是v1。
"timestamp" is the current time. The timestamp MUST be at least as recent as the most recent SCT timestamp in the tree. Each subsequent timestamp MUST be more recent than the timestamp of the previous update.
“时间戳”是当前时间。时间戳必须至少与树中最新的SCT时间戳相同。每个后续时间戳必须比上一次更新的时间戳更新。
"tree_size" equals the number of entries in the new tree.
“tree_size”等于新树中的条目数。
"sha256_root_hash" is the root of the Merkle Hash Tree.
“sha256_root_hash”是Merkle哈希树的根。
Each log MUST produce on demand a Signed Tree Head that is no older than the Maximum Merge Delay. In the unlikely event that it receives no new submissions during an MMD period, the log SHALL sign the same Merkle Tree Hash with a fresh timestamp.
每个日志必须按需生成不超过最大合并延迟的已签名树头。如果在MMD期间没有收到新的提交，日志应使用新的时间戳对相同的Merkle树哈希进行签名。
Messages are sent as HTTPS GET or POST requests. Parameters for POSTs and all responses are encoded as JavaScript Object Notation (JSON) objects [RFC4627]. Parameters for GETs are encoded as order-independent key/value URL parameters, using the "application/ x-www-form-urlencoded" format described in the "HTML 4.01 Specification" [HTML401]. Binary data is base64 encoded [RFC4648] as specified in the individual messages.
消息以HTTPS GET或POST请求的形式发送。POST和所有响应的参数都编码为JavaScript对象表示法（JSON）对象[RFC4627]。GET的参数使用“HTML4.01规范”[HTML401]中描述的“application/x-www-form-urlencoded”格式编码为与顺序无关的键/值URL参数。二进制数据按照单个消息中的规定进行base64编码[RFC4648]。
Note that JSON objects and URL parameters may contain fields not specified here. These extra fields should be ignored.
请注意，JSON对象和URL参数可能包含此处未指定的字段。应忽略这些额外字段。
The <log server> prefix can include a path as well as a server name and a port.
<log server>前缀可以包括路径、服务器名称和端口。
In general, where needed, the "version" is v1 and the "id" is the log id for the log server queried.
通常，如果需要，“版本”是v1，“id”是所查询日志服务器的日志id。
Any errors will be returned as HTTP 4xx or 5xx responses, with human-readable error messages.
任何错误都将作为HTTP 4xx或5xx响应返回，并带有人类可读的错误消息。
POST https://<log server>/ct/v1/add-chain
POST https://<log server>/ct/v1/add-chain
Inputs:
投入：
chain: An array of base64-encoded certificates. The first element is the end-entity certificate; the second chains to the first and so on to the last, which is either the root certificate or a certificate that chains to a known root certificate.
链：base64编码证书的数组。第一个元素是终端实体证书；第二个链接到第一个，依此类推到最后一个，即根证书或链接到已知根证书的证书。
Outputs:
产出：
sct_version: The version of the SignedCertificateTimestamp structure, in decimal. A compliant v1 implementation MUST NOT expect this to be 0 (i.e., v1).
sct_版本：SignedCertificateTimestamp结构的版本，十进制。兼容的v1实现不能期望该值为0（即v1）。
id: The log ID, base64 encoded. Since log clients who request an SCT for inclusion in TLS handshakes are not required to verify it, we do not assume they know the ID of the log.
id：日志id，base64编码。由于请求将SCT包含在TLS握手中的日志客户端不需要验证它，因此我们不认为他们知道日志的ID。
timestamp: The SCT timestamp, in decimal.
时间戳：SCT时间戳，十进制。
extensions: An opaque type for future expansion. It is likely that not all participants will need to understand data in this field. Logs should set this to the empty string. Clients should decode the base64-encoded data and include it in the SCT.
扩展：用于将来扩展的不透明类型。可能并非所有参与者都需要了解该领域的数据。日志应将其设置为空字符串。客户端应解码base64编码数据并将其包含在SCT中。
signature: The SCT signature, base64 encoded.
签名：SCT签名，base64编码。
If the "sct_version" is not v1, then a v1 client may be unable to verify the signature. It MUST NOT construe this as an error. (Note: Log clients don't need to be able to verify this structure; only TLS clients do. If we were to serve the structure as a binary blob, then we could completely change it without requiring an upgrade to v1 clients.)
如果“sct_版本”不是v1，则v1客户端可能无法验证签名。它不能将此解释为错误。（注意：日志客户端不需要验证此结构；只有TLS客户端可以验证此结构。如果我们将此结构作为二进制blob提供，则可以完全更改它，而无需升级到v1客户端。）
POST https://<log server>/ct/v1/add-pre-chain
POST https://<log server>/ct/v1/add-pre-chain
Inputs:
投入：
chain: An array of base64-encoded Precertificates. The first element is the end-entity certificate; the second chains to the first and so on to the last, which is either the root certificate or a certificate that chains to a known root certificate.
链：base64编码的前证书数组。第一个元素是终端实体证书；第二个链接到第一个，依此类推到最后一个，即根证书或链接到已知根证书的证书。
Outputs are the same as in Section 4.1.
输出与第4.1节相同。
GET https://<log server>/ct/v1/get-sth
GET https://<log server>/ct/v1/get-sth
No inputs.
没有输入。
Outputs:
产出：
tree_size: The size of the tree, in entries, in decimal.
树大小：树的大小，以条目为单位，以十进制为单位。
timestamp: The timestamp, in decimal.
时间戳：时间戳，十进制。
sha256_root_hash: The Merkle Tree Hash of the tree, in base64.
sha256_root_hash：树的Merkle树哈希，在base64中。
tree_head_signature: A TreeHeadSignature for the above data.
树头签名：上述数据的树头签名。
GET https://<log server>/ct/v1/get-sth-consistency
GET https://<log server>/ct/v1/get-sth-consistency
Inputs:
投入：
first: The tree_size of the first tree, in decimal.
first：第一棵树的树大小，十进制。
second: The tree_size of the second tree, in decimal.
第二棵树：第二棵树的树大小，十进制。
Both tree sizes must be from existing v1 STHs (Signed Tree Heads).
两个树的大小必须来自现有的v1 STH（签名树头）。
Outputs:
产出：
consistency: An array of Merkle Tree nodes, base64 encoded.
一致性：Merkle树节点数组，base64编码。
Note that no signature is required on this data, as it is used to verify an STH, which is signed.
请注意，此数据无需签名，因为它用于验证已签名的STH。
GET https://<log server>/ct/v1/get-proof-by-hash
GET https://<log server>/ct/v1/get-proof-by-hash
Inputs:
投入：
hash: A base64-encoded v1 leaf hash.
哈希：base64编码的v1叶哈希。
tree_size: The tree_size of the tree on which to base the proof, in decimal.
tree_size：作为证明基础的树的树大小，以十进制为单位。
The "hash" must be calculated as defined in Section 3.4. The "tree_size" must designate an existing v1 STH.
必须按照第3.4节中的定义计算“散列”。“树大小”必须指定现有的v1 STH。
Outputs:
产出：
leaf_index: The 0-based index of the end entity corresponding to the "hash" parameter.
leaf_index：与“hash”参数相对应的结束实体的基于0的索引。
audit_path: An array of base64-encoded Merkle Tree nodes proving the inclusion of the chosen certificate.
audit_path：一个base64编码的Merkle树节点数组，证明包含所选证书。
GET https://<log server>/ct/v1/get-entries
GET https://<log server>/ct/v1/get-entries
Inputs:
投入：
start: 0-based index of first entry to retrieve, in decimal.
开始：要检索的第一个条目的基于0的索引，以十进制为单位。
end: 0-based index of last entry to retrieve, in decimal.
结束：要检索的最后一个条目的基于0的索引，以十进制为单位。
Outputs:
产出：
entries: An array of objects, each consisting of
条目：一个对象数组，每个对象由
leaf_input: The base64-encoded MerkleTreeLeaf structure.
leaf_输入：base64编码的MerkletreeLaf结构。
extra_data: The base64-encoded unsigned data pertaining to the log entry. In the case of an X509ChainEntry, this is the "certificate_chain". In the case of a PrecertChainEntry, this is the whole "PrecertChainEntry".
extra_数据：与日志项相关的base64编码的无符号数据。对于X509ChainEntry，这是“证书链”。如果是PreterChainEntry，这就是整个“PreterChainEntry”。
Note that this message is not signed -- the retrieved data can be verified by constructing the Merkle Tree Hash corresponding to a retrieved STH. All leaves MUST be v1. However, a compliant v1 client MUST NOT construe an unrecognized MerkleLeafType or LogEntryType value as an 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 verify the integrity of the data by treating unrecognized leaves as opaque input to the tree.
请注意，此消息没有签名——可以通过构造与检索到的STH对应的Merkle树散列来验证检索到的数据。所有叶子都必须是v1。但是，兼容v1客户端不得将无法识别的MerkleLeaftType或LogEntryType值分析为错误。这意味着它可能无法解析某些条目，但请注意，每个客户端都可以检查它确实识别的条目，并通过将未识别的叶子视为树的不透明输入来验证数据的完整性。
The "start" and "end" parameters SHOULD be within the range 0 <= x < "tree_size" as returned by "get-sth" in Section 4.3.
“开始”和“结束”参数应在第4.3节“获取某物”返回的0<=x<“树大小”范围内。
Logs MAY honor requests where 0 <= "start" < "tree_size" and "end" >= "tree_size" by returning a partial response covering only the valid entries in the specified range. Note that the following restriction may also apply:
日志可能会通过返回仅包含指定范围内有效项的部分响应来满足0<=“开始”<“树大小”和“结束”>=“树大小”的请求。请注意，以下限制也可能适用：
Logs MAY restrict the number of entries that can be retrieved per "get-entries" request. If a client requests more than the permitted number of entries, the log SHALL return the maximum number of entries permissible. These entries SHALL be sequential beginning with the entry specified by "start".
日志可能会限制每个“获取条目”请求可以检索的条目数。如果客户请求的条目数超过允许的条目数，日志应返回允许的最大条目数。这些条目应按顺序从“开始”指定的条目开始。
GET https://<log server>/ct/v1/get-roots
GET https://<log server>/ct/v1/get-roots
No inputs.
没有输入。
Outputs:
产出：
certificates: An array of base64-encoded root certificates that are acceptable to the log.
证书：日志可接受的base64编码根证书数组。
GET https://<log server>/ct/v1/get-entry-and-proof
GET https://<log server>/ct/v1/get-entry-and-proof
Inputs:
投入：
leaf_index: The index of the desired entry.
叶索引：所需条目的索引。
tree_size: The tree_size of the tree for which the proof is desired.
tree_size：需要证明的树的树大小。
The tree size must designate an existing STH.
树的大小必须指定现有的某事物。
Outputs:
产出：
leaf_input: The base64-encoded MerkleTreeLeaf structure.
leaf_输入：base64编码的MerkletreeLaf结构。
extra_data: The base64-encoded unsigned data, same as in Section 4.6.
额外_数据：base64编码的无符号数据，与第4.6节相同。
audit_path: An array of base64-encoded Merkle Tree nodes proving the inclusion of the chosen certificate.
audit_path：一个base64编码的Merkle树节点数组，证明包含所选证书。
This API is probably only useful for debugging.
此API可能仅对调试有用。
There are various different functions clients of logs might perform. We describe here some typical clients and how they could function. Any inconsistency may be used as evidence that a log has not behaved correctly, and the signatures on the data structures prevent the log from denying that misbehavior.
日志的客户端可能执行各种不同的功能。我们在这里描述一些典型的客户机以及它们如何工作。任何不一致都可以作为日志行为不正确的证据，并且数据结构上的签名可以防止日志否认该错误行为。
All clients should gossip with each other, exchanging STHs at least; this is all that is required to ensure that they all have a consistent view. The exact mechanism for gossip will be described in a separate document, but it is expected there will be a variety.
所有客户都应该互相闲聊，至少交换STH；这就是确保所有人都有一致观点所需的全部内容。流言蜚语的确切机制将在另一份文件中描述，但预计会有多种形式。
Submitters submit certificates or Precertificates to the log as described above. They may go on to use the returned SCT to construct a certificate or use it directly in a TLS handshake.
提交者向日志提交证书或预证书，如上所述。他们可以继续使用返回的SCT来构造证书，或者直接在TLS握手中使用它。
TLS clients are not directly clients of the log, but they receive SCTs alongside or in server certificates. In addition to normal validation of the certificate and its chain, they should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key. Note that this document does not describe how clients obtain the logs' public keys.
TLS客户端不是日志的直接客户端，但它们与服务器证书一起或在服务器证书中接收SCT。除了证书及其链的正常验证外，他们还应该通过计算从SCT数据输入的签名以及证书来验证SCT，并使用相应日志的公钥验证签名。请注意，本文档没有描述客户端如何获取日志的公钥。
TLS clients MUST reject SCTs whose timestamp is in the future.
TLS客户端必须拒绝时间戳在将来的SCT。
Monitors watch logs and check that they behave correctly. They also watch for certificates of interest.
监视器监视日志并检查其行为是否正确。他们还关注利息证书。
A monitor needs to, at least, inspect every new entry in each log it watches. It may also want to keep copies of entire logs. In order to do this, it should follow these steps for each log:
监视器至少需要检查它监视的每个日志中的每个新条目。它可能还希望保留整个日志的副本。为此，应对每个日志执行以下步骤：
1. Fetch the current STH (Section 4.3).
1. 获取当前某物（第4.3节）。
2. Verify the STH signature.
2. 核实签名。
3. Fetch all the entries in the tree corresponding to the STH (Section 4.6).
3. 获取树中与STH对应的所有条目（第4.6节）。
4. Confirm that the tree made from the fetched entries produces the same hash as that in the STH.
4. 确认从获取的条目生成的树生成的哈希值与STH中的哈希值相同。
5. Fetch the current STH (Section 4.3). Repeat until the STH changes.
5. 获取当前某物（第4.3节）。重复，直到某物发生变化。
6. Verify the STH signature.
6. 核实签名。
7. Fetch all the new entries in the tree corresponding to the STH (Section 4.6). If they remain unavailable for an extended period, then this should be viewed as misbehavior on the part of the log.
7. 获取树中与STH对应的所有新条目（第4.6节）。如果它们长时间不可用，则应将其视为日志中的错误行为。
8. Either:
8. 要么：
1. Verify that the updated list of all entries generates a tree with the same hash as the new STH.
1. 验证所有条目的更新列表是否生成一个与新STH具有相同哈希的树。
Or, if it is not keeping all log entries:
或者，如果未保留所有日志条目：
2. Fetch a consistency proof for the new STH with the previous STH (Section 4.4).
2. 为新的某事物与先前的某事物取得一致性证明（第4.4节）。
3. Verify the consistency proof.
3. 验证一致性证明。
4. Verify that the new entries generate the corresponding elements in the consistency proof.
4. 验证新条目是否在一致性证明中生成了相应的元素。
9. Go to Step 5.
9. 转至步骤5。
Auditors take partial information about a log as input and verify that this information is consistent with other partial information 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 function of a monitor.
审核员将日志的部分信息作为输入，并验证该信息是否与他们拥有的其他部分信息一致。审计员可能是TLS客户不可分割的组成部分；它可能是一个独立的服务；或者它可能是监视器的辅助功能。
Any pair of STHs from the same log can be verified by requesting a consistency proof (Section 4.4).
可以通过请求一致性证明（第4.4节）来验证同一日志中的任何一对STH。
A certificate accompanied by an SCT can be verified against any STH dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle audit proof (Section 4.5).
通过请求Merkle审计证明（第4.5节），可以根据SCT时间戳+最大合并延迟后的任何STH对附有SCT的证书进行验证。
Auditors can fetch STHs from time to time of their own accord, of course (Section 4.3).
当然，审核员可以随时主动获取STH（第4.3节）。
IANA has allocated an RFC 5246 ExtensionType value (18) for the SCT TLS extension. The extension name is "signed_certificate_timestamp".
IANA已为SCT TLS扩展分配RFC 5246 ExtensionType值（18）。扩展名是“签名的\u证书\u时间戳”。
With CAs, logs, and servers performing the actions described here, TLS clients can use logs and signed timestamps to reduce the likelihood that they will accept misissued certificates. If a server presents a valid signed timestamp for a certificate, then the client knows that the certificate has been published in a log. From this, the client knows that the subject of the certificate has had some
通过CA、日志和服务器执行此处描述的操作，TLS客户端可以使用日志和签名的时间戳来降低接受错误颁发的证书的可能性。如果服务器为证书提供有效的签名时间戳，则客户端知道该证书已在日志中发布。由此，客户机知道证书的主体有一些
time to notice the misissue and take some action, such as asking a CA to revoke a misissued certificate. A signed timestamp is not a guarantee that the certificate is not misissued, since the subject of the certificate might not have checked the logs or the CA might have refused to revoke the certificate.
是时候通知错误颁发并采取一些措施了，例如要求CA撤销错误颁发的证书。签名的时间戳不能保证证书不会被错误颁发，因为证书的主体可能没有检查日志，或者CA可能拒绝撤销证书。
In addition, if TLS clients will not accept unlogged certificates, then site owners will have a greater incentive to submit certificates to logs, possibly with the assistance of their CA, increasing the overall transparency of the system.
此外，如果TLS客户端不接受未标记的证书，那么站点所有者将有更大的动力向日志提交证书，可能是在其CA的帮助下，从而提高系统的总体透明度。
Misissued certificates that have not been publicly logged, and thus do not have a valid SCT, will be rejected by TLS clients. Misissued certificates that do have an SCT from a log will appear in that public log within the Maximum Merge Delay, assuming the log is operating correctly. Thus, the maximum period of time during which a misissued certificate can be used without being available for audit is the MMD.
TLS客户端将拒绝未公开记录的错误颁发的证书，因此没有有效的SCT。如果日志运行正常，则在最大合并延迟内，错误颁发的证书（具有来自日志的SCT）将出现在该公共日志中。因此，在不可用于审计的情况下使用错误颁发的证书的最长时间段是MMD。
The logs do not themselves detect misissued certificates; they rely instead on interested parties, such as domain owners, to monitor them and take corrective action when a misissue is detected.
日志本身不会检测到错误颁发的证书；相反，它们依赖于相关方（如域所有者）来监控它们，并在检测到错误问题时采取纠正措施。
A log can misbehave in two ways: (1) by failing to incorporate a certificate with an SCT in the Merkle Tree within the MMD and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties. Both forms of violation will be promptly and publicly detectable.
日志可能以两种方式出现错误行为：（1）未能将带有SCT的证书合并到MMD中的Merkle树中；（2）在不同时间和/或向不同方呈现Merkle树的两个不同、冲突的视图，从而违反其仅附加属性。这两种形式的违规行为都将被迅速公开检测。
Violation of the MMD contract is detected by log clients requesting a Merkle audit proof for each observed SCT. These checks can be asynchronous and need only be done once per each certificate. In order to protect the clients' privacy, these checks need not reveal the exact certificate to the log. Clients can instead request the proof from a trusted auditor (since anyone can compute the audit proofs from the log) or request Merkle proofs for a batch of certificates around the SCT timestamp.
日志客户端会检测到违反MMD契约的情况，并要求为每个观察到的SCT提供Merkle审核证明。这些检查可以是异步的，每个证书只需执行一次。为了保护客户的隐私，这些检查不需要向日志显示确切的证书。客户机可以从可信的审核员处请求证明（因为任何人都可以从日志中计算审核证明），或者请求围绕SCT时间戳的一批证书的Merkle证明。
Violation of the append-only property is detected by global gossiping, i.e., everyone auditing logs comparing their versions of the latest Signed Tree Heads. As soon as two conflicting Signed Tree
全局八卦会检测到对append only属性的违反，即每个人都会对日志进行审核，比较其最新签名树头的版本。只要两个相互冲突的签名树
Heads for the same log are detected, this is cryptographic proof of that log's misbehavior.
检测到同一日志的头，这是该日志错误行为的加密证明。
The Merkle Tree design serves the purpose of keeping communication overhead low.
Merkle树设计的目的是保持低通信开销。
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.
完整性审核日志不需要第三方维护每个完整日志的副本。可以在新条目可用时更新已签名的树头，而无需重新计算整个树。第三方审计人员只需根据日志的现有STH获取Merkle一致性证明，就可以有效地验证Merkle树更新的append-only属性，而无需审计整个树。
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 我们可以允许一些密钥滚动机制，而不是强制日志操作员创建新日志以更改日志签名密钥。
o We may add hash and signing algorithm agility.
o 我们可以增加哈希和签名算法的灵活性。
o We may describe some gossip protocols.
o 我们可以描述一些八卦协议。
The authors would like to thank Erwann Abelea, Robin Alden, Al Cutter, Francis Dupont, Stephen Farrell, Brad Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor Perrin, Ryan Sleevi, Rob Stradling, and Carl Wallace for their valuable contributions.
作者要感谢埃尔文·阿贝利亚、罗宾·奥尔登、艾尔·卡特、弗朗西斯·杜邦、斯蒂芬·法雷尔、布拉德·希尔、杰夫·霍奇斯、保罗·霍夫曼、杰弗里·哈泽尔曼、SM、亚历克赛·梅尔尼科夫、克里斯·帕尔默、特雷弗·佩林、瑞安·斯维吉、罗伯·斯特拉丁和卡尔·华莱士，感谢他们的宝贵贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CrosbyWallach] Crosby, S. and D. Wallach, "Efficient Data Structures for Tamper-Evident Logging", Proceedings of the 18th USENIX Security Symposium, Montreal, August 2009, <http://static.usenix.org/event/sec09/ tech/full_papers/crosby.pdf>.
[CrosbyWallach]Crosby，S.和D.Wallach，“防篡改日志记录的有效数据结构”，第18届USENIX安全研讨会论文集，蒙特利尔，2009年8月<http://static.usenix.org/event/sec09/ tech/full_papers/crosby.pdf>。
[DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-3, June 2009, <http://csrc.nist.gov/publications/fips/ fips186-3/fips_186-3.pdf>.
[DSS]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS 186-3，2009年6月<http://csrc.nist.gov/publications/fips/ fips186-3/fips_186-3.pdf>。
[FIPS.180-4] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[FIPS.180-4]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-42012年3月<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>。
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[HTML401]Raggett，D.，Le Hors，A.，和I.Jacobs，“HTML 4.01规范”，万维网联盟建议REC-HTML401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC4627，2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
Authors' Addresses
作者地址
Ben Laurie Google UK Ltd.
谷歌英国有限公司。
EMail: benl@google.com
EMail: benl@google.com
Adam Langley Google Inc.
亚当·兰利谷歌公司。
EMail: agl@google.com
EMail: agl@google.com
Emilia Kasper Google Switzerland GmbH
埃米利娅·卡斯珀谷歌瑞士有限公司
EMail: ekasper@google.com
EMail: ekasper@google.com