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

Tobias Gondrom <> Sat, 23 February 2013 13:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B93C21F8F33 for <>; Sat, 23 Feb 2013 05:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -95.276
X-Spam-Status: No, score=-95.276 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yxziEaTzdBEX for <>; Sat, 23 Feb 2013 05:41:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0EAA521F8F35 for <>; Sat, 23 Feb 2013 05:41:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=oL6ZWM/SKHo7aOCkveooHfcYBe6cr5ZUbattws6ap8hmC2chFh7M1ExNbUNbi50h9TdsnrqHbQo0zhQOrVL+FlOTAyVJYscA2l24gQ/E6ajNolpygW0mxjwkFB3mcx7s; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 24332 invoked from network); 23 Feb 2013 14:41:56 +0100
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Feb 2013 14:41:56 +0100
Message-ID: <>
Date: Sat, 23 Feb 2013 21:41:50 +0800
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Sat, 23 Feb 2013 13:42:00 -0000

On 23/02/13 00:36, Ben Laurie wrote:
> On 10 February 2013 02:54, Tobias Gondrom <> wrote:
>> On 10/02/13 04:47, Ben Laurie wrote:
>>> On 9 February 2013 13:34, Tobias Gondrom <> wrote:
>>>> Hi Ben,
>>>> I also just read through your draft in version -07.
>>>> I can see the draft consists of two parts:
>>>> 1. data structure
>>>> 2. protocol.
>>>> For part #1 the data structure: in case you are not aware of it, some
>>>> years ago the IETF LTANS WG has done something a bit similar in a more
>>>> generic way (i.e. for any data not only for certificates) in form of
>>>> RFC4998 and RFC6283
>>> Interesting. I was not aware of these. From a quick skim they are
>>> indeed similar, but would need a bunch of added machinery to get them
>>> to where CT is (e.g. not append only, no concept of MMD).
>> You are welcome.
>> I believe the gap is mostly towards the protocol side (e.g. including
>> MMD). As the RFCs only define the data structure.
> It seems like a lot of work to inherit an essentially trivial data structure.

Well. Whether you like to take it or parts of it or re-write/re-invent
the wheel is obviously up to you.
(and I agree that the base data structure (Merkle Hash Tree) itself is
pretty trivial. It gets complicated if/when you need to switch to new
algorithms over time, which I believe is ERS has proven very useful in
implementations. Whether that might be a potential use case for your
system, shall be for others to judge.)
I only thought I should make you aware of the existing RFCs.

>>>> with a number of implementations by major ECM and
>>>> DMS vendors.
>>> No idea what ECM or DMS are in this context.
>> ECM: Enterprise Content Management
>> DMS: Document Management System
>> (Systems that store electronic documents/data.
>> And protect the proof of integrity / non-repudiation with Timestamps and
>> RFC4998/RFC6283.)
> These systems rely on trust. :-)
>>>> Just as a thought, maybe helpful looking at or even for re-use instead
>>>> of re-inventing the wheel?
>>>> Best regards, Tobias
>>>> On 30/01/13 18:15, Ben Laurie wrote:
>>>>> On 29 January 2013 21:28, Jeffrey Hutzelman <> wrote:
>>>>>> 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)?
>>>>> A third party can indeed verify this - they just watch the log like
>>>>> any monitor does.
>>>>>>> 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 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.
>>>>>> 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).
>>>>> Cool.
>>>>> _______________________________________________
>>>>> secdir mailing list
>>>>> wiki: