*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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
