Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05
Ben Laurie <benl@google.com> Sat, 16 February 2013 18:55 UTC
Return-Path: <benl@google.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E0421F887D for <ietf@ietfa.amsl.com>; Sat, 16 Feb 2013 10:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level:
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 ZpWKT+4A0mzP for <ietf@ietfa.amsl.com>; Sat, 16 Feb 2013 10:55:59 -0800 (PST)
Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D2BF721F8849 for <ietf@ietf.org>; Sat, 16 Feb 2013 10:55:58 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id l29so2198604iag.31 for <ietf@ietf.org>; Sat, 16 Feb 2013 10:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9GCLH3GRy1sXy/A0r1frGN4WexvkDPA0VvbVHlqlbvg=; b=j9Znx05zHMHbrYwWhXiidxeV53ZvLABu9pRzBBA1s8Ikmnb2v+yeYPk79ORZVN7OtU EDcbX0Gabn9rXIk7GdSI6hN3h3TAS8527c2widbWXCG1vfj/vDbjYZyxV9H0FlxTwOqX SPztoFoGU11/cElGdSXYzLX5LlPJgh4Pra+ndFwnKBg2C/MhFbIzDmnNZ9oNUyGjdqEC 6wNaKzZNls7pBK5TO5EDFfz67D+dIGt8xelGGSwJQOPKdnrb6o+pVDv2y1oNvkZ2almh IOSbXAQ+yMX8HwotLjb7jBKL1IAk1XySfjZI9f7ghTS2yd2Qii/ANAh3YYcrFtUQcOfZ ZmVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=9GCLH3GRy1sXy/A0r1frGN4WexvkDPA0VvbVHlqlbvg=; b=KrCPzxFXT6RiLMPDIKlwFIDnWJz712dwZDDCaQctu4yxsV0kbug6T9tW8d1KFIN3Tr 9OBLhBrZUBmBSTe8D4em6Xlq2+viVnDY9dMVv52SCtQutyhWAcjpThzxSlBak4vMJwN+ i3JhKOThzJHpbyavD4AXxiP8xDeML12yU2xjKaY8I7aKtd5leQOy5OrE18MjwQdc8sMx nZGBWyXtXwtTmaRQdPVbbXxMaQt8wjpYqUOAZkYXz6q23AQkglTdfCR0UlBlgipySy0m CYRBCF+w3mt5PGwFrqc/PyLyKZtHOXKHj4B+3mRPk/Ml+vyZMK/fNEBXya0wZthnINI9 DkZg==
MIME-Version: 1.0
X-Received: by 10.50.17.201 with SMTP id q9mr4680814igd.107.1361040958321; Sat, 16 Feb 2013 10:55:58 -0800 (PST)
Received: by 10.64.19.136 with HTTP; Sat, 16 Feb 2013 10:55:58 -0800 (PST)
In-Reply-To: <CAMm+LwiCQXq9ZLMGtVQMsS8MN9HRDtjg2DqTk9B8S6A7Q38J8w@mail.gmail.com>
References: <CABrd9SQMAGtOTcWVaUfxRE9SZS2dZVhUa3WbJVk8or_LxH6i1w@mail.gmail.com> <CAMm+LwiCQXq9ZLMGtVQMsS8MN9HRDtjg2DqTk9B8S6A7Q38J8w@mail.gmail.com>
Date: Sat, 16 Feb 2013 10:55:58 -0800
Message-ID: <CABrd9SS7as7S3vz2AEOJQruCF7aJRSVGjaG6awV9YWyuQaadWQ@mail.gmail.com>
Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05
From: Ben Laurie <benl@google.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQlE88AO5Nux9f+plivXDzdNicYvfXLdFWkFsIhxT1ouFJbkXmm+TkHu1F6T4G3kFvOKao0fG+16nWDwLYdkYxCPKS4YE9yteD3FEQ0hUj7hsjbM3dtVrr+yfWZqtgJfqyLgTviO7C45fTYo/rAM0cd/71gQnGQ8Y3rfOpib8aDIqjkOKke4RyKSuWoYquP90+NsNfkM
Cc: Emilia Kasper <ekasper@google.com>, "therightkey@ietf.org" <therightkey@ietf.org>, Adam Langley <agl@google.com>, IETF Discussion List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Feb 2013 18:55:59 -0000
On 16 February 2013 10:22, Phillip Hallam-Baker <hallam@gmail.com> wrote: > Sorry for the delay but I have been thinking of CT and in particular the > issues of > > * Latency for the CA waiting for a notary server to respond > * Business models for notary servers > > As a rule open source software works really well as the marginal cost of > production is zero. Open source services tend to sux because even though the > marginal cost of a service is negligible, large numbers times negligible > adds up to big numbers. Running a DNS server for a university department > costs very little, running it for the whole university starts to cost real > money and running a registry like .com with 99.9999% reliability ends up > with $100 million hardware costs. > > So the idea that I plug my business into a network of notary servers being > run by amateurs or as a community service is a non-starter for me. We have > to align the responsibility for running any server that the CA has a > critical dependency on with a business model. Note that we do not expect CAs to talk to _all_ log servers, only those that are appropriately responsive - and also note that a CA can fire off a dozen log requests in parallel and then just use the first three that come back, which would deal with any temporary log issues. We should probably add this ability to the open source stack at some point. > Looking at the CT proposal, it seems to me that we could fix the business > model issue and remove a lot of the CA operational issues as follows: > > 1) Each browser provider that is interested in enforcing a CT requirement > stands up a meta-notary server. > > 2) Each CA runs their own notary server and this is the only resource that > needs to have a check in at certificate issue. Isn't this part the only part that's actually needed? The meta-notaries seem like redundant extra complication (and also sound like they fulfil essentially the same role as monitors). I assume, btw, that by "notary server" you mean "log server"? Also, if a CA only uses its own log, what happens when it screws up and gets its log struck off the list of trusted logs? This is why we recommend some redundancy in log signatures. > 3) Each CA notary server checkpoints to one or more meta-notary servers > every 60 minutes. As part of the check in process it uploads the whole > information for all the certificates issued in that time interval. > > 4) Meta-Notaries deliver tokens that assert that the CA notaries are current > every 60 minutes. Note here that 'current' is according to the criteria set > by the meta notary. This is an intentional piece of 'slop' in the system. > > 5) The OCSP tokens delivered by the CA contain the information necessary to > checkpoint the certificate to the Meta-Notaries. > > 6) A browser enforcing CT disclosure pulls a list of anchor points from its > chosen meta-notary every 60 minutes and uses them to validate the CT > assertions delivered in certs. > > > The 'slop' introduced at the meta-notary can of course be removed if we want > to ensure that the system is robust even if there is a collusion between the > CA and the meta-notary. But since the whole point of the scheme is > transparency, the meta-notary operation can be audited by third parties in > any event. >
- LC comments on draft-laurie-pki-sunlight-05 =JeffH
- Re: LC comments on draft-laurie-pki-sunlight-05 Ben Laurie
- Re: LC comments on draft-laurie-pki-sunlight-05 =JeffH
- Re: LC comments on draft-laurie-pki-sunlight-05 Ben Laurie
- Re: [therightkey] LC comments on draft-laurie-pki… Phillip Hallam-Baker
- Re: [therightkey] LC comments on draft-laurie-pki… Paul Hoffman
- Re: [therightkey] LC comments on draft-laurie-pki… Ben Laurie
- Re: [therightkey] LC comments on draft-laurie-pki… Phillip Hallam-Baker
- Re: [therightkey] LC comments on draft-laurie-pki… Ben Laurie