Certificate Transparency: Check SCTs in incognito mode.

Certificate Transparency: validate SCTs in incognito mode.

The CT verifier is needed in the off-the-record profile to
do SCT validation. Currently the CT verifier is stateless
so it is safe to share it with the OTR profile.

BUG=395648
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=285584

[noms (inactive), 2014-07-24 14:29:57]

I think Matt might be a better reviewer for ProfileIOData.

[mmenke, 2014-07-24 14:38:48]

[+rsleevi]:  Ryan:  What does the transparency verifier do?  Are there any
privacy issues with using the global verifier with incognito profiles?  If it
keeps a cache of verified certificates or something, maybe we should be creating
a new one, or clearing that cache when the last incognito tab closes?

[mmenke, 2014-07-24 14:39:36]

Oops...Eran said it was stateless, missed that, but I'd like some verification
that there aren't any issues here.  Then I'm happy to sign off.

[Eran Messeri, 2014-07-24 15:52:14]

On 2014/07/24 14:39:36, mmenke wrote:
> Oops...Eran said it was stateless, missed that, but I'd like some verification
> that there aren't any issues here.  Then I'm happy to sign off.

Some more context (which I probably should have provided in the first place):
* The CT verifier verifies data that accompanies the certificate (either
embedded in it or provided during the TLS handshake) using the Certificate
Transparency logs' keys it contains. This verification is independent for each
SSL connection establishment.
* Currently the only thing the CT verifier contains is CT logs' public keys and
other related information (which is statically compiled into Chromium). It does
not store any state (including cache), neither of logs nor of SSL connections,
so to the best of my understanding there should not be an issue of sharing this
object between profiles.
* My long-term plan is to store some state for each log, and I am aware that it
should be a separate state for each profile. I'll point it out when I implement
this plan.

I'll be happy to clarify further.
Eran

[Ryan Sleevi, 2014-07-24 23:21:41]

lgtm

[Ryan Sleevi, 2014-07-24 23:22:13]

Be aware that we have several other profile-related contexts (eg: for the
<webview> tag, for system requests, etc). It may require duplicating this.

[mmenke, 2014-07-24 23:30:12]

On 2014/07/24 23:22:13, Ryan Sleevi wrote:
> Be aware that we have several other profile-related contexts (eg: for the
> <webview> tag, for system requests, etc). It may require duplicating this.

There's also the AndroidWebview context, though it may have just been copied
from the profile, and already have one.

LGTM!

[Eran Messeri, 2014-07-25 12:10:32]

The CQ bit was checked by eranm@chromium.org

[commit-bot: I haz the power, 2014-07-25 12:11:26]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/eranm@chromium.org/411333002/1

[commit-bot: I haz the power, 2014-07-25 12:53:24]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  linux_chromium_rel_swarming on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel_sw...)

[commit-bot: I haz the power, 2014-07-25 13:32:45]

Change committed as 285584