IETF Logo Mail Archive

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

"Jeremy Rowley" <jeremy.rowley@digicert.com> Tue, 04 February 2014 19:00 UTC

Return-Path: <jeremy.rowley@digicert.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 738C61A0165 for <therightkey@ietfa.amsl.com>; Tue, 4 Feb 2014 11:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.837
X-Spam-Level:
X-Spam-Status: No, score=-4.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 5leG3Do90DoR for <therightkey@ietfa.amsl.com>; Tue, 4 Feb 2014 11:00:01 -0800 (PST)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id D907C1A0164 for <therightkey@ietf.org>; Tue, 4 Feb 2014 11:00:01 -0800 (PST)
Received: from JROWLEYL1 (unknown [67.137.52.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 0AEAD8FA006; Tue, 4 Feb 2014 12:00:01 -0700 (MST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1391540401; bh=MmRAMLF/l3lLlXGrnXjpwDJc+G1vT8NKXqb3za4yjgk=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=BnP+y8xAEr+1LI2lSepa9E+CqGcgtkyVuVGG0ZPn5CnPNY5CgD2pe/ElEK1OOW7GF 9B5B9tUq/1YgSok6uITs2yR0KAPXlzaZvDMT87R3qRyA9yaDq5W3yHcSBFMa0vujEm C79Skl6YnaupIE5zDhDkhtYMcRsyDX09uvi6qTpI=
From: Jeremy Rowley <jeremy.rowley@digicert.com>
To: 'Adam Langley' <agl@chromium.org>, certificate-transparency@googlegroups.com
References: <CABrd9STwBDxwB1vtmS9Ozb5e_7D=zfOqkOBeAaT2HG7X-cw5gw@mail.gmail.com> <04a001cf21cf$3a649190$af2db4b0$@digicert.com> <CAL9PXLyWFSfHz_230SkWLvr7sUROPv_k0rfKgmkMRRttk-EjGQ@mail.gmail.com>
In-Reply-To: <CAL9PXLyWFSfHz_230SkWLvr7sUROPv_k0rfKgmkMRRttk-EjGQ@mail.gmail.com>
Date: Tue, 04 Feb 2014 12:00:05 -0700
Message-ID: <05bf01cf21db$5146c2a0$f3d447e0$@digicert.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGGS/IGH2GP3iOZeF9RA+GsPjuqQQF9nIx2AUxrmLGbIM2csA==
Content-Language: en-us
Cc: therightkey@ietf.org, 'Ben Laurie' <benl@google.com>, '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: Tue, 04 Feb 2014 19:00:04 -0000

The entire point is to disclose the entire universe of public certificates
to the customer.  If the customer doesn't want to use it, the purpose is no
longer being fulfilled. The way we plan on implementing CT will ensure logs
are not irrevocable.  I agree we should make SCTs as small as possible, but
the last I've heard from our team is  they are still at 100 bytes per log.

Jeremy

-----Original Message-----
From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Adam
Langley
Sent: Tuesday, February 04, 2014 10:52 AM
To: certificate-transparency@googlegroups.com
Cc: therightkey@ietf.org; Ben Laurie; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency +
Extended Validation plan

On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley <jeremy.rowley@digicert.com>
wrote:
> Three or four proofs for a 27 month certificate is way too many.  The
number of proofs should be decided based on the customer's risk profile, not
a set number based on certificate lifecycle. Adding 400 bytes per
certificate will make EV certificates unusable by entities concerned with
performance.

The customer doesn't carry the risk: the risk is that we'll be unable to
revoke a log in clients due to the number of certificates that depend on it.

We should make the SCTs as small as possible, the the switch to larger
initcwnds in recent years has released much of the pressure on keeping
certificate sizes below the tradition initcwnd limit.


Cheers

AGL
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

v2.23.0 | Report a Bug | By Email