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

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 24 Jan 2013 14:06:33 -0500

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.

---

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.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 29 Jan 2013 11:35:36 +0000

> clear that clients MUST NOT depend on such validation having been done.

On second thoughts, whilst that is an effective anti-spam measure, it
is also part of the functionality of CT: i.e. to identify misissue and
give some means to do something about it. The CA check ensures we have
someone to blame for misissue.

I am not averse to suggestions that achieve the overall aim, but I
don't see the virtue of leaving it vague in the description of the
experiment we are actually running.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jan 2013 16:28:39 -0500

> someone to blame for misissue.

Hrm.  I sort of thought the idea was for the logs to be untrusted
repositories, able to be audited but not themselves expected to detect
problems.  If logs are expected to do validation of this sort, is there
a way for a third party to discover whether they are doing so (or at
least, whether they are accepting certificates they shouldn't)?

> experiment we are actually running.

I'm not suggesting vagueness; rather, I'm merely suggesting downgrading
a MUST to a SHOULD, which is still quite strong.  What happens if
someone wants to start logging certs issued by a private CA, or
self-signed certs they have observed, or...?

I'm suppose I'm OK with keeping the scope narrower than that for
purposes of the experiment, as long as it is possible to relax the
requirement later without breaking the system.  Hence the importance of
making it clear that clients must not rely on logs to have done
validation (on which point I think we've already reached agreement).

-- Jeff

---

From: Ben Laurie <[email-masked]>
Date: Wed, 30 Jan 2013 10:15:09 +0000

> least, whether they are accepting certificates they shouldn't)?

A third party can indeed verify this - they just watch the log like
any monitor does.

> self-signed certs they have observed, or...?

I don't see an issue with logging certs from a private CA. As for
self-signed certs, I don't see the point, but I guess if someone
figures out a point we can relax it in the next version.

> validation (on which point I think we've already reached agreement).

Cool.