Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan

Rob Stradling <rob.stradling@comodo.com> Wed, 05 February 2014 17:26 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A6E1A016B for <therightkey@ietfa.amsl.com>; Wed, 5 Feb 2014 09:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0WREz-ffOIC for <therightkey@ietfa.amsl.com>; Wed, 5 Feb 2014 09:26:34 -0800 (PST)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1A1A00F7 for <therightkey@ietf.org>; Wed, 5 Feb 2014 09:26:33 -0800 (PST)
Received: (qmail 29605 invoked by uid 1000); 5 Feb 2014 17:26:30 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 05 Feb 2014 17:26:30 +0000
Message-ID: <52F27445.6040701@comodo.com>
Date: Wed, 05 Feb 2014 17:26:29 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Adam Langley <agl@chromium.org>, certificate-transparency <certificate-transparency@googlegroups.com>
References: <CABrd9STwBDxwB1vtmS9Ozb5e_7D=zfOqkOBeAaT2HG7X-cw5gw@mail.gmail.com> <52F25835.60702@comodo.com> <CAL9PXLzCqvBGW=Du9ZAdMXiVgcO8WJHXf+wG7EuzE2246TFEmg@mail.gmail.com>
In-Reply-To: <CAL9PXLzCqvBGW=Du9ZAdMXiVgcO8WJHXf+wG7EuzE2246TFEmg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, CABFPub <public@cabforum.org>
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 17:26:37 -0000

On 05/02/14 15:39, Adam Langley wrote:
> On Wed, Feb 5, 2014 at 10:26 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
>> Also, what happened to the idea of only requiring 1 SCT for a 1-month cert?
>
> I'm to blame for that.
>
> Certificates with a single SCT put a lower bound on how quickly we can
> distrust a log (at least without special measures, such as shipping
> the whole, public log hashes to all the clients, which is probably
> impractical.)

Sure.

How quickly do you want to be able to distrust a log (without needing to 
resort to using probably impractical special measures)?

Presumably it's somewhere between 10 and 31 days, since 1 SCT is 
acceptable for Stapled OCSP and the BRs permit OCSP Responses to be 
valid for up to 10 days.

> Since I'm not aware of any CAs issuing one month certs,

Maybe not today, but...

> and it only saves ~100 bytes vs 2 SCTs, it seemed to be something that
> should be dropped.

Do you still think [1] is a good plan?

I think we should design CT with the assumption that [1] might happen in 
the future.  Just looking at what CAs are issuing today seems 
short-sighted IMHO.

How about requiring only 1 SCT for certs with durations <= the maximum 
validity period for an OCSP Response?


[1] https://www.imperialviolet.org/2011/03/18/revocation.html
"A much better solution would be for certificates to only be valid for a 
few days and to forget about revocation altogether. This doesn't mean 
that the private key needs to change every few days, just the 
certificate. And the certificate is public data, so servers could just 
download their refreshed certificate over HTTP periodically and 
automatically (like OCSP stapling). Clients wouldn't have to perform 
revocation checks (which are very complex and slow), CAs wouldn't have 
to pay for massive, DDoS proof serving capacity and revocation would 
actually work. If the CA went down for six hours, nobody cares. Only if 
the CA is down for days is there a problem. If you want to “revoke” a 
certificate, just stop renewing it."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online