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

Jeffrey Hutzelman <> Tue, 29 January 2013 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2D0E21F87DF; Tue, 29 Jan 2013 13:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jp8HU1u8XB5U; Tue, 29 Jan 2013 13:28:43 -0800 (PST)
Received: from (SMTP01.SRV.CS.CMU.EDU []) by (Postfix) with ESMTP id 36F1A21F87D5; Tue, 29 Jan 2013 13:28:43 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id r0TLSdi9022872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2013 16:28:40 -0500 (EST)
Message-ID: <>
From: Jeffrey Hutzelman <>
To: Ben Laurie <>
Date: Tue, 29 Jan 2013 16:28:39 -0500
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on
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: Tue, 29 Jan 2013 21:28:43 -0000

On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote:
> On 24 January 2013 19:06, Jeffrey Hutzelman <> wrote:
> > 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.
> 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.

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)?

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

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