I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.


This document describes an experimental protocol for publicly logging
the existence of certificates as they are issued or observed, in a manner
that allows anyone to audit certificate authority activity and notice the
issuance of suspect certificates, as well as to audit the logs themselves.
The intent is that eventually clients would refuse to honor certificates
which do not appear in a log, effectively forcing CAs to add all issued
certificates to the logs.

Overall, the approach used here looks reasonable.  However, I have a few
specific comments, and also recommend that the security area directors pay
special attention to this document, as it has the potential to have
far-reaching effects if the experiment is successful.



The abstract for this document is four paragraphs and takes up an entire
page.  It could be a lot shorter.  For example, I think my one-paragraph
summary above is sufficient to fill the role of an abstract, which is to
allow the reader to find out what a document is about and decide whether
he wants to read it.

This document makes extensive use of RFC2119 requirements language, but
the body of the document does not contain text incorporating the meanings
of these terms.  Instead, the usual text is hidden in a "Requirements
Language" section which appears just below the abstract, outside the main
body of the document.  This should be moved into the document proper.

For describing its messages and data structures, this document makes
extensive use of a language which is unfamiliar to me and for which no
reference is given.  I can make some guesses as to what it means, but
guesswork does not make for interoperable implementations.

I'm concerned that this document attempts to specify operational policy,
particularly for operators of logs.  As the saying goes, "MUST is for
implementors"; statements like "Anyone can submit a certificate to any 
log" are inappropriate for protocol specifications.  In practice, it
seems likely that log operators will establish policies regarding both
who may submit certificates and which certificates they will accept, and
no amount of MUST in a protocol spec is going to change that.

Similarly, as an anti-spam measure, this document proposes that logs accept
only certificates which chain back to a known CA, and requires that logs
validate each submitted certificate before appending it to the log.  This
sounds good, but it's not the only possible mechanism, and so I think MUST
is too strong here.  Additionally, there is no discussion of the security
implications if a client depends on a log to do this and the log does not
actually do so.  Rather than requiring that logs validate every submitted
certificate, the document should only RECOMMEND that they do so, and make
clear that clients MUST NOT depend on such validation having been done.