Subject: [Trans] comments on the Abstract and the doc, overall

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jun 2014 16:45:29 -0400

*Overall comments:*

Throughout the document, "certificate authority" should be changed to 
"certification authority" as per RFC 5280 and its predecessors, X.509, 
and other PKIX RFCs.

The OIDs used here appear to be from a private Google arc. This made 
sense for the experimental RFC, but since this is intended to become an 
IETF Standard, it might be better to use OIDs from the arc that Russ 
Housley manages.

I think the document should consolidate the requirements established for 
each of the identified types of clients, so that both reader and 
developer can easily determine what is required. Also, there are a 
number of places where lowercase words probably need to become 
uppercase, to clearly indicate mandated, strongly suggested, and 
optional aspects of implementations. This might be an added section near 
the end, or even a normative appendix.

In several places a lot of technical details are provided inline, as a 
concept is introduced, e.g., Merkle trees. This makes the document 
harder to read. I suggest moving such details to normative appendices, 
so that the document is easier to read.

Many (most?) of the informative references seem normative, e.g., they 
define algorithms or data formats that are mandated by this document: 
SHA-256, RSA, DSS, JSON, base64 encoding, OCSP (for carrying the SCT 
extension), etc. please review the references and re-arrange them 
accordingly.

*Abstract *

I see Russ already noted that this version of the document is a 
standards track document, as indicated in the header. Thus starting by 
saying "This document describes an experimental protocol ..." should be 
changed. I also suggest that the separate, 1-sentence paragraph in the 
abstract should be merged with the first paragraph.

I wonder if it might make sense to add a paragraph that describes the 
architecture for CT, something like:

Certificate Transparency (CT) is a collection of mechanisms and 
procedures, designed to deter (and remedy?) mis-issuance of certificates 
in the Web PKI context. Its primary focus is certificates issued to web 
servers, used with TLS to secure client/server communications. CT is 
implemented by Web PKI Certification Authorities (CAs), TLS Clients 
(browsers using TLS), TLS Servers (web servers using TLS), Log Operators 
(LOs), Monitors, and Auditors. It enables anyone to audit certificates 
issued under the Web PKI, with the intent of detecting and remedying 
mis-issuance events. The architecture assumes that RPs will, over time, 
refuse to accept a certificate that does not include (or is not 
accompanied by) evidence that it appears in (one or more) logs, thus 
encouraging Web PKI CAs to adopt the CT paradigm.