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

Ben Laurie <benl@google.com> Tue, 11 February 2014 11:00 UTC

Return-Path: <benl@google.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 A8E161A07CD for <therightkey@ietfa.amsl.com>; Tue, 11 Feb 2014 03:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level:
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.548, 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 sSBd6Jt7tpv5 for <therightkey@ietfa.amsl.com>; Tue, 11 Feb 2014 03:00:29 -0800 (PST)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9974A1A0376 for <therightkey@ietf.org>; Tue, 11 Feb 2014 03:00:29 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id jx11so6071272veb.10 for <therightkey@ietf.org>; Tue, 11 Feb 2014 03:00:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EXysm+zMhLMjUQugN0jAL7iosaKp/nPQLiCmaa9Y6mA=; b=b3A27bSzutCEJk/x+HC338wO0NZTLVbhoE49V/f2mN5kW0Lqwt46MYNzkPeiQZkyWd 0aXfxp9caue7ndYZbOItGo2NrA6grTgceEvv1mChaPKqY1aWo4auGolb+w+OHh6IitEu WvoLxb9k3nY0Z8uGN1jy39haLyKAJhJwTfTTUF8Dj/+tU4gqeAKYWSfulWGoE+UCCRrT uAiGdOt6ltfVZyp1MaPZLsPRT3bVD3GJ6osTsUOapyyD84nAmSKKQmutpiNoRatFMi4U GE6INh2tuP0jCg9DXbnBFU9lkv12EjRpVQXvuGooWiPR4T3Ms2c2v1pGKUFsDxUGF95b 1UKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EXysm+zMhLMjUQugN0jAL7iosaKp/nPQLiCmaa9Y6mA=; b=YF+oN5SkX19Ul5rRSWv5xRUjez0QwWShotI7VAVY7B924fBnekyBxdUF/cEn9skWOR tQh+i6kI6xx9MB/urehxYThseO0pPOhEv1aROvIs1uhekXfz/lCBLulPDI3PmHIInIkw fauQc+Zmwsh+ZoTUVC4Ahpup17fGuXgoE8/C2rTqaS7R0OKsBTwdODC0KvJ3aBtvI9R/ dJf2s91iEjI0a2fEgivFjrnwoaL0cvFrCfDaQeZLB6/XCab1qp4R8JOu6+R03bZLBoym S3s5ogUARHCHCyOpzWuhtIaG1kGjZyqxg4rXGUzkc2Zd3Du532kBpeSZRO5G/bmpR9dT SJwQ==
X-Gm-Message-State: ALoCoQmcRItlojbDayT/pAuPIZnQliB22DJZUzpNZPBo7M4WYlOBtmyl76jsewSxf3twg2uMTyCX+KrCLxnvuiJSYuaGsny6cu33nBBwKXEHVsYk9dZiSC+DXX39bnXF6b2t+OMdQD6214FdMp5MQBanadgqviVf5ztgzPGMOMv5R1dPJOZYChZ7i/9Zk+JSxSm7N3yICVzT
MIME-Version: 1.0
X-Received: by 10.58.4.138 with SMTP id k10mr28087815vek.8.1392116428829; Tue, 11 Feb 2014 03:00:28 -0800 (PST)
Received: by 10.52.230.105 with HTTP; Tue, 11 Feb 2014 03:00:28 -0800 (PST)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C42BDAD5@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <CABrd9STwBDxwB1vtmS9Ozb5e_7D=zfOqkOBeAaT2HG7X-cw5gw@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607C3F53600@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAL9PXLwesT0=Q_YFXyfqDGGMZdD0XtZEkCvGUTrV9zkgQQ4=kg@mail.gmail.com> <CABrd9SSv9NEpA9RHJGMtit5vyu3uDLKYrcSz1faexm3JFX9jEw@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607C42BDAD5@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Tue, 11 Feb 2014 11:00:28 +0000
Message-ID: <CABrd9SQJo+Ae+t1Gje9-njQGT8TVnyZKxLjuqc=_CV0as+qvXg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, Adam Langley <agl@chromium.org>, certificate-transparency <certificate-transparency@googlegroups.com>, CABFPub <public@cabforum.org>
Subject: Re: [therightkey] 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, 11 Feb 2014 11:00:31 -0000

On 11 February 2014 00:59, Rick Andrews <Rick_Andrews@symantec.com> wrote:
>> -----Original Message-----
>> From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of
>> Ben Laurie
>> Sent: Saturday, February 08, 2014 5:40 AM
>> To: Adam Langley
>> Cc: therightkey@ietf.org; certificate-transparency; CABFPub
>> Subject: Re: [therightkey] Updated Certificate Transparency + Extended
>> Validation plan
>>
>> On 6 February 2014 19:05, Adam Langley <agl@chromium.org> wrote:
>> > On Thu, Feb 6, 2014 at 1:51 PM, Rick Andrews
>> <Rick_Andrews@symantec.com> wrote:
>> >> Can you clarify something? The SCT delivery options described in the
>> RFC are options for the web site owner, not for the CA. CAs will need
>> to support all three options. We will have customers who won’t do
>> stapling and can’t handle TLS extensions, so they just want the SCTs
>> embedded in the cert. But not all customers will prefer that option. I
>> believe other customers will want the SCT-in-the-OCSP-response or TLS
>> extension option, because in those options you don’t have to transmit
>> the SCTs in every SSL handshake. I suspect some of our large customers
>> who are obsessed with performance will demand one of these options.
>> >>
>> >> So CAs will need to support all three options, unless you’re so
>> small a CA that your few EV customers agree on one option. Is that your
>> expectation?
>> >
>> > SCTs embedded in the certificate won't be sent for resumption
>> > handshakes of course.
>> >
>> > The TLS extension will be sent in the same cases as SCTs embedded in
>> > the certificate. (And the TLS extension doesn't need the CA to do
>> > anything.)
>
> I thought the TLS extension will be sent only if the client requests it. 'Clients that support the extension SHOULD send a ClientHello extension with the appropriate type and empty "extension_data".'

That is true, but I would expect all CT-capable clients to support the
extension.

> And I suspect that CAs would need/want to create a service to help their customers obtain SCTs if they choose the TLS extension option.

Sure.