Skip to main content

Certificate Transparency Version 2.0
draft-ietf-trans-rfc6962-bis-42

Revision differences

Document history

Date Rev. By Action
2021-12-14
42 (System) IANA registries were updated to include RFC9162
2021-12-09
42 (System)
Received changes through RFC Editor sync (created alias RFC 9162, changed abstract to 'This document describes version 2.0 of the Certificate Transparency (CT) protocol …
Received changes through RFC Editor sync (created alias RFC 9162, changed abstract to 'This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.

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 submissions and queries that are defined in this document.', changed pages to 53, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2021-12-09, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-trans-rfc6962-bis and RFC 6962)
2021-12-09
42 (System) RFC published
2021-11-21
42 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-09-24
42 (System) RFC Editor state changed to AUTH48
2021-09-10
42 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-08-31
42 (System) RFC Editor state changed to EDIT from IESG
2021-08-31
42 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-42.txt
2021-08-31
42 (System) New version approved
2021-08-31
42 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-08-31
42 Rob Stradling Uploaded new revision
2021-08-16
41 (System) RFC Editor state changed to IESG from EDIT
2021-08-11
41 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-08-10
41 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-08-09
41 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-08-04
41 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-07-30
41 (System) RFC Editor state changed to EDIT
2021-07-30
41 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-07-30
41 (System) Announcement was received by RFC Editor
2021-07-30
41 (System) IANA Action state changed to In Progress
2021-07-30
41 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-07-30
41 Cindy Morgan IESG has approved the document
2021-07-30
41 Cindy Morgan Closed "Approve" ballot
2021-07-30
41 Cindy Morgan Ballot approval text was generated
2021-07-30
41 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2021-07-30
41 (System) Removed all action holders (IESG state changed)
2021-07-30
41 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-30
41 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-41.txt
2021-07-30
41 (System) New version approved
2021-07-30
41 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-07-30
41 Rob Stradling Uploaded new revision
2021-07-29
40 Roman Danyliw Summary of IESG Review Comments for action: https://mailarchive.ietf.org/arch/msg/trans/gOXKavAMr7mbYtdOUmoA6vdoUzk/
2021-07-29
40 (System) Changed action holders to Ben Laurie, Adam Langley, Rob Stradling, Emilia Kasper, Eran Messeri (IESG state changed)
2021-07-29
40 Roman Danyliw IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2021-07-28
40 (System) Removed all action holders (IESG state changed)
2021-07-28
40 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-07-28
40 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-40.txt
2021-07-28
40 (System) New version approved
2021-07-28
40 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-07-28
40 Rob Stradling Uploaded new revision
2021-07-08
39 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Charlie Kaufman. Submission of review completed at an earlier date.
2021-07-03
39 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Charlie Kaufman.
2021-07-01
39 (System) Changed action holders to Ben Laurie, Adam Langley, Rob Stradling, Emilia Kasper, Eran Messeri (IESG state changed)
2021-07-01
39 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2021-07-01
39 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the efforts of this document.

I think it will be good to add section describing what is expected out of this …
[Ballot comment]
Thanks for the efforts of this document.

I think it will be good to add section describing what is expected out of this experimental document. Shepherd's write up describes the intention of publishing this as Standard Track then WG decision to move it back to Experimental. I think it is worth capturing the thoughts and reasoning there and also set some expectations on this document for potential future reversions.
2021-07-01
39 Zaheduzzaman Sarker Ballot comment text updated for Zaheduzzaman Sarker
2021-07-01
39 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the efforts of this document.

I think it will be good to add section describing what is expected out of this …
[Ballot comment]
Thanks for the efforts of this document.

I think it will be good to add section describing what is expected out of this experimental document. Shepherd's write up describes the intention of publishing this a standard track then WG decision to move it back to experimental. I think it is worth capturing the thoughts and reasoning there and also set some expectations on this document for potential future reversions.
2021-07-01
39 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-06-30
39 Benjamin Kaduk
[Ballot comment]
I owe a sizeable apology to the authors and the WG for being rather
unresponsive to attempts to discuss my previous Discuss points. …
[Ballot comment]
I owe a sizeable apology to the authors and the WG for being rather
unresponsive to attempts to discuss my previous Discuss points.
I am sorry that I did not respond promptly (or, sometimes, at all) to
questions about this document.
Fortunately, the changes made to address my concerns have been
successful even in my absence, and I appreciate the efforts of the WG
members to push forward and make progress while I was not providing
feedback.

I made a pull request on github with some editorial-level suggestions:
https://github.com/google/certificate-transparency-rfcs/pull/337
and have only two other comments.

Section 10.2.2

"Expert Review" with instructions to the experts to ensure that there is
a public specification sounds basically equivalent to "Specification
Required".

Appendix B

I think we should actually use the 'id-mod-public-notary-v2' OID
allocated in Section 10.3 as the identifier for the module.
2021-06-30
39 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from No Record
2021-06-30
39 Benjamin Kaduk
[Ballot comment]
Changing to No Record for an intermediate period to note that my
Discuss points on the -31 have been resolved, though I have …
[Ballot comment]
Changing to No Record for an intermediate period to note that my
Discuss points on the -31 have been resolved, though I have not reviewed
the full set of changes from -31 to -39.

I will also retain my note that I intended to ballot Yes once the Discuss
points on the -31 were resolved.
2021-06-30
39 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Record from Discuss
2021-06-30
39 Martin Duke
[Ballot comment]
Thanks for this document; I found it very interesting and enjoyed working through the Merkle Tree algorithms. Some non-blocking comments:

1. I have …
[Ballot comment]
Thanks for this document; I found it very interesting and enjoyed working through the Merkle Tree algorithms. Some non-blocking comments:

1. I have some concerns about the scalability of this proposal and the Log ID registry. If I understand correctly, there are at least two reasons an operator would choose to shut down their log and start a new one, which requires a new log ID:

- to refresh the signature algorithm and/or key

- As certificates expire and are renewed over time, the log has to retain an ever-expanding listing of useless, expired certificates and chains. While the Merkle tree makes this computationally inexpensive, pruning the storage requirements would require a refresh.

Which is to say that log IDs should change quite frequently. I'm not very knowledgeable about the OID hierarchy, but it might be valuable for log IDs to have enough structure for a given provider to be given one tier of log IDs (e.g. 1.3.101.80.x.y, where "x" is assigned to an operator via IANA and "y" is a version number incremented by that operator).

2. Would it be valuable to have a new "certificate revoked" object type in logs that could provide some assurance that entries hadn't been revoked? I can think of some ways this might work, but am not familiar enough with the use cases to say if it'd be valuable.

3. One nit: 4.1.1 and 4.1.2 have broken markdown tags.
2021-06-30
39 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-06-25
39 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-06-24
39 Amanda Baber IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-06-24
39 Amanda Baber IANA Experts State changed to Reviews assigned from Expert Reviews OK
2021-06-20
39 Erik Kline
[Ballot comment]
Thanks for this document.  Just a few random thoughts.

[S1.3] [nit]

* Consider expanding SCT and STH on first use.  Among other reasons, …
[Ballot comment]
Thanks for this document.  Just a few random thoughts.

[S1.3] [nit]

* Consider expanding SCT and STH on first use.  Among other reasons, the
  RFC Editor Abbreviations List entry for SCT has multiple values (which
  one is intended seems obvious, but still...).

[S4.2.1] [nit]

* The first sentence reads like a bit of a run-on sentence to me. Perhaps:

  "To A, and to B, and to C, the log MUST..." ->
  "To A, to B, and to C, the log MUST..."

[S10.1.2] [comment]

* Not to start a bikeshed, but "trans" strikes me a bit generic for direct
  registration under ietf:params (I'd think it meant "transport" before I
  thought of "transparency", for example :-).
2021-06-20
39 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-06-18
39 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-06-18
39 Amy Vezza Telechat date has been changed to 2021-07-01 from 2019-03-14
2021-06-18
39 Roman Danyliw Ballot has been issued
2021-06-18
39 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-06-18
39 Roman Danyliw Ballot writeup was changed
2021-06-18
39 Roman Danyliw Ballot approval text was generated
2021-06-18
39 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-06-17
39 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2021-06-17
39 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2021-06-17
39 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-trans-rfc6962-bis-39. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-trans-rfc6962-bis-39. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are nine actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the existing entry for value 52:

Value: 52
Name: transparency_info
TLS 1.3:
Recommended: Y
Reference: [ RFC-to-be ]

will have its reference changed to [ RFC-to-be ].

Second, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at:

https://www.iana.org/assignments/params/

a new entry is to be registered as follows:

Registered Parameter Identifier: trans:error
Reference: [ RFC-to-be ]
IANA Registry Reference: https://www.iana.org/assignments/trans

Third, new registry page is to be created called the Public Notary Transparency registry page in the registry matrix located at:

https://www.iana.org/protocols

the new registry page will have a reference of [ RFC-to-be ].

Fourth, on the newly created Public Notary Transparency registry page, a new registry will be created called the Hash Algorithms registry. This new registry will have the following allocation policy as defined by RFC8126:

+========+============+===================+
| Value | Hash | |
| | Algorithm | Assignment Policy |
+========+============+===================+
| 0x00 - | Unassigned | Specification |
| 0xDF | | Required |
+--------+------------+-------------------+
| 0xE0 - | Reserved | Experimental Use |
| 0xEF | | |
+--------+------------+-------------------+
| 0xF0 - | Reserved | Private Use |
| 0xFF | | |
+--------+------------+-------------------+

There is a single value in the registry as follows:

Value: 0x00
Hash Algorithm: SHA-256
OID: 2.16.840.1.101.3.4.2.1
Reference: RFC6234

Fifth, on the newly created Public Notary Transparency registry page, a new registry will be created called the Signature Algorithms registry. The note registry will include a note as follows:

"This is a subset of the TLS SignatureScheme Registry, limited to
those algorithms that are appropriate for CT. A major advantage
of this is leveraging the expertise of the TLS working group and
its Designated Expert(s).

The value "0x0403" appears twice. While this may be confusing, it
is okay because the verification process is the same for both
algorithms, and the choice of which to use when generating a
signature is purely internal to the log server."

This new registry will have the following allocation policy as defined by RFC8126:

+================================+==================+==============+
| SignatureScheme Value | Signature | Assignment |
| | Algorithm | Policy |
+================================+==================+==============+
| 0x0000 - 0xFDFF | Unassigned | Expert |
| | | Review |
+--------------------------------+------------------+--------------+
| 0xFE00 - 0xFEFF | Reserved | Experimental |
| | | Use |
+--------------------------------+------------------+--------------+
| 0xFF00 - 0xFFFF | Reserved | Private Use |
+--------------------------------+------------------+--------------+

There are three initial values in the new registry as follows:

SignatureScheme Value: ecdsa_secp256r1_sha256(0x0403)
Signature Algorithm: ECDSA (NIST P-256) with SHA-256
Reference: [FIPS186-4]

SignatureScheme Value: ecdsa_secp256r1_sha256(0x0403)
Signature Algorithm: Deterministic ECDSA (NIST P-256) with HMAC-SHA256
Reference: [RFC6979]

SignatureScheme Value: ed25519(0x0807)
Signature Algorithm: Ed25519 (PureEdDSA with the edwards25519 curve)
Reference: [RFC8032]

Sixth, on the newly created Public Notary Transparency registry page, a new registry will be created called the VersionedTransTypes registry.

This new registry will have the following allocation policy as defined by RFC8126:

+==========+===============================+
| Value | Assignment Policy |
+==========+===============================+
| 0x0000 | Reserved |
+----------+-------------------------------+
| 0x0001 - | Specification Required |
| 0xDFFF | |
+----------+-------------------------------+
| 0xE000 - | Experimental Use |
| 0xEFFF | |
+----------+-------------------------------+
| 0xF000 - | Private Use |
| 0xFFFF | |
+----------+-------------------------------+

There are initial registrations in the new registry as follows:

+==========+======================+===============================+
| Value | Type and Version | Reference |
+==========+======================+===============================+
| 0x0000 | Reserved | [RFC6962] |
+----------+----------------------+-------------------------------+
| 0x0001 | x509_entry_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+
| 0x0002 | precert_entry_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+
| 0x0003 | x509_sct_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+
| 0x0004 | precert_sct_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+
| 0x0005 | signed_tree_head_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+
| 0x0006 | consistency_proof_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+
| 0x0007 | inclusion_proof_v2 | [ RFC-to-be ] |
+----------+----------------------+-------------------------------+

Seventh, on the newly created Public Notary Transparency registry page, a new registry will be created called the Log Artifact Extensions registry.

This new registry will have the following allocation policy as defined by RFC8126:

+===============+============+=====+===============================+
| ExtensionType | Status | Use | Reference / Assignment Policy |
+===============+============+=====+===============================+
| 0x0000 - | Unassigned | n/a | Specification Required |
| 0xDFFF | | | |
+---------------+------------+-----+-------------------------------+
| 0xE000 - | Reserved | n/a | Experimental Use |
| 0xEFFF | | | |
+---------------+------------+-----+-------------------------------+
| 0xF000 - | Reserved | n/a | Private Use |
| 0xFFFF | | | |
+---------------+------------+-----+-------------------------------+

IANA understands that there are no initial values for this new registry.

Eighth, on the newly created Public Notary Transparency registry page, a new registry will be created called the Log ID registry.

This new registry will have the following allocation policy as defined by RFC8126:

The registry will be made up of two sections with both sections having registration policies of First Come, First Served:

+================+==============+==============+===================+
| Log ID | Log Base URL | Log Operator | Reference / |
| | | | Assignment Policy |
+================+==============+==============+===================+
| 1.3.101.8192 - | Unassigned | Unassigned | First Come First |
| 1.3.101.16383 | | | Served |
+----------------+--------------+--------------+-------------------+
| 1.3.101.80.0 - | Unassigned | Unassigned | First Come First |
| 1.3.101.80.* | | | Served |
+----------------+--------------+--------------+-------------------+

IANA Question --? Should IANA place a note in the new registry that reflects the conditions for assignment that are set out in section 10.2.5 of the current document?

Ninth, on the newly created Public Notary Transparency registry page, a new registry will be created called the Error Types registry.

This new registry will have the following allocation policy as defined by RFC8126: Specification Required.

There are initial registrations in the new registry as follows:

+===================+===============================+===============+
| Identifier | Meaning | Reference |
+===================+===============================+===============+
| malformed | The request could not be | [ RFC-to-be ] |
| | parsed. | |
+-------------------+-------------------------------+---------------+
| badSubmission | "submission" is neither a | [ RFC-to-be ] |
| | valid certificate nor a valid | |
| | precertificate | |
+-------------------+-------------------------------+---------------+
| badType | "type" is neither 1 nor 2 | [ RFC-to-be ] |
+-------------------+-------------------------------+---------------+
| badChain | The first element of "chain" | [ RFC-to-be ] |
| | is not the certifier of the | |
| | "submission", or the second | |
| | element does not certify the | |
| | first, etc. | |
+-------------------+-------------------------------+---------------+
| badCertificate | One or more certificates in | [ RFC-to-be ] |
| | the "chain" are not valid | |
| | (e.g., not properly encoded) | |
+-------------------+-------------------------------+---------------+
| unknownAnchor | The last element of "chain" | [ RFC-to-be ] |
| | (or, if "chain" is an empty | |
| | array, the "submission") both | |
| | is not, and is not certified | |
| | by, an accepted trust anchor | |
+-------------------+-------------------------------+---------------+
| shutdown | The log is no longer | [ RFC-to-be ] |
| | accepting submissions | |
+-------------------+-------------------------------+---------------+
| firstUnknown | "first" is before the latest | [ RFC-to-be ] |
| | known STH but is not from an | |
| | existing STH. | |
+-------------------+-------------------------------+---------------+
| secondUnknown | "second" is before the latest | [ RFC-to-be ] |
| | known STH but is not from an | |
| | existing STH. | |
+-------------------+-------------------------------+---------------+
| secondBeforeFirst | "second" is smaller than | [ RFC-to-be ] |
| | "first". | |
+-------------------+-------------------------------+---------------+
| hashUnknown | "hash" is not the hash of a | [ RFC-to-be ] |
| | known leaf (may be caused by | |
| | skew or by a known | |
| | certificate not yet merged). | |
+-------------------+-------------------------------+---------------+
| treeSizeUnknown | "hash" is before the latest | [ RFC-to-be ] |
| | known STH but is not from an | |
| | existing STH. | |
+-------------------+-------------------------------+---------------+
| startUnknown | "start" is greater than the | [ RFC-to-be ] |
| | number of entries in the | |
| | Merkle tree. | |
+-------------------+-------------------------------+---------------+
| endBeforeStart | "start" cannot be greater | [ RFC-to-be ] |
| | than "end". | |
+-------------------+-------------------------------+---------------+

Tenth, in the SMI Security for PKIX Module Identifier registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

a new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-mod-public-notary-v2
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-06-10
39 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2021-06-10
39 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2021-06-08
39 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2021-06-08
39 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2021-06-04
39 Amy Vezza
The following Last Call announcement was sent out (ends 2021-06-18):

From: The IESG
To: IETF-Announce
CC: Paul Wouters , draft-ietf-trans-rfc6962-bis@ietf.org, paul.wouters@aiven.io, rdd@cert.org, …
The following Last Call announcement was sent out (ends 2021-06-18):

From: The IESG
To: IETF-Announce
CC: Paul Wouters , draft-ietf-trans-rfc6962-bis@ietf.org, paul.wouters@aiven.io, rdd@cert.org, trans-chairs@ietf.org, trans@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Certificate Transparency Version 2.0) to Experimental RFC


The IESG has received a request from the Public Notary Transparency WG
(trans) to consider the following document: - 'Certificate Transparency
Version 2.0'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes version 2.0 of the Certificate Transparency
  (CT) protocol for publicly logging the existence of Transport Layer
  Security (TLS) server certificates as they are issued or observed, in
  a manner that allows anyone to audit certification authority (CA)
  activity and notice the issuance of suspect certificates as well as
  to audit the certificate logs themselves.  The intent is that
  eventually clients would refuse to honor certificates that do not
  appear in a log, effectively forcing CAs to add all issued
  certificates to the logs.

  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
  submissions and queries that are defined in this document.

  [RFC Editor: please update 'RFCXXXX' to refer to this document, once
  its RFC number is known, through the document.]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/



No IPR declarations have been submitted directly on this I-D.




2021-06-04
39 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-06-04
39 Amy Vezza Last call announcement was generated
2021-06-04
39 Paul Wouters
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Experimental

Why is this the proper type of RFC?

  This document is the result of operational experience with running the
  Experimental RFC 6962.  Initially, this was meant to become a Standards
  Track document but at draft -29 it was decided that the changes were
  large enough that it should really be considered Experimental.

Is this type of RFC indicated in the title page header?

  Yes, the document title page indicates being 'standard track'.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a protocol for publicly logging the existence
  of Transport Layer Security (TLS) server certificates as they are
  issued or observed, in a manner that allows anyone to audit
  certification authority (CA) activity and notice the issuance of
  suspect certificates as well as to audit the certificate logs
  themselves.  The intent is that eventually clients would refuse to
  honor certificates that do not appear in a log, effectively forcing
  CAs to add all issued certificates to the logs.

  This document is a bis document for the Experimental RFC 6962.
  The major changes between that document and this document are
  listed in Section 1.3 of the draft, and are:

  o  Hash and signature algorithm agility: permitted algorithms are now
      specified in IANA registries.

  o  Precertificate format: precertificates are now CMS objects rather
      than X.509 certificates, which avoids violating the certificate
      serial number uniqueness requirement in Section 4.1.2.2 of
      [RFC5280].

  o  Removed precertificate signing certificates and the precertificate
      poison extension: the change of precertificate format means that
      these are no longer needed.

  o  Logs IDs: each log is now identified by an OID rather than by the
      hash of its public key.  OID allocations are managed by an IANA
      registry.

  o  "TransItem" structure: this new data structure is used to
      encapsulate most types of CT data.  A "TransItemList", consisting
      of one or more "TransItem" structures, can be used anywhere that
      "SignedCertificateTimestampList" was used in [RFC6962].

  o  Merkle tree leaves: the "MerkleTreeLeaf" structure has been
      replaced by the "TransItem" structure, which eases extensibility
      and simplifies the leaf structure by removing one layer of
      abstraction.

  o  Unified leaf format: the structure for both certificate and
      precertificate entries now includes only the TBSCertificate
      (whereas certificate entries in [RFC6962] included the entire
      certificate).

  o  SCT extensions: these are now typed and managed by an IANA
      registry.

  o  STH extensions: STHs can now contain extensions, which are typed
      and managed by an IANA registry.

  o  API outputs: complete "TransItem" structures are returned, rather
      than the constituent parts of each structure.

  o  get-all-by-hash: new client API for obtaining an inclusion proof
      and the corresponding consistency proof at the same time.

  o  Presenting SCTs with proofs: TLS servers may present SCTs together
      with the corresponding inclusion proofs using any of the
      mechanisms that [RFC6962] defined for presenting SCTs only.
      (Presenting SCTs only is still supported).

  o  CT TLS extension: the "signed_certificate_timestamp" TLS extension
      has been replaced by the "transparency_info" TLS extension.

  o  Other TLS extensions: "status_request_v2" may be used (in the same
      manner as "status_request"); "cached_info" may be used to avoid
      sending the same complete SCTs and inclusion proofs to the same
      TLS clients multiple times.

  o  TLS Feature extension: this certificate extension may be used by a
      CA to indicate that CT compliance is required.

  o  Verification algorithms: added detailed algorithms for verifying
      inclusion proofs, for verifying consistency between two STHs, and
      for verifying a root hash given a complete list of the relevant
      leaf input entries.

  o  Extensive clarifications and editorial work.

  o  Clarifications for use with TLS v1.2 and v1.3

  Backwards compatibility:

  Logs can either conform to RFC6962 (???v1???) or RFC6962??bis (???v2???),
  not both, as the format of the data logged is different. As v1 and
  v2 SCTs are delivered using different X.509, TLS and OCSP extensions,
  they can mostly co??exist and TLS clients can support both
  simultaneously. One provision has been made for embedded v1 and
  v2 SCTs by requiring v2 clients to  remove v1 SCTs from the
  TBSCertificate portion of the certificate before validating v2 SCTs
  over it (to allow v2 SCTs to be embedded before v1 SCTs are issued).

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  During the document development, some content was split of
  into other documents for clarity. Topics split of covers a threat
  model document, a log monitoring API, and a client/gossip API.

  Name redaction has been considered and was split of in another
  document as well. The WG is still discussing whether or not to
  allow name redaction as well as the redaction method that would
  be used.

  Currently, there is still an open issue between some major vendors
  about whether this document is good enough as a basis to develop
  further preventative client actions on. The WG Chairs are organising
  a meeting with these parties to determine if the document should be
  stalled or proceed.

Document Quality

Are there existing implementations of the protocol?

  There are various implementations in different state of completion
  which have lead to updates to the document.

  Various well-known crypto libraries have started implementation.

Have a significant number of vendors indicated their plan to implement
the specification?

  Yes. Various well-known crypto libraries have started implementation.
  A few new independent parties have also implemented or mostly
  implemented this document's specification - both proprietary as well
  as opensource implementations.

Are there any reviewers that merit special mention as having done
a thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

  Stephen Kent gave many in-depth reviews of many versions of the
  document, all of which were dealt with by the Working Group. Daniel
  Kahn Gillmor came up with a new attack, which is now described in one
  of the documents that was split off from this one. During WGLC several
  implementers came forward explaining that one MUST keyword (in Section
  5.1) had to change to SHOULD to allow for log behaviour that was deemed
  necessary for actual deployments, which was agreed on by the Working
  Group.

If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  There was no such review.

Personnel

Who is the Document Shepherd?

  Paul Wouters

Who is the Responsible Area Director?

  Roman Danyliw  (Eric Rescorla before him, as this document has taken a long time)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I read all the threads about this document on the mailing list to be
  sure that the issues raised were address or at least discussed in the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been seen and is (being) implemented widely in
  various different parts of the industry and opensource communities.
  There is significant interest and traction to roll-out implementations
  of this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No. The important groups that needed to read and comment on this
  document were the PKIX and TLS communities and these groups were
  very well represented.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns other than taking more time to publish.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  [PAUL: Do I need to click on the IPR button in the datatracker before
  submitting this? ]

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Not that the WG chairs are aware of.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  It represents strong consensus within the WG, which includes many
  relevant affected players in the industry (CA vendors, browser
  vendors, TLS implementors, crypto library authors). The only item
  which did not have strong consensus was name redaction, which has
  therefore been moved to its own document for possible future work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    Appeals were threatened in the past, but have been resolved.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool shows a few warnings:

  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

These are false positives (I think it is reading OID's as IPv6?)


  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)

That is correct. That is TLS v1.2 and the document specifically talks about TLS v1.2 and v1.3



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.


  There is one. RFC 6979 "Deterministic Usage of the Digital Signature
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Yes. It obsoletes RFC 6962.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  It has been reviews and complies with the requirements of RFC-5226

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The IANA is requested to create the "Public Notary Transparency"
  registry. Within that registry, the following sub registries are requested
  to be created:

  Section  Registry Name

  10.2.1    Hash Algorithms
  10.2.2    Signature Algorithms
  10.2.3  VersionedTransTypes
  10.2.4  Log Artifact Extensions
  10.2.5  Log ID Registry
  10.2.6  Error Types

[note: Log ID Registry should probably just be called Log IDs ?]

All of these Registries are defined to require Expert Review. An Expert
should be a person that has intimate knowledge of TLS, PKIX and cryptography.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The idnits checker was used on the document.

2021-06-04
39 Roman Danyliw Last call was requested
2021-06-04
39 Roman Danyliw IESG state changed to Last Call Requested from Publication Requested
2021-06-03
39 Paul Wouters
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposed Standard

Why is this the proper type of RFC?

  This document is the result of operational experience with running the
  Experimental RFC 6962. This bis document is therefore intended as
  Proposed Standard.

Is this type of RFC indicated in the title page header?

  Yes, the document title page indicates being 'standard track'.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a protocol for publicly logging the existence
  of Transport Layer Security (TLS) server certificates as they are
  issued or observed, in a manner that allows anyone to audit
  certification authority (CA) activity and notice the issuance of
  suspect certificates as well as to audit the certificate logs
  themselves.  The intent is that eventually clients would refuse to
  honor certificates that do not appear in a log, effectively forcing
  CAs to add all issued certificates to the logs.

  This document is a bis document for the Experimental RFC 6962.
  The major changes between that document and this document are
  listed in Section 1.3 of the draft, and are:

  o  Hash and signature algorithm agility: permitted algorithms are now
      specified in IANA registries.

  o  Precertificate format: precertificates are now CMS objects rather
      than X.509 certificates, which avoids violating the certificate
      serial number uniqueness requirement in Section 4.1.2.2 of
      [RFC5280].

  o  Removed precertificate signing certificates and the precertificate
      poison extension: the change of precertificate format means that
      these are no longer needed.

  o  Logs IDs: each log is now identified by an OID rather than by the
      hash of its public key.  OID allocations are managed by an IANA
      registry.

  o  "TransItem" structure: this new data structure is used to
      encapsulate most types of CT data.  A "TransItemList", consisting
      of one or more "TransItem" structures, can be used anywhere that
      "SignedCertificateTimestampList" was used in [RFC6962].

  o  Merkle tree leaves: the "MerkleTreeLeaf" structure has been
      replaced by the "TransItem" structure, which eases extensibility
      and simplifies the leaf structure by removing one layer of
      abstraction.

  o  Unified leaf format: the structure for both certificate and
      precertificate entries now includes only the TBSCertificate
      (whereas certificate entries in [RFC6962] included the entire
      certificate).

  o  SCT extensions: these are now typed and managed by an IANA
      registry.

  o  STH extensions: STHs can now contain extensions, which are typed
      and managed by an IANA registry.

  o  API outputs: complete "TransItem" structures are returned, rather
      than the constituent parts of each structure.

  o  get-all-by-hash: new client API for obtaining an inclusion proof
      and the corresponding consistency proof at the same time.

  o  Presenting SCTs with proofs: TLS servers may present SCTs together
      with the corresponding inclusion proofs using any of the
      mechanisms that [RFC6962] defined for presenting SCTs only.
      (Presenting SCTs only is still supported).

  o  CT TLS extension: the "signed_certificate_timestamp" TLS extension
      has been replaced by the "transparency_info" TLS extension.

  o  Other TLS extensions: "status_request_v2" may be used (in the same
      manner as "status_request"); "cached_info" may be used to avoid
      sending the same complete SCTs and inclusion proofs to the same
      TLS clients multiple times.

  o  TLS Feature extension: this certificate extension may be used by a
      CA to indicate that CT compliance is required.

  o  Verification algorithms: added detailed algorithms for verifying
      inclusion proofs, for verifying consistency between two STHs, and
      for verifying a root hash given a complete list of the relevant
      leaf input entries.

  o  Extensive clarifications and editorial work.

  o  Clarifications for use with TLS v1.2 and v1.3

  Backwards compatibility:

  Logs can either conform to RFC6962 (???v1???) or RFC6962??bis (???v2???),
  not both, as the format of the data logged is different. As v1 and
  v2 SCTs are delivered using different X.509, TLS and OCSP extensions,
  they can mostly co??exist and TLS clients can support both
  simultaneously. One provision has been made for embedded v1 and
  v2 SCTs by requiring v2 clients to  remove v1 SCTs from the
  TBSCertificate portion of the certificate before validating v2 SCTs
  over it (to allow v2 SCTs to be embedded before v1 SCTs are issued).

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  During the document development, some content was split of
  into other documents for clarity. Topics split of covers a threat
  model document, a log monitoring API, and a client/gossip API.

  Name redaction has been considered and was split of in another
  document as well. The WG is still discussing whether or not to
  allow name redaction as well as the redaction method that would
  be used.

  Currently, there is still an open issue between some major vendors
  about whether this document is good enough as a basis to develop
  further preventative client actions on. The WG Chairs are organising
  a meeting with these parties to determine if the document should be
  stalled or proceed.

Document Quality

Are there existing implementations of the protocol?

  There are various implementations in different state of completion
  which have lead to updates to the document.

  Various well-known crypto libraries have started implementation.

Have a significant number of vendors indicated their plan to implement
the specification?

  Yes. Various well-known crypto libraries have started implementation.
  A few new independent parties have also implemented or mostly
  implemented this document's specification - both proprietary as well
  as opensource implementations.

Are there any reviewers that merit special mention as having done
a thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

  Stephen Kent gave many in-depth reviews of many versions of the
  document, all of which were dealt with by the Working Group. Daniel
  Kahn Gillmor came up with a new attack, which is now described in one
  of the documents that was split off from this one. During WGLC several
  implementers came forward explaining that one MUST keyword (in Section
  5.1) had to change to SHOULD to allow for log behaviour that was deemed
  necessary for actual deployments, which was agreed on by the Working
  Group.

If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  There was no such review.

Personnel

Who is the Document Shepherd?

  Paul Wouters

Who is the Responsible Area Director?

  Roman Danyliw  (Eric Rescorla before him, as this document has taken a long time)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I read all the threads about this document on the mailing list to be
  sure that the issues raised were address or at least discussed in the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been seen and is (being) implemented widely in
  various different parts of the industry and opensource communities.
  There is significant interest and traction to roll-out implementations
  of this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No. The important groups that needed to read and comment on this
  document were the PKIX and TLS communities and these groups were
  very well represented.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns other than taking more time to publish.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  [PAUL: Do I need to click on the IPR button in the datatracker before
  submitting this? ]

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Not that the WG chairs are aware of.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  It represents strong consensus within the WG, which includes many
  relevant affected players in the industry (CA vendors, browser
  vendors, TLS implementors, crypto library authors). The only item
  which did not have strong consensus was name redaction, which has
  therefore been moved to its own document for possible future work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    Appeals were threatened in the past, but have been resolved.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool shows a few warnings:

  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

These are false positives (I think it is reading OID's as IPv6?)


  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)

That is correct. That is TLS v1.2 and the document specifically talks about TLS v1.2 and v1.3



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.


  There is one. RFC 6979 "Deterministic Usage of the Digital Signature
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Yes. It obsoletes RFC 6962.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  It has been reviews and complies with the requirements of RFC-5226

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The IANA is requested to create the "Public Notary Transparency"
  registry. Within that registry, the following sub registries are requested
  to be created:

  Section  Registry Name

  10.2.1    Hash Algorithms
  10.2.2    Signature Algorithms
  10.2.3  VersionedTransTypes
  10.2.4  Log Artifact Extensions
  10.2.5  Log ID Registry
  10.2.6  Error Types

[note: Log ID Registry should probably just be called Log IDs ?]

All of these Registries are defined to require Expert Review. An Expert
should be a person that has intimate knowledge of TLS, PKIX and cryptography.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The idnits checker was used on the document.

2021-06-03
39 Paul Wouters IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-06-03
39 Paul Wouters IESG state changed to Publication Requested from I-D Exists
2021-06-03
39 Paul Wouters IESG process started in state Publication Requested
2021-06-03
39 Paul Wouters
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposed Standard

Why is this the proper type of RFC?

  This document is the result of operational experience with running the
  Experimental RFC 6962. This bis document is therefore intended as
  Proposed Standard.

Is this type of RFC indicated in the title page header?

  Yes, the document title page indicates being 'standard track'.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a protocol for publicly logging the existence
  of Transport Layer Security (TLS) server certificates as they are
  issued or observed, in a manner that allows anyone to audit
  certification authority (CA) activity and notice the issuance of
  suspect certificates as well as to audit the certificate logs
  themselves.  The intent is that eventually clients would refuse to
  honor certificates that do not appear in a log, effectively forcing
  CAs to add all issued certificates to the logs.

  This document is a bis document for the Experimental RFC 6962.
  The major changes between that document and this document are
  listed in Section 1.3 of the draft, and are:

  o  Hash and signature algorithm agility: permitted algorithms are now
      specified in IANA registries.

  o  Precertificate format: precertificates are now CMS objects rather
      than X.509 certificates, which avoids violating the certificate
      serial number uniqueness requirement in Section 4.1.2.2 of
      [RFC5280].

  o  Removed precertificate signing certificates and the precertificate
      poison extension: the change of precertificate format means that
      these are no longer needed.

  o  Logs IDs: each log is now identified by an OID rather than by the
      hash of its public key.  OID allocations are managed by an IANA
      registry.

  o  "TransItem" structure: this new data structure is used to
      encapsulate most types of CT data.  A "TransItemList", consisting
      of one or more "TransItem" structures, can be used anywhere that
      "SignedCertificateTimestampList" was used in [RFC6962].

  o  Merkle tree leaves: the "MerkleTreeLeaf" structure has been
      replaced by the "TransItem" structure, which eases extensibility
      and simplifies the leaf structure by removing one layer of
      abstraction.

  o  Unified leaf format: the structure for both certificate and
      precertificate entries now includes only the TBSCertificate
      (whereas certificate entries in [RFC6962] included the entire
      certificate).

  o  SCT extensions: these are now typed and managed by an IANA
      registry.

  o  STH extensions: STHs can now contain extensions, which are typed
      and managed by an IANA registry.

  o  API outputs: complete "TransItem" structures are returned, rather
      than the constituent parts of each structure.

  o  get-all-by-hash: new client API for obtaining an inclusion proof
      and the corresponding consistency proof at the same time.

  o  Presenting SCTs with proofs: TLS servers may present SCTs together
      with the corresponding inclusion proofs using any of the
      mechanisms that [RFC6962] defined for presenting SCTs only.
      (Presenting SCTs only is still supported).

  o  CT TLS extension: the "signed_certificate_timestamp" TLS extension
      has been replaced by the "transparency_info" TLS extension.

  o  Other TLS extensions: "status_request_v2" may be used (in the same
      manner as "status_request"); "cached_info" may be used to avoid
      sending the same complete SCTs and inclusion proofs to the same
      TLS clients multiple times.

  o  TLS Feature extension: this certificate extension may be used by a
      CA to indicate that CT compliance is required.

  o  Verification algorithms: added detailed algorithms for verifying
      inclusion proofs, for verifying consistency between two STHs, and
      for verifying a root hash given a complete list of the relevant
      leaf input entries.

  o  Extensive clarifications and editorial work.

  o  Clarifications for use with TLS v1.2 and v1.3

  Backwards compatibility:

  Logs can either conform to RFC6962 (???v1???) or RFC6962??bis (???v2???),
  not both, as the format of the data logged is different. As v1 and
  v2 SCTs are delivered using different X.509, TLS and OCSP extensions,
  they can mostly co??exist and TLS clients can support both
  simultaneously. One provision has been made for embedded v1 and
  v2 SCTs by requiring v2 clients to  remove v1 SCTs from the
  TBSCertificate portion of the certificate before validating v2 SCTs
  over it (to allow v2 SCTs to be embedded before v1 SCTs are issued).

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  During the document development, some content was split of
  into other documents for clarity. Topics split of covers a threat
  model document, a log monitoring API, and a client/gossip API.

  Name redaction has been considered and was split of in another
  document as well. The WG is still discussing whether or not to
  allow name redaction as well as the redaction method that would
  be used.

  Currently, there is still an open issue between some major vendors
  about whether this document is good enough as a basis to develop
  further preventative client actions on. The WG Chairs are organising
  a meeting with these parties to determine if the document should be
  stalled or proceed.

Document Quality

Are there existing implementations of the protocol?

  There are various implementations in different state of completion
  which have lead to updates to the document.

  Various well-known crypto libraries have started implementation.

Have a significant number of vendors indicated their plan to implement
the specification?

  Yes. Various well-known crypto libraries have started implementation.
  A few new independent parties have also implemented or mostly
  implemented this document's specification - both proprietary as well
  as opensource implementations.

Are there any reviewers that merit special mention as having done
a thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

  Stephen Kent gave many in-depth reviews of many versions of the
  document, all of which were dealt with by the Working Group. Daniel
  Kahn Gillmor came up with a new attack, which is now described in one
  of the documents that was split off from this one. During WGLC several
  implementers came forward explaining that one MUST keyword (in Section
  5.1) had to change to SHOULD to allow for log behaviour that was deemed
  necessary for actual deployments, which was agreed on by the Working
  Group.

If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  There was no such review.

Personnel

Who is the Document Shepherd?

  Paul Wouters

Who is the Responsible Area Director?

  Roman Danyliw  (Eric Rescorla before him, as this document has taken a long time)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I read all the threads about this document on the mailing list to be
  sure that the issues raised were address or at least discussed in the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been seen and is (being) implemented widely in
  various different parts of the industry and opensource communities.
  There is significant interest and traction to roll-out implementations
  of this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No. The important groups that needed to read and comment on this
  document were the PKIX and TLS communities and these groups were
  very well represented.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns other than taking more time to publish.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  [PAUL: Do I need to click on the IPR button in the datatracker before
  submitting this? ]

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Not that the WG chairs are aware of.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  It represents strong consensus within the WG, which includes many
  relevant affected players in the industry (CA vendors, browser
  vendors, TLS implementors, crypto library authors). The only item
  which did not have strong consensus was name redaction, which has
  therefore been moved to its own document for possible future work.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    Appeals were threatened in the past, but have been resolved.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool shows a few warnings:

  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

These are false positives (I think it is reading OID's as IPv6?)


  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)

That is correct. That is TLS v1.2 and the document specifically talks about TLS v1.2 and v1.3



(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.


  There is one. RFC 6979 "Deterministic Usage of the Digital Signature
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Yes. It obsoletes RFC 6962.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  It has been reviews and complies with the requirements of RFC-5226

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The IANA is requested to create the "Public Notary Transparency"
  registry. Within that registry, the following sub registries are requested
  to be created:

  Section  Registry Name

  10.2.1    Hash Algorithms
  10.2.2    Signature Algorithms
  10.2.3  VersionedTransTypes
  10.2.4  Log Artifact Extensions
  10.2.5  Log ID Registry
  10.2.6  Error Types

[note: Log ID Registry should probably just be called Log IDs ?]

All of these Registries are defined to require Expert Review. An Expert
should be a person that has intimate knowledge of TLS, PKIX and cryptography.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The idnits checker was used on the document.

2021-06-03
39 Paul Wouters Notification list changed to "Paul Wouters" <paul@nohats.ca>, paul.wouters@aiven.io from "Paul Wouters" <paul@nohats.ca> because the document shepherd was set
2021-06-03
39 Paul Wouters Document shepherd changed to Paul Wouters
2021-06-03
39 Paul Wouters IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-05-17
39 Paul Wouters Redoing a WGLC in response to resolving the open DISCUSS items and because the previous one  was a very long time ago.
2021-05-17
39 Paul Wouters Tags Other - see Comment Log, Revised I-D Needed - Issue raised by WG cleared.
2021-05-17
39 Paul Wouters IETF WG state changed to In WG Last Call from WG Document
2021-05-17
39 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-39.txt
2021-05-17
39 (System) New version approved
2021-05-17
39 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-05-17
39 Rob Stradling Uploaded new revision
2021-05-14
38 Murray Kucherawy [Ballot comment]
Thanks for the extra work on the IANA Considerations section.  My DISCUSS (and Alexey's) points are all resolved.
2021-05-14
38 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2021-05-14
38 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-38.txt
2021-05-14
38 (System) New version approved
2021-05-14
38 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-05-14
38 Rob Stradling Uploaded new revision
2021-05-13
37 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-37.txt
2021-05-13
37 (System) New version approved
2021-05-13
37 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-05-13
37 Rob Stradling Uploaded new revision
2021-05-13
36 Murray Kucherawy
[Ballot discuss]
Thanks for addressing Alexey's DISCUSS position.  In -36, a few important IANA-related issues remain, all easy fixes:

* Section 10.4 has some messed …
[Ballot discuss]
Thanks for addressing Alexey's DISCUSS position.  In -36, a few important IANA-related issues remain, all easy fixes:

* Section 10.4 has some messed up markdown around its Specification Required guidance.

* Section 10.7 needs to name the sub-registry it's creating.  (If it's the title of the section, that should be made clear; the prose doesn't say.)

* It should be clear that all of these are sub-registries of "Transport Layer Security (TLS) Extensions".  Either say that in each section (i.e., refer to the XYZ sub-registry of the "Transport Layer Security (TLS) Extensions" registry), or say in Section 10 that everything below is a sub-registry of that one.
2021-05-13
36 Murray Kucherawy Ballot comment and discuss text updated for Murray Kucherawy
2021-05-13
36 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-36.txt
2021-05-13
36 (System) New version approved
2021-05-13
36 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-05-13
36 Rob Stradling Uploaded new revision
2021-05-12
35 Roman Danyliw IETF WG state changed to WG Document from Submitted to IESG for Publication
2021-05-12
35 Roman Danyliw Returning to the WG: https://mailarchive.ietf.org/arch/msg/trans/i0dOlP2zPW7ZlIO7TwnlAmJjdS0/
2021-05-12
35 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-05-12
35 Roman Danyliw IESG state changed to I-D Exists from IESG Evaluation::AD Followup
2021-03-25
35 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-03-25
35 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-35.txt
2021-03-25
35 (System) New version approved
2021-03-25
35 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Ben Laurie , Emilia Kasper , Eran Messeri , Rob Stradling
2021-03-25
35 Rob Stradling Uploaded new revision
2021-03-05
34 Roman Danyliw Status Update: https://mailarchive.ietf.org/arch/msg/trans/pz8N7Zv1o4zBccqZR9utp1VZqgQ/
2020-04-05
34 Murray Kucherawy [Ballot discuss]
Preserving Alexey's DISCUSS position...
2020-04-05
34 Murray Kucherawy [Ballot comment]
...and his comments.
2020-04-05
34 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2020-02-25
34 Roman Danyliw IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2020-02-25
34 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss and adding some more text in the security consideration section!

I believe all comments below are still valid, …
[Ballot comment]
Thanks for addressing my discuss and adding some more text in the security consideration section!

I believe all comments below are still valid, expect 2 which is a nit that was fixed. I would really like to see some recommendations on point 5 before this document moves on!

1) I found section 2 a bit hard to follow. Would it maybe be possible to provide more textual explanation of the algorithms instead of just describing the steps of the algorithms? Also I was wondering how much much these algorithms are actually „part“ of the protocol spec…? Are could these be rather seen as example algorithms? Maybe that could be further clarified

2) Please expand STH on first occurrence (in sec 4.1)

3) Sec 4.4: „A log's operator MUST either allocate the OID
    themselves or request an OID from the Log ID Registry (see
    Section 10.6.1).“
