Document Action: 'Certificate Transparency Version 2.0' to Experimental RFC (draft-ietf-trans-rfc6962-bis-41.txt)
The IESG <email@example.com> Fri, 30 July 2021 19:44 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9165F3A0CFA; Fri, 30 Jul 2021 12:44:46 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: The IESG <firstname.lastname@example.org>
To: "IETF-Announce" <email@example.com>
Subject: Document Action: 'Certificate Transparency Version 2.0' to Experimental RFC (draft-ietf-trans-rfc6962-bis-41.txt)
Cc: Paul Wouters <firstname.lastname@example.org>, The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
Content-Type: text/plain; charset="utf-8"
Date: Fri, 30 Jul 2021 12:44:46 -0700
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 19:44:47 -0000
The IESG has approved the following document: - 'Certificate Transparency Version 2.0' (draft-ietf-trans-rfc6962-bis-41.txt) as Experimental RFC This document is the product of the Public Notary Transparency Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ Technical Summary 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. This document is a bis document for the Experimental RFC 6962. Working Group Summary (2019 Summary) 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. (2021 Additions) Per WG discussions around version -29, this document was made Experimental (not PS) because of the lack of deployed implementations and a sense that there was insufficient operational experience. The 2019-03 IESG review on -31 produced a few DISCUSSes which took some time to resolve. This delay included returning the document back to the WG and finding additional document production help. Document Quality (2019 Summary) 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. A few new independent parties have also implemented or mostly implemented this document's specification - both proprietary as well as opensource implementations. 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. Personnel Who is the Document Shepherd? Paul Wouters Who is the Responsible Area Director? Roman Danyliw