Re: [secdir] dir review of draft-laurie-pki-sunlight-05
Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 23 February 2013 13:42 UTC
Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B93C21F8F33 for <secdir@ietfa.amsl.com>; Sat, 23 Feb 2013 05:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.276
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxziEaTzdBEX for <secdir@ietfa.amsl.com>; Sat, 23 Feb 2013 05:41:59 -0800 (PST)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAA521F8F35 for <secdir@ietf.org>; Sat, 23 Feb 2013 05:41:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; 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 d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Feb 2013 14:41:56 +0100
Message-ID: <5128C71E.6000408@gondrom.org>
Date: Sat, 23 Feb 2013 21:41:50 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: benl@google.com
References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> <CABrd9ST1mHpq=Cd8yoLHbbhjBQQpATdoKamKsKCZ8D7+4BOC5w@mail.gmail.com> <5116507D.7070000@gondrom.org> <CABrd9STd0_z-bL1X1ED7XmJ7a+nAvaf7-kn105q9d7ucLsO57w@mail.gmail.com> <51170BF7.6060409@gondrom.org> <CABrd9ST04Cuy-BAcmZer=6-A7y+xrQ48FH_=n-up5PCQMaQuMw@mail.gmail.com>
In-Reply-To: <CABrd9ST04Cuy-BAcmZer=6-A7y+xrQ48FH_=n-up5PCQMaQuMw@mail.gmail.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org, iesg@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org, jhutz@cmu.edu
Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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 <tobias.gondrom@gondrom.org> wrote: >> On 10/02/13 04:47, Ben Laurie wrote: >>> On 9 February 2013 13:34, Tobias Gondrom <tobias.gondrom@gondrom.org> 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 <jhutz@cmu.edu> wrote: >>>>>> On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >>>>>>> On 24 January 2013 19:06, Jeffrey Hutzelman <jhutz@cmu.edu> 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 >>>>> secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
- [secdir] dir review of draft-laurie-pki-sunlight-… Jeffrey Hutzelman
- Re: [secdir] dir review of draft-laurie-pki-sunli… Ben Laurie
- Re: [secdir] [therightkey] dir review of draft-la… =JeffH
- Re: [secdir] dir review of draft-laurie-pki-sunli… Ben Laurie
- Re: [secdir] dir review of draft-laurie-pki-sunli… Jeffrey Hutzelman
- Re: [secdir] dir review of draft-laurie-pki-sunli… Ben Laurie
- Re: [secdir] dir review of draft-laurie-pki-sunli… Tobias Gondrom
- Re: [secdir] dir review of draft-laurie-pki-sunli… Ben Laurie
- Re: [secdir] dir review of draft-laurie-pki-sunli… Tobias Gondrom
- Re: [secdir] dir review of draft-laurie-pki-sunli… Ben Laurie
- Re: [secdir] dir review of draft-laurie-pki-sunli… Tobias Gondrom