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

[Ryan Sleevi]

On Tue, Feb 4, 2014 at 11:06 AM, Jeremy Rowley
<jeremy.rowley at digicert.com>wrote:

> Also, I'm not sure how basing the number of logs based on the lifecycle
> actually minimizes the impact of log revocation. If a log containing a
> couple thousand 1-year certificates is compromised, the damage from
> revocation is about the same as a log containing thousands of 3-year certs.
> Unless you plan is to revoke the log and wait for all impacted certificates
> to actually expire (giving a 12 month risk), the impact depends on the
> number of certificates valid at the time of revocation, not the expiration
> date of the certificate.
>
>
The "impact" is only present if a single SCT is acceptable.

Increasing the number of SCTs decreases the impact of log revocation, as
the probability that any given certificate will be directly affected by a
single revocation (which is far, far less common one would hope) decreases
relative to the number of distinct logs it is logged in.

Further, a 1 year certificate that is renewed every year has a greater
chance to respond to any revocation events than a 3 year certificate, which
will not be re-issued for 3 years, and thus is unable to respond to any
revocation events (as unlikely as they may be) that happen in the interim.


> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Jeremy Rowley
> Sent: Tuesday, February 04, 2014 12:00 PM
> To: 'Adam Langley'; certificate-transparency at googlegroups.com
> Cc: therightkey at ietf.org; 'CABFPub'
> Subject: Re: [cabfpub] [therightkey] Updated Certificate Transparency +
> Extended Validation plan
>
> 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 at ietf.org] On Behalf Of Adam
> Langley
> Sent: Tuesday, February 04, 2014 10:52 AM
> To: certificate-transparency at googlegroups.com
> Cc: therightkey at 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 at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140204/23391e93/attachment-0003.html>