Return-Path: <hallam@gmail.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 5FA9221F8953; Sat, 16 Feb 2013 10:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.794
X-Spam-Level: 
X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=-2.196,
 BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 zn0sB2+6UtxB;
 Sat, 16 Feb 2013 10:22:54 -0800 (PST)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
 [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id A22B621F8930;
 Sat, 16 Feb 2013 10:22:53 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id hi18so2238263wib.9 for
 <multiple recipients>; Sat, 16 Feb 2013 10:22:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:x-received:in-reply-to:references:date:message-id
 :subject:from:to:cc:content-type;
 bh=mhWeL7kjJLap9HNa5NHMm97l86OvwXO7JPfPET7oqAU=;
 b=D4AYCQ98so6IBf4lVsXG9iEwnym+gFfCNKVdI6xu23PMI4k0F2LG1W+Ywq8VvMNodj
 sHCzLdKGXKabboEX1D579KQsocX71t15WgzlUvijGBoKwa8vK8RqIpl5zb3gVKEPPzfN
 XRQApS22dT1QujLzTxYTHPPex1fQJSWQ1EsLLzBplacKfpJesvXC8TvNG6dEjLLtUGfM
 wVkgOEX7pNIf1xSP2/PCgOLWsfA/fd3Nhdhh7sIj9GP1J5geeW3pen89+hblp6xm6eg0
 QvM0j7RJ2YZwmARFnLB0RQem1TCmIl5/feVYuJ4i1cUmfbObJPcTd+3gl04KaBerSsde zsaQ==
MIME-Version: 1.0
X-Received: by 10.180.100.169 with SMTP id ez9mr12326625wib.3.1361038972848;
 Sat, 16 Feb 2013 10:22:52 -0800 (PST)
Received: by 10.194.176.169 with HTTP; Sat, 16 Feb 2013 10:22:52 -0800 (PST)
In-Reply-To: <CABrd9SQMAGtOTcWVaUfxRE9SZS2dZVhUa3WbJVk8or_LxH6i1w@mail.gmail.com>
References: <CABrd9SQMAGtOTcWVaUfxRE9SZS2dZVhUa3WbJVk8or_LxH6i1w@mail.gmail.com>
Date: Sat, 16 Feb 2013 13:22:52 -0500
Message-ID: <CAMm+LwiCQXq9ZLMGtVQMsS8MN9HRDtjg2DqTk9B8S6A7Q38J8w@mail.gmail.com>
Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary=14dae9cc9c56808b2304d5db9408
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:22:55 -0000

--14dae9cc9c56808b2304d5db9408
Content-Type: text/plain; charset=ISO-8859-1

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.

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.

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.

--14dae9cc9c56808b2304d5db9408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry for the delay but I have been thinking of CT and in particular the is=
sues of
<div><br></div><div>* Latency for the CA waiting for a notary server to res=
pond</div><div>* Business models for notary servers</div><div><br></div><di=
v>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 th=
e marginal cost of a service is negligible, large numbers times negligible =
adds up to big numbers. Running a DNS server for a university department co=
sts very little, running it for the whole university starts to cost real mo=
ney and running a registry like .com with 99.9999% reliability ends up with=
 $100 million hardware costs.</div>
<div><br></div><div>So the idea that I plug my business into a network of n=
otary servers being run by amateurs or as a community service is a non-star=
ter for me. We have to align the responsibility for running any server that=
 the CA has a critical dependency on with a business model.</div>
<div><br></div><div>Looking at the CT proposal, it seems to me that we coul=
d fix the business model issue and remove a lot of the CA operational issue=
s as follows:</div><div><br></div><div>1) Each browser provider that is int=
erested in enforcing a CT requirement stands up a meta-notary server.</div>
<div><br></div><div>2) Each CA runs their own notary server and this is the=
 only resource that needs to have a check in at certificate issue.</div><di=
v><br></div><div>3) Each CA notary server checkpoints to one or more meta-n=
otary 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=
.</div>
<div><br></div><div>4) Meta-Notaries deliver tokens that assert that the CA=
 notaries are current every 60 minutes. Note here that &#39;current&#39; is=
 according to the criteria set by the meta notary. This is an intentional p=
iece of &#39;slop&#39; in the system.=A0</div>
<div><br></div><div>5) The OCSP tokens delivered by the CA contain the info=
rmation necessary to checkpoint the certificate to the Meta-Notaries.</div>=
<div><br></div><div>6) A browser enforcing CT disclosure pulls a list of an=
chor points from its chosen meta-notary every 60 minutes and uses them to v=
alidate the CT assertions delivered in certs.</div>
<div><br></div><div><br></div><div>The &#39;slop&#39; introduced at the met=
a-notary can of course be removed if we want to ensure that the system is r=
obust 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 operat=
ion can be audited by third parties in any event.=A0</div>
<div><br></div>

--14dae9cc9c56808b2304d5db9408--