Isn't there an obligation to register?

4) sec 4.8: „If an
  implementation sees an extension that it does not understand, it
  SHOULD ignore that extension.“
Maybe it’s just me because I may have missed some context but does „ignore“ mean here that it should log it or not?

5) sec 5: „MAY retry the same
  request without modification at a later date.“
Would it be possible to provide a recommendation how long the client should wait?

6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per
  "get-entries" request.“
Should this be added to sec 4.1?

7) sec 10.3: Couldn’t you use the TLS  SignatureScheme Registry directly (instead of forming an own registry)?

8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate for the VersionedTransTypes registry?

9) sec 10.6.1:I guess  the registration policy is FCFS? RFC 8126 recommend to always (clearly) name the registry.

And finally one higher level question mainly out of curiosity: was it considered to e.g. use json for all data structures? Is there a performance reason to not do that or wasn’t that even discussed?
2020-02-25
34 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2020-02-24
34 Roman Danyliw
[Ballot comment]
(Adding a Yes ballot with comments on my own document as it was inherent during an AD change)

** Section 2.2 and 3.2.  …
[Ballot comment]
(Adding a Yes ballot with comments on my own document as it was inherent during an AD change)

** Section 2.2 and 3.2.  Reference the IANA registry name, not just the document section

-- Section 2.2. Per “A log MUST use one of the signature algorithms defined in Section 10.3.”, recommend instead saying that the acceptable signature algorithms are defined in “the IANA ‘CT Signature Algorithms’ registry described in Section 10.3.

