Re: [secdir] dir review of draft-laurie-pki-sunlight-05

[Ben Laurie <[e-mail]>]

On 24 January 2013 19:06, Jeffrey Hutzelman <[e-mail]> 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.

>
>