Subject: [therightkey] Fwd: [secdir] dir review of draft-laurie-pki-sunlight-05

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Jan 2013 19:12:05 +0000

Forwarding.

S

-------- Original Message --------
Subject: [secdir] dir review of draft-laurie-pki-sunlight-05
Date: Thu, 24 Jan 2013 14:06:33 -0500
From: Jeffrey Hutzelman <[email-masked]>
To: [email-masked], [email-masked],
[email-masked]
CC: [email-masked]

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.

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Ben Laurie <[email-masked]>
Date: Mon, 28 Jan 2013 11:48:40 +0000

> allow the reader to find out what a document is about and decide whether

Fair enough. I have copied your version. Thanks.

> body of the document.  This should be moved into the document proper.

Moved.

> guesswork does not make for interoperable implementations.

Oops. This is the language used by TLS. I will add a reference.

> 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
> is too strong here.

I think you are right, I have changed this to MAY.

>  Additionally, there is no discussion of the security

I've mentioned that normal validation should be done by the client.