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

From: Joseph Bonneau <[email-masked]>
Date: Thu, 26 Sep 2013 01:15:13 -0400

I'd like some elaboration on the plan for step 6, creating a whitelist of
valid EV certificates without an SCT. How is this going to be achieved?
Also, if we could do this, why not do it for all certificates and bootstrap
CT that way? Are the parameters of EV special for this (fewer certs, better
records, etc.)?

An alternate approach to a whitelist is to require SCTs for certs with a
"not before" validity period after time T (presumably this requirement
kicksn in around time T). With a stolen/compromised EV CA key you could
still issue a fraudulent cert and backdate it, so you'd have to more
strictly enforce the limits on validity periods for EV certs which I
believe are 27 months in the CA/Browser forum guidelines and 39 months in
the EV code-signing cert proposal. Of course this isn't attractive in that
it means years before you really have protection against fraudulent EV
certs. Has this approach been considered?

Joe

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 25 Sep 2013 23:31:58 -0700

>  CT that way? Are the parameters of EV special for this (fewer certs,

Fewer certs, by many orders of magnitude, such that whitelisting is a
reasonable approach.

>  certs. Has this approach been considered?

As you note, with a stolen/compromised EV CA key, you can still backdate
certs. The whitelist approach balances the tradeoffs and brings the delta
for practical checking on the client side down to a reasonable value and
with acceptable (and negligible) performance overheads, which decrease
over time.

---

From: Joseph Bonneau <[email-masked]>
Date: Thu, 26 Sep 2013 10:29:08 -0400

> 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?

Also, why isn't there be a step 8 in the plan, where the whitelist is
deprecated and every EV cert requires SCTs and Chrome is rejecting the EV
certs without them?

---

From: Joseph Bonneau <[email-masked]>
Date: Thu, 26 Sep 2013 10:44:47 -0400

> 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
> 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?

---

From: Emilia Kasper <[email-masked]>
Date: Thu, 26 Sep 2013 17:44:26 +0200

On Thu, Sep 26, 2013 at 5:35 PM, Ben Laurie <[email-masked]> wrote:

> On 26 September 2013 15:44, Joseph Bonneau <[email-masked]> wrote:
> >
> issued?
> My assumption is that this is true. If it's not, then CAs need to tell us
> :-)
>

CAs are required to retain records for audit, and are required to pass
audit to obtain EV status in the first place, so I would very much hope
it's not an unreasonable assumption :)

> > Or is this something that we're hoping can be (at least mostly) achieved
> by
> > network observation?
>
> This is also likely.
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>