<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>That said, I'm not completely opposed to the idea. However, i do think it's premature to discuss this as a requirement. Before deciding, I'd like to see which international organizations elect to host a log. If several prominent and trustworthy organizations host the logs, this quickly becomes a non-issue.<br>Jeremy Rowley <jeremy.rowley@digicert.com> wrote:<br><br>-----Original Message-----<br>From: public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] On<br>Behalf Of Sigbjørn Vik<br>Sent: Friday, November 08, 2013 9:25 AM<br>To: Jeremy Rowley; public@cabforum.org<br>Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate<br>handling<br><br>On 08-Nov-13 16:10, Jeremy Rowley wrote:<br>> I disagree. For the outset, the log operator responsibility has been <br>> to gossip with other logs to ensure they aren't forked or in a bubble.<br><br>And if forced by threat to do otherwise by the government?<br><br>- Then the log becomes untrusted. Either it gossips or it's not trusted.<br>Of course, all the government needs to do is coerce the browser to trust a<br>non-public log and you have the same effect. You are worrying about an<br>attack where easier work-arounds exist for government entities. <br><br>> The<br>> CA's responsibility is to log the certificate in a trusted log. The <br>> browser is responsible for determining the trustworthiness of the log. <br>> Each actor has a role to play.<br><br>I am saying that the trustworthiness of a separate log is greater than that<br>of a log made by the same people who issued the CA, as collusion is less<br>likely.<br><br>- I don't necessarily agree. The reliability of the logs is equally as<br>important. A log going down is a serious event. If two logs go down, and<br>they are the same two logs the CA is using, then there is a major problem.<br>I'd rather trust a log run by someone with multi-national presence (and thus<br>subject to the jurisdiction of several areas) that a small log operator who<br>may be untrusted later on.<br><br>> A log proof from the CA itself should be sufficient as the logs are <br>> supposed to communicate with each other.<br><br>Unless forced not to, e.g. by government.<br><br>- Then the log is not trusted.<br><br>> A CA's log that is offline too long becomes untrusted.<br><br>And if a 30 second window is all it takes?<br><br>- This is starting to smell like FUD. What if the government demands the<br>browser not list their log as publicly trusted?<br><br>> Plus, I trust DigiCert's log server availability and integrity way <br>> more than I trust anyone else's. If I'm hitting a couple of log <br>> servers, I want them to be the servers I know won't go down or be<br>untrusted.<br><br>Let me explain the attack scenario in more detail. None of the protections<br>you mention above can protect against this, even if implemented strictly and<br>correctly.<br><br>- Neither does the proposal to require mutli-jurisdictional logs, especially<br>since the only two logs (that I know of) are Google and DigiCert, both<br>located jurisdictionally in the US.<br><br>Some government agency acquires a cert and a forked log proving its<br>authenticity. They hijack some victim's internet connection. They let the<br>victim's browser gossip as much as it likes. Once the victim visits their<br>mail account, gossip protocols are shut down, and they serve the false<br>certificate and the log proof, thus obtaining the user's password.<br>Once the password is obtained, the SWAT team swoops in and confiscates the<br>computer, wiping the traces of the forged certificate and proof.<br>Unless the browser is going to stop the login because of a 30 second<br>gossipless window, this would work just fine.<br><br>- Okay. But that isn't stopped with mulit-jurisdictional logs. <br><br>Do you trust every employee at DigiTrust to do the right thing when<br>presented a threat of 10 years in jail (or worse) unless they fork over some<br>documents to the government and do not ever mention it to anyone?<br><br>- As much as I trust every browser employee to do the same thing when<br>presented with the same scenario.<br><br>And even if you do, do you trust every employee of every CA in every country<br>to do the same, or would you rather have rules protecting against this?<br><br>- There are rules protecting against this. Whether they are sufficient is<br>the question. I propose the are, at least for phase 1.<br><br>This fix is easy, don't set up a system which allows governments (or<br>individual CAs) to do this.<br><br>- Okay. How? Multi-jurisdictional logs don't do that. All you've done is<br>make the browsers the target, which is already more likely than the CA.<br><br>> -----Original Message-----<br>> From: public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <br>> On Behalf Of Sigbjørn Vik<br>> Sent: Friday, November 08, 2013 3:01 AM<br>> To: public@cabforum.org<br>> Subject: Re: [cabfpub] Upcoming changes to Google Chrome's certificate <br>> handling<br>> <br>> On 07-Nov-13 20:44, Jeremy Rowley wrote:<br>> <br>>> 5) Size. We do not support Googles recommendation for three<br>>> separate time stamps. Two is sufficient to provide protection. In <br>>> fact, Id prefer to include only a single proof in each certificate.<br>>> If you log a cert to multiple servers, you can include a new proof <br>>> later on during re-issue, which minimizes concerns about log compromise.<br>>> Regardless, I do not think Google should dictate the number of logs. <br>>> Instead, each CA should individually evaluate the risks of a log <br>>> compromise or unavailability and decide the number of proofs required.<br>> <br>> There is an additional requirement I would like to see implemented on <br>> the proofs, that at least one is issued by a log under a different <br>> jurisdiction than the certificate. The threat scenario is a government <br>> agency telling CAs "We want a certificate for this site and a forked <br>> log proving it.", then deploying this in a closed network from where it<br>will never leak.<br>> <br>> A log proof from the CA itself should never be considered sufficient, <br>> as this makes authoritarian misconduct much easier. A requirement for <br>> different jurisdictions would also make life easier for CAs, as they <br>> don't have to worry about government interference.<br>> <br>> --<br>> Sigbjørn Vik<br>> Opera Software<br>> _______________________________________________<br>> Public mailing list<br>> Public@cabforum.org<br>> https://cabforum.org/mailman/listinfo/public<br>> <br><br><br>--<br>Sigbjørn Vik<br>Opera Software<br>_______________________________________________<br>Public mailing list<br>Public@cabforum.org<br>https://cabforum.org/mailman/listinfo/public<br><br>_______________________________________________<br>Public mailing list<br>Public@cabforum.org<br>https://cabforum.org/mailman/listinfo/public<br></body>