On 24 January 2013 19:06, Jeffrey Hutzelman <[email protected]> wrote: > 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.
Fair enough. I have copied your version. Thanks. > 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. Moved. > 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. Oops. This is the language used by TLS. I will add a reference. > 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. This is not a MUST, however - in any case, we've changed this language in the next version. > 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. I think you are right, I have changed this to MAY. > 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. I've mentioned that normal validation should be done by the client. > > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