-- Section 3.2.  Per the digestAlgorithm “MUST be one of the hash algorithm OIDs listed in Section 10.2”, recommend instead saying “MUST be one of the hash algorithms OIDs listed in the IANA ‘CT Hash  Algorithms’ registry described in Section 10.2”.

** Section 4.13.  Per the list of guidance on shutting down a log following “[t]o avoid that, the following actions are suggested:”, should normative language be used in making this recommendation.  Perhaps “To avoid that the following actions are RECOMMENDED:” or “To avoid that the following actions SHOULD be taken:”?

** Section 4.13.  Per “Make it known to clients and monitors that the log will be frozen.”, I recommend clarifying that this is via some out-of-band/out-of-scope mechanism not defined in the Section 5.x API.

** Section 5.1, 5.3, 5.4, 5.6.  Each of these sections helpfully lists the possible errors given the action, however, the corresponding HTTP response codes is not clear.

** Section 11.3 and 11.4.  Do the following references to gossip still make sense since ietf-trans-gossip is not proceeding?
-- (Section 11.3) “There are various ways this could be done, for example via gossip (see [I-D.ietf-trans-gossip]) …”

-- (Section 11.4)  “Clients that gossip STH …”, if the gossip reference is removed, using this verb doesn’t make sense.

** Editorial nits:

