Document Action: 'Certificate Transparency Version 2.0' to Experimental RFC (draft-ietf-trans-rfc6962-bis-41.txt)

[The IESG <[e-mail]>]

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