Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Feb 2013 13:22:52 -0500

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.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 Feb 2013 10:54:32 -0800

On Feb 16, 2013, at 10:22 AM, Phillip Hallam-Baker <[email-masked]> wrote:

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

Are you saying that those six items should be added to the experimental RFC as requirements, or are you just discussing what might happen operationally after the RFC is published? 

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Sat, 16 Feb 2013 10:55:58 -0800

On 16 February 2013 10:22, Phillip Hallam-Baker <[email-masked]> wrote:
> 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.
>

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.

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

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Feb 2013 19:24:09 -0500

On Sat, Feb 16, 2013 at 1:55 PM, Ben Laurie <[email-masked]> wrote:

> the

That is the reason for checkpointing against meta notaries.

Otherwise a CA might not actually release the logs.

-- 
Website: http://hallambaker.com/

---

From: Ben Laurie <[email-masked]>
Date: Fri, 22 Feb 2013 11:18:42 +0000

> Otherwise a CA might not actually release the logs.

An unreleased log is not compliant - and so would not be accepted by browsers.