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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 16 February 2013 18:54 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 1355421F87CE; Sat, 16 Feb 2013 10:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level:
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 cYWmPBo5wDGK; Sat, 16 Feb 2013 10:54:37 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1DE21F86AF; Sat, 16 Feb 2013 10:54:37 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1GIsW2B020451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Feb 2013 11:54:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAMm+LwiCQXq9ZLMGtVQMsS8MN9HRDtjg2DqTk9B8S6A7Q38J8w@mail.gmail.com>
Date: Sat, 16 Feb 2013 10:54:32 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <72D4ABBB-9B39-41F6-9AFF-37F0A7DBDAC1@vpnc.org>
References: <CABrd9SQMAGtOTcWVaUfxRE9SZS2dZVhUa3WbJVk8or_LxH6i1w@mail.gmail.com> <CAMm+LwiCQXq9ZLMGtVQMsS8MN9HRDtjg2DqTk9B8S6A7Q38J8w@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1499)
Cc: therightkey@ietf.org, 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:54:39 -0000

On Feb 16, 2013, at 10:22 AM, Phillip Hallam-Baker <hallam@gmail.com> 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