[cabfpub] Upcoming changes to Google Chrome's certificate handling

Rick Andrews Rick_Andrews at symantec.com
Fri Nov 8 09:32:17 MST 2013


Jeremy, we heard about gossip some time ago, but AFAIK Google has removed that from the spec. I believe they're working on some other process whereby two logs (one possibly smuggled out of an Internet bubble) can be compared as some kind of consistency check. 

-Rick

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Jeremy Rowley
> Sent: Friday, November 08, 2013 7:10 AM
> To: 'Sigbjørn Vik'; public at cabforum.org
> Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate
> handling
> 
> I disagree.  For the outset, the log operator responsibility has been
> to
> gossip with other logs to ensure they aren't forked or in a bubble.
> The
> CA's responsibility is to log the certificate in a trusted log.  The
> browser
> is responsible for determining the trustworthiness of the log.  Each
> actor
> has a role to play.
> 
> A log proof from the CA itself should be sufficient as the logs are
> supposed
> to communicate with each other.  A CA's log that is offline too long
> becomes
> untrusted. Plus, I trust DigiCert's log server availability and
> integrity
> way more than I trust anyone else's.  If I'm hitting a couple of log
> servers, I want them to be the servers I know won't go down or be
> untrusted.
> 
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On
> Behalf Of Sigbjørn Vik
> Sent: Friday, November 08, 2013 3:01 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate
> handling
> 
> On 07-Nov-13 20:44, Jeremy Rowley wrote:
> 
> > 5)      Size. We do not support Google's recommendation for three
> > separate time stamps.  Two is sufficient to provide protection.  In
> > fact, I'd prefer to include only a single proof in each certificate.
> > If you log a cert to multiple servers, you can include a new proof
> > later on during re-issue, which minimizes concerns about log
> compromise.
> > Regardless, I do not think Google should dictate the number of logs.
> > Instead, each CA should individually evaluate the risks of a log
> > compromise or unavailability and decide the number of proofs
> required.
> 
> There is an additional requirement I would like to see implemented on
> the
> proofs, that at least one is issued by a log under a different
> jurisdiction
> than the certificate. The threat scenario is a government agency
> telling CAs
> "We want a certificate for this site and a forked log proving it.",
> then
> deploying this in a closed network from where it will never leak.
> 
> A log proof from the CA itself should never be considered sufficient,
> as
> this makes authoritarian misconduct much easier. A requirement for
> different
> jurisdictions would also make life easier for CAs, as they don't have
> to
> worry about government interference.
> 
> --
> Sigbjørn Vik
> Opera Software
> _______________________________________________
> 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


More information about the Public mailing list