-- Per “Various data structures Section 1.2 are signed”:
o s/Section 1.2/in Section 1.2/
o practically, there are no data structures in Section 1.2, only a reference to a presentation language of available data structures.
2020-02-24
34 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-02-24
34 Roman Danyliw
[Ballot comment]
** Section 2.2 and 3.2.  Reference the IANA registry name, not just the document section

-- Section 2.2. Per “A log MUST use …
[Ballot comment]
** Section 2.2 and 3.2.  Reference the IANA registry name, not just the document section

-- Section 2.2. Per “A log MUST use one of the signature algorithms defined in Section 10.3.”, recommend instead saying that the acceptable signature algorithms are defined in “the IANA ‘CT Signature Algorithms’ registry described in Section 10.3.

-- Section 3.2.  Per the digestAlgorithm “MUST be one of the hash algorithm OIDs listed in Section 10.2”, recommend instead saying “MUST be one of the hash algorithms OIDs listed in the IANA ‘CT Hash  Algorithms’ registry described in Section 10.2”.

** Section 4.13.  Per the list of guidance on shutting down a log following “[t]o avoid that, the following actions are suggested:”, should normative language be used in making this recommendation.  Perhaps “To avoid that the following actions are RECOMMENDED:” or “To avoid that the following actions SHOULD be taken:”?

** Section 4.13.  Per “Make it known to clients and monitors that the log will be frozen.”, I recommend clarifying that this is via some out-of-band/out-of-scope mechanism not defined in the Section 5.x API.

** Section 5.1, 5.3, 5.4, 5.6.  Each of these sections helpfully lists the possible errors given the action, however, the corresponding HTTP response codes is not clear.

** Section 11.3 and 11.4.  Do the following references to gossip still make sense since ietf-trans-gossip is not proceeding?
-- (Section 11.3) “There are various ways this could be done, for example via gossip (see [I-D.ietf-trans-gossip]) …”

-- (Section 11.4)  “Clients that gossip STH …”, if the gossip reference is removed, using this verb doesn’t make sense.

** Editorial nits:

-- Per “Various data structures Section 1.2 are signed”:
o s/Section 1.2/in Section 1.2/
o practically, there are no data structures in Section 1.2, only a reference to a presentation language of available data structures.
2020-02-24
34 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2019-11-04
34 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-34.txt
2019-11-04
34 (System) New version approved
2019-11-04
34 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Rob Stradling , Ben Laurie , Eran Messeri , Emilia Kasper
2019-11-04
34 Rob Stradling Uploaded new revision
2019-09-27
33 Alissa Cooper [Ballot comment]
Thanks for addressing my DISCUSS.
2019-09-27
33 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2019-09-18
33 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-33.txt
2019-09-18
33 (System) New version approved
2019-09-18
33 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Rob Stradling , Ben Laurie , Eran Messeri , Emilia Kasper
2019-09-18
33 Rob Stradling Uploaded new revision
2019-08-26
32 Gunter Van de Velde Assignment of request for Telechat review by OPSDIR to Shwetha Bhandari was marked no-response
2019-08-19
32 Adam Roach
[Ballot comment]
Based on the discussion at IETF 105, and on the discussion on the
ART mailing list, it appears that there is at least …
[Ballot comment]
Based on the discussion at IETF 105, and on the discussion on the
ART mailing list, it appears that there is at least weak support for
allowing a narrow carve out to BCP 190 regarding provisioned
directory prefixes in URLs. I'm therefore clearing my DISCUSS in
advance of an anticipated update to BCP 190 to reflect this carve
out. The initial DISCUSS is retained below for historical purposes.

---------------------------------------------------------------------------

Thanks to everyone who worked on updating this protocol to reflect experience
gathered from the initial CT protocol. I have one blocking comment, and a small
number of editorial suggestions.

---------------------------------------------------------------------------

§5:

>  Clients are configured with a base URL for a log and construct URLs
>  for requests by appending suffixes to this base URL.  This structure
>  places some degree of restriction on how log operators can deploy
>  these services, as noted in [RFC7320].  However, operational
>  experience with version 1 of this protocol has not indicated that
>  these restrictions are a problem in practice.

The synthesis of URLs by a protocol in this fashion is prohibited by BCP 190:

  Scheme definitions define the presence, format, and semantics of a
  path component in URIs; all other specifications MUST NOT constrain,
  or define the structure or the semantics for any path component.

Unless the intention of this document is to update BCP 190 to change this
normative requirement, we can't publish it in its current form. Note that doing
so would require a change of venue, as updates to BCP 190 would not be covered
by the current TRANS charter.

Please see BCP 190 section 3 for alternate approaches. All three approaches
could be made to work for CT, and I would be happy to explain how to do so if
clarification is desired.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§1.3:

>  This document revises and obsoletes the experimental CT 1.0 [RFC6962]
>  protocol, drawing on insights gained from CT 1.0 deployments and on
>  feedback from the community.

Given that *this* document is also experimental, it seems a bit odd to call out
RFC 6962 as experimental.

---------------------------------------------------------------------------

§2.1.1:

