draft-ietf-trans-rfc6962-bis-25.txt   draft-ietf-trans-rfc6962-bis-26.txt 
TRANS (Public Notary Transparency) B. Laurie TRANS (Public Notary Transparency) B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Obsoletes: 6962 (if approved) E. Kasper Obsoletes: 6962 (if approved) E. Kasper
Intended status: Standards Track E. Messeri Intended status: Standards Track E. Messeri
Expires: January 1, 2018 Google Expires: January 29, 2018 Google
R. Stradling R. Stradling
Comodo Comodo
June 30, 2017 July 28, 2017
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-25 draft-ietf-trans-rfc6962-bis-26
Abstract Abstract
This document describes version 2.0 of the Certificate Transparency This document describes version 2.0 of the Certificate Transparency
(CT) protocol for publicly logging the existence of Transport Layer (CT) protocol for publicly logging the existence of Transport Layer
Security (TLS) server certificates as they are issued or observed, in Security (TLS) server certificates as they are issued or observed, in
a manner that allows anyone to audit certification authority (CA) a manner that allows anyone to audit certification authority (CA)
activity and notice the issuance of suspect certificates as well as activity and notice the issuance of suspect certificates as well as
to audit the certificate logs themselves. The intent is that to audit the certificate logs themselves. The intent is that
eventually clients would refuse to honor certificates that do not eventually clients would refuse to honor certificates that do not
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 1, 2018. This Internet-Draft will expire on January 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 19 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 19
4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 20 4.7. Merkle Tree Leaves . . . . . . . . . . . . . . . . . . . 20
4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 21 4.8. Signed Certificate Timestamp (SCT) . . . . . . . . . . . 21
4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 22 4.9. Merkle Tree Head . . . . . . . . . . . . . . . . . . . . 22
4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 22 4.10. Signed Tree Head (STH) . . . . . . . . . . . . . . . . . 22
4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23 4.11. Merkle Consistency Proofs . . . . . . . . . . . . . . . . 23
4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 24 4.12. Merkle Inclusion Proofs . . . . . . . . . . . . . . . . . 24
4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 24 4.13. Shutting down a log . . . . . . . . . . . . . . . . . . . 24
5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 25 5. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 25
5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 26 5.1. Submit Entry to Log . . . . . . . . . . . . . . . . . . . 26
5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 28 5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 29
5.3. Retrieve Merkle Consistency Proof between Two Signed Tree 5.3. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 30 5.4. Retrieve Merkle Inclusion Proof from Log by Leaf Hash . . 30
5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and 5.5. Retrieve Merkle Inclusion Proof, Signed Tree Head and
Consistency Proof by Leaf Hash . . . . . . . . . . . . . 31 Consistency Proof by Leaf Hash . . . . . . . . . . . . . 31
5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 32 5.6. Retrieve Entries and STH from Log . . . . . . . . . . . . 32
5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34 5.7. Retrieve Accepted Trust Anchors . . . . . . . . . . . . . 34
6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. TLS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . . 35
6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 35 6.2. TransItemList Structure . . . . . . . . . . . . . . . . . 35
skipping to change at page 4, line 8 skipping to change at page 4, line 8
10.7. Object Identifiers . . . . . . . . . . . . . . . . . . . 46 10.7. Object Identifiers . . . . . . . . . . . . . . . . . . . 46
10.7.1. Log ID Registry . . . . . . . . . . . . . . . . . . 46 10.7.1. Log ID Registry . . . . . . . . . . . . . . . . . . 46
10.7.2. Expert Review guidelines . . . . . . . . . . . . . . 47 10.7.2. Expert Review guidelines . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 48 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 48
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 48 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 48
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 48 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 48
11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 49 11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 49
11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 49 11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 49
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 13.1. Normative References . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 51 13.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 53 Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Certificate Transparency aims to mitigate the problem of misissued Certificate Transparency aims to mitigate the problem of misissued
certificates by providing append-only logs of issued certificates. certificates by providing append-only logs of issued certificates.
The logs do not need to be trusted because they are publicly The logs do not need to be trusted because they are publicly
skipping to change at page 6, line 38 skipping to change at page 6, line 38
o Log Artifact Extensions: these are now typed and managed by an o Log Artifact Extensions: these are now typed and managed by an
IANA registry, and they can now appear not only in SCTs but also IANA registry, and they can now appear not only in SCTs but also
in STHs. in STHs.
o API outputs: complete "TransItem" structures are returned, rather o API outputs: complete "TransItem" structures are returned, rather
than the constituent parts of each structure. than the constituent parts of each structure.
o get-all-by-hash: new client API for obtaining an inclusion proof o get-all-by-hash: new client API for obtaining an inclusion proof
and the corresponding consistency proof at the same time. and the corresponding consistency proof at the same time.
o submit-entry: new client API, replacing add-chain and add-pre-
chain.
o Presenting SCTs with proofs: TLS servers may present SCTs together o Presenting SCTs with proofs: TLS servers may present SCTs together
with the corresponding inclusion proofs using any of the with the corresponding inclusion proofs using any of the
mechanisms that [RFC6962] defined for presenting SCTs only. mechanisms that [RFC6962] defined for presenting SCTs only.
(Presenting SCTs only is still supported). (Presenting SCTs only is still supported).
o CT TLS extension: the "signed_certificate_timestamp" TLS extension o CT TLS extension: the "signed_certificate_timestamp" TLS extension
has been replaced by the "transparency_info" TLS extension. has been replaced by the "transparency_info" TLS extension.
o Other TLS extensions: "status_request_v2" may be used (in the same o Other TLS extensions: "status_request_v2" may be used (in the same
manner as "status_request"); "cached_info" may be used to avoid manner as "status_request"); "cached_info" may be used to avoid
skipping to change at page 27, line 10 skipping to change at page 27, line 10
Inputs: Inputs:
submission: The base64 encoded certificate or precertificate. submission: The base64 encoded certificate or precertificate.
type: The "VersionedTransType" integer value that indicates the type: The "VersionedTransType" integer value that indicates the
type of the "submission": 1 for "x509_entry_v2", or 2 for type of the "submission": 1 for "x509_entry_v2", or 2 for
"precert_entry_v2". "precert_entry_v2".
chain: An array of zero or more base64 encoded CA certificates. chain: An array of zero or more base64 encoded CA certificates.
The first element is the signer of the "submission"; the second The first element is the certifier of the "submission"; the
certifies the first; etc. The last element of "chain" (or, if second certifies the first; etc. The last element of "chain"
"chain" is an empty array, the "submission") either is, or is (or, if "chain" is an empty array, the "submission") is
certified by, an accepted trust anchor. certified by an accepted trust anchor.
Outputs: Outputs:
sct: A base64 encoded "TransItem" of type "x509_sct_v2" or sct: A base64 encoded "TransItem" of type "x509_sct_v2" or
"precert_sct_v2", signed by this log, that corresponds to the "precert_sct_v2", signed by this log, that corresponds to the
"submission". "submission".
If the submitted entry is immediately appended to (or already If the submitted entry is immediately appended to (or already
exists in) this log's tree, then the log SHOULD also output: exists in) this log's tree, then the log SHOULD also output:
skipping to change at page 28, line 13 skipping to change at page 28, line 13
Error codes: Error codes:
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Error Code | Meaning | | Error Code | Meaning |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| bad | "submission" is neither a valid certificate nor a | | bad | "submission" is neither a valid certificate nor a |
| submission | valid precertificate. | | submission | valid precertificate. |
| | | | | |
| bad type | "type" is neither 1 nor 2. | | bad type | "type" is neither 1 nor 2. |
| | | | | |
| bad chain | The first element of "chain" is not the signer of | | bad chain | The first element of "chain" is not the certifier |
| | the "submission", or the second element does not | | | of the "submission", or the second element does not |
| | certify the first, etc. | | | certify the first, etc. |
| | | | | |
| bad | One or more certificates in the "chain" are not | | bad | One or more certificates in the "chain" are not |
| certificate | valid (e.g., not properly encoded). | | certificate | valid (e.g., not properly encoded). |
| | | | | |
| unknown | The last element of "chain" (or, if "chain" is an | | unknown | The last element of "chain" (or, if "chain" is an |
| anchor | empty array, the "submission") both is not, and is | | anchor | empty array, the "submission") both is not, and is |
| | not certified by, an accepted trust anchor. | | | not certified by, an accepted trust anchor. |
| | | | | |
| shutdown | The log is no longer accepting submissions. | | shutdown | The log is no longer accepting submissions. |
skipping to change at page 28, line 39 skipping to change at page 28, line 39
is to avoid forcing an upgrade of compliant v2 clients that do not is to avoid forcing an upgrade of compliant v2 clients that do not
use the returned SCTs. use the returned SCTs.
If a log detects bad encoding in a chain that otherwise verifies If a log detects bad encoding in a chain that otherwise verifies
correctly then the log MUST either log the certificate or return the correctly then the log MUST either log the certificate or return the
"bad certificate" error. If the certificate is logged, an SCT MUST "bad certificate" error. If the certificate is logged, an SCT MUST
be issued. Logging the certificate is useful, because monitors be issued. Logging the certificate is useful, because monitors
(Section 8.2) can then detect these encoding errors, which may be (Section 8.2) can then detect these encoding errors, which may be
accepted by some TLS clients. accepted by some TLS clients.
If the returned "sct" is intended to be provided to clients, then If "submission" is an accepted trust anchor whose certifier is
"sth" and "inclusion" (if returned) SHOULD also be provided to neither an accepted trust anchor nor the first element of "chain",
clients (e.g., if "type" was 1 then all three "TransItem"s could be then the log MUST return the "unknown anchor" error. A log cannot
embedded in the certificate). generate an SCT for a submission if it does not have access to the
issuer's public key.
If the returned "sct" is intended to be provided to TLS clients, then
"sth" and "inclusion" (if returned) SHOULD also be provided to TLS
clients (e.g., if "type" was 2 (for "precert_sct_v2") then all three
"TransItem"s could be embedded in the certificate).
5.2. Retrieve Latest Signed Tree Head 5.2. Retrieve Latest Signed Tree Head
GET https://<log server>/ct/v2/get-sth GET https://<log server>/ct/v2/get-sth
No inputs. No inputs.
Outputs: Outputs:
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
skipping to change at page 33, line 26 skipping to change at page 33, line 26
client can inspect the entries it does recognize as well as verify client can inspect the entries it does recognize as well as verify
the integrity of the data by treating unrecognized leaves as opaque the integrity of the data by treating unrecognized leaves as opaque
input to the tree. input to the tree.
The "start" and "end" parameters SHOULD be within the range 0 <= x < The "start" and "end" parameters SHOULD be within the range 0 <= x <
"tree_size" as returned by "get-sth" in Section 5.2. "tree_size" as returned by "get-sth" in Section 5.2.
The "start" parameter MUST be less than or equal to the "end" The "start" parameter MUST be less than or equal to the "end"
parameter. parameter.
The "chain" field in the "submission" output parameter MUST include Each "submitted_entry" output parameter MUST include the trust anchor
the trust anchor that the log used to verify the submission, even if that the log used to verify the "submission", even if that trust
it was omitted in the original submission. anchor was not provided to "submit-entry" (see Section 5.1). If the
"submission" does not certify itself, then the first element of
"chain" MUST be present and MUST certify the "submission".
Log servers MUST honor requests where 0 <= "start" < "tree_size" and Log servers MUST honor requests where 0 <= "start" < "tree_size" and
"end" >= "tree_size" by returning a partial response covering only "end" >= "tree_size" by returning a partial response covering only
the valid entries in the specified range. "end" >= "tree_size" could the valid entries in the specified range. "end" >= "tree_size" could
be caused by skew. Note that the following restriction may also be caused by skew. Note that the following restriction may also
apply: apply:
Logs MAY restrict the number of entries that can be retrieved per Logs MAY restrict the number of entries that can be retrieved per
"get-entries" request. If a client requests more than the permitted "get-entries" request. If a client requests more than the permitted
number of entries, the log SHALL return the maximum number of entries number of entries, the log SHALL return the maximum number of entries
skipping to change at page 48, line 35 skipping to change at page 48, line 35
The logs do not themselves detect misissued certificates; they rely The logs do not themselves detect misissued certificates; they rely
instead on interested parties, such as domain owners, to monitor them instead on interested parties, such as domain owners, to monitor them
and take corrective action when a misissue is detected. and take corrective action when a misissue is detected.
11.3. Misbehaving Logs 11.3. Misbehaving Logs
A log can misbehave in several ways. Examples include: failing to A log can misbehave in several ways. Examples include: failing to
incorporate a certificate with an SCT in the Merkle Tree within the incorporate a certificate with an SCT in the Merkle Tree within the
MMD; presenting different, conflicting views of the Merkle Tree at MMD; presenting different, conflicting views of the Merkle Tree at
different times and/or to different parties; and issuing STHs too different times and/or to different parties; issuing STHs too
frequently. Such misbehavior is detectable and frequently; mutating the signature of a logged certificate; and
failing to present a chain containing the certifier of a logged
certificate. Such misbehavior is detectable and
[I-D.ietf-trans-threat-analysis] provides more details on how this [I-D.ietf-trans-threat-analysis] provides more details on how this
can be done. can be done.
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 inclusion proof (Section 5.4) for each observed SCT. These Merkle inclusion proof (Section 5.4) for each observed SCT. These
checks can be asynchronous and need only be done once per checks can be asynchronous and need only be done once per
certificate. In order to protect the clients' privacy, these checks certificate. In order to protect the clients' privacy, these checks
need not reveal the exact certificate to the log. Instead, clients need not reveal the exact certificate to the log. Instead, clients
can request the proof from a trusted auditor (since anyone can can request the proof from a trusted auditor (since anyone can
compute the proofs from the log) or communicate with the log via compute the proofs from the log) or communicate with the log via
skipping to change at page 50, line 18 skipping to change at page 50, line 21
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
April 2017. July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
 End of changes. 13 change blocks. 
23 lines changed or deleted 36 lines changed or added

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