Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security

Joseph Bonneau <jbonneau@gmail.com> Thu, 26 September 2013 14:45 UTC

Return-Path: <jbonneau@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF011E8103; Thu, 26 Sep 2013 07:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAEGdrtpq054; Thu, 26 Sep 2013 07:45:09 -0700 (PDT)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81B11E80DE; Thu, 26 Sep 2013 07:45:07 -0700 (PDT)
Received: by mail-vc0-f179.google.com with SMTP id ht10so920541vcb.10 for <multiple recipients>; Thu, 26 Sep 2013 07:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tbOEH//K3fAbv/psP5xvs6AVXZy+OKiDpyK8WpZmEQY=; b=sbr26cCLfaVm+FaKNh7J/cVmiFlkZOfu5SM2sj4ROZ9Wy+LCInxd2/y+mY9g1cev4f hGshRYhHRodJXv3d8mrd63v1Mh0fgZam7/bfX7Kwmndn6gsIRKNfAXgxcnUHdtFwhs3n mCZ0U6yv0Yx0tnTDvS4bcyEtJ0DgDboD23ae8qNXkplko0w10X7IpgR/HlhinVZAumIR tmWhnU84iX7VoL7tMVtlhiUWvLVwYd0/7kBzfJV/eAZ9dObCARpbqQmVIJWfVEJpAeVT 6RYNzOPEGtjFMH9bkqeq4EWLNo8pxTLl/c8Rfjct/0KfV/sSgYHOSZYefjWOET6i7b3s 6dAg==
X-Received: by 10.220.173.134 with SMTP id p6mr524781vcz.36.1380206707065; Thu, 26 Sep 2013 07:45:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.241.198 with HTTP; Thu, 26 Sep 2013 07:44:47 -0700 (PDT)
In-Reply-To: <CABrd9SR=x8Nbg8nU9uxavaF6_UCb11NgadBdo8r_mzrwAbCRqA@mail.gmail.com>
References: <CABrd9STHiKL-ecavLCkw1jqGyLAUwEQb61yJWhZV9fFKbSR8vA@mail.gmail.com> <CABrd9STcVGiYb9QBrezFza=Lhpcc=Hwh4h03R4gomCYVp=zLUw@mail.gmail.com> <CAOe4UikiA6vLnZXCxyUdK=VXRUgKf6T5k--anEJiPvK59KWVzQ@mail.gmail.com> <CABrd9STs7TimumEC=ee7-=1O05j=xFo1P3Nhj4YHyaH5LFkfRA@mail.gmail.com> <CAOe4Uinow2WqWCtgJaFaknriejXmALg8qPzLaidzG4EwFywDvQ@mail.gmail.com> <CABrd9SR=x8Nbg8nU9uxavaF6_UCb11NgadBdo8r_mzrwAbCRqA@mail.gmail.com>
From: Joseph Bonneau <jbonneau@gmail.com>
Date: Thu, 26 Sep 2013 10:44:47 -0400
Message-ID: <CAOe4UikEoWLE8CO0wjQcXifKepvax-nZi1irdW3sN3vLyyDJog@mail.gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary=089e0158b1547dcc9e04e74a6a60
X-Mailman-Approved-At: Wed, 02 Oct 2013 08:21:22 -0700
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 14:45:10 -0000

> >> Not sure what the question is - as the doc says, the list will be
> >> constructed from the logs...
> >
> >
> > I think I read it incorrectly as "without an embedded CT from *any*
> qualify
> > logs" instead of "from all qualifying logs." Now I can see how the
> whitelist
> > is created, but I'm less clear on what the intention of it is. Is the
> > assumption that some certs will be issued with more than zero but fewer
> than
> > three SCTs (proposed to the minimum acceptable in the "Qualifying
> > Certificates" section) and you'd like to whitelist such certs during the
> > rollout period?
>
> Ah. So, all existing certs do not have embedded SCTs. So, we either
> wait until all existing certs expire before we can enforce CT, or we
> whitelist the unexpired certs.


I think I'm back to my original question now :-) How do all the existing
certs get into the CT log? (at which point building the whitelist is easy)
Is the onus on EV users then to log their old certs or face failing in
Chrome? Or do EV-issuing CAs have sufficient records of what they've
issued? Or is this something that we're hoping can be (at least mostly)
achieved by network observation?