>  We have established a registry of acceptable hash algorithms (see

The use of first person here is awkward. Consider: "This document
establishes..."

---------------------------------------------------------------------------

§10.2:

>  | 0x01 - | Unassigned |                        | Specification      |
>  | 0xDF  |            |                        | Required and      |
>  |        |            |                        | Expert Review      |

The policy being cited here is confusing. It is unclear whether the intention is
that values can be registered under both §4.5 and §4.6 of RFC 8126. I suspect
the intention here is the policy specified in RFC 8126 §4.6 only, without
reference to the policy in §4.5. If so, please use the formal name
"Specification Required."

---------------------------------------------------------------------------

§10.4:

>  | 0x0008 -    | Unassigned          | Specification Required and  |
>  | 0xDFFF      |                      | Expert Review                |

Same comment as above.

---------------------------------------------------------------------------

§10.5:

>  | 0x0000 -      | Unassigned | n/a | Specification Required and    |
>  | 0xDFFF        |            |    | Expert Review                  |

Same comment as above.
2019-08-19
32 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss
2019-06-20
32 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-06-20
32 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2019-06-20
32 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-32.txt
2019-06-20
32 (System) New version approved
2019-06-20
32 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Rob Stradling , Ben Laurie , Eran Messeri , Emilia Kasper
2019-06-20
32 Rob Stradling Uploaded new revision
2019-05-03
31 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Charlie Kaufman.
2019-03-27
31 Cindy Morgan Shepherding AD changed to Roman Danyliw
2019-03-14
31 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead
2019-03-14
31 Benjamin Kaduk
[Ballot discuss]
First off, thanks for this well-written document!  I intend to ballot Yes,
but there are a few issues that need to be resolved …
[Ballot discuss]
First off, thanks for this well-written document!  I intend to ballot Yes,
but there are a few issues that need to be resolved first.

Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and
inclusion proofs, respectively, with minimum array size of 1.  However,
Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the
possibility of zero-length proofs in degenerate cases, which the
aforementioned protocol description language forbids the conveyance of.
(Section 5.3 explicitly requires the use of an empty consistency proof.)
Do those minimum array sizes need to be (implicit) zero?
(If they do not, it seems that a minimum size of 32 would have the same
effect as that of one, since a NodeHash has minimum size 32.)

I support Alexey's Discuss regarding the registration of a
"urn:ietf:params:trans:error" URN namespace.

In Section 6:

  o  An Online Certificate Status Protocol (OCSP) [RFC6960] response
      extension (see Section 7.1.1), where the OCSP response is provided
      in the "CertificateStatus" message, provided that the TLS client
      included the "status_request" extension in the (extended)
      "ClientHello" (Section 8 of [RFC6066]).  [...]

This is not quite a TLS 1.3-compliant formulation -- TLS 1.3 does not
use the "CertificateStatus message", but rather uses the encoding of
that structure in a status_request extension in the CertificateEntry.

I also think we need greater clarity on the (non-)usage of CT for TLS
client certificates; see COMMENT

I also support Alissa's Discuss.
2019-03-14
31 Benjamin Kaduk
[Ballot comment]
Since the 64-bit timestamp format (milliseconds since epoch) is used in
multiple places, there is perhaps room for consolidation into a single
definition. …
[Ballot comment]
Since the 64-bit timestamp format (milliseconds since epoch) is used in
multiple places, there is perhaps room for consolidation into a single
definition.

Section 1

Do we need to provide a definition or reference for "public
certification authority"?

  It is necessary to treat each log as a trusted third party, because
  the log auditing mechanisms described in this document can be
  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.

Doesn't Section 11.3 discuss/link to some (partial) mechanisms to detect
misbehaving logs?  It's not clear that "anticipated" is quite the right
terminology to use here, then...

Section 2.1.1

  We have established a registry of acceptable hash algorithms (see
  Section 10.2).  [...]

It's not clear that we need to use the first person here.

Section 2.1.2

  When a client has a complete list of n input "entries" from "0" up to
  "tree_size - 1" and wishes to verify this list against a tree head
  "root_hash" returned by the log for the same "tree_size", the
  following algorithm may be used:

This seems to imply that n equals "tree_size"; do we want to normalize
to one name or the other?

  3.  If there is more than one element in the "stack", repeat the same
      merge procedure (Step 2.3 above) until only a single element
      remains.

nit: we just want the sub-sub-bullets of 2.3, and not the "repeat
merge_count times" part, since "merge_count" is not defined in this
scope?

Section 2.1.3.2

IMPORTANT: We need to define/specify what "leaf_index" is.

Section 2.1.4.1

  SUBPROOF(m, D[m], true) = {}

I don't remember seeing the "D[m]" notation defined; is this a typo for
something else?

  If m <= k, the right subtree entries D[k:n] only exist in the current
  tree.  We prove that the left subtree entries D[0:k] are consistent
  and add a commitment to D[k:n]:

  SUBPROOF(m, D_n, b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])

This 'b' is always 'false', right?

Section 2.2

  Various data structures Section 1.2 are signed.  A log MUST use one
  of the signature algorithms defined in Section 10.3.

A literal reading of this forbids any algorithms registered in the
future but not listed in this document; we probably want to say "listed
in the registry defined in".

Section 3.2

  o  "SignedData.digestAlgorithms" MUST only include the
      "SignerInfo.digestAlgorithm" OID value (see below).

nit: this could be misread as saying that there is a single
distinguished OID that has symbolic name "SingerInfo.digestAlgorithm";
we just want this one to match the one in the SignerInfo in the
SignedData.signerInfos, so maybe something about "same as" would avoid
the ambiguity.

Section 4.1

  Maximum Chain Length:  The longest chain submission the log is
      willing to accept, if the log imposes any limit.

Is the absence of a limit indicated by the absence of the parameter or a
distinguished sentinel value?

  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,
      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
      be provided in the form of a TransItem of type
      "signed_tree_head_v2".

Is this a lowercase "should" or a "SHOULD" or a "MUST"?  (How else would
it be provided?)

Do we need to say that the Final STH is not provided for a log that is
still accepting submissions?

Section 4.4

  Note that the ASN.1 length and the opaque vector length are identical
  in size (1 byte) and value, so the DER encoding of the OID can be
  reproduced simply by prepending an OBJECT IDENTIFIER tag (0x06) to
  the opaque vector length and contents.

nit: maybe "full DER encoding (including tag and length)" to contrast
with the previous paragraph?

  OIDs used to identify logs are limited such that the DER encoding of
  their value is less than or equal to 127 octets.

This seems to be a new requirement to this spec, in which case RFC 2119
language would be appropriate?

Section 4.7

  "sct_extensions" matches the SCT extensions of the corresponding SCT.

Is this supposed to imply the ordering and non-duplication requirements?
(If it does not, then recreating the log entry from the SCT for
signature validation could prove difficult.)

Sections 4.9, 4.10

Do we really want to allow for zero-length signatures in the structure
definition?

Section 4.11

  "consistency_path" is a vector of Merkle Tree nodes proving the
  consistency of two STHs.

A backreference to Section 2.1.4 might be helpful.

Section 4.12

  "inclusion_path" is a vector of Merkle Tree nodes proving the
  inclusion of the chosen certificate or precertificate.

A backreference to Section 2.1.3 might be helpful.

Section 5

Sometimes documents using base64 note explicitly that the padding
characters are (or aren't) included; 4648 is fairly clear that the
default is to include the padding characters, so there isn't necessarily
any change needed here.

Section 5.1

      chain:  An array of zero or more base64 encoded CA certificates.
        The first element is the certifier of the "submission"; the
        second certifies the first; etc.  The last element of "chain"
        (or, if "chain" is an empty array, the "submission") is
        certified by an accepted trust anchor.

I'm reading this to be a JSON array of strings; is that correct, and do
we want to be more explicit about it ("no" may well be fine)?

  If "submission" is an accepted trust anchor whose certifier is
  neither an accepted trust anchor nor the first element of "chain",
  then the log MUST return the "unknown anchor" error.  A log cannot
  generate an SCT for a submission if it does not have access to the
  issuer's public key.

Is this a descriptive "cannot" or a normative "MUST NOT"?

  If the returned "sct" is intended to be provided to TLS clients, then
  "sth" and "inclusion" (if returned) SHOULD also be provided to TLS
  clients (e.g., if "type" was 2 (for "precert_sct_v2") then all three
  "TransItem"s could be embedded in the certificate).

nit: the grammar is a bit weird around the second "then", maybe ", so
that" is easier to read?

Section 5.4

IMPORTANT: The input to get-proof-by-hash has a "tree_size" but the
processing discussion refers to a single "requested STH".  It does not
seem like the one uniquely determines the other, since there could be
multiple valid STHs for a given tree size (e.g., if there are no
submissions for more than the MMD).  Is the intent to supply an STH as
input, or is there otherwise need for further clarity here?

      inclusion:  A base64 encoded "TransItem" of type
        "inclusion_proof_v2" whose "inclusion_path" array of Merkle
        Tree nodes proves the inclusion of the chosen certificate in
        the selected STH.

We don't seem to define "chosen certificate"; do we just want to refer
to the (input) leaf hash?

Section 5.5

[similar note about tree_size/STH mapping]

Similarly, we talk about "index of requested hash", which is at least
unambiguous (IIUC), but we don't give a description of how the server
could/should determine.

[same comment about "chosen certificate"]

Section 5.6

        submitted_entry:  JSON object representing the inputs that were
            submitted to "submit-entry", with the addition of the trust

What does "representing" mean?  (In particular, does it use the same
JSON structure?)

Section 5.7

There is not a note here about how no signature is required on the
results, and in fact this data does seem to only be authenticated by the
surrounding TLS connection.  Perhaps it's worth making a note of that.

Section 6

  CT-using TLS servers MUST use at least one of the three mechanisms
  listed below to present one or more SCTs from one or more logs to
  each TLS client during full TLS handshakes, where each SCT

This MUST may need some caveats, given that the server can't use TLS
extensions not offered first by the client.  So maybe it has to be
"each CT-using TLS client".

Section 6.1

  o  One or more logs may not have become acceptable to all CT-using
      TLS clients.

nit: are we concerned about (new?) logs potentially becoming acceptable
to clients, or logs acceptable to clients becoming no longer accepted
(or both)?

Section 6.3

  In each "TransItemList" that is sent to a client during a TLS

nit: I don't know that "to a client" is needed; the server can just as
well use CT for client certificates, right?

  o  The TLS server MUST 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 MUST include the
      "transparency_info" extension with the "extension_data" set to
      this "TransItemList".

Am I allowed to send an empty "transparency_info" extension if the
TransItemList is empty?

  TLS servers MUST only include this extension in the following
  messages:

  o  the ServerHello message (for TLS 1.2 or earlier).

  o  the Certificate or CertificateRequest message (for TLS 1.3).

Servers sending it in CR implies that clients can send it in Certificate
(heh, the normal "CT" abbreviation is not really usable in this
context), but we don't explicitly say that.

Section 10.3

I'm confused by this registry.  Is the SignatureScheme value required to
come from/match the TLS SignatureScheme registry?  Is anything going to
key off that value or otherwise use the value in a protocol data
structure?  (Why are there two entries for 0x0403?)

Section 10.5

  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
  has an encoded length of 4 octets.

The table says "Unassigned"; which is it?

Section 11.1

This seems to be making some unstated assumptions, including perhaps
that someone has actually submitted the misissued certificate in
question to a log (in order to support the claim that the maximum time
it can be used without audit is twice the MMD).

Section 11.3

We may want to note the potential privacy concerns relating to gossip
and similar mechanisms, at least in passing.  I do see Section 11.4,
though there's not a terribly tight linkage in the text, and 11.4 may
not have comprehensive coverage of all privacy considerations.

Section 13.2

I think that RFCs 6234 and 6979 may need to be normative, since they're
needed for the signature/hash algorithms that are specified for use.
2019-03-14
31 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-03-14
31 Mirja Kühlewind
[Ballot discuss]
There was a presentation at maprg IETF 103 about the question if CT helps attackers to find new domains. I think this risk …
[Ballot discuss]
There was a presentation at maprg IETF 103 about the question if CT helps attackers to find new domains. I think this risk should at least be mentioned in the security considerations section.
2019-03-14
31 Mirja Kühlewind
[Ballot comment]
1) I found section 2 a bit hard to follow. Would it maybe be possible to provide more textual explanation of the algorithms …
[Ballot comment]
1) I found section 2 a bit hard to follow. Would it maybe be possible to provide more textual explanation of the algorithms instead of just describing the steps of the algorithms? Also I was wondering how much much these algorithms are actually „part“ of the protocol spec…? Are could these be rather seen as example algorithms? Maybe that could be further clarified

2) Please expand STH on first occurrence (in sec 4.1)

3) Sec 4.4: „A log's operator MUST either allocate the OID
    themselves or request an OID from the Log ID Registry (see
    Section 10.6.1).“
Isn't there an obligation to register?

4) sec 4.8: „If an
  implementation sees an extension that it does not understand, it
  SHOULD ignore that extension.“
Maybe it’s just me because I may have missed some context but does „ignore“ mean here that it should log it or not?

5) sec 5: „MAY retry the same
  request without modification at a later date.“
Would it be possible to provide a recommendation how long the client should wait?

6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per
  "get-entries" request.“
Should this be added to sec 4.1?

7) sec 10.3: Couldn’t you use the TLS  SignatureScheme Registry directly (instead of forming an own registry)?

8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate for the VersionedTransTypes registry?

9) sec 10.6.1:I guess  the registration policy is FCFS? RFC 8126 recommend to always (clearly) name the registry.

