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

Ben Laurie <benl@google.com> Sat, 08 February 2014 13:40 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 415301A0302 for <therightkey@ietfa.amsl.com>; Sat, 8 Feb 2014 05:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.027
X-Spam-Level:
X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[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 ByEgwsTjkMhr for <therightkey@ietfa.amsl.com>; Sat, 8 Feb 2014 05:40:09 -0800 (PST)
Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7892C1A0300 for <therightkey@ietf.org>; Sat, 8 Feb 2014 05:40:09 -0800 (PST)
Received: by mail-vb0-f52.google.com with SMTP id p14so3565946vbm.11 for <therightkey@ietf.org>; Sat, 08 Feb 2014 05:40:09 -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=rWqbKdNIo4umHuIP7QBOSeBiocREjNk5cVvywJxyGtM=; b=F6b6KXf6rDalR29IyVKJS3joL88IyHDgX1uJ6YdFDvS04YYi25TX1B8xVc20tUG+JO Cy91CnRlnWpfkUoaLiplnQ5yeEz6BJtGVRfQLtqIB+8GSsZEdlb4ZBSAhEW1maW9dImP UF6HwezJgX0PGoC0UP3BRw12Nvatw6lrOPO+tjf59gTkBNARbmzZ5S2237y7Ni9igjuK rVBKKt1DreJ9ORc4aQ+oXiYctN/RQFSy3c31XEH6e33Ef839nQbeLSIqvSF191vkNxyF L2jurvv1sMrdaPzXZu98DBImgs9L/VWf9QuSlXVK3D4cUCEd2yhZ9XqUAB/dcpyM15aK 3T1Q==
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=rWqbKdNIo4umHuIP7QBOSeBiocREjNk5cVvywJxyGtM=; b=Ch9J/8xo/Ps2RcdXyFD5EYGkFEsg8kz7720usj3jBP79A5RVXO9Spd+KYXYfgDbk4/ mb88SeKrcRtxGMpvsF+b+M0f2q+ODteDaX6NychGGJq067loxJe5bnBhshBhb5RKxyVa MPd0+szPp710Xxm/nzh0GRDWgB8J86Bic4x0YzOR3hZeX7Y9A378eIURW+C1F+TNqIBs TvG2CjskKjs9j4I5tIgi2DL51kLoJXw3yxlsK2svS54D/gdWLq4KD24mwbtHvW9NLHRj 2nZxjmW+xu9LVZaut99cmCkOMRqUvLpCanjxk14XAxq5YlkGVQhS874KPkuwIMwXcnex PrLw==
X-Gm-Message-State: ALoCoQklekQBOrNeuNjxAQ5TqVHmM5Uv/Ch40FgDBMcL5gzQlcTB2Rj2d67jBeux+HboJiYv0gFGZhlu3IQcaBBrLZZwMQ2lSAi2mGNRowWKuI65dt4GMN3GC4TkURJKAObYj73Ti9vLYmd2KW9lldGl2A+/bMuSIJFoKYpYQ0U4a8RBiQPe9o4Bae+UEFS+0ZloF9eJTnSc
MIME-Version: 1.0
X-Received: by 10.58.132.203 with SMTP id ow11mr15217746veb.1.1391866809849; Sat, 08 Feb 2014 05:40:09 -0800 (PST)
Received: by 10.52.230.105 with HTTP; Sat, 8 Feb 2014 05:40:09 -0800 (PST)
In-Reply-To: <CAL9PXLwesT0=Q_YFXyfqDGGMZdD0XtZEkCvGUTrV9zkgQQ4=kg@mail.gmail.com>
References: <CABrd9STwBDxwB1vtmS9Ozb5e_7D=zfOqkOBeAaT2HG7X-cw5gw@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607C3F53600@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAL9PXLwesT0=Q_YFXyfqDGGMZdD0XtZEkCvGUTrV9zkgQQ4=kg@mail.gmail.com>
Date: Sat, 08 Feb 2014 13:40:09 +0000
Message-ID: <CABrd9SSv9NEpA9RHJGMtit5vyu3uDLKYrcSz1faexm3JFX9jEw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Adam Langley <agl@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "therightkey@ietf.org" <therightkey@ietf.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: Sat, 08 Feb 2014 13:40:11 -0000

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.)
>
> The stapled OCSP response is likely to be sent in the same cases also.
> One could imagine a client that doesn't request a stapled OCSP
> response when it has a cached OCSP response for the certificate that
> it saw from the server last time. But, if the server responds with a
> different certificate it's stuck. So I expect clients to always
> request the OCSP staple.
>
> So a CA only really need worry about the embedded case. Customers who
> are concerned about the performance impact of a few hundred extra
> bytes very likely have much easier avenues to reduce the size, like
> having different certs for different names rather than dozens of SANs.

Just to clarify: if CAs want to use OCSP stapling, then obviously they
need to add CT support to their OCSP responder. But the only thing CAs
really _have_ to do is the embedded case.