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

Ben Laurie <> Mon, 28 January 2013 11:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D139C21F886D for <>; Mon, 28 Jan 2013 03:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.724
X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8sSnGff3M0Ab for <>; Mon, 28 Jan 2013 03:48:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8049721F884B for <>; Mon, 28 Jan 2013 03:48:41 -0800 (PST)
Received: by with SMTP id jm19so795467bkc.30 for <>; Mon, 28 Jan 2013 03:48:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=70DbQ3OA4E+UhSxHXFKvGu3iJhSXVNp5mnujsr4+e10=; b=GVoeiRV9Gga9RQxdLHkfg6X6sNecfF+EkY2B6ezRbi58x3hqQlfh53l9GfkLlh2wPm YXtdTogC4KnVzSyQKohycBOhfNtZhnJOJ1Bn3sPcnvvyzOmURPSLtouS6jNpY1yEX4RQ ur1r0H/ptZLZLjqe4hreEr+HTuDEKaK5J4DgKADkgfhwL5PYx5PK32iUBla1iZuUqO5N lNXB8SCTJmoqHxd3saKu5KU7UZsb2qDJJH4rBUPUWLW7PCB50YOMWL8M06bRIcEIeysK J3yNXk1joMtBTScGJQMZSaAPppBfqoIoKRmXT5X1bvHTFbqb7z9ySTcp6QKn5JWm/5B+ 6DAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=70DbQ3OA4E+UhSxHXFKvGu3iJhSXVNp5mnujsr4+e10=; b=QVWOiZ0Vni62FXLR+mJLVFbtFviYiolLj176bmgARu9ZyEW+pk5b6Axg87QE5/xnfQ SD0SL0EERxeAApNk6orzX9/gClrlttK8hemdNBD7kBOsNPyHWQ0XgkUwgB5nWfj5b6S0 wWa91IeKWgBJozKhHRLpr+Um+rKkpNYQKf3KvePUDlKyf9Mfnhgxcktc0ulI282NkjUf k6yD4XL7GK8b6HiKjjDLSr7xe1/5qe5PP7IchJJhh2kPnIgLi9iYZeeqiBLTqN6pc11T bsF+TWjWLoitLvdqigWwc9JiVZGpUyEjIESd57loHAbdIjWz5jilOolhycvMlk9Z8n15 Z6EQ==
MIME-Version: 1.0
X-Received: by with SMTP id j18mr3878877bkv.79.1359373720433; Mon, 28 Jan 2013 03:48:40 -0800 (PST)
Received: by with HTTP; Mon, 28 Jan 2013 03:48:40 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 28 Jan 2013 11:48:40 +0000
Message-ID: <>
From: Ben Laurie <>
To: Jeffrey Hutzelman <>, "" <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQmovUlEdzse/dF2WQWDmNgxzL/No3qnIa/j/0WhCEDUQTmSVk9L/5RlfJBB83iSCzz+zg9/Xa9WqGJJkc/Ap3fF5vAa2dWr994zwdwweOMVub30qin86rxb0FqH/U0ooeP4SlSKHZ/vKm3aNcKdRcxstTGHbsw1lffgrssX8VZlxmk6hmJDSdZcRHoJwyTHAxcFM0Ge
Cc: The IESG <>,,
Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jan 2013 11:48:43 -0000

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


> 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.