And finally one higher level question mainly out of curiosity: was it considered to e.g. use json for all data structures? Is there a performance reason to not do that or wasn’t that even discussed?
2019-03-14
31 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Record
2019-03-14
31 Mirja Kühlewind
[Ballot comment]
1) I found section 2 a bit hard to follow. Maybe it would be possible to provide more textual explanation of the algorithms …
[Ballot comment]
1) I found section 2 a bit hard to follow. Maybe it would be possible to provide more textual explanation of the algorithms instead of just describing the steps of the algorithms? Also I was wondering how much much these algorithms are actually „part“ of the protocol spec…? Are could these be rather seen as example algorithms?

2) Expand STH on first occurrence (sec 4.1)

3) Sec 4.4: „A log's operator MUST either allocate the OID
    themselves or request an OID from the Log ID Registry (see
    Section 10.6.1).“
Is there obligation to register?

4) sec 4.8: „If an
  implementation sees an extension that it does not understand, it
  SHOULD ignore that extension.“
Maybe it’s just me because I may have missed some context but does „ignore“ mean here that it should log it or not?

5) sec 5: „MAY retry the same
  request without modification at a later date.“
Would it be possible to provide a recommendation hoe long the client should wait?

6) sec 5.6: „Logs MAY restrict the number of entries that can be retrieved per
  "get-entries" request.“
Should this be added to sec 4.1?

7) sec 10.3: couldn’t you use the TLS  SignatureScheme Registry directly?

8) sec 10.4: i Wonder if an RFC-required policy wouldn’t be more appropriate for the VersionedTransTypes registry?

9) sec 10.6.1: I guess the registration policy is FCFS?


One higher level question mainly out of curiosity: was it considered to e.g, use Json for all data structures? Is there a performance reason to not do that or wasn’t that even discussed?
2019-03-14
31 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-03-14
31 Alexey Melnikov
[Ballot discuss]
I think this is an important document and I am looking forward to seeing it as a Proposed Standard in the future.
However, …
[Ballot discuss]
I think this is an important document and I am looking forward to seeing it as a Proposed Standard in the future.
However, it has a good number of editorial issues that make the document hard to read and implement.

5.  Log Client Messages

  type:  A URN reference identifying the problem.  To facilitate
      automated response to errors, this document defines a set of
      standard tokens for use in the "type" field, within the URN
      namespace of: "urn:ietf:params:trans:error:".

I think you need to register this in

Also, can you clarify whether error need an IANA registry?
2019-03-14
31 Alexey Melnikov
[Ballot comment]
General:

STH is only defined in the table of Content! Please define it early in the document (before the "Changes since v1" section), …
[Ballot comment]
General:

STH is only defined in the table of Content! Please define it early in the document (before the "Changes since v1" section), so that it would be easier to understand for somebody who is new to this.

"LSB" is never defined.

It might be just me, but I don't know what is the meaning of the ":" operation for an expression "A : B" outside of an index.

DER encoding needs a Normative Reference.

TLS 1.2 needs at least an Informative Reference.



In 4.1: URL needs a reference.

In 4.1:
What is the typical resolution for Maximum Merge Delay? 10 seconds? 20 minutes?

In 4.3:

  This prevents the CA from avoiding blame by logging a partial or empty chain.

"prevents the CA from avoiding blame" reads very awkwardly, maybe rephrase?

4.4.  Log ID

  Each log is identified by an OID, which is one of the log's
  parameters (see Section 4.1) and which MUST NOT be used to identify
  any other log.  A log's operator MUST either allocate the OID
  themselves or request an OID from the Log ID Registry (see
  Section 10.6.1).  Various data structures include the DER encoding of
  this OID, excluding the ASN.1 tag and length bytes,

OID encoding in DER really needs a normative reference.

5.  Log Client Messages

  Messages are sent as HTTPS GET or POST requests.  Parameters for
  POSTs and all responses are encoded as JavaScript Object Notation
  (JSON) objects [RFC8259].  Parameters for GETs are encoded as order-
  independent key/value URL parameters, using the "application/x-www-
  form-urlencoded" format described in the "HTML 4.01 Specification"
  [HTML401].  Binary data is base64 encoded [RFC4648] as specified in

Please clarify whether you are using Section 4 or Section 5 version of base64.
Also, are the trailing "=" expected in values?

  the individual messages.


  Note that JSON objects and URL parameters may contain fields not
  specified here.  These extra fields SHOULD be ignored.

Why not "MUST be ignored"? This is important for forward compatibility.



8.1.6.  Evaluating compliance

  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

Maybe "evaluate" above is a wrong verb, I think "enforce" would be better here.

  "transparency_info" and "status_request" TLS extensions in the
  ClientHello.


8.2.  Monitor

  1.  Fetch the current STH (Section 5.2).  Repeat until the STH
      changes.

I think the above text should recommend how often the client should poll for this.
2019-03-14
31 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov
2019-03-14
31 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2019-03-13
31 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2019-03-13
31 Jana Iyengar Request for Last Call review by TSVART Completed: Ready. Reviewer: Jana Iyengar. Sent review to list.
2019-03-13
31 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2019-03-13
31 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-trans-rfc6962-bis-31. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-trans-rfc6962-bis-31. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about some of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the existing entry for value 52:

Value: 52
Name: transparency_info
TLS 1.3:
Recommended: Y
Reference: [ RFC-to-be ]

will have its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the CT Hash Algorithms registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA understands that there is a single, initial registration in the new registry and that the registration policy for the registry (RFC 8126) is as follows:

+--------+------------+------------------------+--------------------+
| Value | Hash | OID | Reference / |
| | Algorithm | | Assignment Policy |
+--------+------------+------------------------+--------------------+
| 0x00 | SHA-256 | 2.16.840.1.101.3.4.2.1 | [RFC6234] |
| | | | |
| 0x01 - | Unassigned | | Specification |
| 0xDF | | | Required and |
| | | | Expert Review |
| | | | |
| 0xE0 - | Reserved | | Experimental Use |
| 0xEF | | | |
| | | | |
| 0xF0 - | Reserved | | Private Use |
| 0xFF | | | |
+--------+------------+------------------------+--------------------+

Third, a new registry is to be created called the CT Signature Algorithms registry.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA understands that there are three initial registrations in the new registry and that the registration policy for the registry (RFC 8126) is as follows:

+--------------------------------+--------------------+-------------+
| SignatureScheme Value | Signature | Reference / |
| | Algorithm | Assignment |
| | | Policy |
+--------------------------------+--------------------+-------------+
| ecdsa_secp256r1_sha256(0x0403) | ECDSA (NIST P-256) | [FIPS186-4] |
| | with SHA-256 | |
| | | |
| ecdsa_secp256r1_sha256(0x0403) | Deterministic | [RFC6979] |
| | ECDSA (NIST P-256) | |
| | with HMAC-SHA256 | |
| | | |
| ed25519(0x0807) | Ed25519 (PureEdDSA | [RFC8032] |
| | with the | |
| | edwards25519 | |
| | curve) | |
| | | |
| private_use(0xFE00..0xFFFF) | Reserved | Private Use |
+--------------------------------+--------------------+-------------+

IANA Question --> except for the private use SignatureScheme Values, what is the registration policy for the remainder of the registry (RFC 8126)?

Fourth, a new registry is to be created called the CT VersionedTransTypes registry.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA understands that there are seven initial registrations in the new registry and that the registration policy for the registry (RFC 8126) is as follows:

+-------------+----------------------+------------------------------+
| Value | Type and Version | Reference / Assignment |
| | | Policy |
+-------------+----------------------+------------------------------+
| 0x0000 | Reserved | [RFC6962] (*) |
| | | |
| 0x0001 | x509_entry_v2 | [ RFC-to-be ] |
| | | |
| 0x0002 | precert_entry_v2 | [ RFC-to-be ] |
| | | |
| 0x0003 | x509_sct_v2 | [ RFC-to-be ] |
| | | |
| 0x0004 | precert_sct_v2 | [ RFC-to-be ] |
| | | |
| 0x0005 | signed_tree_head_v2 | [ RFC-to-be ] |
| | | |
| 0x0006 | consistency_proof_v2 | [ RFC-to-be ] |
| | | |
| 0x0007 | inclusion_proof_v2 | [ RFC-to-be ] |
| | | |
| 0x0008 - | Unassigned | Specification Required and |
| 0xDFFF | | Expert Review |
| | | |
| 0xE000 - | Reserved | Experimental Use |
| 0xEFFF | | |
| | | |
| 0xF000 - | Reserved | Private Use |
| 0xFFFF | | |
+-------------+----------------------+------------------------------+

Fifth, a new registry is to be created called the CT Log Artifact Extensions registry.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

IANA understands that there are no initial registrations in the new registry and that the registration policy for the registry (RFC 8126) is as follows:

+---------------+------------+-----+--------------------------------+
| ExtensionType | Status | Use | Reference / Assignment Policy |
+---------------+------------+-----+--------------------------------+
| 0x0000 - | Unassigned | n/a | Specification Required and |
| 0xDFFF | | | Expert Review |
| | | | |
| 0xE000 - | Reserved | n/a | Experimental Use |
| 0xEFFF | | | |
| | | | |
| 0xF000 - | Reserved | n/a | Private Use |
| 0xFFFF | | | |
+---------------+------------+-----+--------------------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-03-13
31 Alissa Cooper
[Ballot discuss]
Glad to see this revision of the protocol. My comments and questions should be easy to address.

= Section 10.2, 10.4, 10.5 = …
[Ballot discuss]
Glad to see this revision of the protocol. My comments and questions should be easy to address.

= Section 10.2, 10.4, 10.5 =

A Specification Required registry policy implies expert review. So a registry policy of "Specification Required and Expert Review" is duplicative; it should just say "Specification Required." I know this seems trivial but there has been so much confusion about this through the years that it is important to be precise.

= Section 10.3 =

This section needs to state what the registry policy is for the code points not already registered (presumably Expert Review given 10.3.1, but it needs to be explicit).

= Section 10.6.1 =

Using the term "Parameters Required" as a capitalized term is confusing. FCFS registries by definition can require additional information to be provided in order to get something registered. For avoidance of confusion I think the assignment policy should be listed as First Come First Served and the requirement that parameters be included in the application can use a normative MUST in the last paragraph if there is concern that the parameters won't be supplied.

However, I also wonder what will be done with the parameters that are supplied. Is IANA expected to just maintain them privately, or to publish them?

What is expected to appear in the 'Log' column in the registry?
2019-03-13
31 Alissa Cooper [Ballot comment]
In Section 1.1, please use the RFC 8174 boilerplate in lieu of the RFC 2119 boilerplate.
2019-03-13
31 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2019-03-12
31 Adam Roach
[Ballot discuss]
Thanks to everyone who worked on updating this protocol to reflect experience
gathered from the initial CT protocol. I have one blocking comment, …
[Ballot discuss]
Thanks to everyone who worked on updating this protocol to reflect experience
gathered from the initial CT protocol. I have one blocking comment, and a small
number of editorial suggestions.

---------------------------------------------------------------------------

§5:

>  Clients are configured with a base URL for a log and construct URLs
>  for requests by appending suffixes to this base URL.  This structure
>  places some degree of restriction on how log operators can deploy
>  these services, as noted in [RFC7320].  However, operational
>  experience with version 1 of this protocol has not indicated that
>  these restrictions are a problem in practice.

The synthesis of URLs by a protocol in this fashion is prohibited by BCP 190:

  Scheme definitions define the presence, format, and semantics of a
  path component in URIs; all other specifications MUST NOT constrain,
  or define the structure or the semantics for any path component.

Unless the intention of this document is to update BCP 190 to change this
normative requirement, we can't publish it in its current form. Note that doing
so would require a change of venue, as updates to BCP 190 would not be covered
by the current TRANS charter.

Please see BCP 190 section 3 for alternate approaches. All three approaches
could be made to work for CT, and I would be happy to explain how to do so if
clarification is desired.
2019-03-12
31 Adam Roach
[Ballot comment]
§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  …
[Ballot comment]
§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§1.3:

>  This document revises and obsoletes the experimental CT 1.0 [RFC6962]
>  protocol, drawing on insights gained from CT 1.0 deployments and on
>  feedback from the community.

Given that *this* document is also experimental, it seems a bit odd to call out
RFC 6962 as experimental.

---------------------------------------------------------------------------

§2.1.1:

