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

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, ekr@rtfm.com, trans@ietf.org, draft-ietf-trans-rfc6962-bis@ietf.org, trans-chairs@ietf.org, Paul Wouters <paul@nohats.ca>, paul@nohats.ca, rfc-editor@rfc-editor.org
Subject: Document Action: 'Certificate Transparency Version 2.0' to Experimental RFC (draft-ietf-trans-rfc6962-bis-31.txt)

The IESG has approved the following document:
- 'Certificate Transparency Version 2.0'
  (draft-ietf-trans-rfc6962-bis-31.txt) as Experimental RFC

This document is the product of the Public Notary Transparency Working Group.

The IESG contact persons are Benjamin Kaduk and Eric Rescorla.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/


Note: This document is Experimental not PS because there are no
deployed implementations and there was a feeling that there was
not enough operational experience to be confident in the document.

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