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

[Ben Laurie]

On 8 November 2013 17:30, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> They might not be in the RFC, but a form of gossiping was still discussed at
> the CT face-to-face in London.  I'll wait for Ben Laurie to confirm whether
> this is still the case.

Gossip was not removed from the spec, because it was never in it.

It was never in it because, although we agree that it is an essential
component, we have not yet worked out how best to do it. So, writing
an RFC on it seemed premature.

We are absolutely confident that gossip can be done, the only question
is exactly how and exactly what. This question does not actually need
to be answered until CT is mandatory...

>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Rick Andrews
> Sent: Friday, November 08, 2013 9:32 AM
> To: Jeremy Rowley; 'Sigbjørn Vik'; public at cabforum.org
> Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate
> handling
>
> 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
> _______________________________________________
> 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