>  We have established a registry of acceptable hash algorithms (see

The use of first person here is awkward. Consider: "This document
establishes..."

---------------------------------------------------------------------------

§10.2:

>  | 0x01 - | Unassigned |                        | Specification      |
>  | 0xDF  |            |                        | Required and      |
>  |        |            |                        | Expert Review      |

The policy being cited here is confusing. It is unclear whether the intention is
that values can be registered under both §4.5 and §4.6 of RFC 8126. I suspect
the intention here is the policy specified in RFC 8126 §4.6 only, without
reference to the policy in §4.5. If so, please use the formal name
"Specification Required."

---------------------------------------------------------------------------

§10.4:

>  | 0x0008 -    | Unassigned          | Specification Required and  |
>  | 0xDFFF      |                      | Expert Review                |

Same comment as above.

---------------------------------------------------------------------------

§10.5:

>  | 0x0000 -      | Unassigned | n/a | Specification Required and    |
>  | 0xDFFF        |            |    | Expert Review                  |

Same comment as above.
2019-03-12
31 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2019-03-12
31 Eric Rescorla Ballot has been issued
2019-03-12
31 Eric Rescorla [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla
2019-03-12
31 Eric Rescorla Created "Approve" ballot
2019-03-12
31 Eric Rescorla Ballot writeup was changed
2019-03-07
31 Tero Kivinen Request for Telechat review by SECDIR is assigned to Charlie Kaufman
2019-03-07
31 Tero Kivinen Request for Telechat review by SECDIR is assigned to Charlie Kaufman
2019-03-04
31 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Shwetha Bhandari
2019-03-04
31 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Shwetha Bhandari
2019-03-01
31 Joel Halpern Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2019-03-01
31 Amy Vezza Placed on agenda for telechat - 2019-03-14
2019-03-01
31 Magnus Westerlund Request for Last Call review by TSVART is assigned to Jana Iyengar
2019-03-01
31 Magnus Westerlund Request for Last Call review by TSVART is assigned to Jana Iyengar
2019-02-28
31 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2019-02-28
31 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2019-02-28
31 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-02-28
31 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-03-14):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, trans@ietf.org, draft-ietf-trans-rfc6962-bis@ietf.org, trans-chairs@ietf.org, Paul …
The following Last Call announcement was sent out (ends 2019-03-14):

From: The IESG
To: IETF-Announce
CC: ekr@rtfm.com, trans@ietf.org, draft-ietf-trans-rfc6962-bis@ietf.org, trans-chairs@ietf.org, Paul Wouters , paul@nohats.ca
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Certificate Transparency Version 2.0) to Experimental RFC


The IESG has received a request from the Public Notary Transparency WG
(trans) to consider the following document: - 'Certificate Transparency
Version 2.0'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-03-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes version 2.0 of the Certificate Transparency
  (CT) protocol for publicly logging the existence of Transport Layer
  Security (TLS) server certificates as they are issued or observed, in
  a manner that allows anyone to audit certification authority (CA)
  activity and notice the issuance of suspect certificates as well as
  to audit the certificate logs themselves.  The intent is that
  eventually clients would refuse to honor certificates that do not
  appear in a log, effectively forcing CAs to add all issued
  certificates to the logs.

  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
  submissions and queries that are defined in this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-02-28
31 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-02-28
31 Cindy Morgan Last call announcement was generated
2019-02-27
31 Eric Rescorla Last call was requested
2019-02-27
31 Eric Rescorla Last call announcement was generated
2019-02-27
31 Eric Rescorla Ballot approval text was generated
2019-02-27
31 Eric Rescorla Ballot writeup was generated
2019-02-27
31 Eric Rescorla IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-02-25
31 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-25
31 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-31.txt
2019-02-25
31 (System) New version approved
2019-02-25
31 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Rob Stradling , Ben Laurie , Eran Messeri , Emilia Kasper
2019-02-25
31 Rob Stradling Uploaded new revision
2018-12-24
30 Eric Rescorla https://mozphab-ietf.devsvcdev.mozaws.net/D4182
2018-12-24
30 Eric Rescorla IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2018-11-06
30 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-30.txt
2018-11-06
30 (System) New version approved
2018-11-06
30 (System) Request for posting confirmation emailed to previous authors: trans-chairs@ietf.org, Adam Langley , Eran Messeri , Rob Stradling , Ben Laurie , Emilia Kasper
2018-11-06
30 Rob Stradling Uploaded new revision
2018-10-22
29 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-29.txt
2018-10-22
29 (System) New version approved
2018-10-22
29 (System) Request for posting confirmation emailed to previous authors: trans-chairs@ietf.org, Rob Stradling , Adam Langley , Eran Messeri , Ben Laurie , Emilia Kasper
2018-10-22
29 Rob Stradling Uploaded new revision
2018-08-06
28 Melinda Shore
Since the changes between 6962 and 6962bis are not trivial, and we have no implementations yet that validate that there are no implementation issues, with …
Since the changes between 6962 and 6962bis are not trivial, and we have no implementations yet that validate that there are no implementation issues, with the agreement of the working group we are changing the document status to Experimental.
2018-08-06
28 Melinda Shore Intended Status changed to Experimental from Proposed Standard
2018-03-05
28 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-03-05
28 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-28.txt
2018-03-05
28 (System) New version approved
2018-03-05
28 (System) Request for posting confirmation emailed to previous authors: trans-chairs@ietf.org, Rob Stradling , Eran Messeri , Ben Laurie , Emilia Kasper , Adam Langley
2018-03-05
28 Rob Stradling Uploaded new revision
2017-11-12
27 Eric Rescorla IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2017-10-30
27 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-30
27 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-27.txt
2017-10-30
27 (System) New version approved
2017-10-30
27 (System) Request for posting confirmation emailed to previous authors: Adam Langley , Rob Stradling , Ben Laurie , Eran Messeri , Emilia Kasper
2017-10-30
27 Rob Stradling Uploaded new revision
2017-09-03
26 Eric Rescorla IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-08-26
26 Eric Rescorla IESG state changed to AD Evaluation from Publication Requested
2017-08-04
26 Amy Vezza
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposed Standard

Why is this the proper type of RFC?

  This document is the result of operational experience with running the
  Experimental RFC 6962. This bis document is therefore intended as
  Proposed Standard.

Is this type of RFC indicated in the title page header?

  Yes, the document title page indicates being 'standard track'.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a protocol for publicly logging the existence
  of Transport Layer Security (TLS) server certificates as they are
  issued or observed, in a manner that allows anyone to audit
  certification authority (CA) activity and notice the issuance of
  suspect certificates as well as to audit the certificate logs
  themselves.  The intent is that eventually clients would refuse to
  honor certificates that do not appear in a log, effectively forcing
  CAs to add all issued certificates to the logs.

  This document is a bis document for the Experimental RFC 6962.
  The major changes between that document and this document are
  listed in Section 1.3 of the draft, and are:

  o  Hash and signature algorithm agility: permitted algorithms are now
      specified in IANA registries.

  o  Precertificate format: precertificates are now CMS objects rather
      than X.509 certificates, which avoids violating the certificate
      serial number uniqueness requirement in Section 4.1.2.2 of
      [RFC5280].

  o  Removed precertificate signing certificates and the precertificate
      poison extension: the change of precertificate format means that
      these are no longer needed.

  o  Logs IDs: each log is now identified by an OID rather than by the
      hash of its public key.  OID allocations are managed by an IANA
      registry.

  o  "TransItem" structure: this new data structure is used to
      encapsulate most types of CT data.  A "TransItemList", consisting
      of one or more "TransItem" structures, can be used anywhere that
      "SignedCertificateTimestampList" was used in [RFC6962].

  o  Merkle tree leaves: the "MerkleTreeLeaf" structure has been
      replaced by the "TransItem" structure, which eases extensibility
      and simplifies the leaf structure by removing one layer of
      abstraction.

  o  Unified leaf format: the structure for both certificate and
      precertificate entries now includes only the TBSCertificate
      (whereas certificate entries in [RFC6962] included the entire
      certificate).

  o  SCT extensions: these are now typed and managed by an IANA
      registry.

  o  STH extensions: STHs can now contain extensions, which are typed
      and managed by an IANA registry.

  o  API outputs: complete "TransItem" structures are returned, rather
      than the constituent parts of each structure.

  o  get-all-by-hash: new client API for obtaining an inclusion proof
      and the corresponding consistency proof at the same time.

  o  Presenting SCTs with proofs: TLS servers may present SCTs together
      with the corresponding inclusion proofs using any of the
      mechanisms that [RFC6962] defined for presenting SCTs only.
      (Presenting SCTs only is still supported).

  o  CT TLS extension: the "signed_certificate_timestamp" TLS extension
      has been replaced by the "transparency_info" TLS extension.

  o  Other TLS extensions: "status_request_v2" may be used (in the same
      manner as "status_request"); "cached_info" may be used to avoid
      sending the same complete SCTs and inclusion proofs to the same
      TLS clients multiple times.

  o  TLS Feature extension: this certificate extension may be used by a
      CA to indicate that CT compliance is required.

  o  Verification algorithms: added detailed algorithms for verifying
      inclusion proofs, for verifying consistency between two STHs, and
      for verifying a root hash given a complete list of the relevant
      leaf input entries.

  o  Extensive clarifications and editorial work.

  Backwards compatibility:

  Logs can either conform to RFC6962 (???v1???) or RFC6962??bis (???v2???),
  not both, as the format of the data logged is different. As v1 and
  v2 SCTs are delivered using different X.509, TLS and OCSP extensions,
  they can mostly co??exist and TLS clients can support both
  simultaneously. One provision has been made for embedded v1 and
  v2 SCTs by requiring v2 clients to  remove v1 SCTs from the
  TBSCertificate portion of the certificate before validating v2 SCTs
  over it (to allow v2 SCTs to be embedded before v1 SCTs are issued).

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  During the document development, some content was split of
  into other documents for clarity. Topics split of covers a threat
  model document, a log monitoring API, and a client/gossip API.

  Name redaction has been considered and was split of in another
  document as well. The WG is still discussing whether or not to
  allow name redaction as well as the redaction method that would
  be used.

  Currently, there is still an open issue between some major vendors
  about whether this document is good enough as a basis to develop
  further preventative client actions on. The WG Chairs are organising
  a meeting with these parties to determine if the document should be
  stalled or proceed.

Document Quality

Are there existing implementations of the protocol?

  There are various implementations in different state of completion
  which have lead to updates to the document.

  Various well-known crypto libraries have started implementation.

Have a significant number of vendors indicated their plan to implement
the specification?

  Yes. Various well-known crypto libraries have started implementation.
  A few new independent parties have also implemented or mostly
  implemented this document's specification - both proprietary as well
  as opensource implementations.

Are there any reviewers that merit special mention as having done
a thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

  Stephen Kent gave many in-depth reviews of many versions of the
  document, all of which were dealt with by the Working Group. Daniel
  Kahn Gillmor came up with a new attack, which is now described in one
  of the documents that was split off from this one. During WGLC several
  implementers came forward explaining that one MUST keyword (in Section
  5.1) had to change to SHOULD to allow for log behaviour that was deemed
  necessary for actual deployments, which was agreed on by the Working
  Group.

If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  There was no such review.

Personnel

Who is the Document Shepherd?

  Paul Wouters

Who is the Responsible Area Director?

  Eric Rescorla

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I read all the threads about this document on the mailing list to be
  sure that the issues raised were address or at least discussed in the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been seen and is (being) implemented widely in
  various different parts of the industry and opensource communities.
  There is significant interest and traction to roll-out implementations
  of this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No. The important groups that needed to read and comment on this
  document were the PKIX and TLS communities and these groups were
  very well represented.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  There are no concerns other then the currently scheduled meeting
  between browser parties to determine whether or not the document
  provides a good basis for further feature development. We do
  recommend the IESG postpones the IETF LC until after this meeting
  has taken place.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  [PAUL: Do I need to click on the IPR button in the datatracker before
  submitting this? ]

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Not that the WG chairs are aware of.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  It represents strong consensus within the WG, which includes many
  relevant affected players in the industry (CA vendors, browser
  vendors, TLS implementors, crypto library authors). The only item
  which did not have strong consensus was name redaction, which has
  therefore been moved to its own document for possible WG adoption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    Appeals were threatened in the past, but have been resolved.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool shows a few warnings:

  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

These are false positives

  -- The draft header indicates that this document obsoletes RFC6962, but the
    abstract doesn't seem to mention this, which it should.

It does mention this is "version 2.0 of CT", but I will request the authors
to more explicitely mention this in the abstract.

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 29, 2016) is 31 days in the past.  Is this
    intentional?

Artifact of year rollover.

  -- Looks like a reference, but probably isn't: '1' on line 363

  -- Looks like a reference, but probably isn't: '7' on line 498

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML401'

  ** Downref: Normative reference to an Informational RFC: RFC 8017

The listing is part of citing an exiting Signature Algorithm.

  == Outdated reference: A later version (-04) exists of
    draft-ietf-trans-gossip-03

This can be updated if/when the document is at the RFC Editor or if it
goes through another round of LC.

  -- Obsolete informational reference (is this intentional?): RFC 4634
    (Obsoleted by RFC 6234)

This listing is part of a table listing the RFC responsible for the table
entry. It is using the non-obsolete reference on purpose.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.


  There is one. RFC 6979 "Deterministic Usage of the Digital Signature
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Yes. It obsoleted RFC 6962.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  It has been reviews and complies with the requirements of RFC-5226

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The following new registries are requested to be created:

  Section  Registry Name

  10.3    CT Hash Algorithms
  10.4    CT Signature Algorithms
  10.5    CT VersionedTransTypes
  10.6    CT Extension Types for SCT
  10.7    CT Extension Types for STH
  10.8.1  CT Log ID Registry"

All of these Registries are defined to require Expert Review. An Expert
should be a person that has intimate knowledge of TLS, PKIX and cryptography.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The idnits checker was used on the document.

2017-07-29
26 Melinda Shore
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Proposed Standard

Why is this the proper type of RFC?

  This document is the result of operational experience with running the
  Experimental RFC 6962. This bis document is therefore intended as
  Proposed Standard.

