draft-ietf-trans-rfc6962-bis-27.txt   draft-ietf-trans-rfc6962-bis-28.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: May 3, 2018 Google Expires: September 6, 2018 Google
R. Stradling R. Stradling
Comodo Comodo CA
October 30, 2017 March 05, 2018
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-27 draft-ietf-trans-rfc6962-bis-28
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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 42 skipping to change at page 2, line 42
2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 12 2.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 13
3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Submitters . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Certificates . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14 3.2. Precertificates . . . . . . . . . . . . . . . . . . . . . 14
4. Log Format and Operation . . . . . . . . . . . . . . . . . . 15 4. Log Format and Operation . . . . . . . . . . . . . . . . . . 15
4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16 4.1. Log Parameters . . . . . . . . . . . . . . . . . . . . . 16
4.2. Accepting Submissions . . . . . . . . . . . . . . . . . . 17 4.2. Accepting Submissions . . . . . . . . . . . . . . . . . . 17
4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Log ID . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 18 4.5. TransItem Structure . . . . . . . . . . . . . . . . . . . 19
4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 19 4.6. Log Artifact Extensions . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . 29 5.2. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 29
skipping to change at page 17, line 27 skipping to change at page 17, line 27
the client should know the final valid STH in the log to ensure no the client should know the final valid STH in the log to ensure no
new entries can be added without detection. The final STH should new entries can be added without detection. The final STH should
be provided in the form of a TransItem of type be provided in the form of a TransItem of type
"signed_tree_head_v2". "signed_tree_head_v2".
[JSON.Metadata] is an example of a metadata format which includes the [JSON.Metadata] is an example of a metadata format which includes the
above elements. above elements.
4.2. Accepting Submissions 4.2. Accepting Submissions
To avoid being overloaded by invalid submissions, the log MUST NOT To set clear expectations for what monitors would find in a log, and
accept any submission until it has verified that the certificate or to avoid being overloaded by invalid submissions, the log MUST NOT
precertificate was submitted with a valid signature chain to an accept any submission until it has verified that the submitted
accepted trust anchor. The log MUST NOT use other sources of certificate or precertificate chains to an accepted trust anchor.
intermediate CA certificates to attempt certification path While there are no security implications to a log accepting a
construction; instead, it MUST only use the intermediate CA submission that does not chain to one of its accepted trust anchors,
certificates provided in the submission, in the order provided. doing so would put additional burden on monitors that inspect log
entries. Additionally, there are no provisions in the protocol for a
log to indicate that a particular submission was erroneously
accepted.
The log MUST NOT use other sources of intermediate CA certificates to
attempt certification path construction; instead, it MUST only use
the intermediate CA certificates provided in the submission, in the
order provided.
Logs SHOULD accept certificates and precertificates that are fully Logs SHOULD accept certificates and precertificates that are fully
valid according to RFC 5280 [RFC5280] verification rules and are valid according to RFC 5280 [RFC5280] verification rules and are
submitted with such a chain. (A log may decide, for example, to submitted with such a chain. (A log may decide, for example, to
temporarily reject valid submissions to protect itself against temporarily reject valid submissions to protect itself against
denial-of-service attacks). denial-of-service attacks).
Logs MAY accept certificates and precertificates that have expired, Logs MAY accept certificates and precertificates that have expired,
are not yet valid, have been revoked, or are otherwise not fully are not yet valid, have been revoked, or are otherwise not fully
valid according to RFC 5280 verification rules in order to valid according to RFC 5280 verification rules in order to
skipping to change at page 36, line 40 skipping to change at page 36, line 40
6.4. transparency_info TLS Extension 6.4. transparency_info TLS Extension
Provided that a TLS client includes the "transparency_info" extension Provided that a TLS client includes the "transparency_info" extension
type in the ClientHello and the TLS server supports the type in the ClientHello and the TLS server supports the
"transparency_info" extension: "transparency_info" extension:
o The TLS server MUST verify that the received "extension_data" is o The TLS server MUST verify that the received "extension_data" is
empty. empty.
o The TLS server SHOULD construct a "TransItemList" of relevant o The TLS server MUST construct a "TransItemList" of relevant
"TransItem"s (see Section 6.3), which SHOULD omit any "TransItem"s "TransItem"s (see Section 6.3), which SHOULD omit any "TransItem"s
that are already embedded in the server certificate or the stapled that are already embedded in the server certificate or the stapled
OCSP response (see Section 7.1). If the constructed OCSP response (see Section 7.1). If the constructed
"TransItemList" is not empty, then the TLS server SHOULD include "TransItemList" is not empty, then the TLS server MUST include the
the "transparency_info" extension in the ServerHello with the "transparency_info" extension with the "extension_data" set to
"extension_data" set to this "TransItemList". this "TransItemList".
TLS servers MUST only include this extension in the following
messages:
o the ServerHello message (for TLS 1.2 or earlier).
o the Certificate or CertificateRequest message (for TLS 1.3).
TLS servers MUST NOT process or include this extension when a TLS TLS servers MUST NOT process or include this extension when a TLS
session is resumed, since session resumption uses the original session is resumed, since session resumption uses the original
session information. session information.
6.5. cached_info TLS Extension 6.5. cached_info TLS Extension
When a TLS server includes the "transparency_info" extension in the When a TLS server includes the "transparency_info" extension, it
ServerHello, it SHOULD NOT include any "TransItem" structures of type SHOULD NOT include any "TransItem" structures of type "x509_sct_v2"
"x509_sct_v2" or "precert_sct_v2" in the "TransItemList" if all of or "precert_sct_v2" in the "TransItemList" if all of the following
the following conditions are met: conditions are met:
o The TLS client includes the "cached_info" ([RFC7924]) extension o The TLS client includes the "cached_info" ([RFC7924]) extension
type in the ClientHello, with a "CachedObject" of type type in the ClientHello, with a "CachedObject" of type
"ct_compliant" (see Section 8.1.7) and at least one "CachedObject" "ct_compliant" (see Section 8.1.7) and at least one "CachedObject"
of type "cert". of type "cert".
o The TLS server sends a modified Certificate message (as described o The TLS server sends a modified Certificate message (as described
in section 4.1 of [RFC7924]). in section 4.1 of [RFC7924]).
If the "hash_value" of any "CachedObject" of type "ct_compliant" sent If the "hash_value" of any "CachedObject" of type "ct_compliant" sent
skipping to change at page 38, line 44 skipping to change at page 38, line 46
8.1. TLS Client 8.1. TLS Client
8.1.1. Receiving SCTs and inclusion proofs 8.1.1. Receiving SCTs and inclusion proofs
TLS clients receive SCTs and inclusion proofs alongside or in TLS clients receive SCTs and inclusion proofs alongside or in
certificates. CT-using TLS clients MUST implement all of the three certificates. CT-using TLS clients MUST implement all of the three
mechanisms by which TLS servers may present SCTs (see Section 6) and mechanisms by which TLS servers may present SCTs (see Section 6) and
MAY also accept SCTs via the "status_request_v2" extension MAY also accept SCTs via the "status_request_v2" extension
([RFC6961]). ([RFC6961]).
TLS clients that support the "transparency_info" TLS extension SHOULD TLS clients that support the "transparency_info" TLS extension (see
include it in ClientHello messages, with empty "extension_data". If Section 6.4) SHOULD include it in ClientHello messages, with empty
a TLS server includes the "transparency_info" TLS extension when "extension_data". If a TLS server includes the "transparency_info"
resuming a TLS session, the TLS client MUST abort the handshake. TLS extension when resuming a TLS session, the TLS client MUST abort
the handshake.
8.1.2. Reconstructing the TBSCertificate 8.1.2. Reconstructing the TBSCertificate
Validation of an SCT for a certificate (where the "type" of the Validation of an SCT for a certificate (where the "type" of the
"TransItem" is "x509_sct_v2") uses the unmodified TBSCertificate "TransItem" is "x509_sct_v2") uses the unmodified TBSCertificate
component of the certificate. component of the certificate.
Before an SCT for a precertificate (where the "type" of the Before an SCT for a precertificate (where the "type" of the
"TransItem" is "precert_sct_v2") can be validated, the TBSCertificate "TransItem" is "precert_sct_v2") can be validated, the TBSCertificate
component of the precertificate needs to be reconstructed from the component of the precertificate needs to be reconstructed from the
skipping to change at page 42, line 8 skipping to change at page 42, line 8
Or, if it is not keeping all log entries: Or, if it is not keeping all log entries:
1. Fetch a consistency proof for the new STH with the previous 1. Fetch a consistency proof for the new STH with the previous
STH (Section 5.3). STH (Section 5.3).
2. Verify the consistency proof. 2. Verify the consistency proof.
3. Verify that the new entries generate the corresponding 3. Verify that the new entries generate the corresponding
elements in the consistency proof. elements in the consistency proof.
6. Repeat from step 6. 6. Repeat from step 1.
8.3. Auditing 8.3. Auditing
Auditing ensures that the current published state of a log is Auditing ensures that the current published state of a log is
reachable from previously published states that are known to be good, reachable from previously published states that are known to be good,
and that the promises made by the log in the form of SCTs have been and that the promises made by the log in the form of SCTs have been
kept. Audits are performed by monitors or TLS clients. kept. Audits are performed by monitors or TLS clients.
In particular, there are four log behavior properties that should be In particular, there are four log behavior properties that should be
checked: checked:
skipping to change at page 51, line 7 skipping to change at page 51, line 7
<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-21 (work in progress), Version 1.3", draft-ietf-tls-tls13-26 (work in progress),
July 2017. March 2018.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. 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,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
skipping to change at page 53, line 7 skipping to change at page 53, line 7
[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>.
[I-D.ietf-trans-gossip] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-04 (work in progress), CT", draft-ietf-trans-gossip-05 (work in progress),
January 2017. January 2018.
[I-D.ietf-trans-threat-analysis] [I-D.ietf-trans-threat-analysis]
Kent, S., "Attack and Threat Model for Certificate Kent, S., "Attack and Threat Model for Certificate
Transparency", draft-ietf-trans-threat-analysis-12 (work Transparency", draft-ietf-trans-threat-analysis-12 (work
in progress), October 2017. in progress), October 2017.
[JSON.Metadata] [JSON.Metadata]
The Chromium Projects, "Chromium Log Metadata JSON The Chromium Projects, "Chromium Log Metadata JSON
Schema", 2014, <https://www.gstatic.com/ct/log_list/ Schema", 2014, <https://www.gstatic.com/ct/log_list/
log_list_schema.json>. log_list_schema.json>.
skipping to change at page 55, line 5 skipping to change at page 55, line 5
Emilia Kasper Emilia Kasper
Google Switzerland GmbH Google Switzerland GmbH
Email: ekasper@google.com Email: ekasper@google.com
Eran Messeri Eran Messeri
Google UK Ltd. Google UK Ltd.
Email: eranm@google.com Email: eranm@google.com
Rob Stradling Rob Stradling
Comodo CA, Ltd. Comodo CA Ltd.
Email: rob.stradling@comodo.com Email: rob.stradling@comodoca.com
 End of changes. 16 change blocks. 
33 lines changed or deleted 49 lines changed or added

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