draft-ietf-trans-rfc6962-bis-26.txt   draft-ietf-trans-rfc6962-bis-27.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 29, 2018 Google Expires: May 3, 2018 Google
R. Stradling R. Stradling
Comodo Comodo
July 28, 2017 October 30, 2017
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-26 draft-ietf-trans-rfc6962-bis-27
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 29, 2018. This Internet-Draft will expire on May 3, 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 17 skipping to change at page 3, line 17
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
6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36 6.3. Presenting SCTs, inclusions proofs and STHs . . . . . . . 36
6.4. transparency_info TLS Extension . . . . . . . . . . . . . 36 6.4. transparency_info TLS Extension . . . . . . . . . . . . . 36
6.5. cached_info TLS Extension . . . . . . . . . . . . . . . . 36 6.5. cached_info TLS Extension . . . . . . . . . . . . . . . . 37
7. Certification Authorities . . . . . . . . . . . . . . . . . . 37 7. Certification Authorities . . . . . . . . . . . . . . . . . . 37
7.1. Transparency Information X.509v3 Extension . . . . . . . 37 7.1. Transparency Information X.509v3 Extension . . . . . . . 37
7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 37 7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 37
7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 37 7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38
7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 37 7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 38
8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 38
8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 38 8.1.1. Receiving SCTs and inclusion proofs . . . . . . . . . 38
8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 38 8.1.2. Reconstructing the TBSCertificate . . . . . . . . . . 39
8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 39 8.1.3. Validating SCTs . . . . . . . . . . . . . . . . . . . 39
8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 39 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 39
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 39 8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40
8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40 8.1.6. Evaluating compliance . . . . . . . . . . . . . . . . 40
8.1.7. cached_info TLS Extension . . . . . . . . . . . . . . 40 8.1.7. cached_info TLS Extension . . . . . . . . . . . . . . 40
8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 41 8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 42 9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 43 10.1. New Entry to the TLS ExtensionType Registry . . . . . . 43
10.2. New Entry to the TLS CachedInformationType registry . . 43 10.2. New Entry to the TLS CachedInformationType registry . . 43
10.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 43 10.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44
10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 43 10.3.1. Expert Review guidelines . . . . . . . . . . . . . . 44
10.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 43 10.4. Signature Algorithms . . . . . . . . . . . . . . . . . . 44
10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 44 10.4.1. Expert Review guidelines . . . . . . . . . . . . . . 45
10.5. VersionedTransTypes . . . . . . . . . . . . . . . . . . 44 10.5. VersionedTransTypes . . . . . . . . . . . . . . . . . . 45
10.5.1. Expert Review guidelines . . . . . . . . . . . . . . 45 10.5.1. Expert Review guidelines . . . . . . . . . . . . . . 46
10.6. Log Artifact Extension Registry . . . . . . . . . . . . 45 10.6. Log Artifact Extension Registry . . . . . . . . . . . . 46
10.6.1. Expert Review guidelines . . . . . . . . . . . . . . 46 10.6.1. Expert Review guidelines . . . . . . . . . . . . . . 47
10.7. Object Identifiers . . . . . . . . . . . . . . . . . . . 46 10.7. Object Identifiers . . . . . . . . . . . . . . . . . . . 47
10.7.1. Log ID Registry . . . . . . . . . . . . . . . . . . 46 10.7.1. Log ID Registry . . . . . . . . . . . . . . . . . . 47
10.7.2. Expert Review guidelines . . . . . . . . . . . . . . 47 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 49
11.1. Misissued Certificates . . . . . . . . . . . . . . . . . 48 11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 49
11.2. Detection of Misissue . . . . . . . . . . . . . . . . . 48 11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 49
11.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 48 11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 50
11.4. Preventing Tracking Clients . . . . . . . . . . . . . . 49 11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 50
11.5. Multiple SCTs . . . . . . . . . . . . . . . . . . . . . 49 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 13.1. Normative References . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 51 13.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 53 Appendix A. Supporting v1 and v2 simultaneously . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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 themselves prevent misissuance, but they ensure that
auditable. Anyone may verify the correctness of each log and monitor interested parties (particularly those named in certificates) can
when new certificates are added to it. The logs do not themselves detect such misissuance. Note that this is a general mechanism that
prevent misissue, but they ensure that interested parties could be used for transparently logging any form of binary data,
(particularly those named in certificates) can detect such subject to some kind of inclusion criteria. In this document, we
misissuance. Note that this is a general mechanism that could be only describe its use for public TLS server certificates (i.e., where
used for transparently logging any form of binary data, subject to the inclusion criteria is a valid certificate issued by a public
some kind of inclusion criteria. In this document, we only describe certification authority (CA)).
its use for public TLS server certificates (i.e., where the inclusion
criteria is a valid certificate issued by a public certification
authority (CA)).
Each log contains certificate chains, which can be submitted by Each log contains certificate chains, which can be submitted by
anyone. It is expected that public CAs will contribute all their anyone. It is expected that public CAs will contribute all their
newly issued certificates to one or more logs; however certificate newly issued certificates to one or more logs; however certificate
holders can also contribute their own certificate chains, as can holders can also contribute their own certificate chains, as can
third parties. In order to avoid logs being rendered useless by the third parties. In order to avoid logs being rendered useless by the
submission of large numbers of spurious certificates, it is required submission of large numbers of spurious certificates, it is required
that each chain ends with a trust anchor that is accepted by the log. that each chain ends with a trust anchor that is accepted by the log.
When a chain is accepted by a log, a signed timestamp is returned, When a chain is accepted by a log, a signed timestamp is returned,
which can later be used to provide evidence to TLS clients that the which can later be used to provide evidence to TLS clients that the
skipping to change at page 5, line 18 skipping to change at page 5, line 15
Similarly, those who have seen signed timestamps from a particular Similarly, those who have seen signed timestamps from a particular
log can later demand a proof of inclusion from that log. If the log log can later demand a proof of inclusion from that log. If the log
is unable to provide this (or, indeed, if the corresponding is unable to provide this (or, indeed, if the corresponding
certificate is absent from monitors' copies of that log), that is certificate is absent from monitors' copies of that log), that is
evidence of the incorrect operation of the log. The checking evidence of the incorrect operation of the log. The checking
operation is asynchronous to allow clients to proceed without delay, operation is asynchronous to allow clients to proceed without delay,
despite possible issues such as network connectivity and the vagaries despite possible issues such as network connectivity and the vagaries
of firewalls. of firewalls.
The append-only property of each log is achieved using Merkle Trees, The append-only property of each log is achieved using Merkle Trees,
which can be used to show that any particular instance of the log is which can be used to efficiently prove that any particular instance
a superset of any particular previous instance. Likewise, Merkle of the log is a superset of any particular previous instance and to
Trees avoid the need to blindly trust logs: if a log attempts to show efficiently detect various misbehaviors of the log (e.g., issuing a
different things to different people, this can be efficiently signed timestamp for a certificate that is not subsequently logged).
detected by comparing tree roots and consistency proofs. Similarly,
other misbehaviors of any log (e.g., issuing signed timestamps for It is necessary to treat each log as a trusted third party, because
certificates they then don't log) can be efficiently detected and the log auditing mechanisms described in this document can be
proved to the world at large. circumvented by a misbehaving log that shows different, inconsistent
views of itself to different clients. Whilst it is anticipated that
additional mechanisms could be developed to address these
shortcomings and thereby avoid the need to blindly trust logs, such
mechanisms are outside the scope of this document.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Data Structures 1.2. Data Structures
Data structures are defined and encoded according to the conventions Data structures are defined and encoded according to the conventions
laid out in Section 4 of [RFC5246]. laid out in Section 3 of [I-D.ietf-tls-tls13].
1.3. Major Differences from CT 1.0 1.3. Major Differences from CT 1.0
This document revises and obsoletes the experimental CT 1.0 [RFC6962] This document revises and obsoletes the experimental CT 1.0 [RFC6962]
protocol, drawing on insights gained from CT 1.0 deployments and on protocol, drawing on insights gained from CT 1.0 deployments and on
feedback from the community. The major changes are: feedback from the community. The major changes are:
o Hash and signature algorithm agility: permitted algorithms are now o Hash and signature algorithm agility: permitted algorithms are now
specified in IANA registries. specified in IANA registries.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Various data structures Section 1.2 are signed. A log MUST use one Various data structures Section 1.2 are signed. A log MUST use one
of the signature algorithms defined in Section 10.4. of the signature algorithms defined in Section 10.4.
3. Submitters 3. Submitters
Submitters submit certificates or preannouncements of certificates Submitters submit certificates or preannouncements of certificates
prior to issuance (precertificates) to logs for public auditing, as prior to issuance (precertificates) to logs for public auditing, as
described below. In order to enable attribution of each logged described below. In order to enable attribution of each logged
certificate or precertificate to its issuer, each submission MUST be certificate or precertificate to its issuer, each submission MUST be
accompanied by all additional certificates required to verify the accompanied by all additional certificates required to verify the
chain up to an accepted trust anchor. The trust anchor (a root or chain up to an accepted trust anchor (Section 5.7). The trust anchor
intermediate CA certificate) MAY be omitted from the submission. (a root or intermediate CA certificate) MAY be omitted from the
submission.
If a log accepts a submission, it will return a Signed Certificate If a log accepts a submission, it will return a Signed Certificate
Timestamp (SCT) (see Section 4.8). The submitter SHOULD validate the Timestamp (SCT) (see Section 4.8). The submitter SHOULD validate the
returned SCT as described in Section 8.1 if they understand its returned SCT as described in Section 8.1 if they understand its
format and they intend to use it directly in a TLS handshake or to format and they intend to use it directly in a TLS handshake or to
construct a certificate. If the submitter does not need the SCT (for construct a certificate. If the submitter does not need the SCT (for
example, the certificate is being submitted simply to make it example, the certificate is being submitted simply to make it
available in the log), it MAY validate the SCT. available in the log), it MAY validate the SCT.
3.1. Certificates 3.1. Certificates
skipping to change at page 16, line 17 skipping to change at page 16, line 17
entries will have to be created, one for each SCT (as the timestamp entries will have to be created, one for each SCT (as the timestamp
is a part of the leaf structure). Note that if a certificate was is a part of the leaf structure). Note that if a certificate was
previously logged as a precertificate, then the precertificate's SCT previously logged as a precertificate, then the precertificate's SCT
of type "precert_sct_v2" would not be appropriate; instead, a fresh of type "precert_sct_v2" would not be appropriate; instead, a fresh
SCT of type "x509_sct_v2" should be generated. SCT of type "x509_sct_v2" should be generated.
An SCT is the log's promise to append to its Merkle Tree an entry for An SCT is the log's promise to append to its Merkle Tree an entry for
the accepted submission. Upon producing an SCT, the log MUST fulfil the accepted submission. Upon producing an SCT, the log MUST fulfil
this promise by performing the following actions within a fixed this promise by performing the following actions within a fixed
amount of time known as the Maximum Merge Delay (MMD), which is one amount of time known as the Maximum Merge Delay (MMD), which is one
of the log's parameters (see Section 4.1): * Allocate a tree index to of the log's parameters (see Section 4.1):
the entry representing the accepted submission. * Calculate the root
of the tree. * Sign the root of the tree (see Section 4.10). The o Allocate a tree index to the entry representing the accepted
log may append multiple entries before signing the root of the tree. submission.
o Calculate the root of the tree.
o Sign the root of the tree (see Section 4.10).
The log may append multiple entries before signing the root of the
tree.
Log operators SHOULD NOT impose any conditions on retrieving or Log operators SHOULD NOT impose any conditions on retrieving or
sharing data from the log. sharing data from the log.
4.1. Log Parameters 4.1. Log Parameters
A log is defined by a collection of parameters, which are used by A log is defined by a collection of parameters, which are used by
clients to communicate with the log and to verify log artifacts. clients to communicate with the log and to verify log artifacts.
Base URL: The URL to substitute for <log server> in Section 5. Base URL: The URL to substitute for <log server> in Section 5.
skipping to change at page 16, line 48 skipping to change at page 17, line 9
the log. A log MUST NOT use the same keypair as any other log. the log. A log MUST NOT use the same keypair as any other log.
Log ID: The OID that uniquely identifies the log. Log ID: The OID that uniquely identifies the log.
Maximum Merge Delay: The MMD the log has committed to. Maximum Merge Delay: The MMD the log has committed to.
Version: The version of the protocol supported by the log (currently Version: The version of the protocol supported by the log (currently
1 or 2). 1 or 2).
Maximum Chain Length: The longest chain submission the log is Maximum Chain Length: The longest chain submission the log is
willing to accept, if the log chose to limit it. willing to accept, if the log imposes any limit.
STH Frequency Count: The maximum number of STHs the log may produce STH Frequency Count: The maximum number of STHs the log may produce
in any period equal to the "Maximum Merge Delay" (see in any period equal to the "Maximum Merge Delay" (see
Section 4.10). Section 4.10).
Final STH: If a log has been closed down (i.e., no longer accepts Final STH: If a log has been closed down (i.e., no longer accepts
new entries), existing entries may still be valid. In this case, new entries), existing entries may still be valid. In this case,
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 avoid being overloaded by invalid submissions, the log MUST NOT
accept any submission until it has verified that the submitted accept any submission until it has verified that the certificate or
certificate or precertificate has a valid signature chain to an precertificate was submitted with a valid signature chain to an
accepted trust anchor, using only the chain of intermediate CA accepted trust anchor. The log MUST NOT use other sources of
certificates provided by the submitter. 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 25, line 28 skipping to change at page 25, line 28
the individual messages. the individual messages.
Clients are configured with a base URL for a log and construct URLs Clients are configured with a base URL for a log and construct URLs
for requests by appending suffixes to this base URL. This structure for requests by appending suffixes to this base URL. This structure
places some degree of restriction on how log operators can deploy places some degree of restriction on how log operators can deploy
these services, as noted in [RFC7320]. However, operational these services, as noted in [RFC7320]. However, operational
experience with version 1 of this protocol has not indicated that experience with version 1 of this protocol has not indicated that
these restrictions are a problem in practice. these restrictions are a problem in practice.
Note that JSON objects and URL parameters may contain fields not Note that JSON objects and URL parameters may contain fields not
specified here. These extra fields should be ignored. specified here. These extra fields SHOULD be ignored.
The <log server> prefix, which is one of the log's parameters, MAY The <log server> prefix, which is one of the log's parameters, MAY
include a path as well as a server name and a port. include a path as well as a server name and a port.
In practice, log servers may include multiple front-end machines. In practice, log servers may include multiple front-end machines.
Since it is impractical to keep these machines in perfect sync, Since it is impractical to keep these machines in perfect sync,
errors may occur that are caused by skew between the machines. Where errors may occur that are caused by skew between the machines. Where
such errors are possible, the front-end will return additional such errors are possible, the front-end will return additional
information (as specified below) making it possible for clients to information (as specified below) making it possible for clients to
make progress, if progress is possible. Front-ends MUST only serve make progress, if progress is possible. Front-ends MUST only serve
skipping to change at page 31, line 34 skipping to change at page 31, line 34
Inputs: Inputs:
hash: A base64 encoded v2 leaf hash. hash: A base64 encoded v2 leaf hash.
tree_size: The tree_size of the tree on which to base the proofs, tree_size: The tree_size of the tree on which to base the proofs,
in decimal. in decimal.
The "hash" must be calculated as defined in Section 4.7. The The "hash" must be calculated as defined in Section 4.7. The
"tree_size" must designate an existing v2 STH. "tree_size" must designate an existing v2 STH.
Because of skew, the front-end may not know the requested STH or Because of skew, the front-end may not know the requested STH or the
the requested hash, which leads to a number of cases. requested hash, which leads to a number of cases:
latest STH < requested STH Return latest STH.
latest STH > requested STH Return latest STH and a consistency
proof between it and the requested STH (see Section 5.3).
index of requested hash < latest STH Return "inclusion".
Note that more than one case can be true, in which case the +--------------------+----------------------------------------------+
returned data is their concatenation. It is also possible for | Case | Response |
none to be true, in which case the front-end MUST return an empty +--------------------+----------------------------------------------+
response. | latest STH < | Return latest STH |
| requested STH | |
| | |
| latest STH > | Return latest STH and a consistency proof |
| requested STH | between it and the requested STH (see |
| | Section 5.3) |
| | |
| index of requested | Return "inclusion" |
| hash < latest STH | |
+--------------------+----------------------------------------------+
Note that more than one case can be true, in which case the returned
data is their union. It is also possible for none to be true, in
which case the front-end MUST return an empty response.
Outputs: Outputs:
inclusion: A base64 encoded "TransItem" of type inclusion: A base64 encoded "TransItem" of type
"inclusion_proof_v2" whose "inclusion_path" array of Merkle "inclusion_proof_v2" whose "inclusion_path" array of Merkle
Tree nodes proves the inclusion of the chosen certificate in Tree nodes proves the inclusion of the chosen certificate in
the returned STH. the returned STH.
sth: A base64 encoded "TransItem" of type "signed_tree_head_v2", sth: A base64 encoded "TransItem" of type "signed_tree_head_v2",
signed by this log. signed by this log.
skipping to change at page 34, line 23 skipping to change at page 34, line 26
certificates: An array of base64 encoded trust anchors that are certificates: An array of base64 encoded trust anchors that are
acceptable to the log. acceptable to the log.
max_chain_length: If the server has chosen to limit the length of max_chain_length: If the server has chosen to limit the length of
chains it accepts, this is the maximum number of certificates chains it accepts, this is the maximum number of certificates
in the chain, in decimal. If there is no limit, this is in the chain, in decimal. If there is no limit, this is
omitted. omitted.
6. TLS Servers 6. TLS Servers
TLS servers MUST use at least one of the three mechanisms listed CT-using TLS servers MUST use at least one of the three mechanisms
below to present one or more SCTs from one or more logs to each TLS listed below to present one or more SCTs from one or more logs to
client during full TLS handshakes, where each SCT corresponds to the each TLS client during full TLS handshakes, where each SCT
server certificate. TLS servers SHOULD also present corresponding corresponds to the server certificate. They SHOULD also present
inclusion proofs and STHs. corresponding inclusion proofs and STHs.
Three mechanisms are provided because they have different tradeoffs. Three mechanisms are provided because they have different tradeoffs.
o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type o A TLS extension (Section 7.4.1.4 of [RFC5246]) with type
"transparency_info" (see Section 6.4). This mechanism allows TLS "transparency_info" (see Section 6.4). This mechanism allows TLS
servers to participate in CT without the cooperation of CAs, servers to participate in CT without the cooperation of CAs,
unlike the other two mechanisms. It also allows SCTs and unlike the other two mechanisms. It also allows SCTs and
inclusion proofs to be updated on the fly. inclusion proofs to be updated on the fly.
o An Online Certificate Status Protocol (OCSP) [RFC6960] response o An Online Certificate Status Protocol (OCSP) [RFC6960] response
skipping to change at page 35, line 15 skipping to change at page 35, line 17
need of re-issuance. need of re-issuance.
Additionally, a TLS server which supports presenting SCTs using an Additionally, a TLS server which supports presenting SCTs using an
OCSP response MAY provide it when the TLS client included the OCSP response MAY provide it when the TLS client included the
"status_request_v2" extension ([RFC6961]) in the (extended) "status_request_v2" extension ([RFC6961]) in the (extended)
"ClientHello", but only in addition to at least one of the three "ClientHello", but only in addition to at least one of the three
mechanisms listed above. mechanisms listed above.
6.1. Multiple SCTs 6.1. Multiple SCTs
TLS servers SHOULD send SCTs from multiple logs in case one or more CT-using TLS servers SHOULD send SCTs from multiple logs, because:
logs are not acceptable to the TLS client (for example, if a log has
been struck off for misbehavior, has had a key compromise, or is not o One or more logs may not have become acceptable to all CT-using
known to the TLS client). For example: TLS clients.
o If a CA and a log collude, it is possible to temporarily hide o If a CA and a log collude, it is possible to temporarily hide
misissuance from clients. Including SCTs from different logs misissuance from clients. When a TLS client requires SCTs from
makes it more difficult to mount this attack. multiple logs to be provided, it is more difficult to mount this
attack.
o If a log misbehaves, a consequence may be that clients cease to o If a log misbehaves or suffers a key compromise, a consequence may
trust it. Since the time an SCT may be in use can be considerable be that clients cease to trust it. Since the time an SCT may be
(several years is common in current practice when embedded in a in use can be considerable (several years is common in current
certificate), servers may wish to reduce the probability of their practice when embedded in a certificate), including SCTs from
certificates being rejected as a result by including SCTs from multiple logs reduces the probability of the certificate being
different logs. rejected by TLS clients.
o TLS clients may have policies related to the above risks requiring o TLS clients may have policies related to the above risks requiring
servers to present multiple SCTs. For example, at the time of TLS servers to present multiple SCTs. For example, at the time of
writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to
be presented with EV certificates in order for the EV indicator to be presented with EV certificates in order for the EV indicator to
be shown. be shown.
To select the logs from which to obtain SCTs, a TLS server can, for To select the logs from which to obtain SCTs, a TLS server can, for
example, examine the set of logs popular TLS clients accept and example, examine the set of logs popular TLS clients accept and
recognize. recognize.
6.2. TransItemList Structure 6.2. TransItemList Structure
skipping to change at page 36, line 20 skipping to change at page 36, line 26
whose versions they don't understand). whose versions they don't understand).
6.3. Presenting SCTs, inclusions proofs and STHs 6.3. Presenting SCTs, inclusions proofs and STHs
In each "TransItemList" that is sent to a client during a TLS In each "TransItemList" that is sent to a client during a TLS
handshake, the TLS server MUST include a "TransItem" structure of handshake, the TLS server MUST include a "TransItem" structure of
type "x509_sct_v2" or "precert_sct_v2" (except as described in type "x509_sct_v2" or "precert_sct_v2" (except as described in
Section 6.5). Section 6.5).
Presenting inclusion proofs and STHs in the TLS handshake helps to Presenting inclusion proofs and STHs in the TLS handshake helps to
protect the client's privacy (see Section 8.1.5) and reduces load on protect the client's privacy (see Section 8.1.4) and reduces load on
log servers. Therefore, if the TLS server can obtain them, it SHOULD log servers. Therefore, if the TLS server can obtain them, it SHOULD
also include "TransItem"s of type "inclusion_proof_v2" and also include "TransItem"s of type "inclusion_proof_v2" and
"signed_tree_head_v2" in the "TransItemList". "signed_tree_head_v2" in the "TransItemList".
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, the TLS server SHOULD include the type in the ClientHello and the TLS server supports the
"transparency_info" extension in the ServerHello with "transparency_info" extension:
"extension_data" set to a "TransItemList". The TLS server SHOULD
ignore any "extension_data" sent by the TLS client. Additionally, o The TLS server MUST verify that the received "extension_data" is
the TLS server MUST NOT process or include this extension when a TLS empty.
o The TLS server SHOULD construct a "TransItemList" of relevant
"TransItem"s (see Section 6.3), which SHOULD omit any "TransItem"s
that are already embedded in the server certificate or the stapled
OCSP response (see Section 7.1). If the constructed
"TransItemList" is not empty, then the TLS server SHOULD include
the "transparency_info" extension in the ServerHello with the
"extension_data" set to this "TransItemList".
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 in the
ServerHello, it SHOULD NOT include any "TransItem" structures of type ServerHello, it SHOULD NOT include any "TransItem" structures of type
"x509_sct_v2" or "precert_sct_v2" in the "TransItemList" if all of "x509_sct_v2" or "precert_sct_v2" in the "TransItemList" if all of
the following conditions are met: the following conditions are met:
o The TLS client includes the "transparency_info" extension type in
the ClientHello.
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]).
TLS servers SHOULD ignore the "hash_value" fields of each If the "hash_value" of any "CachedObject" of type "ct_compliant" sent
"CachedObject" of type "ct_compliant" sent by TLS clients. by a TLS client is not 1 byte long with the value 0, the CT-using TLS
server MUST abort the handshake.
7. Certification Authorities 7. Certification Authorities
7.1. Transparency Information X.509v3 Extension 7.1. Transparency Information X.509v3 Extension
The Transparency Information X.509v3 extension, which has OID The Transparency Information X.509v3 extension, which has OID
1.3.101.75 and SHOULD be non-critical, contains one or more 1.3.101.75 and SHOULD be non-critical, contains one or more
"TransItem" structures in a "TransItemList". This extension MAY be "TransItem" structures in a "TransItemList". This extension MAY be
included in OCSP responses (see Section 7.1.1) and certificates (see included in OCSP responses (see Section 7.1.1) and certificates (see
Section 7.1.2). Since RFC5280 requires the "extnValue" field (an Section 7.1.2). Since RFC5280 requires the "extnValue" field (an
skipping to change at page 38, line 19 skipping to change at page 38, line 34
Any inconsistency may be used as evidence that a log has not behaved Any inconsistency may be used as evidence that a log has not behaved
correctly, and the signatures on the data structures prevent the log correctly, and the signatures on the data structures prevent the log
from denying that misbehavior. from denying that misbehavior.
All clients need various parameters in order to communicate with logs All clients need various parameters in order to communicate with logs
and verify their responses. These parameters are described in and verify their responses. These parameters are described in
Section 4.1, but note that this document does not describe how the Section 4.1, but note that this document does not describe how the
parameters are obtained, which is implementation-dependent (see, for parameters are obtained, which is implementation-dependent (see, for
example, [Chromium.Policy]). example, [Chromium.Policy]).
Clients should somehow exchange STHs they see, or make them available
for scrutiny, in order to ensure that they all have a consistent
view. The exact mechanisms will be in separate documents, but it is
expected there will be a variety.
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 alongside or in certificates. TLS clients TLS clients receive SCTs and inclusion proofs alongside or in
MUST implement all of the three mechanisms by which TLS servers may certificates. CT-using TLS clients MUST implement all of the three
present SCTs (see Section 6). TLS clients MAY also accept SCTs via mechanisms by which TLS servers may present SCTs (see Section 6) and
the "status_request_v2" extension ([RFC6961]). TLS clients that MAY also accept SCTs via the "status_request_v2" extension
support the "transparency_info" TLS extension SHOULD include it in ([RFC6961]).
ClientHello messages, with empty "extension_data". TLS clients may
also receive inclusion proofs in addition to SCTs, which should be TLS clients that support the "transparency_info" TLS extension SHOULD
checked once the SCTs are validated. include it in ClientHello messages, with empty "extension_data". If
a TLS server includes the "transparency_info" 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
To reconstruct the TBSCertificate component of a precertificate from Validation of an SCT for a certificate (where the "type" of the
a certificate, TLS clients should remove the Transparency Information "TransItem" is "x509_sct_v2") uses the unmodified TBSCertificate
extension described in Section 7.1. component of the certificate.
If the SCT checked is for a precertificate (where the "type" of the Before an SCT for a precertificate (where the "type" of the
"TransItem" is "precert_sct_v2"), then the client SHOULD also remove "TransItem" is "precert_sct_v2") can be validated, the TBSCertificate
embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (See component of the precertificate needs to be reconstructed from the
Section 3.3. of [RFC6962]), in the process of reconstructing the TBSCertificate component of the certificate as follows:
TBSCertificate. That is to allow embedded v1 and v2 SCTs to co-exist
in a certificate (See Appendix A). o Remove the Transparency Information extension (see Section 7.1).
o Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2
(see section 3.3 of [RFC6962]). This allows embedded v1 and v2
SCTs to co-exist in a certificate (see Appendix A).
8.1.3. Validating SCTs 8.1.3. Validating SCTs
In addition to normal validation of the server certificate and its In addition to normal validation of the server certificate and its
chain, TLS clients SHOULD validate each received SCT for which they chain, CT-using TLS clients MUST validate each received SCT for which
have the corresponding log's parameters. To validate an SCT, a TLS they have the corresponding log's parameters. To validate an SCT, a
client computes the signature input by constructing a "TransItem" of TLS client computes the signature input by constructing a "TransItem"
type "x509_entry_v2" or "precert_entry_v2", depending on the SCT's of type "x509_entry_v2" or "precert_entry_v2", depending on the SCT's
"TransItem" type. The "TimestampedCertificateEntryDataV2" structure "TransItem" type. The "TimestampedCertificateEntryDataV2" structure
is constructed in the following manner: is constructed in the following manner:
o "timestamp" is copied from the SCT. o "timestamp" is copied from the SCT.
o "tbs_certificate" is the reconstructed TBSCertificate portion of o "tbs_certificate" is the reconstructed TBSCertificate portion of
the server certificate, as described in Section 8.1.2. the server certificate, as described in Section 8.1.2.
o "issuer_key_hash" is computed as described in Section 4.7. o "issuer_key_hash" is computed as described in Section 4.7.
o "sct_extensions" is copied from the SCT. o "sct_extensions" is copied from the SCT.
The SCT's "signature" is then verified using the public key of the The SCT's "signature" is then verified using the public key of the
corresponding log, which is identified by the "log_id". The required corresponding log, which is identified by the "log_id". The required
signature algorithm is one of the log's parameters. signature algorithm is one of the log's parameters.
TLS clients MUST NOT consider valid any SCT whose timestamp is in the
future.
8.1.4. Fetching inclusion proofs 8.1.4. Fetching inclusion proofs
When a TLS client has validated a received SCT but does not yet When a TLS client has validated a received SCT but does not yet
possess a corresponding inclusion proof, the TLS client MAY request possess a corresponding inclusion proof, the TLS client MAY request
the inclusion proof directly from a log using "get-proof-by-hash" the inclusion proof directly from a log using "get-proof-by-hash"
(Section 5.4) or "get-all-by-hash" (Section 5.5). Note that this (Section 5.4) or "get-all-by-hash" (Section 5.5).
will disclose to the log which TLS server the client has been
communicating with. Note that fetching inclusion proofs directly from a log will disclose
to the log which TLS server the client has been communicating with.
This may be regarded as a significant privacy concern, and so it is
preferable for the TLS server to send the inclusion proofs (see
Section 6.3).
8.1.5. Validating inclusion proofs 8.1.5. Validating inclusion proofs
When a TLS client has received, or fetched, an inclusion proof (and When a TLS client has received, or fetched, an inclusion proof (and
an STH), it SHOULD proceed to verifying the inclusion proof to the an STH), it SHOULD proceed to verifying the inclusion proof to the
provided STH. The TLS client SHOULD also verify consistency between provided STH. The TLS client SHOULD also verify consistency between
the provided STH and an STH it knows about. the provided STH and an STH it knows about.
If the TLS client holds an STH that predates the SCT, it MAY, in the If the TLS client holds an STH that predates the SCT, it MAY, in the
process of auditing, request a new STH from the log (Section 5.2), process of auditing, request a new STH from the log (Section 5.2),
then verify it by requesting a consistency proof (Section 5.3). Note then verify it by requesting a consistency proof (Section 5.3). Note
that if the TLS client uses "get-all-by-hash", then it will already that if the TLS client uses "get-all-by-hash", then it will already
have the new STH. have the new STH.
8.1.6. Evaluating compliance 8.1.6. Evaluating compliance
It is up to a client's local policy to specify the quantity and form It is up to a client's local policy to specify the quantity and form
of evidence (SCTs, inclusion proofs or a combination) needed to of evidence (SCTs, inclusion proofs or a combination) needed to
achieve compliance and how to handle non-compliance. achieve compliance and how to handle non-compliance.
A TLS client MUST NOT evaluate compliance if it did not send both the A TLS client can only evaluate compliance if it has given the TLS
server the opportunity to send SCTs and inclusion proofs by any of
the three mechanisms that are mandatory to implement for CT-using TLS
clients (see Section 8.1.1). Therefore, a TLS client MUST NOT
evaluate compliance if it did not include both the
"transparency_info" and "status_request" TLS extensions in the "transparency_info" and "status_request" TLS extensions in the
ClientHello. ClientHello.
8.1.7. cached_info TLS Extension 8.1.7. cached_info TLS Extension
If a TLS client uses the "cached_info" TLS extension ([RFC7924]) to If a TLS client uses the "cached_info" TLS extension ([RFC7924]) to
indicate 1 or more cached certificates, all of which it already indicate 1 or more cached certificates, all of which it already
considers to be CT compliant, the TLS client MAY also include a considers to be CT compliant, the TLS client MAY also include a
"CachedObject" of type "ct_compliant" in the "cached_info" extension. "CachedObject" of type "ct_compliant" in the "cached_info" extension.
The "hash_value" field MUST be 1 byte long with the value 0. Its "hash_value" field MUST have the value 0 and be 1 byte long (the
minimum length permitted by [RFC7924]).
8.2. Monitor 8.2. Monitor
Monitors watch logs to check that they behave correctly, for Monitors watch logs to check that they behave correctly, for
certificates of interest, or both. For example, a monitor may be certificates of interest, or both. For example, a monitor may be
configured to report on all certificates that apply to a specific configured to report on all certificates that apply to a specific
domain name when fetching new entries for consistency validation. domain name when fetching new entries for consistency validation.
A monitor needs to, at least, inspect every new entry in each log it A monitor MUST at least inspect every new entry in every log it
watches. It may also want to keep copies of entire logs. In order watches, and it MAY also choose to keep copies of entire logs.
to do this, it should follow these steps for each log:
To inspect all of the existing entries, the monitor SHOULD follow
these steps once for each log:
1. Fetch the current STH (Section 5.2). 1. Fetch the current STH (Section 5.2).
2. Verify the STH signature. 2. Verify the STH signature.
3. Fetch all the entries in the tree corresponding to the STH 3. Fetch all the entries in the tree corresponding to the STH
(Section 5.6). (Section 5.6).
4. Confirm that the tree made from the fetched entries produces the 4. If applicable, check each entry to see if it's a certificate of
interest.
5. Confirm that the tree made from the fetched entries produces the
same hash as that in the STH. same hash as that in the STH.
5. Fetch the current STH (Section 5.2). Repeat until the STH To inspect new entries, the monitor SHOULD follow these steps
repeatedly for each log:
1. Fetch the current STH (Section 5.2). Repeat until the STH
changes. changes.
6. Verify the STH signature. 2. Verify the STH signature.
7. Fetch all the new entries in the tree corresponding to the STH 3. Fetch all the new entries in the tree corresponding to the STH
(Section 5.6). If they remain unavailable for an extended (Section 5.6). If they remain unavailable for an extended
period, then this should be viewed as misbehavior on the part of period, then this should be viewed as misbehavior on the part of
the log. the log.
8. Either: 4. If applicable, check each entry to see if it's a certificate of
interest.
5. Either:
1. Verify that the updated list of all entries generates a tree 1. Verify that the updated list of all entries generates a tree
with the same hash as the new STH. with the same hash as the new STH.
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.
9. Go to Step 5. 6. Repeat from step 6.
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 42, line 18 skipping to change at page 43, line 4
A TLS client (Section 8.1) can audit by verifying an SCT against any A TLS client (Section 8.1) can audit by verifying an SCT against any
STH dated after the SCT timestamp + the Maximum Merge Delay by STH dated after the SCT timestamp + the Maximum Merge Delay by
requesting a Merkle inclusion proof (Section 5.4). It can also requesting a Merkle inclusion proof (Section 5.4). It can also
verify that the SCT corresponds to the server certificate it arrived verify that the SCT corresponds to the server certificate it arrived
with (i.e., the log entry is that certificate, or is a precertificate with (i.e., the log entry is that certificate, or is a precertificate
corresponding to that certificate). corresponding to that certificate).
Checking of the consistency of the log view presented to all entities Checking of the consistency of the log view presented to all entities
is more difficult to perform because it requires a way to share log is more difficult to perform because it requires a way to share log
responses among a set of CT-aware entities, and is discussed in responses among a set of CT-using entities, and is discussed in
Section 11.3. Section 11.3.
9. Algorithm Agility 9. Algorithm Agility
It is not possible for a log to change any of its algorithms part way It is not possible for a log to change any of its algorithms part way
through its lifetime: through its lifetime:
Signature algorithm: SCT signatures must remain valid so signature Signature algorithm: SCT signatures must remain valid so signature
algorithms can only be added, not removed. algorithms can only be added, not removed.
Hash algorithm: A log would have to support the old and new hash Hash algorithm: A log would have to support the old and new hash
algorithms to allow backwards-compatibility with clients that are algorithms to allow backwards-compatibility with clients that are
not aware of a hash algorithm change. not aware of a hash algorithm change.
Allowing multiple signature or hash algorithms for a log would Allowing multiple signature or hash algorithms for a log would
require that all data structures support it and would significantly require that all data structures support it and would significantly
complicate client implementation, which is why it is not supported by complicate client implementation, which is why it is not supported by
this document. this document.
If it should become necessary to deprecate an algorithm used by a If it should become necessary to deprecate an algorithm used by a
live log, then the log should be frozen as specified in Section 4.13 live log, then the log MUST be frozen as specified in Section 4.13
and a new log should be started. Certificates in the frozen log that and a new log SHOULD be started. Certificates in the frozen log that
have not yet expired and require new SCTs SHOULD be submitted to the have not yet expired and require new SCTs SHOULD be submitted to the
new log and the SCTs from that log used instead. new log and the SCTs from that log used instead.
10. IANA Considerations 10. IANA Considerations
The assignment policy criteria mentioned in this section refer to the The assignment policy criteria mentioned in this section refer to the
policies outlined in [RFC5226]. policies outlined in [RFC5226].
10.1. TLS Extension Type 10.1. New Entry to the TLS ExtensionType Registry
IANA is asked to allocate an RFC 5246 ExtensionType value for the IANA is asked to add an entry for "transparency_info(TBD)" to the
"transparency_info" TLS extension. IANA should update this extension "TLS ExtensionType Values" registry defined in [I-D.ietf-tls-tls13],
type to point at this document. citing this document as the "Reference" and setting the "Recommended"
value to "Yes".
10.2. New Entry to the TLS CachedInformationType registry 10.2. New Entry to the TLS CachedInformationType registry
IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS IANA is asked to add an entry for "ct_compliant(TBD)" to the "TLS
CachedInformationType Values" registry that was defined in [RFC7924]. CachedInformationType Values" registry defined in [RFC7924], citing
this document as the "Reference".
10.3. Hash Algorithms 10.3. Hash Algorithms
IANA is asked to establish a registry of hash algorithm values, named IANA is asked to establish a registry of hash algorithm values, named
"CT Hash Algorithms", that initially consists of: "CT Hash Algorithms", that initially consists of:
+--------+------------+------------------------+--------------------+ +--------+------------+------------------------+--------------------+
| Value | Hash | OID | Reference / | | Value | Hash | OID | Reference / |
| | Algorithm | | Assignment Policy | | | Algorithm | | Assignment Policy |
+--------+------------+------------------------+--------------------+ +--------+------------+------------------------+--------------------+
skipping to change at page 47, line 5 skipping to change at page 48, line 5
Section 4.4), the precertificate CMS "eContentType" (see Section 4.4), the precertificate CMS "eContentType" (see
Section 3.2), and X.509v3 extensions in certificates (see Section 3.2), and X.509v3 extensions in certificates (see
Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are Section 7.1.2) and OCSP responses (see Section 7.1.1). The OIDs are
defined in an arc that was selected due to its short encoding. defined in an arc that was selected due to its short encoding.
10.7.1. Log ID Registry 10.7.1. Log ID Registry
IANA is asked to establish a registry of Log IDs, named "CT Log ID IANA is asked to establish a registry of Log IDs, named "CT Log ID
Registry", that initially consists of: Registry", that initially consists of:
+------------------------+------------+-----------------------------+ +---------------------+------------+--------------------------------+
| Value | Log | Reference / Assignment | | Value | Log | Reference / Assignment Policy |
| | | Policy | +---------------------+------------+--------------------------------+
+------------------------+------------+-----------------------------+ | 1.3.101.8192 - | Unassigned | Parameters Required and First |
| 1.3.101.8192 - | Unassigned | Parameters Required and | | 1.3.101.16383 | | Come First Served |
| 1.3.101.16383 | | Expert Review | | | | |
| | | | | 1.3.101.80.0 - | Unassigned | Parameters Required and First |
| 1.3.101.80.0 - | Unassigned | Parameters Required and | | 1.3.101.80.* | | Come First Served |
| 1.3.101.80.127 | | Expert Review | +---------------------+------------+--------------------------------+
| | | |
| 1.3.101.80.128 - | Unassigned | First Come First Served |
| 1.3.101.80.* | | |
+------------------------+------------+-----------------------------+
All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been
reserved. This is a limited resource of 8,192 OIDs, each of which reserved. This is a limited resource of 8,192 OIDs, each of which
has an encoded length of 4 octets. has an encoded length of 4 octets.
The 1.3.101.80 arc has been delegated. This is an unlimited The 1.3.101.80 arc has been delegated. This is an unlimited
resource, but only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127 resource, but only the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127
have an encoded length of only 4 octets. have an encoded length of only 4 octets.
Each application for the allocation of a Log ID should be accompanied Each application for the allocation of a Log ID should be accompanied
by all of the required parameters (except for the Log ID) listed in by all of the required parameters (except for the Log ID) listed in
Section 4.1. Section 4.1.
10.7.2. Expert Review guidelines
Since the Log IDs with the shortest encodings are a limited resource,
the appointed Expert should review the submitted parameters and judge
whether or not the applicant is requesting a Log ID in good faith
(with the intention of actually running a CT log that will be
identified by the allocated Log ID).
11. Security Considerations 11. Security Considerations
With CAs, logs, and servers performing the actions described here, With CAs, logs, and servers performing the actions described here,
TLS clients can use logs and signed timestamps to reduce the TLS clients can use logs and signed timestamps to reduce the
likelihood that they will accept misissued certificates. If a server likelihood that they will accept misissued certificates. If a server
presents a valid signed timestamp for a certificate, then the client presents a valid signed timestamp for a certificate, then the client
knows that a log has committed to publishing the certificate. From knows that a log has committed to publishing the certificate. From
this, the client knows that monitors acting for the subject of the this, the client knows that monitors acting for the subject of the
certificate have had some time to notice the misissue and take some certificate have had some time to notice the misissuance and take
action, such as asking a CA to revoke a misissued certificate, or some action, such as asking a CA to revoke a misissued certificate.
that the log has misbehaved, which will be discovered when the SCT is A signed timestamp does not guarantee this though, since appropriate
audited. A signed timestamp is not a guarantee that the certificate monitors might not have checked the logs or the CA might have refused
is not misissued, since appropriate monitors might not have checked to revoke the certificate.
the logs or the CA might have refused to revoke the certificate.
In addition, if TLS clients will not accept unlogged certificates, In addition, if TLS clients will not accept unlogged certificates,
then site owners will have a greater incentive to submit certificates then site owners will have a greater incentive to submit certificates
to logs, possibly with the assistance of their CA, increasing the to logs, possibly with the assistance of their CA, increasing the
overall transparency of the system. overall transparency of the system.
[I-D.ietf-trans-threat-analysis] provides a more detailed threat [I-D.ietf-trans-threat-analysis] provides a more detailed threat
analysis of the Certificate Transparency architecture. analysis of the Certificate Transparency architecture.
11.1. Misissued Certificates 11.1. Misissued Certificates
Misissued certificates that have not been publicly logged, and thus Misissued certificates that have not been publicly logged, and thus
do not have a valid SCT, are not considered compliant. Misissued do not have a valid SCT, are not considered compliant. Misissued
certificates that do have an SCT from a log will appear in that certificates that do have an SCT from a log will appear in that
public log within the Maximum Merge Delay, assuming the log is public log within the Maximum Merge Delay, assuming the log is
operating correctly. As a log is allowed to serve an STH that's up operating correctly. Since a log is allowed to serve an STH of any
to MMD old, the maximum period of time during which a misissued age up to the MMD, the maximum period of time during which a
certificate can be used without being available for audit is twice misissued certificate can be used without being available for audit
the MMD. is twice the MMD.
11.2. Detection of Misissue 11.2. Detection of Misissue
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
skipping to change at page 48, line 45 skipping to change at page 49, line 37
different times and/or to different parties; issuing STHs too different times and/or to different parties; issuing STHs too
frequently; mutating the signature of a logged certificate; and frequently; mutating the signature of a logged certificate; and
failing to present a chain containing the certifier of a logged failing to present a chain containing the certifier of a logged
certificate. Such misbehavior is detectable and 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. However, note that there may be privacy concerns (see
need not reveal the exact certificate to the log. Instead, clients Section 8.1.4).
can request the proof from a trusted auditor (since anyone can
compute the proofs from the log) or communicate with the log via
proxies.
Violation of the append-only property or the STH issuance rate limit Violation of the append-only property or the STH issuance rate limit
can be detected by clients comparing their instances of the Signed can be detected by clients comparing their instances of the Signed
Tree Heads. There are various ways this could be done, for example Tree Heads. There are various ways this could be done, for example
via gossip (see [I-D.ietf-trans-gossip]) or peer-to-peer via gossip (see [I-D.ietf-trans-gossip]) or peer-to-peer
communications or by sending STHs to monitors (who could then communications or by sending STHs to monitors (who could then
directly check against their own copy of the relevant log). Proof of directly check against their own copy of the relevant log). Proof of
misbehavior in such cases would be: a series of STHs that were issued misbehavior in such cases would be: a series of STHs that were issued
too closely together, proving violation of the STH issuance rate too closely together, proving violation of the STH issuance rate
limit; or an STH with a root hash that does not match the one limit; or an STH with a root hash that does not match the one
skipping to change at page 49, line 30 skipping to change at page 50, line 21
o Using deterministic signature schemes, or o Using deterministic signature schemes, or
o Producing no more than one SCT for each distinct submission and no o Producing no more than one SCT for each distinct submission and no
more than one STH for each distinct tree_size. Each of these SCTs more than one STH for each distinct tree_size. Each of these SCTs
and STHs can be stored by the log and served to other clients that and STHs can be stored by the log and served to other clients that
submit the same certificate or request the same STH. submit the same certificate or request the same STH.
11.5. Multiple SCTs 11.5. Multiple SCTs
By offering multiple SCTs, each from a different log, TLS servers By requiring TLS servers to offer multiple SCTs, each from a
reduce the effectiveness of an attack where a CA and a log collude different log, TLS clients reduce the effectiveness of an attack
(see Section 6.1). where a CA and a log collude (see Section 6.1).
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Erwann Abelea, Robin Alden, Andrew The authors would like to thank Erwann Abelea, Robin Alden, Andrew
Ayer, Richard Barnes, Al Cutter, David Drysdale, Francis Dupont, Adam Ayer, Richard Barnes, Al Cutter, David Drysdale, Francis Dupont, Adam
Eijdenberg, Stephen Farrell, Daniel Kahn Gillmor, Paul Hadfield, Brad Eijdenberg, Stephen Farrell, Daniel Kahn Gillmor, Paul Hadfield, Brad
Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Kat Joyce, Hill, Jeff Hodges, Paul Hoffman, Jeffrey Hutzelman, Kat Joyce,
Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer, Stephen Kent, SM, Alexey Melnikov, Linus Nordberg, Chris Palmer,
Trevor Perrin, Pierre Phaneuf, Eric Rescorla, Melinda Shore, Ryan Trevor Perrin, Pierre Phaneuf, Eric Rescorla, Melinda Shore, Ryan
Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their Sleevi, Martin Smith, Carl Wallace and Paul Wouters for their
skipping to change at page 50, line 26 skipping to change at page 51, line 12
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-21 (work in progress),
July 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, <https://www.rfc-
<http://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,
<http://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6066>. editor.org/info/rfc6066>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6961>. editor.org/info/rfc6961>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7231>. editor.org/info/rfc7231>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>. October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7924>. editor.org/info/rfc7924>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc8032>. editor.org/info/rfc8032>.
13.2. Informative References 13.2. Informative References
[Chromium.Log.Policy] [Chromium.Log.Policy]
The Chromium Projects, "Chromium Certificate Transparency The Chromium Projects, "Chromium Certificate Transparency
Log Policy", 2014, <http://www.chromium.org/Home/chromium- Log Policy", 2014, <http://www.chromium.org/Home/chromium-
security/certificate-transparency/log-policy>. security/certificate-transparency/log-policy>.
[Chromium.Policy] [Chromium.Policy]
The Chromium Projects, "Chromium Certificate The Chromium Projects, "Chromium Certificate
skipping to change at page 52, line 24 skipping to change at page 53, line 12
<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-04 (work in progress),
January 2017. January 2017.
[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-11 (work Transparency", draft-ietf-trans-threat-analysis-12 (work
in progress), April 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, <http://www.certificate-transparency.org/ Schema", 2014, <https://www.gstatic.com/ct/log_list/
known-logs/log_list_schema.json>. log_list_schema.json>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5226>. editor.org/info/rfc5226>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6234>. editor.org/info/rfc6234>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014, RFC 7320, DOI 10.17487/RFC7320, July 2014,
<http://www.rfc-editor.org/info/rfc7320>. <https://www.rfc-editor.org/info/rfc7320>.
Appendix A. Supporting v1 and v2 simultaneously Appendix A. Supporting v1 and v2 simultaneously
Certificate Transparency logs have to be either v1 (conforming to Certificate Transparency logs have to be either v1 (conforming to
[RFC6962]) or v2 (conforming to this document), as the data [RFC6962]) or v2 (conforming to this document), as the data
structures are incompatible and so a v2 log could not issue a valid structures are incompatible and so a v2 log could not issue a valid
v1 SCT. v1 SCT.
CT clients, however, can support v1 and v2 SCTs, for the same CT clients, however, can support v1 and v2 SCTs, for the same
certificate, simultaneously, as v1 SCTs are delivered in different certificate, simultaneously, as v1 SCTs are delivered in different
 End of changes. 79 change blocks. 
229 lines changed or deleted 257 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/