Is this type of RFC indicated in the title page header?

  Yes, the document title page indicates being 'standard track'.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes a protocol for publicly logging the existence
  of Transport Layer Security (TLS) server certificates as they are
  issued or observed, in a manner that allows anyone to audit
  certification authority (CA) activity and notice the issuance of
  suspect certificates as well as to audit the certificate logs
  themselves.  The intent is that eventually clients would refuse to
  honor certificates that do not appear in a log, effectively forcing
  CAs to add all issued certificates to the logs.

  This document is a bis document for the Experimental RFC 6962.
  The major changes between that document and this document are
  listed in Section 1.3 of the draft, and are:

  o  Hash and signature algorithm agility: permitted algorithms are now
      specified in IANA registries.

  o  Precertificate format: precertificates are now CMS objects rather
      than X.509 certificates, which avoids violating the certificate
      serial number uniqueness requirement in Section 4.1.2.2 of
      [RFC5280].

  o  Removed precertificate signing certificates and the precertificate
      poison extension: the change of precertificate format means that
      these are no longer needed.

  o  Logs IDs: each log is now identified by an OID rather than by the
      hash of its public key.  OID allocations are managed by an IANA
      registry.

  o  "TransItem" structure: this new data structure is used to
      encapsulate most types of CT data.  A "TransItemList", consisting
      of one or more "TransItem" structures, can be used anywhere that
      "SignedCertificateTimestampList" was used in [RFC6962].

  o  Merkle tree leaves: the "MerkleTreeLeaf" structure has been
      replaced by the "TransItem" structure, which eases extensibility
      and simplifies the leaf structure by removing one layer of
      abstraction.

  o  Unified leaf format: the structure for both certificate and
      precertificate entries now includes only the TBSCertificate
      (whereas certificate entries in [RFC6962] included the entire
      certificate).

  o  SCT extensions: these are now typed and managed by an IANA
      registry.

  o  STH extensions: STHs can now contain extensions, which are typed
      and managed by an IANA registry.

  o  API outputs: complete "TransItem" structures are returned, rather
      than the constituent parts of each structure.

  o  get-all-by-hash: new client API for obtaining an inclusion proof
      and the corresponding consistency proof at the same time.

  o  Presenting SCTs with proofs: TLS servers may present SCTs together
      with the corresponding inclusion proofs using any of the
      mechanisms that [RFC6962] defined for presenting SCTs only.
      (Presenting SCTs only is still supported).

  o  CT TLS extension: the "signed_certificate_timestamp" TLS extension
      has been replaced by the "transparency_info" TLS extension.

  o  Other TLS extensions: "status_request_v2" may be used (in the same
      manner as "status_request"); "cached_info" may be used to avoid
      sending the same complete SCTs and inclusion proofs to the same
      TLS clients multiple times.

  o  TLS Feature extension: this certificate extension may be used by a
      CA to indicate that CT compliance is required.

  o  Verification algorithms: added detailed algorithms for verifying
      inclusion proofs, for verifying consistency between two STHs, and
      for verifying a root hash given a complete list of the relevant
      leaf input entries.

  o  Extensive clarifications and editorial work.

  Backwards compatibility:

  Logs can either conform to RFC6962 (???v1???) or RFC6962??bis (???v2???),
  not both, as the format of the data logged is different. As v1 and
  v2 SCTs are delivered using different X.509, TLS and OCSP extensions,
  they can mostly co??exist and TLS clients can support both
  simultaneously. One provision has been made for embedded v1 and
  v2 SCTs by requiring v2 clients to  remove v1 SCTs from the
  TBSCertificate portion of the certificate before validating v2 SCTs
  over it (to allow v2 SCTs to be embedded before v1 SCTs are issued).

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  During the document development, some content was split of
  into other documents for clarity. Topics split of covers a threat
  model document, a log monitoring API, and a client/gossip API.

  Name redaction has been considered and was split of in another
  document as well. The WG is still discussing whether or not to
  allow name redaction as well as the redaction method that would
  be used.

  Currently, there is still an open issue between some major vendors
  about whether this document is good enough as a basis to develop
  further preventative client actions on. The WG Chairs are organising
  a meeting with these parties to determine if the document should be
  stalled or proceed.

Document Quality

Are there existing implementations of the protocol?

  There are various implementations in different state of completion
  which have lead to updates to the document.

  Various well-known crypto libraries have started implementation.

Have a significant number of vendors indicated their plan to implement
the specification?

  Yes. Various well-known crypto libraries have started implementation.
  A few new independent parties have also implemented or mostly
  implemented this document's specification - both proprietary as well
  as opensource implementations.

Are there any reviewers that merit special mention as having done
a thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

  Stephen Kent gave many in-depth reviews of many versions of the
  document, all of which were dealt with by the Working Group. Daniel
  Kahn Gillmor came up with a new attack, which is now described in one
  of the documents that was split off from this one. During WGLC several
  implementers came forward explaining that one MUST keyword (in Section
  5.1) had to change to SHOULD to allow for log behaviour that was deemed
  necessary for actual deployments, which was agreed on by the Working
  Group.

If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  There was no such review.

Personnel

Who is the Document Shepherd?

  Paul Wouters

Who is the Responsible Area Director?

  Stephen Farrell

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I read all the threads about this document on the mailing list to be
  sure that the issues raised were address or at least discussed in the WG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document has been seen and is (being) implemented widely in
  various different parts of the industry and opensource communities.
  There is significant interest and traction to roll-out implementations
  of this document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No. The important groups that needed to read and comment on this
  document were the PKIX and TLS communities and these groups were
  very well represented.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  There are no concerns other then the currently scheduled meeting
  between browser parties to determine whether or not the document
  provides a good basis for further feature development. We do
  recommend the IESG postpones the IETF LC until after this meeting
  has taken place.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  [PAUL: Do I need to click on the IPR button in the datatracker before
  submitting this? ]

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Not that the WG chairs are aware of.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  It represents strong consensus within the WG, which includes many
  relevant affected players in the industry (CA vendors, browser
  vendors, TLS implementors, crypto library authors). The only item
  which did not have strong consensus was name redaction, which has
  therefore been moved to its own document for possible WG adoption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    Appeals were threatened in the past, but have been resolved.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool shows a few warnings:

  == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

These are false positives

  -- The draft header indicates that this document obsoletes RFC6962, but the
    abstract doesn't seem to mention this, which it should.

It does mention this is "version 2.0 of CT", but I will request the authors
to more explicitely mention this in the abstract.

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 29, 2016) is 31 days in the past.  Is this
    intentional?

Artifact of year rollover.

  -- Looks like a reference, but probably isn't: '1' on line 363

  -- Looks like a reference, but probably isn't: '7' on line 498

  -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML401'

  ** Downref: Normative reference to an Informational RFC: RFC 8017

The listing is part of citing an exiting Signature Algorithm.

  == Outdated reference: A later version (-04) exists of
    draft-ietf-trans-gossip-03

This can be updated if/when the document is at the RFC Editor or if it
goes through another round of LC.

  -- Obsolete informational reference (is this intentional?): RFC 4634
    (Obsoleted by RFC 6234)

This listing is part of a table listing the RFC responsible for the table
entry. It is using the non-obsolete reference on purpose.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.


  There is one. RFC 6979 "Deterministic Usage of the Digital Signature
  Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Yes. It obsoleted RFC 6962.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  It has been reviews and complies with the requirements of RFC-5226

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The following new registries are requested to be created:

  Section  Registry Name

  10.3    CT Hash Algorithms
  10.4    CT Signature Algorithms
  10.5    CT VersionedTransTypes
  10.6    CT Extension Types for SCT
  10.7    CT Extension Types for STH
  10.8.1  CT Log ID Registry"

All of these Registries are defined to require Expert Review. An Expert
should be a person that has intimate knowledge of TLS, PKIX and cryptography.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The idnits checker was used on the document.

2017-07-29
26 Melinda Shore Responsible AD changed to Eric Rescorla
2017-07-29
26 Melinda Shore IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-07-29
26 Melinda Shore IESG state changed to Publication Requested
2017-07-29
26 Melinda Shore IESG process started in state Publication Requested
2017-07-29
26 Melinda Shore Intended Status changed to Proposed Standard from None
2017-07-29
26 Melinda Shore Changed consensus to Yes from Unknown
2017-07-28
26 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-26.txt
2017-07-28
26 (System) New version approved
2017-07-28
26 (System) Request for posting confirmation emailed to previous authors: Rob Stradling , Ben Laurie , Adam Langley , Emilia Kasper , Eran Messeri
2017-07-28
26 Rob Stradling Uploaded new revision
2017-07-20
25 Melinda Shore We need one more minor revision, in parallel with the write-up.
2017-07-20
25 Melinda Shore Tag Revised I-D Needed - Issue raised by WG set. Tag Awaiting External Review/Resolution of Issues Raised cleared.
2017-07-20
25 Melinda Shore IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2017-06-30
25 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-25.txt
2017-06-30
25 (System) New version approved
2017-06-30
25 (System) Request for posting confirmation emailed to previous authors: Rob Stradling , Ben Laurie , Adam Langley , Emilia Kasper , Eran Messeri
2017-06-30
25 Rob Stradling Uploaded new revision
2017-01-29
24 Paul Wouters
At the last moment of the WGLC, an important vendor voiced a concern about the extendability of the document fur their purpose. A conference call …
At the last moment of the WGLC, an important vendor voiced a concern about the extendability of the document fur their purpose. A conference call is scheduled to see if this can be resolved and whether changes to the document are needed or not. This is scheduled to happen within 1-2 weeks, after which the WG chairs will decide on whether to proceed or whether to allow changes followed by a new WGLC
2017-01-29
24 Paul Wouters Tags Other - see Comment Log, Awaiting External Review/Resolution of Issues Raised set.
2017-01-29
24 Paul Wouters IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2017-01-29
24 Paul Wouters Changed document writeup
2016-12-29
24 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-24.txt
2016-12-29
24 (System) New version approved
2016-12-29
24 (System) Request for posting confirmation emailed to previous authors: "Ben Laurie" , "Emilia Kasper" , "Eran Messeri" , "Rob Stradling" , "Adam Langley"
2016-12-29
24 Eran Messeri Uploaded new revision
2016-12-22
23 Paul Wouters
Since the last (second) WGLC of the 6962bis document, a number of
changes were made that although relatively contained, caused a
non-trivial amount of change …
Since the last (second) WGLC of the 6962bis document, a number of
changes were made that although relatively contained, caused a
non-trivial amount of change in the document. It mostly relates
to the IANA registries and a further removal of text related to
redaction that is moving into a separate document. We still thought
it best to restart a WGLC for this.

This starts a new WGLC for draft-ietf-trans-rfc6962-bis-23 for three
weeks. The WGLC closes on January 11, 2017.
2016-12-22
23 Paul Wouters IETF WG state changed to In WG Last Call from WG Consensus: Waiting for Write-Up
2016-12-21
23 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-23.txt
2016-12-21
23 (System) New version approved
2016-12-21
23 (System) Request for posting confirmation emailed to previous authors: "Ben Laurie" , "Emilia Kasper" , "Eran Messeri" , "Rob Stradling" , "Adam Langley"
2016-12-21
23 Eran Messeri Uploaded new revision
2016-12-14
22 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-22.txt
2016-12-14
22 (System) New version approved
2016-12-14
22 (System) Request for posting confirmation emailed to previous authors: "Ben Laurie" , "Emilia Kasper" , "Eran Messeri" , "Rob Stradling" , "Adam Langley"
2016-12-14
22 Rob Stradling Uploaded new revision
2016-11-29
21 Paul Wouters Notification list changed to "Paul Wouters" <paul@nohats.ca>
2016-11-29
21 Paul Wouters Document shepherd changed to Paul Wouters
2016-11-24
21 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-21.txt
2016-11-24
21 (System) New version approved
2016-11-24
21 (System) Request for posting confirmation emailed to previous authors: "Ben Laurie" , "Emilia Kasper" , "Eran Messeri" , "Rob Stradling" , "Adam Langley"
2016-11-24
21 Eran Messeri Uploaded new revision
2016-10-31
20 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-20.txt
2016-10-31
20 (System) New version approved
2016-10-31
19 (System) Request for posting confirmation emailed to previous authors: "Ben Laurie" , "Emilia Kasper" , "Eran Messeri" , "Rob Stradling" , "Adam Langley"
2016-10-31
19 Rob Stradling Uploaded new revision
2016-09-25
19 Melinda Shore IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2016-08-31
19 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-19.txt
2016-07-27
18 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-18.txt
2016-07-21
17 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-17.txt
2016-05-27
16 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-16.txt
2016-05-26
15 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-15.txt
2016-04-11
14 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-14.txt
2016-03-21
13 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-13.txt
2016-01-28
12 Eran Messeri New version available: draft-ietf-trans-rfc6962-bis-12.txt
2015-11-20
11 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-11.txt
2015-10-19
10 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-10.txt
2015-10-13
09 Rob Stradling New version available: draft-ietf-trans-rfc6962-bis-09.txt
2015-07-06
08 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-08.txt
2015-03-09
07 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-07.txt
2015-03-09
06 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-06.txt
2015-01-27
05 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-05.txt
2014-07-10
04 Cindy Morgan New revision available
2014-05-01
03 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-03.txt
2014-04-17
02 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-02.txt
2014-04-16
01 Ben Laurie New version available: draft-ietf-trans-rfc6962-bis-01.txt
2014-02-19
00 Cindy Morgan New revision available