draft-ietf-trans-rfc6962-bis-29.txt   draft-ietf-trans-rfc6962-bis-30.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: Experimental E. Messeri Intended status: Experimental E. Messeri
Expires: April 25, 2019 Google Expires: May 10, 2019 Google
R. Stradling R. Stradling
Comodo CA Sectigo
October 22, 2018 November 06, 2018
Certificate Transparency Version 2.0 Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-29 draft-ietf-trans-rfc6962-bis-30
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
appear in a log, effectively forcing CAs to add all issued appear in a log, effectively forcing CAs to add all issued
certificates to the logs. certificates to the logs.
This document obsoletes RFC 6962. It also specifies a new TLS
extension that is used to send various CT log artifacts.
Logs are network services that implement the protocol operations for Logs are network services that implement the protocol operations for
submissions and queries that are defined in this document. submissions and queries that are defined in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 April 25, 2019. This Internet-Draft will expire on May 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 3, line 28 skipping to change at page 3, line 28
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 . . . . . . . . . . . . . . . 38 7.1.1. OCSP Response Extension . . . . . . . . . . . . . . . 38
7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38 7.1.2. Certificate Extension . . . . . . . . . . . . . . . . 38
7.2. TLS Feature X.509v3 Extension . . . . . . . . . . . . . . 38 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 . . . . . . . . . . 39 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 . . . . . . . . . . . . . . 40 8.1.4. Fetching inclusion proofs . . . . . . . . . . . . . . 39
8.1.5. Validating inclusion proofs . . . . . . . . . . . . . 40 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 . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42 8.3. Auditing . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43 9. Algorithm Agility . . . . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10.1. New Entry to the TLS ExtensionType Registry . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 44 10.3. Hash Algorithms . . . . . . . . . . . . . . . . . . . . 44
skipping to change at page 25, line 16 skipping to change at page 25, line 16
o Keep the log running until the certificates in all of its entries o Keep the log running until the certificates in all of its entries
have expired or exist in other logs (this can be determined by have expired or exist in other logs (this can be determined by
scanning other logs or connecting to domains mentioned in the scanning other logs or connecting to domains mentioned in the
certificates and inspecting the SCTs served). certificates and inspecting the SCTs served).
5. Log Client Messages 5. Log Client Messages
Messages are sent as HTTPS GET or POST requests. Parameters for Messages are sent as HTTPS GET or POST requests. Parameters for
POSTs and all responses are encoded as JavaScript Object Notation POSTs and all responses are encoded as JavaScript Object Notation
(JSON) objects [RFC7159]. Parameters for GETs are encoded as order- (JSON) objects [RFC8259]. Parameters for GETs are encoded as order-
independent key/value URL parameters, using the "application/x-www- independent key/value URL parameters, using the "application/x-www-
form-urlencoded" format described in the "HTML 4.01 Specification" form-urlencoded" format described in the "HTML 4.01 Specification"
[HTML401]. Binary data is base64 encoded [RFC4648] as specified in [HTML401]. Binary data is base64 encoded [RFC4648] as specified in
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
skipping to change at page 35, line 20 skipping to change at page 35, line 20
o An X509v3 certificate extension (see Section 7.1.2). This o An X509v3 certificate extension (see Section 7.1.2). This
mechanism allows the use of unmodified TLS servers, but the SCTs mechanism allows the use of unmodified TLS servers, but the SCTs
and inclusion proofs cannot be updated on the fly. Since the logs and inclusion proofs cannot be updated on the fly. Since the logs
from which the SCTs and inclusion proofs originated won't from which the SCTs and inclusion proofs originated won't
necessarily be accepted by TLS clients for the full lifetime of necessarily be accepted by TLS clients for the full lifetime of
the certificate, there is a risk that TLS clients will the certificate, there is a risk that TLS clients will
subsequently consider the certificate to be non-compliant and in subsequently consider the certificate to be non-compliant and in
need of re-issuance. need of re-issuance.
Additionally, a TLS server which supports presenting SCTs using an
OCSP response MAY provide it when the TLS client included the
"status_request_v2" extension ([RFC6961]) in the (extended)
"ClientHello", but only in addition to at least one of the three
mechanisms listed above.
6.1. Multiple SCTs 6.1. Multiple SCTs
CT-using TLS servers SHOULD send SCTs from multiple logs, because: CT-using TLS servers SHOULD send SCTs from multiple logs, because:
o One or more logs may not have become acceptable to all CT-using o One or more logs may not have become acceptable to all CT-using
TLS clients. 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. When a TLS client requires SCTs from misissuance from clients. When a TLS client requires SCTs from
multiple logs to be provided, it is more difficult to mount this multiple logs to be provided, it is more difficult to mount this
skipping to change at page 38, line 52 skipping to change at page 38, line 48
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]).
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).
MAY also accept SCTs via the "status_request_v2" extension
([RFC6961]).
TLS clients that support the "transparency_info" TLS extension (see TLS clients that support the "transparency_info" TLS extension (see
Section 6.4) SHOULD include it in ClientHello messages, with empty Section 6.4) SHOULD include it in ClientHello messages, with empty
"extension_data". If a TLS server includes the "transparency_info" "extension_data". If a TLS server includes the "transparency_info"
TLS extension when resuming a TLS session, the TLS client MUST abort TLS extension when resuming a TLS session, the TLS client MUST abort
the handshake. 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
skipping to change at page 43, line 38 skipping to change at page 43, line 38
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 MUST 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 [RFC8126].
10.1. New Entry to the TLS ExtensionType Registry 10.1. New Entry to the TLS ExtensionType Registry
IANA is asked to add an entry for "transparency_info(TBD)" to the IANA is asked to add an entry for "transparency_info(TBD)" to the
"TLS ExtensionType Values" registry defined in [RFC8446], setting the "TLS ExtensionType Values" registry defined in [RFC8446], setting the
"Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR, "Recommended" value to "Y", setting the "TLS 1.3" value to "CH, CR,
CT", and citing this document as the "Reference". CT", and citing this document as the "Reference".
10.2. New Entry to the TLS CachedInformationType registry 10.2. New Entry to the TLS CachedInformationType registry
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>.
[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,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[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, <https://www.rfc- DOI 10.17487/RFC6066, January 2011,
editor.org/info/rfc6066>. <https://www.rfc-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,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, <https://www.rfc-
editor.org/info/rfc6961>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
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, <https://www.rfc- DOI 10.17487/RFC7231, June 2014,
editor.org/info/rfc7231>. <https://www.rfc-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, <https://www.rfc-editor.org/info/rfc7633>. October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>. <https://www.rfc-editor.org/info/rfc7807>.
[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, <https://www.rfc- DOI 10.17487/RFC7924, July 2016,
editor.org/info/rfc7924>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC8032, January 2017,
editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[UNIXTIME] [UNIXTIME]
IEEE, "The Open Group Base Specifications Issue 7 IEEE Std IEEE, "The Open Group Base Specifications Issue 7 IEEE Std
1003.1-2008, 2016 Edition", n.d., <http://pubs.opengroup.o 1003.1-2008, 2016 Edition", n.d., <http://pubs.opengroup.o
rg/onlinepubs/9699919799.2016edition/basedefs/ rg/onlinepubs/9699919799.2016edition/basedefs/
V1_chap04.html#tag_04_16>. V1_chap04.html#tag_04_16>.
skipping to change at page 53, line 15 skipping to change at page 53, line 10
[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-16 (work Transparency", draft-ietf-trans-threat-analysis-16 (work
in progress), October 2018. in progress), October 2018.
[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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
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, <https://www.rfc- DOI 10.17487/RFC6234, May 2011,
editor.org/info/rfc6234>. <https://www.rfc-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,
<https://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, <https://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,
<https://www.rfc-editor.org/info/rfc7320>. <https://www.rfc-editor.org/info/rfc7320>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
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
TLS, X.509 and OCSP extensions than v2 SCTs. TLS, X.509 and OCSP extensions than v2 SCTs.
skipping to change at page 55, line 4 skipping to change at page 54, line 41
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. Sectigo Ltd.
Email: rob@comodoca.com Email: rob@sectigo.com
 End of changes. 24 change blocks. 
46 lines changed or deleted 38 lines changed or added

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