Proposed May 2015 CT Policy Update

[Ryan Sleevi]

Note: This is a draft proposal to update the current Chrome EV/CT
Plan. This proposal has not yet been accepted, and thus all of the
existing EV/CT Plan remains in force.

Based on the ongoing feedback and discussion with Certificate
Authorities and Log Operators, we’d like to propose a change to the
definition of a what constitutes a Qualifying Certificate. This change
should eliminate an area of both concern and ambiguity in the current
EV/CT Plan, while still providing appropriate controls and safeguards
against bad actors.

Under the current Plan, each of the three methods used to determine if
a certificate is a Qualifying Certificate requires a minimum number of
SCTs from independent qualifying logs. Independence, as defined in the
Plan, is defined as a “one that does not share infrastructure or
administrative access with another log used for the same certificate.”
Presently, this requirement is not enforced, as part of a temporary
relaxation for certificates issued before 1 July 2015. Instead, CAs
and site operators are required to ensure at least one of the SCTs
presented comes from a log operated by Google.

We propose to extend this relaxation indefinitely, removing the
“independence” requirement from logs used, while still requiring that
every Qualifying Certificate present AT LEAST one SCT from a
Google-operated Log.

This should resolve the ambiguity regarding what constitutes
independence, such as what to do when two logs share the same cloud
hosting provider, the same ISP, exist within the same legal
jurisdiction, or, to an extreme, the same hardware vendor.

While this relaxes the policy and technical enforcement of
organizationally distinct logs, in order to minimize potential
disruption to their users in the event a log is removed, or worse,
that a series of logs operated by the same organization are removed,
CAs are encouraged to diversify their logging across a variety of
Qualified Logs.

In addition, we’ve updated the December 2014 EV/CT Plan to reflect the
fact that the plan, as documented, has been implemented. This
hopefully simplifies and clarifies the expectations for recognition of
EV status within Chrome. To again emphasize, this revised plan is,
like this email, still a draft for discussion.

The proposed modified Plan is attached.

We welcome constructive feedback and discussion of this proposal, and
hope to reach a decision within the next several weeks.

[Michael Klieman]

Thanks Ryan, three immediate notes:

1. We welcome the removal of the independence requirement... this removes
a key implementation issue.
2. You¹ve removed mention of CT & EV treatment in mobile versions of
Chrome. Can you clarify what your plan is there?
3. Nit: the footnotes 1 & 2 are identical (this is the case with the same
2 & 3 in the current version).

Michael Klieman

>--
>You received this message because you are subscribed to the Google Groups
>"Certificate Transparency Policy" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to ct-policy+...@chromium.org.
>To post to this group, send email to ct-p...@chromium.org.
>To view this discussion on the web visit
>https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvapQSiJsU
>msAcfOdTKV-ciskUz%2BmcTLzjpNbsednSP%2BMw%40mail.gmail.com.

[Ryan Sleevi]

On Fri, May 1, 2015 at 6:08 PM, Michael Klieman
<Michael...@symantec.com> wrote:
> Thanks Ryan, three immediate notes:
>
> 1. We welcome the removal of the independence requirement... this removes
> a key implementation issue.
> 2. You¹ve removed mention of CT & EV treatment in mobile versions of
> Chrome. Can you clarify what your plan is there?

The plan is as stated in the document. That is, the definition of a
Qualifying Certificate applies.

The only exception to that is Chrome for desktop platforms, and that's
specifically called out as exceptional in the "current Certificate
Transparency implementation" item #4.

> 3. Nit: the footnotes 1 & 2 are identical (this is the case with the same
> 2 & 3 in the current version).

Yup.

[Sigbjørn Vik]

On 02-May-15 02:47, Ryan Sleevi wrote:
> Note: This is a draft proposal to update the current Chrome EV/CT
> Plan. This proposal has not yet been accepted, and thus all of the
> existing EV/CT Plan remains in force.

[...]

> Instead, CAs
> and site operators are required to ensure at least one of the SCTs
> presented comes from a log operated by Google.
>

> We propose to extend this [...] indefinitely,

We applaud Google's move to provide stable logs, but think the
requirement that all certs be logged with Google is a bad move. This
formalizes control over which certs are issued with a single entity, and
the internet is all about decentralization.

While this might be a good temporary requirement, we would not want this
to be permanent, and would consider removing any such permanent
requirements from our downstream version of chromium code. We do not
believe the internet is best served with each browser having their own
requirements for SCTs either.

While browsers today can block individual certificates, this would
essentially give a single entity the power to block CAs from issuing
valid certificates for cooperating browsers. All CAs would have to apply
to Google beforehand to issue such certificates, and might (in theory,
in the future) be rejected for any reason.

As Chrome is the first browser to fully implement CT, the specification
is important, and will form the basis of other implementations. We would
want to the specification to be vendor agnostic, and would want to
dissuade other vendors from adding their own requirements.

--
Sigbjørn Vik
Opera Software

[Ryan Sleevi]

On May 4, 2015 3:59 AM, "Sigbjørn Vik" <sigb...@opera.com> wrote:
>
> We applaud Google's move to provide stable logs, but think the
> requirement that all certs be logged with Google is a bad move. This
> formalizes control over which certs are issued with a single entity, and
> the internet is all about decentralization.

Could you explain how this formalizes control? It sounds like your concern is over how Google's logs accept root certificates, is that correct? If so, how does that differ from a Google-run Root Program (which already exists for platforms such as Chrome on Android, iOS, and ChromeOS)?

> While this might be a good temporary requirement, we would not want this
> to be permanent, and would consider removing any such permanent
> requirements from our downstream version of chromium code. We do not
> believe the internet is best served with each browser having their own
> requirements for SCTs either.

How is it possible to _not_ arrive here? Browsers already have their own requirements for what root CAs they will accept, directly or indirectly.

Under the current policy, we require, for example, certain up time requirements and a certain maximum MMD. That seems inescapable as a policy decision.

> While browsers today can block individual certificates, this would
> essentially give a single entity the power to block CAs from issuing
> valid certificates for cooperating browsers. All CAs would have to apply
> to Google beforehand to issue such certificates, and might (in theory,
> in the future) be rejected for any reason.

How is this different from root stores today? And how would you propose this be treated differently in the future?

It seems inherent the need to use policy to address the risks of coercion, compromise, collusion, and collapse of logs and CAs, so I can't see how one can avoid needing some element of policies to address those risks, and the policies will always reflect the organizations that define them.

> As Chrome is the first browser to fully implement CT, the specification
> is important, and will form the basis of other implementations. We would
> want to the specification to be vendor agnostic, and would want to
> dissuade other vendors from adding their own requirements.

The specification is vendor agnostic. But you're currently depending on Chrome policy for what an acceptable log is, so that isn't exactly vendor agnostic.

That said, it seems you've raised some concerns with the approach, so I'm curious how you would see the present issues in the policy be addressed, if not the relaxation of independence. In particular, can you come up with a suitably robust criteria for independence that could objectively evaluate a log's suitability? If a log was operated by the same board of directors, but an independent holding company, would that be robust? Would you even know? What if it was that Log B was operated by the spouses and legal partners of Log A? Is that independent?

Ultimately, a set of objective criteria are needed, and with respect to independence, it is quite challenging to find such a set.

[Sigbjørn Vik]

On 04-May-15 17:42, Ryan Sleevi wrote:
>
> On May 4, 2015 3:59 AM, "Sigbjørn Vik" <sigb...@opera.com

> <mailto:sigb...@opera.com>> wrote:
>> This
>> formalizes control over which certs are issued with a single entity, and
>> the internet is all about decentralization.
>
> Could you explain how this formalizes control?

It gives Google the power to pre-emptively reject any certificates
issued for the web at large. Even if just by de facto, it will still
change the dynamics of the web.

> It sounds like your
> concern is over how Google's logs accept root certificates, is that
> correct?

I am concerned about the principle, of a vendor requiring CAs to log all
certificates ahead of time with a vendor supplied log.

>> We do not
>> believe the internet is best served with each browser having their own
>> requirements for SCTs either.
>
> How is it possible to _not_ arrive here? Browsers already have their own
> requirements for what root CAs they will accept, directly or indirectly.

Having requirements on the CA is quite different from having
requirements on the certificates. Accepting a root, and having all
certificates automatically accepted is quite different from needing all
the certificates to be accepted ahead of time.

> Under the current policy, we require, for example, certain up time
> requirements and a certain maximum MMD. That seems inescapable as a
> policy decision.

As this is entirely vendor agnostic, this is not a problem, and not
related to the issue I am raising.

>> While browsers today can block individual certificates, this would
>> essentially give a single entity the power to block CAs from issuing
>> valid certificates for cooperating browsers. All CAs would have to apply
>> to Google beforehand to issue such certificates, and might (in theory,
>> in the future) be rejected for any reason.
>
> How is this different from root stores today? And how would you propose
> this be treated differently in the future?

Quite different, in a number of ways. Today, individual certs are
blocked after-the-fact. Any one browser cannot impose requirements on
the CAs. With this, a vendor could unilaterally block the issuance of
certificates ahead of issuance. In the worst case, Google could block
all issuance of non-Google-CA certificates by rejecting logging. (I am
not implying Google would, I am just concerned about the principle.)
While a browser today could stop accepting all but Google-CA
certificates, that would hurt the browser, not the CAs, after this
change, the burden falls on CAs if a vendor so misbehaves.

>> As Chrome is the first browser to fully implement CT, the specification
>> is important, and will form the basis of other implementations. We would
>> want to the specification to be vendor agnostic, and would want to
>> dissuade other vendors from adding their own requirements.
>
> The specification is vendor agnostic. But you're currently depending on
> Chrome policy for what an acceptable log is, so that isn't exactly
> vendor agnostic.

I consider "acceptable log policy" part of the specification, and see no
reason why this cannot be made vendor agnostic too.

> That said, it seems you've raised some concerns with the approach, so
> I'm curious how you would see the present issues in the policy be
> addressed, if not the relaxation of independence. In particular, can you
> come up with a suitably robust criteria for independence that could
> objectively evaluate a log's suitability? If a log was operated by the
> same board of directors, but an independent holding company, would that
> be robust? Would you even know? What if it was that Log B was operated
> by the spouses and legal partners of Log A? Is that independent?
>
> Ultimately, a set of objective criteria are needed, and with respect to
> independence, it is quite challenging to find such a set.

I take it that part of the reason for this change was to get
independence, and that Google logs were deemed "independent". So that a
Google issued certificate with 3 Google SCTs is still deemed to have
independent SCTs? That in itself sounds wrong. If Google logs were
operated by the same board of directors as other logs, I (both as an end
user, and as a downstream vendor) wouldn't even know, so for anyone but
Google, there is no extra assurance of independence either.

I believe logs being independent of the CA is more important than being
independent of each other (at least one log should be run by someone
else). The CAs have contractual obligations and audits, so asking them
to assert they have no interests in their backup log(s) should be fully
doable.

I have previously argued that ensuring at least one log is run in a
location with a different government than where the CA is run - so that
no single government can coerce a CA and a log to issue/fork secret
certificates to be used in secret, walled-off networks. For this set of
independence, the board of directors and owner company doesn't matter,
only the law of the land of the operators and admins does (everybody who
has access to private keys).

Those two sets of independence would, in my eyes, ensure more
independence than forcing a Google log to be used. Having more SCTs than
that is about redundancy, not independence, and it is up to CAs how much
more independence they want.

If you do want more independence, that is achievable. It seems most logs
are operated by CAs anyhow, and CAs could make assurances that such logs
are operated by that CA alone. That would give a business incentive for
other CAs to choose such a log.

[Ryan Sleevi]

On May 4, 2015 9:22 AM, "Sigbjørn Vik" <sigb...@opera.com> wrote:
> It gives Google the power to pre-emptively reject any certificates
> issued for the web at large. Even if just by de facto, it will still
> change the dynamics of the web.

I'm sorry, I'm still not following how you see this happening?

> I am concerned about the principle, of a vendor requiring CAs to log all
> certificates ahead of time with a vendor supplied log.

This isn't required though. What is required is that the certificates are, at time of evaluation, provided with sufficient SCTs.

> Having requirements on the CA is quite different from having
> requirements on the certificates. Accepting a root, and having all
> certificates automatically accepted is quite different from needing all
> the certificates to be accepted ahead of time.

Again, this isn't required.

It sounds like you have a particular "worst case" scenario in mind, and from that are arguing against incremental improvements. It would help to know/elaborate what this scenario is, so that we can collectively look to see what can be done to ameliorate your concerns.

> > Under the current policy, we require, for example, certain up time
> > requirements and a certain maximum MMD. That seems inescapable as a
> > policy decision.
>
> As this is entirely vendor agnostic, this is not a problem, and not
> related to the issue I am raising.

It fundamentally is a vendor setting a policy. I fail to see how one set of requirements is vendor agnostic (especially when it is Google quantifying and measuring compliance) while at the same time arguing that it is vendor specific.

I think you're operating with some demarcation of policies into agnostic & specific, and it's unclear what that demarcation is so that we could propose an alternative that meets your desired definition.

> Quite different, in a number of ways. Today, individual certs are
> blocked after-the-fact.

Just to be clear, you see that as a strength in the current system, right? While we certainly aren't arguing for that, as hopefully clearly shown by our policies, the fact remains that a number of people point out the above as a _weakness_, not a strength.

> Any one browser cannot impose requirements on
> the CAs.

Well that's not true. That is exactly what root store policies do. There is no root store that requires exactly and only what the CA/B Forum, ETSI, or WebTrust have dictated. They all impose unliteral policies above and beyond, and have since time immemorial.

> With this, a vendor could unilaterally block the issuance of
> certificates ahead of issuance. In the worst case, Google could block
> all issuance of non-Google-CA certificates by rejecting logging. (I am
> not implying Google would, I am just concerned about the principle.)

And do you not think the current policies require that disclosure a priori? Logs applying for application are required to state their policies of acceptance, and required to update when those policies of acceptance change.

For example, Rocketeer (a Google log) states in https://code.google.com/p/chromium/issues/detail?id=431057 that it will "Will log any certificate that is anchored in a root trusted by one of the major browser vendors."

Certly.io (a non-Google log, although how would you prove it), states in https://code.google.com/p/chromium/issues/detail?id=442173 "The log is preloaded with the current (as of today) Ubuntu root list. An internal testing root is also included. CAs in at least one CA program (Microsoft, Mozilla, or Apple) who are not already added can contact me."

> While a browser today could stop accepting all but Google-CA
> certificates, that would hurt the browser, not the CAs, after this
> change, the burden falls on CAs if a vendor so misbehaves.

How so? This doesn't logically extend in any way. From the user's perspective, the act of accepting/rejecting a CA is virtually indistinguishable from a log doing so. That is, if a browser such as Chrome requires that a certificate be logged in a Google operated log, and that Google operated log rejects a certificate because of the CA that issued it or the technical content of it, how is that different than if Chrome simply rejected that certificate because of the CA that issued it or the technical content of it?

I mean, for that matter, Chrome already enforces technical constraints on certificates to ensure they comply with the Baseline Requirements, and reject such certificates that fail on certain criteria. How, from a user experience, is that different? It sounds like you're arguing that these are somehow distinct (a browser rejecting a CA vs a browser-required log rejecting a CA), but both seem fundamentally identical through an identity property.

> I consider "acceptable log policy" part of the specification, and see no
> reason why this cannot be made vendor agnostic too.

I'm sorry, but I need a something a little more concrete to understand what you are proposing here as acceptable log policy.

Are you saying the IETF Trans WG should come up with a definition of what represents a trustworthy log? That IANA (or, more aptly, ICANN, a non-profit US corporation) should maintain a list of known trustworthy logs? I just want to make sure we're being explicit here.

> I take it that part of the reason for this change was to get
> independence, and that Google logs were deemed "independent". So that a
> Google issued certificate with 3 Google SCTs is still deemed to have
> independent SCTs? That in itself sounds wrong.

Elaborate why, as otherwise we can't address the perceived wrongness, only the uncertainty being presented.

For example, is this mitigated by establishing "at least one Google and one not-Google"? If so, why? What attacks are you concerned about, and why? Let's elaborate the threat model.

Is your concern only with a Google-issued certificate? What if, say, a non-Google CA (and I'll use Digicert as an example, because they run a log) logged their certificate into three Google logs. Would you be concerned then? Why or why not?

> I believe logs being independent of the CA is more important than being
> independent of each other (at least one log should be run by someone
> else).

I'm not disagreeing with you, but it would help if you spell out why. Objectively, this sounds entirely subjective. The majority of the logs accepted today are CA's logs, but you haven't said anything yet against this when these logs have been accepted, nor really proposed any changes to policy.

> I have previously argued that ensuring at least one log is run in a
> location with a different government than where the CA is run - so that
> no single government can coerce a CA and a log to issue/fork secret
> certificates to be used in secret, walled-off networks. For this set of
> independence, the board of directors and owner company doesn't matter,
> only the law of the land of the operators and admins does (everybody who
> has access to private keys).

Except such coercion is detectable and would be the death of the log. No party can ensure the SCT never makes it to the public and thus reveals the fork. That is one of the key concepts of CT.

What about a CA like Symantec or GlobalSign, where the private keys are geographically diverse. Would a browser running a CT policy be required to investigate where each copy of the private key lives? What about subsidiary relationships - do those count towards your "where the CA is run" definition? How would the public be assured that this information was correct and due diligence was followed?

I'm not trying to be negative, but I think the requirement you've proposed there is far, far more difficult to quantify than you realize, and is fundamentally as problematic as the "independence" requirement is when it comes to having objective criteria.

>
> Those two sets of independence would, in my eyes, ensure more
> independence than forcing a Google log to be used. Having more SCTs than
> that is about redundancy, not independence, and it is up to CAs how much
> more independence they want.

To make sure it is clear - you want the log to not be (???) by the CA and not in the same jurisdiction?

The former has definitional issues - is it operated by? How do you quantify that? What about the CAs that have engaged in financial relationships with Digicert - are those meeting your definition of independence? How would that be quantified - would the CA have to self-declare? What would they self-declare? How would the auditor - which I presume means WebTrust/ETSI (and thus would require 18 months, on the early, to incorporate into any audit frameworks) - measure this? The lack of a financial relationship between the log is a negative statement - that is, there's no evidence you can provide to show you do have a relationship, only suppress that evidence.

Or are you simply looking for a legal opinion letter? If so, how does that mitigate any of the coercion or collusion concerns you seem to have?

With respect to jurisdictional independence, how do you quantify that? For example, extradition treaties involve in-kind recognition of the legal rights of distinct countries. And it's well known that treaties such as the Trans-Pacific Partnership or the EU membership agreements extend well into the realm of computer-based activities. So how do you quantify jurisdictional independence?

>
> If you do want more independence, that is achievable. It seems most logs
> are operated by CAs anyhow, and CAs could make assurances that such logs
> are operated by that CA alone. That would give a business incentive for
> other CAs to choose such a log.

Except most of the logs aren't operated by that CA alone, and I'm not sure that represents a bad thing in practice or in spirit; but it seems you do?

[Richard Salz]

I think the concern is about a CT log operator being able to refuse a certificate "just because it wants to."

[Jeremy Rowley]

The independence requirement was previously inserted  because of a concern that a government actor could target the log operator to force non-logging of certificates. The risk was minimized because the government entity would have to target multiple entities to avoid logging. With Google running three logs (sufficient for logging any certificates), this means CAs can use solely Google logs to  meet the requirements. What's worse, is that Google itself can use only the Google logs to log all of its certificates, making Google the single point of government intervention. Is this no longer a risk Google is considering?

Jeremy

[Ryan Sleevi]

On Mon, May 4, 2015 at 10:24 AM, Jeremy Rowley <rowl...@gmail.com> wrote:
> The independence requirement was previously inserted because of a concern
> that a government actor could target the log operator to force non-logging
> of certificates. The risk was minimized because the government entity would
> have to target multiple entities to avoid logging. With Google running three
> logs (sufficient for logging any certificates), this means CAs can use
> solely Google logs to meet the requirements. What's worse, is that Google
> itself can use only the Google logs to log all of its certificates, making
> Google the single point of government intervention. Is this no longer a risk
> Google is considering?
>
> Jeremy

That's not a fair or accurate summary of why the independence
requirement was inserted. As I mentioned in past messages, there's
multiple concerns:

* Coercion - By a government level actor that wishes to use the force
of law to compel a log to violate the append-only property in such a
way that the log is "forked"

* Collusion - Two parties wish to enter into a secret agreement to
fork the log (e.g. for business purposes). Alternatively, a CA may
wish to try to make a log "too big to fail", such that action against
it would cause too many sites to fail to meet quorum. This is, for
example, the risk when a "large" CA has a misstep. [As an aside, there
are means separate from independence to address the TBTF issue, which
is why it's not as significant.]

* Compromise - By having all of the logs operated by the issuing
party, a compromise of the CA MAY lead to compromise of the log. It
depends on how the log operator has configured things, but it's a risk
when infrastructure is shared.

* Collapse - A general failure of the log to adhere to its policies
and thus resulting in removal. Similar to compromise, we assume
multiple logs operated by a same entity are at risk of simultaneous
failure.


Now, it's certainly true that the independence requirement that I
ended up putting in the draft policy was misworded, as the intent was
to require "one Google" and "one not Google" log. However, I've tried
to avoid focusing on that wording (which will be addressed
seperately), as Sigbjorn has raised multiple concerns, and none of
which seem to focus on that distinction.

Independence in theory allowed for a mitigation for each of these
concerns, but at the risk of being definitionally unsound, a problem
area we recognized going in and wished to iterate on and refine with
community input. From the perspective of Chrome, and finding
mitigations for each of these, the "Google & Not Google" requirement
provide adequate and equivalent mitigations for each of the above
scenarios, which I can elaborate on if not immediately obvious how.

However, none of these seem to be Sigbjorn's concern, which is why I'm
pressing back to better understand the set of risks or issues seen
both by Opera and the community at large.

[Ryan Sleevi]

On Mon, May 4, 2015 at 10:15 AM, Richard Salz <rich...@gmail.com> wrote:
> I think the concern is about a CT log operator being able to refuse a
> certificate "just because it wants to."
>

Well, that's not a fair summary either, since logs already have a
degree of flexibility with respect to that. For example, Digicert's
and Izenpe's log don't necessary accept every root CA that Google's
do.

The issue seems to be a combination of requiring a particular log
(namely, the ISV of the application) and the ability of said required
logs to set their own policy. However, that's fundamentally no
different then the application setting its policies w/ respect to
validation or trust stores.

So there's clearly "something more", and that's something that seems
to be unclear to you, Jeremy, and myself, judging by the three
incomplete summaries of the issues Sigbjorn has raised.

[kirk...@trendmicro.com]

Thanks for this clarification.

One further question -- your message below says a Qualifying Certificate must present "AT LEAST one SCT from a Google-operated Log." (Emphasis in the original message.) Could a Qualifying Certificate contain ONLY Google SCTs? I did not see anything in the policy itself to prevent that.

We intend to get SCTs from multiple sources, including our own, but wanted to know if multiple SCTs from Google CT logs only are acceptable (as a backup plan in case the other CT logs we use go down for some reason).

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvapQSiJsUmsAcfOdTKV-ciskUz%2BmcTLzjpNbsednSP%2BMw%40mail.gmail.com.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>

[Ryan Sleevi]

On Mon, May 4, 2015 at 10:56 AM, kirk...@trendmicro.com
<kirk...@trendmicro.com> wrote:
> Thanks for this clarification.
>
> One further question -- your message below says a Qualifying Certificate must present "AT LEAST one SCT from a Google-operated Log." (Emphasis in the original message.) Could a Qualifying Certificate contain ONLY Google SCTs? I did not see anything in the policy itself to prevent that.

See my reply to Jeremy later in this thread. No, that was not the
intent - it was a wording snafu on my part when drafting the
modifications and will be fixed.

AT LEAST one SCT from a Google-operated Log and AT LEAST one SCT from
a non-Google-operated Log.

[David Leon Gil]

Two questions:

1. Do you consider a log hosted on Google Compute Engine to be a 'Google-operated' log? 

2. Is there any way to edit Chrome's 'CT-log trust-store' settings?

- David

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvYcgWz%3Dc-OiXAd9DFSzeWMG_EufDT5sOzp-3G_F7BbfdA%40mail.gmail.com.

[Ryan Sleevi]

On Mon, May 4, 2015 at 11:12 AM, David Leon Gil <cor...@gmail.com> wrote:
> Two questions:
>
> 1. Do you consider a log hosted on Google Compute Engine to be a
> 'Google-operated' log?

The answer we ultimately settled on is "Yes", to avoid any of the
ambiguity that exists at present with respect to independence.

> 2. Is there any way to edit Chrome's 'CT-log trust-store' settings?

There are command-line options to test new logs. There is not a way to
edit the log settings overall, nor are there any plans to offer that.
Conceptually and fundamentally, it runs counter to the goals of CT if
such a use case (for distrusting logs) exists independent of provable
log compromise, in which case, we should distrust for all.

[Peter Bowen]

On Mon, May 4, 2015 at 11:18 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Mon, May 4, 2015 at 11:12 AM, David Leon Gil <cor...@gmail.com> wrote:
>> Two questions:
>>
>> 1. Do you consider a log hosted on Google Compute Engine to be a
>> 'Google-operated' log?
>
> The answer we ultimately settled on is "Yes", to avoid any of the
> ambiguity that exists at present with respect to independence.

If we assume log.trans.xm is hosted on GCE and ct.other.xs is hosted
on another provider, would one SCT from each of these this meet the
requirement for 12-month certificate?

[Ryan Sleevi]

On May 4, 2015 11:55 AM, "Peter Bowen" <pzb...@gmail.com> wrote:
>
> If we assume log.trans.xm is hosted on GCE and ct.other.xs is hosted
> on another provider, would one SCT from each of these this meet the
> requirement for 12-month certificate?

Fair question, and the intended answer is no.

I think the distinction here that probably needs to be made is one log operated by Google and one log that is independent from Google. Unfortunately, that reintroduces the I word.

[Ben Laurie]

Google can determine which logs, in its opinion, are not "operated by Google". That seems sufficient to me.

[Sigbjørn Vik]

On 04-May-15 19:05, Ryan Sleevi wrote:
> On May 4, 2015 9:22 AM, "Sigbjørn Vik" wrote:

Let's take a step back here. You started this thread by saying that a)
there would no longer be a need for independent logs, and b) there would
be a need for a Google log.

I assume you mean that a Google log thus maintains the independence
attribute, but you didn't state how. Would you care to explain how you
think it achieves this?

How do users know that the Google log is independent from other logs,
apart from a self-assured statement from the log operator?
Google browser users already need to place a lot of trust in the binary.
How does requiring them to place even more trust into the same company
increase their overall trust?
How does company A requiring logs from company A increase independence?

My general issue is that this is creating log services that are too big
to fail (3 Google logs is still just one log service). Changing the
requirement to also need a non-Google log helps, but doesn't suffice.
Changing the requirement to be a log independent of Google would also
help, but would still create a log "too big to fail".

Let's assume some browser which already is too big to fail (meaning
certs must work in it) makes a requirement for a particular log to be
used. This means (at least some) CAs will necessarily make procedural
changes so that they issue no certs until they have an SCT from that
log. To demonstrate what power such a log has, imagine it inadvertently
failing to accept connections from Russia for a weekend - making Russian
CAs unable to issue certs. That would introduce a serious CA bias - a
bias which doesn't exist today.

If such a failure were to be permanent, CAs would learn how to work
around it, but that doesn't mean the log has no power. A buggy browser
for a weekend (until an update ships) doesn't introduce the same bias
into CA competition, so this is quite different from existing root store
policies.

I can come up with lots of worst case scenarios of what a log "too big
to fail" could do to abuse its market position, I think you can too.
This is something we want to avoid.

>> > Under the current policy, we require, for example, certain up time
>> > requirements and a certain maximum MMD. That seems inescapable as a
>> > policy decision.
>>
>> As this is entirely vendor agnostic, this is not a problem, and not
>> related to the issue I am raising.
>
> It fundamentally is a vendor setting a policy. I fail to see how one set
> of requirements is vendor agnostic (especially when it is Google
> quantifying and measuring compliance) while at the same time arguing
> that it is vendor specific.

We must have different definitions of "vendor agnostic", what is yours?
I fail to see how 99.99% uptime and 1 hour MMD evaluates differently for
Safari and Yandex. Requiring at least one US log does evaluate quite
differently though. The first example fits my definition of agnostic,
the second does not.

>> Today, individual certs are blocked after-the-fact.
>
> Just to be clear, you see that as a strength in the current system,
> right?

This is clearly a weakness (for a priori bad certs).

>> With this, a vendor could unilaterally block the issuance of
>> certificates ahead of issuance. In the worst case, Google could block
>> all issuance of non-Google-CA certificates by rejecting logging.
>

> And do you not think the current policies require that disclosure a
> priori? Logs applying for application are required to state their
> policies of acceptance, and required to update when those policies of
> acceptance change.

We don't want to reduce this to "trust us" semantics, "we would have
disclosed had we done that". We want to build a robust system where this
isn't required. If a malicious log wanted, there are plenty of ways of
claiming adherence, and creating problems - e.g. "this IP address is
unfortunately on our blacklist of known spam addresses, we hope to get
an update next month".

>> While a browser today could stop accepting all but Google-CA
>> certificates, that would hurt the browser, not the CAs, after this
>> change, the burden falls on CAs if a vendor so misbehaves.
>
> How so?

Today:
Chrome stops accepting Digicert certs. Half the web stops working for
Chrome users. Other browsers are unaffected. Digicert can continue
issuing certs as before. Site operators who find their new certs not
working are told "Chrome is buggy - just check other sites to prove it".

With this change:
Google logs stop accepting Digicert certs. The web is unaffected.
Digicert can no longer issue valid certs. If they do issue certs, site
operators who find their new certs not working are told "Digicert lacks
the proper logging".

In the first case, Chrome loses. In the second, Digicert loses. This is
a massive shift in the dynamics of the web PKI.

> Are you saying the IETF Trans WG should come up with a definition of
> what represents a trustworthy log? That IANA (or, more aptly, ICANN, a
> non-profit US corporation) should maintain a list of known trustworthy
> logs? I just want to make sure we're being explicit here.

Why does it matter who writes it down? It can be an unwritten
gentleman's agreement for all I care (as it most likely will be), as
long as we agree. If 360 browser requires at least one Chinese log,
Yandex at least one Russian, Vivaldi at least one Icelandic, Opera at
least one Norwegian, etc, certs will get bloated, and the web loses. Or
even worse, if IE requires all logs to be run by corporations, and
Firefox requires all logs to be run by non-profits, we lose
compatibility. Clearly, browsers need to agree on this.

>> I take it that part of the reason for this change was to get
>> independence, and that Google logs were deemed "independent". So that a
>> Google issued certificate with 3 Google SCTs is still deemed to have
>> independent SCTs? That in itself sounds wrong.
>
> Elaborate why, as otherwise we can't address the perceived wrongness,
> only the uncertainty being presented.

This was really meant as a question to you :P
"Company A requires you to log your certs with Company A. This is in
order to ensure company independence." - If that doesn't sound the least
bit wrong to you, I'd ask you what your definition of independence is?
To me, company A requiring you to use company A, is the opposite of
independence.

> Is your concern only with a Google-issued certificate? What if, say, a
> non-Google CA (and I'll use Digicert as an example, because they run a
> log) logged their certificate into three Google logs. Would you be
> concerned then? Why or why not?

Significantly less so than Google doing it, because the level of
independence is higher.

>> I believe logs being independent of the CA is more important than being
>> independent of each other (at least one log should be run by someone
>> else).
>
> I'm not disagreeing with you, but it would help if you spell out why.
> Objectively, this sounds entirely subjective. The majority of the logs
> accepted today are CA's logs, but you haven't said anything yet against
> this when these logs have been accepted, nor really proposed any changes
> to policy.

I fail to see how the two are linked? CA A using a log from CA B and CA
C is fine, and ensures plenty of independence, even though they are all
CA logs. CA A using logs from CA A only, would not be independent.

>> I have previously argued that ensuring at least one log is run in a
>> location with a different government than where the CA is run - so that
>> no single government can coerce a CA and a log to issue/fork secret
>> certificates to be used in secret, walled-off networks.
>

> Except such coercion is detectable and would be the death of the log.

If it is detectable, then the network would necessarily not be
walled-off, would it? :P
Some examples:
* A government surveillance team taking over all the communication
gateways of an individual, and confiscating the equipment once they have
enough information.
* A confiscated device with a trusted platform module, which will only
divulge its secrets if connected to a trusted server.
In a post-Snowden world, these examples shouldn't even seem paranoid...

> What about a CA like Symantec or GlobalSign, where the private keys are
> geographically diverse. Would a browser running a CT policy be required
> to investigate where each copy of the private key lives? What about
> subsidiary relationships - do those count towards your "where the CA is
> run" definition? How would the public be assured that this information
> was correct and due diligence was followed?

This is actually audited. How is this any different than Google
self-stating where its logs live? Which isn't even audited.

> To make sure it is clear - you want the log to not be (???) by the CA
> and not in the same jurisdiction?

At least one log by an entity different from the issuer.
At least one log with no overlapping jurisdiction with the issuer.
(Those two requirements might both be satisfied by a single log.)

> The former has definitional issues - is it operated by? How do you
> quantify that? What about the CAs that have engaged in financial
> relationships with Digicert - are those meeting your definition of
> independence? How would that be quantified - would the CA have to
> self-declare? What would they self-declare? How would the auditor -
> which I presume means WebTrust/ETSI (and thus would require 18 months,
> on the early, to incorporate into any audit frameworks) - measure this?
> The lack of a financial relationship between the log is a negative
> statement - that is, there's no evidence you can provide to show you do
> have a relationship, only suppress that evidence.

We already have temporary rules, 18 months waiting for audits isn't a
problem - we can ask CAs to self-attest in the meanwhile. I am not a
lawyer, but there is plenty of existing examples for how to avoid
conflicts of interest, spelling this out doesn't seem difficult. How did
Google ensure there are no conflict of interest with any other logs?

> With respect to jurisdictional independence, how do you quantify that?
> For example, extradition treaties involve in-kind recognition of the
> legal rights of distinct countries. And it's well known that treaties
> such as the Trans-Pacific Partnership or the EU membership agreements
> extend well into the realm of computer-based activities. So how do you
> quantify jurisdictional independence?

In practice, I don't think this is very difficult. If a request for
coercion would have to go through an independent court system, we're
good to go. This maps fairly well to the independence of a
country/region's court system. Even with treaties, the receiving party
would get a chance to be heard in a court not run by the requesting party.

>> If you do want more independence, that is achievable. It seems most logs
>> are operated by CAs anyhow, and CAs could make assurances that such logs
>> are operated by that CA alone. That would give a business incentive for
>> other CAs to choose such a log.
>
> Except most of the logs aren't operated by that CA alone, and I'm not
> sure that represents a bad thing in practice or in spirit; but it seems
> you do?

I don't see how it makes a difference how many CAs operate a log? If
multiple CAs operate a log, please rephrase the above to "the group of
CAs could make assurances that such logs are operated by that group alone".

[Ben Laurie]

On 5 May 2015 at 08:56, Sigbjørn Vik <sigb...@opera.com> wrote:
>
> On 04-May-15 19:05, Ryan Sleevi wrote:
> > On May 4, 2015 9:22 AM, "Sigbjørn Vik" wrote:
>
> Let's take a step back here. You started this thread by saying that a)
> there would no longer be a need for independent logs, and b) there would
> be a need for a Google log.

As Ryan said, we intended to say that we require one Google log, one
non-Google log.

> I assume you mean that a Google log thus maintains the independence
> attribute, but you didn't state how. Would you care to explain how you
> think it achieves this?
>
> How do users know that the Google log is independent from other logs,
> apart from a self-assured statement from the log operator?

They don't. This is precisely why we ended up with the requirement
above: in general, its difficult to determine independence of two
logs, unless you operate one of them and are sure you don't operate
the other.

If you have a better answer, we're all ears.

But surely Chrome is already able to abuse its market position in
exactly the same way? I don't get how CT changes that at all.

> >> While a browser today could stop accepting all but Google-CA
> >> certificates, that would hurt the browser, not the CAs, after this
> >> change, the burden falls on CAs if a vendor so misbehaves.
> >
> > How so?
>
> Today:
> Chrome stops accepting Digicert certs. Half the web stops working for
> Chrome users. Other browsers are unaffected. Digicert can continue
> issuing certs as before. Site operators who find their new certs not
> working are told "Chrome is buggy - just check other sites to prove it".
>
> With this change:
> Google logs stop accepting Digicert certs. The web is unaffected.
> Digicert can no longer issue valid certs. If they do issue certs, site
> operators who find their new certs not working are told "Digicert lacks
> the proper logging".

Surely not - no other browser requires SCTs, so Digicert goes right on
issuing certs which Chrome no longer accepts, just like in the first
case.

[Sigbjørn Vik]

On 05-May-15 11:20, Ben Laurie wrote:
> On 5 May 2015 at 08:56, Sigbjørn Vik <sigb...@opera.com> wrote:
>>
>> How do users know that the Google log is independent from other logs,
>> apart from a self-assured statement from the log operator?
>
> They don't. This is precisely why we ended up with the requirement
> above: in general, its difficult to determine independence of two
> logs, unless you operate one of them and are sure you don't operate
> the other.
>
> If you have a better answer, we're all ears.

So what you are saying, is that unless you happen to be employed in
Google, the suggested change makes no difference? In particular that it
makes no difference to users?

I have already suggested multiple alternatives which are auditable,
vendor agnostic, objective, and can inspire trust in the end user.

>> I can come up with lots of worst case scenarios of what a log "too big
>> to fail" could do to abuse its market position, I think you can too.
>> This is something we want to avoid.
>
> But surely Chrome is already able to abuse its market position in
> exactly the same way? I don't get how CT changes that at all.

Surely not. See below for one example not possible today. Making certain
CAs suffer due to e.g. claimed "bad connections" is another novel way.
Requiring CAs to pay per certificate is a third new approach. But surely
you do not want me to enumerate the evils of "too big to fail"? Even if
one market player is "too big to fail" in one area, that doesn't mean we
should automatically endorse it (or someone else) growing equally large
in another area?

>>>> While a browser today could stop accepting all but Google-CA
>>>> certificates, that would hurt the browser, not the CAs, after this
>>>> change, the burden falls on CAs if a vendor so misbehaves.
>>>
>>> How so?
>>
>> Today:
>> Chrome stops accepting Digicert certs. Half the web stops working for
>> Chrome users. Other browsers are unaffected. Digicert can continue
>> issuing certs as before. Site operators who find their new certs not
>> working are told "Chrome is buggy - just check other sites to prove it".
>>
>> With this change:
>> Google logs stop accepting Digicert certs. The web is unaffected.
>> Digicert can no longer issue valid certs. If they do issue certs, site
>> operators who find their new certs not working are told "Digicert lacks
>> the proper logging".
>
> Surely not - no other browser requires SCTs, so Digicert goes right on
> issuing certs which Chrome no longer accepts, just like in the first
> case.

I am assuming here that all browsers eventually will require CT and
SCTs. Please re-read with that in mind.

But even if other browsers don't support CT, Digicert's procedures will
still fail in the second case, and Digicert will stop issuing certs
until their admins can look into it. If they do continue issuing certs
anyway, when site admins will test out the new certs, they will find
that they don't work in Chrome. Digicert cannot reply "due to an
update/bug in Chrome, take it up with Google or downgrade to a working
version". The burden is on Digicert to get those certificates working,
which it will no longer be able to do.

[Ben Laurie]

On 5 May 2015 at 12:08, Sigbjørn Vik <sigb...@opera.com> wrote:
> On 05-May-15 11:20, Ben Laurie wrote:
>> On 5 May 2015 at 08:56, Sigbjørn Vik <sigb...@opera.com> wrote:
>>>
>>> How do users know that the Google log is independent from other logs,
>>> apart from a self-assured statement from the log operator?
>>
>> They don't. This is precisely why we ended up with the requirement
>> above: in general, its difficult to determine independence of two
>> logs, unless you operate one of them and are sure you don't operate
>> the other.
>>
>> If you have a better answer, we're all ears.
>
> So what you are saying, is that unless you happen to be employed in
> Google, the suggested change makes no difference? In particular that it
> makes no difference to users?

The change was not intended to make a difference to users: users can
already verify the correct operation of logs. The reason we would like
independent logs to be used is to make it less likely that failure of
a log operator would break a substantial number of certificates.

> I have already suggested multiple alternatives which are auditable,
> vendor agnostic, objective, and can inspire trust in the end user.

I reviewed your emails, and I must be missing something. The only
suggested alternative I could find was to have CAs state which logs
they are using and auditors audit that (some of?) those are
independent of the CA.

[Sigbjørn Vik]

On 05-May-15 14:43, Ben Laurie wrote:
> On 5 May 2015 at 12:08, Sigbjørn Vik <sigb...@opera.com> wrote:
>> On 05-May-15 11:20, Ben Laurie wrote:
>>> On 5 May 2015 at 08:56, Sigbjørn Vik <sigb...@opera.com> wrote:
>
>> So what you are saying, is that unless you happen to be employed in
>> Google, the suggested change makes no difference? In particular that it
>> makes no difference to users?
>
> The change was not intended to make a difference to users: users can
> already verify the correct operation of logs. The reason we would like
> independent logs to be used is to make it less likely that failure of
> a log operator would break a substantial number of certificates.

Excellent, seems we are at the crux of the issue now. If this indeed was
the purpose of the change, then the change failed to address some
important points. If there were more reasons for the change, it would be
great if you could enumerate them. If these points are no longer
addressed, the change should be reconsidered.

Users need to be able to trust the independence of logs. Technically
equipped users can verify the operation, but not the independence. We
need other methods to do this. So even though this change was not
intended to make a difference to users, it does make a negative one.

No single log should be given too much weight. With this change, Google
logs become a centralized bottleneck. Google logs become too big to
fail, something which was previously explicitly unwanted.

You want to avoid failure of a log operator having a substantial effect.
This change ensures the opposite: If Google log services should stop
accepting new certs (e.g. due to legal counsel saying so), all cert
issuing for Chrome would be impossible.

The collapse argument of Ryan (a log should be entirely removed) is more
of an issue with this setup, as before the change. Should Google logs go
down, no certs would validate.

>> I have already suggested multiple alternatives which are auditable,
>> vendor agnostic, objective, and can inspire trust in the end user.
>
> I reviewed your emails, and I must be missing something. The only
> suggested alternative I could find was to have CAs state which logs
> they are using and auditors audit that (some of?) those are
> independent of the CA.

Here are three methods I suggested:
1. CAs self-state some logs they have no overlapping interests with.
They can then use these logs as independent logs. This statement is
followed up contractually and in audits.

2. Logs and CAs (self-)declare from which countries private keys can be
accessed. For CAs, this can be audited. Logs with countries which do not
overlap with CA countries count as independent. (This needs to run in
parallel to some other solution like 1 or 3.)

3. Ask logs to voluntarily go through audits. Given that most are run by
CAs, this should be doable. These audits check if there are overlapping
interests with other CAs. Audited logs with no CA overlap qualify as
independent.

[Ben Laurie]

On 5 May 2015 at 14:18, Sigbjørn Vik <sigb...@opera.com> wrote:
> On 05-May-15 14:43, Ben Laurie wrote:
>> On 5 May 2015 at 12:08, Sigbjørn Vik <sigb...@opera.com> wrote:
>>> On 05-May-15 11:20, Ben Laurie wrote:
>>>> On 5 May 2015 at 08:56, Sigbjørn Vik <sigb...@opera.com> wrote:
>>
>>> So what you are saying, is that unless you happen to be employed in
>>> Google, the suggested change makes no difference? In particular that it
>>> makes no difference to users?
>>
>> The change was not intended to make a difference to users: users can
>> already verify the correct operation of logs. The reason we would like
>> independent logs to be used is to make it less likely that failure of
>> a log operator would break a substantial number of certificates.
>
> Excellent, seems we are at the crux of the issue now. If this indeed was
> the purpose of the change, then the change failed to address some
> important points. If there were more reasons for the change, it would be
> great if you could enumerate them. If these points are no longer
> addressed, the change should be reconsidered.
>
> Users need to be able to trust the independence of logs. Technically
> equipped users can verify the operation, but not the independence. We
> need other methods to do this. So even though this change was not
> intended to make a difference to users, it does make a negative one.

Why do users need to be able to trust the independence of logs?

> No single log should be given too much weight. With this change, Google
> logs become a centralized bottleneck. Google logs become too big to
> fail, something which was previously explicitly unwanted.
>
> You want to avoid failure of a log operator having a substantial effect.
> This change ensures the opposite: If Google log services should stop
> accepting new certs (e.g. due to legal counsel saying so), all cert
> issuing for Chrome would be impossible.

Except Chrome would obviously revise its policy in this case.

> The collapse argument of Ryan (a log should be entirely removed) is more
> of an issue with this setup, as before the change. Should Google logs go
> down, no certs would validate.

That is not correct.

>>> I have already suggested multiple alternatives which are auditable,
>>> vendor agnostic, objective, and can inspire trust in the end user.
>>
>> I reviewed your emails, and I must be missing something. The only
>> suggested alternative I could find was to have CAs state which logs
>> they are using and auditors audit that (some of?) those are
>> independent of the CA.
>
> Here are three methods I suggested:
> 1. CAs self-state some logs they have no overlapping interests with.
> They can then use these logs as independent logs. This statement is
> followed up contractually and in audits.

OK. CAs are not the only entities that can log - how would server
operators comply with this requirement?

> 2. Logs and CAs (self-)declare from which countries private keys can be
> accessed. For CAs, this can be audited. Logs with countries which do not
> overlap with CA countries count as independent. (This needs to run in
> parallel to some other solution like 1 or 3.)

This seems a little weird. For example, I run a log on AWS: which
countries would I list?

And again, how would server operators comply?

Also, I don't see why you need to log and the CA to be independent -
you just need the logs to be independent.

> 3. Ask logs to voluntarily go through audits. Given that most are run by
> CAs, this should be doable. These audits check if there are overlapping
> interests with other CAs. Audited logs with no CA overlap qualify as
> independent.

Overlapping interests with other logs, you mean? Again, CAs are not logs.

BTW, I don't think it is the case that most logs are run by CAs and
anyway we should certainly not assume or require it.

[Sigbjørn Vik]

On 05-May-15 15:32, Ben Laurie wrote:
> Why do users need to be able to trust the independence of logs?

For the same reason users need to be able to trust CAs. Remember that
this is a trust system. We want to have complete trust that logs cannot
be coerced. Users also need to have trust that all the other benefits of
independence are lived up to. Without trust, the web PKI is worthless.

>> You want to avoid failure of a log operator having a substantial effect.
>> This change ensures the opposite: If Google log services should stop
>> accepting new certs (e.g. due to legal counsel saying so), all cert
>> issuing for Chrome would be impossible.
>
> Except Chrome would obviously revise its policy in this case.

Obviously. But the log might shut down immediately, it still takes time
to get a Chrome update out. These kind of reliability issues are
supposed to be taken care of by independence. When they are not, as in
this case, we should revise the requirements.

>> The collapse argument of Ryan (a log should be entirely removed) is more
>> of an issue with this setup, as before the change. Should Google logs go
>> down, no certs would validate.
>
> That is not correct.

You argument is utterly unconvincing :P

>> 1. CAs self-state some logs they have no overlapping interests with.
>> They can then use these logs as independent logs. This statement is
>> followed up contractually and in audits.
>
> OK. CAs are not the only entities that can log - how would server
> operators comply with this requirement?

I assume you mean a certificate owner, who chooses to submit the
certificate for additional SCTs? If initial SCTs provided by the CA
weren't sufficient, he should complain ;) Certificate owners could use
the logs that are allowed by the CA - if this still isn't enough to make
the cert work, as for the money back and use a different CA. I don't
think SCTs should work when logged much after the not-valid-before date
in any case, that way it is impossible to backdate certificates.

>> 2. Logs and CAs (self-)declare from which countries private keys can be
>> accessed. For CAs, this can be audited. Logs with countries which do not
>> overlap with CA countries count as independent. (This needs to run in
>> parallel to some other solution like 1 or 3.)
>
> This seems a little weird. For example, I run a log on AWS: which
> countries would I list?

Any country where the private key might be accessed. In this case, if
you have the login, the private key sits in the cloud, and you happen to
be in the country X, the government of country X can coerce you to give
them the private key.

> Also, I don't see why you need to log and the CA to be independent -
> you just need the logs to be independent.

No, if you want trust in the system, you need the CA and a log to be
independent - see previous mails. Of course, having two independent logs
achieve the same effect. This proposal can of course be tweaked to hold
for logs only if you so prefer.

>> 3. Ask logs to voluntarily go through audits. Given that most are run by
>> CAs, this should be doable. These audits check if there are overlapping
>> interests with other CAs. Audited logs with no CA overlap qualify as
>> independent.
>
> Overlapping interests with other logs, you mean? Again, CAs are not logs.

As with the above, you can certainly tweak this to mean what you wrote
as well. There are lots of possibilities. :)

[Ben Laurie]

On 5 May 2015 at 14:59, Sigbjørn Vik <sigb...@opera.com> wrote:
> On 05-May-15 15:32, Ben Laurie wrote:
>> Why do users need to be able to trust the independence of logs?
>
> For the same reason users need to be able to trust CAs. Remember that
> this is a trust system. We want to have complete trust that logs cannot
> be coerced. Users also need to have trust that all the other benefits of
> independence are lived up to. Without trust, the web PKI is worthless.

But that's the whole point. Logs are verifiable, precisely so you
don't have to trust them.

>>> You want to avoid failure of a log operator having a substantial effect.
>>> This change ensures the opposite: If Google log services should stop
>>> accepting new certs (e.g. due to legal counsel saying so), all cert
>>> issuing for Chrome would be impossible.
>>
>> Except Chrome would obviously revise its policy in this case.
>
> Obviously. But the log might shut down immediately, it still takes time
> to get a Chrome update out. These kind of reliability issues are
> supposed to be taken care of by independence. When they are not, as in
> this case, we should revise the requirements.
>
>>> The collapse argument of Ryan (a log should be entirely removed) is more
>>> of an issue with this setup, as before the change. Should Google logs go
>>> down, no certs would validate.
>>
>> That is not correct.
>
> You argument is utterly unconvincing :P

Certificates are only required to have one SCT that is from a log that
is working. If we require, as we plan, to require one non-Google log,
then if Google's logs go down, certs continue to validate.

>
>>> 1. CAs self-state some logs they have no overlapping interests with.
>>> They can then use these logs as independent logs. This statement is
>>> followed up contractually and in audits.
>>
>> OK. CAs are not the only entities that can log - how would server
>> operators comply with this requirement?
>
> I assume you mean a certificate owner, who chooses to submit the
> certificate for additional SCTs?

For SCTs, not necessarily additional.

> If initial SCTs provided by the CA
> weren't sufficient, he should complain ;) Certificate owners could use
> the logs that are allowed by the CA - if this still isn't enough to make
> the cert work, as for the money back and use a different CA.

Sorry, but CT does not require CAs to include SCTs.

> I don't
> think SCTs should work when logged much after the not-valid-before date
> in any case, that way it is impossible to backdate certificates.

Who cares if a certificate is backdated?

>
>>> 2. Logs and CAs (self-)declare from which countries private keys can be
>>> accessed. For CAs, this can be audited. Logs with countries which do not
>>> overlap with CA countries count as independent. (This needs to run in
>>> parallel to some other solution like 1 or 3.)
>>
>> This seems a little weird. For example, I run a log on AWS: which
>> countries would I list?
>
> Any country where the private key might be accessed. In this case, if
> you have the login, the private key sits in the cloud, and you happen to
> be in the country X, the government of country X can coerce you to give
> them the private key.

And how about the governments of countries that can coerce Amazon?

>> Also, I don't see why you need to log and the CA to be independent -
>> you just need the logs to be independent.
>
> No, if you want trust in the system, you need the CA and a log to be
> independent - see previous mails. Of course, having two independent logs
> achieve the same effect. This proposal can of course be tweaked to hold
> for logs only if you so prefer.

Once more, CT is about _proving_ correct operation, not trust.

[Ryan Sleevi]

I admit, these replies are getting out of hand, and so I wanted to
respond to your concerns.

I think, in the sake of communication, we need to vastly compress
this. The replies here and the follow-on discussion with Ben make it
clear to me that there's some confusion about what the existing
independence requirement was meant to accomplish, as well as many
fundamental misunderstandings about the trust model of CT that have
lead to just a vocal reaction against. I think if we can work through
those, you will see that not only is this policy change "not a big
deal", but arguably *good*, and why your proposed solutions simply do
not work - on paper or in practice.

On Tue, May 5, 2015 at 12:56 AM, Sigbjørn Vik <sigb...@opera.com> wrote:
> How does company A requiring logs from company A increase independence?

I didn't claim that requiring a Google log increased independence, but
that it obviates the need for independence. There's a marked
difference.

> My general issue is that this is creating log services that are too big
> to fail (3 Google logs is still just one log service). Changing the
> requirement to also need a non-Google log helps, but doesn't suffice.
> Changing the requirement to be a log independent of Google would also
> help, but would still create a log "too big to fail".

Except that this is irrelevant (as Ben has pointed out later), since
*any* change to Chrome is equivalent to "too big to fail". And that's
(part of) the point - that requiring a Google log that implements
policy X is, from the client perspective, indistinguishable from
implementing policy X in Chrom[e/ium]. They're two sides of the same
coin.

> Let's assume some browser which already is too big to fail (meaning
> certs must work in it) makes a requirement for a particular log to be
> used. This means (at least some) CAs will necessarily make procedural
> changes so that they issue no certs until they have an SCT from that
> log. To demonstrate what power such a log has, imagine it inadvertently
> failing to accept connections from Russia for a weekend - making Russian
> CAs unable to issue certs. That would introduce a serious CA bias - a
> bias which doesn't exist today.

1) I want to again restate that they are _not_ unable to issue certs.
2) That bias already exists today, and HEAVILY SO, in as much as it
can takes YEARS for a root cert to be added to browsers. I think
plenty of CAs can attest to this fact. It's a bias that exists today
with the operation of the EV programs by various browsers -
recognition of EV is neither instantaneous nor guaranteed, but IS
necessary to receive the EV status.

Even something as "simple" as committing a change is non-deterministic
as to when or how many users will have sufficiently updated to
incorporate those changes. I think the Android story is a prime
example of carrier-controlled update schedules that are presently
beyond our ken for when and how clients will be updated to recognize
those roots.

Now, perhaps your point is that there are more pieces in the system,
but I don't think I'd agree with that. The pieces are different, but
the effects are the same.

> I can come up with lots of worst case scenarios of what a log "too big
> to fail" could do to abuse its market position, I think you can too.
> This is something we want to avoid.

No, I think it'd help if you be explicit about what you perceive as
threats. As Ben notes, one of the significant factors of CT is that
you don't have to "trust" the log (in the same way that you have to
"trust" a CA) - anything it tells you can be separately verified
(STHS, inclusion proofs, and gossip).

The independence requirement served multiple purposes in the
short-term, but is not intrinsically necessary in a well-functioning
system. It was just scaffolding to bootstrap the initial
implementation, and as secondary pieces are built out (the ability to
freeze/mirror a log, consistency checking, proof gossip, etc), they
become less important for an intrinsic implementation of CT. That
said, not all the pieces are there yet, AND there is still significant
compelling reason to require disclosure to Google-operated logs as
part of Chrome's overall goal to restore and improve trust in the PKI
system.

> We must have different definitions of "vendor agnostic", what is yours?
> I fail to see how 99.99% uptime and 1 hour MMD evaluates differently for
> Safari and Yandex. Requiring at least one US log does evaluate quite
> differently though. The first example fits my definition of agnostic,
> the second does not.

Because Safari might require 98% update, Yandex may except a 48 hour
MMD. They're the same thing - they're policies being defined by
implementers.

> We don't want to reduce this to "trust us" semantics, "we would have
> disclosed had we done that". We want to build a robust system where this
> isn't required. If a malicious log wanted, there are plenty of ways of
> claiming adherence, and creating problems - e.g. "this IP address is
> unfortunately on our blacklist of known spam addresses, we hope to get
> an update next month".

I'm really not sure I follow your point or your complaint here,
especially in the broader scenario with Ben's clarifications.

That is, I'm not denying it's possible - but that it *does not matter*
if a log does this, for the many reasons hopefully clearly raised
elsewhere in this thread.

> Today:
> Chrome stops accepting Digicert certs. Half the web stops working for
> Chrome users. Other browsers are unaffected. Digicert can continue
> issuing certs as before. Site operators who find their new certs not
> working are told "Chrome is buggy - just check other sites to prove it".
>
> With this change:
> Google logs stop accepting Digicert certs. The web is unaffected.
> Digicert can no longer issue valid certs. If they do issue certs, site
> operators who find their new certs not working are told "Digicert lacks
> the proper logging".
>
> In the first case, Chrome loses. In the second, Digicert loses. This is
> a massive shift in the dynamics of the web PKI.

Um, no?

With this change:
Google logs stop accepting Digicert certs. New Digicert certs no
longer work in Chrome.

How is that different than:
Chrome stops accepting Digicert certs. New Digicert certs no longer
work in Chrome.

I mean, the latter scenario isn't just hypothetical - it's obviously
real (as in the case of CNNIC), where existing certs were accepted but
not new certificates.

> Why does it matter who writes it down? It can be an unwritten
> gentleman's agreement for all I care (as it most likely will be), as
> long as we agree. If 360 browser requires at least one Chinese log,
> Yandex at least one Russian, Vivaldi at least one Icelandic, Opera at
> least one Norwegian, etc, certs will get bloated, and the web loses.

I don't see that as a bad outcome - that is, that different browsers
require different logs. Your concern is bloat, and I can understand
and appreciate that, but it's also quite clearly an exagerated
hypothetical that no one is proposing, nor is it immediately pressing
to solve right now, nor does it intrinsically prevent progress.

> Or
> even worse, if IE requires all logs to be run by corporations, and
> Firefox requires all logs to be run by non-profits, we lose
> compatibility.

Yes, anything is possible. This specific scenario you describe is
unrealistic-to-absurd, though, because the requirements for CT are NOT
that you need to "trust all logs", or that "all logs meet criteria X",
just that *enough* logs meet whatever criteria set. If Browser 1
required *all* logs meet criteria X, and Browser 2 required *all* logs
meet criteria Y, the bug is NOT that criteria X and Y are disjoint,
the bug is that they're requiring *all* logs meet that criteria. It
would demonstrate a fundamental misunderstanding of CT to do that. And
while that's possible, in theory, much the same way it's possible that
small green people from Mars will land on Earth tomorrow, it's
extremely unlikely, so we needn't lose sleep and fret over it.

> Clearly, browsers need to agree on this.

I strongly disagree on this, for reasons explained both in this
response and elsewhere in this thread. There's no intrinsic need for
agreement, and while agreement is nice, it's far from a must-have
property.

> This was really meant as a question to you :P
> "Company A requires you to log your certs with Company A. This is in
> order to ensure company independence." - If that doesn't sound the least
> bit wrong to you, I'd ask you what your definition of independence is?
> To me, company A requiring you to use company A, is the opposite of
> independence.

"Company A requires you to log your certs with Company A, as an
alternative to ensuring that a sufficient number of your logs are
organizationally independent of eachother".

Let's be clear here, it's not to *ensure* independence, it's an
*alternative* to independence.

>> What about a CA like Symantec or GlobalSign, where the private keys are
>> geographically diverse. Would a browser running a CT policy be required
>> to investigate where each copy of the private key lives? What about
>> subsidiary relationships - do those count towards your "where the CA is
>> run" definition? How would the public be assured that this information
>> was correct and due diligence was followed?
>
> This is actually audited. How is this any different than Google
> self-stating where its logs live? Which isn't even audited.

I'm afraid you haven't been following the CA/B Forum or WebTrust/ETSI
if that's how you think audits work :)

TL;DR: No, it doesn't work that way, it never has. If we had even a
sliver of such a system, the very situations that led to CT would be
far less prevalent than they are.

> At least one log by an entity different from the issuer.

How can that be programatically enforced? (Trick question, it can't,
not without reintroducing all the definitional issues).

> At least one log with no overlapping jurisdiction with the issuer.
> (Those two requirements might both be satisfied by a single log.)

How can that be programatically enforced? (Trick question, it can't,
not without reintroducing all the definitional issues).

> We already have temporary rules, 18 months waiting for audits isn't a
> problem - we can ask CAs to self-attest in the meanwhile. I am not a
> lawyer, but there is plenty of existing examples for how to avoid
> conflicts of interest, spelling this out doesn't seem difficult.

While I'm also not a lawyer, I encourage you to just spend a lunch
trying to think of a definition that could possibly be verified
independently and sufficiently clear. My wager is that it's not
possible, as it's an ontology that requires a complete and
comprehensive understanding of global business and global law AND all
of the (conflicting) local jurisdictional issues.

It's an (un)surprisingly hard problem, and you can't just hand-wave it
away with "Audits solve this"

Indeed, it's an explicit non-goal to introduce auditing requirements,
because CT doesn't require you inherently trust the log, since you can
verify the log.

[Sigbjørn Vik]

Ben and Ryan,

Thanks for the responses so far. Replying in general.

Trust is intrinsic to the web PKI, and it couldn't work without it. Not
just trust in the cryptographic calculations, but in the system, the
people, the implementations and its future. Trust needs to be an
intrinsic property of everything we do. Waving away the needs for users
to trust the overall system, because individual parts can be verified
fails to see the larger issue.

Chrome being too large to fail, is very different than a log being too
large to fail. If Google were to become a CA, that doesn't mean we
should allow that CA to become too large to fail, just because Chrome
is. Having an issue in one part of the system, doesn't mean we should
propagate that issue to another part - instead we should work to contain
the issue.

I believe that if an entity fails to understand other's concerns, it is
unlikely to make future decisions which take those concerns into
account. If anything, this discussion has only made me more convinced
that requiring Google logs is an unwise move, and it has made me lose
trust in how much CT will be able to improve on the current state of
affairs. :(

There is certainly no need for web browsers to agree on CT details, they
can all implement it their own way. In fact, there is no need for the
current CT policy to work for other browsers at all. It seems to me that
CT is turning out to be a Google policy, not a web specification. That's
sad, but OK. :-/

[Matt Palmer]

On Wed, May 06, 2015 at 10:18:34AM +0200, Sigbjørn Vik wrote:
> Chrome being too large to fail, is very different than a log being too
> large to fail. If Google were to become a CA, that doesn't mean we
> should allow that CA to become too large to fail, just because Chrome
> is. Having an issue in one part of the system, doesn't mean we should
> propagate that issue to another part - instead we should work to contain
> the issue.

I've read all of the messages you've sent in this thread, and I'm yet to
find a credible description of how TBTF can apply to any CT log, Google-run
or otherwise. On the contrary, Google's CT policy, both the current version
and this new proposal, tries hard to explicitly avoid the problem of any
log becoming so essential that it cannot fail, or be forcibly removed from
"the system", without causing disruption to the Internet PKI.

> I believe that if an entity fails to understand other's concerns, it is
> unlikely to make future decisions which take those concerns into
> account.

On the other hand, an entity which fails to coherently describe its concerns
can hardly blame others for failing to take those concerns into account.

> If anything, this discussion has only made me more convinced
> that requiring Google logs is an unwise move, and it has made me lose
> trust in how much CT will be able to improve on the current state of
> affairs. :(

Having CAs publicising all issued certificates is what will improve the
current state of affairs. Everything else is window dressing; merely the
means to that end.

For the record, I'm not particularly in favour of this change, but at the
same time I'm not vehemently against it. I can't see any way in which this
policy makes things any worse, in the short-to-medium term. On the other
hand, I don't think it is a practical improvement, but I don't know what the

"feedback and discussion with Certificate Authorities and Log Operators"

was. Since I don't have to write the code to implement the policy, I don't
have an opinion on making more work for the Chromium devs. <grin>

> There is certainly no need for web browsers to agree on CT details, they
> can all implement it their own way. In fact, there is no need for the
> current CT policy to work for other browsers at all. It seems to me that
> CT is turning out to be a Google policy, not a web specification. That's
> sad, but OK. :-/

CT is actually "turning out" to be less of a Google-only thing than it was
initially. Google people did all the hard work of developing RFC6962 and
implementing support for it, so it started out as a *very* Google thing.
Now, however, plenty of non-Google people are involved in the TRANS WG group
(the IETF working group tasked with writing a standards-track RFC version of
the CT protocol). The control of CT, the technology, is becoming less
Google-centric over time.

That the Chromium CT policy is a Google policy shouldn't be controversial.
Chromium is largely a Google-developed piece of software, so it makes sense
that the policies in Chromium would be Google policies. I'm confident that
the policies that Opera implements in their software could be consudered
"Opera policies", rather than "web specifications", too.

- Matt

--
I seem to have my life in reverse. When I was a wee'un, it seemed perfectly
normal that one could pick up the phone and speak to anybody else in the
world who also has a phone. Now I'm older and more experienced, I'm amazed
that this could possibly work. -- Peter Corlett, in the Monastery

[Ryan Sleevi]

Warning: This is quite a long email, but I want to make sure to
comprehensively explain how we came to the current policy, why we're
looking to change it, why we think it's OK, and what the overall
long-term picture for CT looks like. Even for how long it is, it's far
from comprehensive as to all the design concerns, but I honestly and
truly want to make sure there's no feeling that we're being
disingenuous in proposing the update we have.

I realize this is a long email, and in the worst case, it may result
in a message that strives for a point-by-point takedown or take
summaries out of context. I don't think that'd be entirely helpful for
discussion though. If there are still concerns, it may be more useful
to discuss what goals may have been omitted (intentionally or
unintentionally) from our set, and what options may exist to achieve
those goals. We want to make sure we're keeping the communities
interests in mind, but at the same time, we want to make sure the
policy is sensibly implementable and enforceable.

== Background ==

As a precursor, let me reiterate the end goal and the end state of things:
- As a protocol, CT does not require that you intrinsically trust any
of the logs you recognize. CT is based on the notion of "Trust, but
verify" - but the recognition of a Log is not in and of itself a
recognition of any form of special status or trust
- CT is not designed to be a trust mechanism. I want to reiterate
that, as it seems there's some confusion. It can detect misissuance
after-the-fact, and through that, deter misissuance, but it does not
deny misissuance, nor is that a goal.
- In the whole system, hostile logs are expected, but their ability to
do damage or hide malfeasance is so curtailed that the _value_ of
being hostile is virtually non-existent.
- It is _accepted_ that a user who is fully isolated and segmented
from the world will not be able to report to the world their view of
hostility. That's long been understood in the design of CT. However,
anyone who has worked in network security knows that machines are
always porous, and an attacker has to expend significant resources to
fully segment the user. Indeed, the resources are often so expensive
that it's far more viable to leverage another attack - whether it be
through direct physical compromise (e.g. Stuxnet), remote tailored
exploits (e.g. NSA's TAO), or things along that line. This
significantly raises the bar for SSL/PKI from the terrible low that
some people believe it is.

Along those lines, we're doing a staged roll-out. Along each phase,
more people gain experience implementing and using, the system becomes
more robust, and concrete value is added in each step. Additionally,
we can use and leverage the past experience to improve on future
plans, which may, can, and do change. This proposal is simply the next
stage in that iteration.

Our current, and proposed, log policies and CT policies are designed
as incremental bootstraps into the full system. There's been
significant demonstrated value in the current approach, and as
Chromium continues implementing more, everyone wins.

So now that I've got that out of the way, let me explain a bit about
how we got to where we are today, and where and why we see this
proposed policy change as the next step.

== Why CT ==
I'll save restating all of the reasons why we've been pushing for CT
in Chrome, but I will highlight the most important _at present_.

Today, if Chromium is going to present to users strong signals of
identity (aka the EV bar), we want to ensure those signals are
reliable, and those tasked with vetting those signals (CAs) are
reliable. We have little-to-no faith in the audit system at present,
which can easily be understood by looking at the corpus of
certificates that exist. Further, if you discuss with virtually any of
the auditors or the relevant accreditation bodies (WebTrust or those
in the ETSI system), you will understand that _technical_ compliance
is NOT something that's generally checked, measured, quantified,
enforced, or any of the other things you might assume.

To this end, CT is an augmentation to Chromium's existing policies
regarding EV recognition. That is, in addition to ensuring that an
appropriate auditor using an appropriate audit criteria has evaluated
as CAs claims, we want to vet the ongoing technical compliance with
the policies that the CA is meant to uphold, and in a
user-privacy-preserving manner (e.g. not simply reporting every
certificate that a user encounters, or a statistically problematic
portion thereof, to Google)

== Why the Current Policy ==
The current CT policy and Log Inclusion policy are designed with these
goals in mind. In particular, we (Google) want reasonable assurances
that certificates are being logged appropriately, and we (Google) want
reasonable assurances that if we present information as accurate to
the user, it meets our bar.

However, there are also a number of aspects of CT not (yet)
implemented in Chrom[e/ium]. For example, SCT inclusion proofs and the
gossip thereof are a significant factor for detecting whether or not a
log is behaving hostilely (by violating the append-only requirement
and forking the log), but that's not yet fully implemented. Another
example is how to fetch SCT inclusion proofs in a privacy preserving
manner (e.g. without disclosing to the Log operator every site you've
been to), which is closely related to gossip. Likewise, a historically
consistent view of STHs (and their inclusion proofs). These are all
things being implemented in Chromium, and are part of the overall CT
picture, but are not quite in place yet.

But that's OK, because we can still meet our initial goals (ensuring
conformance) with far less than "the whole system", and as we build
"the whole system", we get far more.

Because we lack these things, we wanted a policy that could give us
(Google) and the many who rely on Chromium (such as Opera) confidence
in the system, while still being achievable for CAs. Indeed, for our
initial roll-out, we could have required certificates _exclusively_ be
logged in a single Google log as the only requirement, and that would
have satisfied our (Google's) needs. However, we wanted even the
initial system to be usable by others, especially those who don't
trust Google, and so we required at the outset a multitude of logs
with a multitude of operators.

This is to defend against the four C's I mentioned earlier:

Collapse - A log accidentally and unintentionally falling apart (we've
already seen one run into operational challenges)
Compromise - A log being owned in some way that causes it to present a
view controlled by a remote attacker, even if the log is well
intentioned.
Collusion - A log intentionally behaving hostilely, such that it
actively works to present a hostile view to the world for reasons that
are best not speculated about. Indistinguishable from compromise, save
by intent.
Coercion - A log being forced by extraordinary means to present a
hostile view, such as by judicial or (unfortunately) non-judicial
order. Indistinguishable from compromise, save by means.

As I said at the outset - the latter 3 Cs are expected, and the whole
CT system detects, deters, and defends against them. The first -
collapse - is primarily an operational concern, but we have ample
evidence that unless operational concerns are made mandatory,
participants in the PKI system _will_ botch this.

However, absent the full system, the current policy works to deter
them. Collapse (of any non-Google log) is deterred by having a Google
log that uses Google's expertise in scalable global systems.
Compromise (of a non-Google log) is defended against by having a
Google-log required - you gain nothing if you only compromise
non-Google. To the extent you trust Google, collusion is defended
against because if we wanted to collude, we could just land native
code that did whatever evil we wanted. Coercion - requiring a split
view be presented - is a risk for Google logs, yes. But so to is
Chromium code - you never can be truly sure that Google hasn't added a
backdoor through judicial coercion.

I'm not trying to scare monger on that last point - I love our Google
lawyers - but the topic of trusting trust is a topic as old as
computing, and the underhanded C competition show how easy it is to
do. If you genuinely consider coercion a threat, then the only
solution is to build every single piece of hardware and software
yourself, from scratch, lest you run the risk of backdoor. Anything
less than that, and you're discussing tradeoffs, and once you're
willing to do that, you're able to understand why we consider the risk
of coercion of a log to be far less appealing than just coercing
Chrome to serve hostile bits.

Another part of the policy was pragmatic - how quickly can we deliver
an update to Chrome's users if we needed to. We wanted to ensure that
the odds of us needing to do any out of band updates for CT to be
extremely low. This is why, for example, we have a log inclusion
policy that has requirements on MMD, compliance testing, and uptime.
It's also why we require logs operate in the public interest, another
sort of nebulous term that we'll be tackling soon. This is not because
they're intrinsic requirements of CT - they simply help keep the
management overhead low as the full system is built out.

That is, put differently, we don't want to have to add/remove a log
every day - that's not a system that scales organizationally, even if
CT itself is wholly fine with that.

And finally, to that end, we wanted to ensure the system was not gamed
by parties interested in seeing CT fail. As unfortunate as it is,
there are some entities actively hostile to CT and, were the means to
game the system available, our belief is that they actively would take
advantage of them. The current policies significantly reduce the
opportunities and incentives for this.

== Why the change ==
As you can see from past discussions on this list, as well places like
https://cabforum.org/2015/03/11/2015-03-11-minutes-of-cupertino-f2f-meeting-34/
, the question of what does independence mean is one that is
frequently asked. While we hoped to have a more robust system during
these bootstrapping phases, at the end of the day, it doesn't really
matter. "Google" and "not-Google" can fully accomplish the goals I
laid out above.

As we've evalauted our experience, and our next steps, we think we can
safely relax this requirement without undermining any of these goals,
or introducing new ways for hostile parties to game the system.

== What comes next ==
As I said, we're already working on the next phases of implementation,
to continue to make Chrome's CT implementation robust and aligned with
the overall goals for CT.

- We're working on privacy-preserving ways for clients to fetch
inclusion proofs for the SCTs they've encountered (thus ensuring all
certificates are logged and MMDs honoured)
- We're working on privacy-preserving ways for users to gossip the
STHs they've encountered (thus ensuring that logs do not have the
ability to fork and present hostile views)
- We're working on gathering better metrics and insights into log
reachability and uptime from the perspective of clients (a historic
problem when comparing CA's reports of OCSP status vs actual user
experience)
- We're working on improving our (Google's) ability to reduce the
impact if a log goes offline, minimizing or eliminating any disruption
to users, while still maintaining trust in the system - past and
present.

As these roll out in time, I think we'll have greater ability to relax
requirements on independence. Requiring a minimum number of SCTs is
still primarily an operational concern, and even if we're able to
wholly mitigate things from the perspective of Chrome/Chromium, we may
chose to keep sane requirements in place.

== Closing notes ==
Again, I want to re-emphasize that CT does not require trusting the
logs in its full forms. Gossip and inclusion proofs provide far more
empirical data than any set of policies good. But we're not quite
there yet.

It's a system that has multiple stakeholders, each of which gain
experience every step of the way and help build out the full system.
Things remain fairly fluid, and that's good - we build the scaffolding
for the system, we fill in the rough parts, and we eventually get to a
world where CT can be required for all certificates (which has always
been the end game) in a scalable and reliable way.

For other browsers looking at CT, it's ideal for them to get involved
early, rather than later, as it helps influence the designs and
properties. For example, I emphasized repeatedly the
privacy-preserving properties we're preserving. It may be that others
care less about those properties, or it may be that others care more
about certain attacks, and having implementations that allow them to
experiment and experience different solutions are a net-win, not a
net-loss.

Finally, we're not trying to solve every problem in one pass. There
will still remain challenges that will need solving, but are not
intrinsic for value to be realized. For example, how do you distribute
logs such that monitors can have full awareness of the set of logs to
look at? The public suffix list provides one such example of vendor
collaboration. IANA provides another. There are many systems
in-between that may also be viable. For Chrome's implementation, you
only have to worry about updating your set of recognized logs every 6
weeks (e.g. with every release). That's quite a long time compared to
other systems, such as the DNS root zone database, for example, that
updates thrice daily, or the public suffix list, which could be
updated twice weekly.

I can appreciate Opera's concerns with not wanting to trust Google
(outside of the code and infrastructure for that code that you already
trust us for ;D). There are lots of ways to mitigate that. However, I
don't think objecting to policy language that can't be implemented or
sanely defined really accomplishes that, so I hope we can find a
different path forward to resolve your concerns. So far, the proposals
have all suffered from the limitations of the current policy, and have
been things we've entertained and dismissed for that reason. Hopefully
the above explains why your concerns are probably unwarranted, and why
the proposal is a win for everyone, all as part of the next stage in
deploying CT.

[Matt Palmer]

Hi Ryan,

Thanks for this lengthy exposition of Google's position re: CT. It
provides valuable rationale for why you're proposing the policy change.

- Matt

[Ryan Sleevi]

Does anyone else have any feedback on this thread?

Sigbjorn, does the aforementioned exposition help change Opera's opposition at all? Does it imply that Opera will be forking the CT policy from Chromium? It'd be helpful to clarify on the list if possible, especially if there is a counter-proposal to be made.

Without wanting to diminish the contributions you've put forward so far, I don't think we could enforce (or define) what you've proposed, so if there are alternate proposals, it'd be great to know. Otherwise, I think this policy update is better than what we have, and though not perfect, a step forward.

[Sigbjørn Vik]

On 19-May-15 00:42, Ryan Sleevi wrote:

> Sigbjorn, does the aforementioned exposition help change Opera's
> opposition at all?

Not really, it contains the same contents as the preceeding discussion.

> Does it imply that Opera will be forking the CT
> policy from Chromium?

It implies that we'd like to make a better policy for Opera users. Doing
so has costs and difficulties though, I'll leave foretelling the future
to professional fortune tellers. :)

[Ryan Sleevi]

On Mon, May 18, 2015 at 3:42 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

Does anyone else have any feedback on this thread?

I'd like to thank everyone for the long and productive discussion that this produced, for the suggested edits and clarifications, and for the continued participation.

I've updated the Certificate Transparency EV/CT Plan to reflect this. It is linked from both https://sites.google.com/a/chromium.org/dev/Home/chromium-security/certificate-transparency and https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy , but the new policy document is https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy/EVCTPlanMay2015edition.pdf?attredirects=0

We hope that this addresses the needs of CAs, while moving us collectively one step closer to a system that can relax these policies further.

[Michael Klieman]

Thanks Ryan. This is a helpful update to the policy. 

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvZscvwV0Hq%2BKwre-NwgGfz9k1x5SYvkOw1r4f%3DUUCXmuA%40mail.gmail.com.

[Ray Cheng]

Can you clarify whether the May 2015 policy update will be rolled out to a stable Chrome release by July 1, 2015?

My question is centered around whether we would need to support the previous Dec 2014 policy around log independence from July 1, 2015 until the latest policy takes effect. If the latest policy rolls out to stable Chrome by July 1, this will not be an issue.

[Iñigo Barreira]

Ryan, can you also check this site https://www.efpe.eu? I see that it has the 3 logs from google and can't find another one so is it complying with the current policy? With the may2015 one? Somewhere else where to look at? Just to be clear.

--

You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/2c0b852e-2013-46f7-bc92-ce78468c9358%40chromium.org.

[Ryan Sleevi]

On Wed, Jun 10, 2015 at 6:59 AM, Ray Cheng <ray....@entrust.com> wrote:

Can you clarify whether the May 2015 policy update will be rolled out to a stable Chrome release by July 1, 2015?

My question is centered around whether we would need to support the previous Dec 2014 policy around log independence from July 1, 2015 until the latest policy takes effect. If the latest policy rolls out to stable Chrome by July 1, this will not be an issue.

Could you clarify what you mean by "support the previous Dec 2014 policy"? 

Under the Dec 2014 policy (with the relaxation of independence), you were required to include the minimum number, with at least one from Google.

Under the present, May 2015 policy, you're required to include the minimum number, with at least one from Google and one not from Google.

Is there something else that I missed that concerns you?

[Ryan Sleevi]

On Wed, Jun 10, 2015 at 7:51 AM, Iñigo Barreira <inigo.b...@gmail.com> wrote:

Ryan, can you also check this site https://www.efpe.eu? I see that it has the 3 logs from google and can't find another one so is it complying with the current policy? With the may2015 one? Somewhere else where to look at? Just to be clear.

With the Dec 2014 (no longer current) policy - yes, it would; a 2 year cert with 3 SCTs, one of which from Google

With the May 2015 one (current) policy - no, it would not; a 2 year cert with 3 SCTs, one of which from Google, but zero from non-Google

[Ray Cheng]

Hi Ryan,

What I mean by "support the previous Dec 2014 policy" is that it includes supporting the relaxation of log independence that ends on July 1, 2015. If this policy was already fully implemented in Chrome, the log independence relaxation would go away on July 1, 2015 and certificates requiring 3 SCTs would need to come from 3 independent logs.

Suppose we are currently issuing certificates requiring 3 SCTs with 2 from Google and 1 non-Google.

This would be non-compliant under the Dec 2014 policy on July 1, 2015, when the log relaxation ends.

However, if the May 2015 policy is rolled out to Chrome before July 1, 2015, we would be compliant.

I suppose this issue would also go away if the "removal of the log independence on July 1, 2015" part of the Dec 2014 policy has not been rolled out to Chrome. We would then just go from the Dec 2014 "relaxed" independence policy straight to the May 2015 independence policy.

[Ryan Sleevi]

On Wed, Jun 17, 2015 at 6:39 AM, Ray Cheng <ray....@entrust.com> wrote:

Hi Ryan,

What I mean by "support the previous Dec 2014 policy" is that it includes supporting the relaxation of log independence that ends on July 1, 2015. If this policy was already fully implemented in Chrome, the log independence relaxation would go away on July 1, 2015 and certificates requiring 3 SCTs would need to come from 3 independent logs.

Suppose we are currently issuing certificates requiring 3 SCTs with 2 from Google and 1 non-Google.

This would be non-compliant under the Dec 2014 policy on July 1, 2015, when the log relaxation ends.

However, if the May 2015 policy is rolled out to Chrome before July 1, 2015, we would be compliant.

I suppose this issue would also go away if the "removal of the log independence on July 1, 2015" part of the Dec 2014 policy has not been rolled out to Chrome. We would then just go from the Dec 2014 "relaxed" independence policy straight to the May 2015 independence policy.

Correct. You can transition directly from the "relaxed independence" policy to the current policy. There is no timebomb that will go off on July 1, 2015 for older versions of Chrome. 

[Ray Cheng]

Thanks for confirming.

[Rob Stradling]

Hi Ryan. A couple of questions about dates...

Given that the Dec 2014 independence requirement was deferred and never
actually came into effect, the May 2015 policy update took us from
no independence requirement
to
"with at least one SCT being from a Google­-operated log and at least
one SCT being from a non­-Google­-operated log".

Q1: What was (or what will be) the effective date of your May 2015 CT
policy update?
(The policy itself doesn't seem to say)

Partly because I'm an idiot, Comodo only came into full compliance (via
precertificates alone) with the May 2015 policy update on August 3rd
2015. (Before then, our 1yr EV certs included SCTs from Pilot and
Aviator, which we did because this complied with the Dec 2014 policy and
because these were the only 2 logs accepted by Chrome M35 to M40).

Prompted by today's news/speculation from Netcraft [1]...

Q2: What (if any) will be the enforcement date (in Chrome) of your May
2015 CT policy update?

In a quick hunt on the Chromium bug tracker earlier today I found [2].
I do like the idea of updating Chrome's EV whitelist in order to avoid
"breaking existing certificates that are only logged in Google's logs". :-)


Thanks.


[1]
http://news.netcraft.com/archives/2015/08/24/thousands-short-changed-by-ev-certificates-that-dont-display-correctly-in-chrome.html
"Comodo is the CA most affected by the May 2015 policy update, with
almost 6,000 EV certificates at risk if Google's new policy is
applied from 1st Jan 2015. Comodo has recently issued certificates
with SCTs from too few independent logs: for example, Comodo issued
a certificate on 3rd August 2015 that is missing a non-Google SCT."

[2] https://code.google.com/p/chromium/issues/detail?id=425174

> --
> You received this message because you are subscribed to the Google
> Groups "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ct-policy+...@chromium.org

> <mailto:ct-policy+...@chromium.org>.

> To post to this group, send email to ct-p...@chromium.org

> <mailto:ct-p...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvZscvwV0Hq%2BKwre-NwgGfz9k1x5SYvkOw1r4f%3DUUCXmuA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvZscvwV0Hq%2BKwre-NwgGfz9k1x5SYvkOw1r4f%3DUUCXmuA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

[Ryan Sleevi]

On Mon, Aug 24, 2015 at 2:31 PM, Rob Stradling <rob.st...@comodo.com> wrote:

Hi Ryan.  A couple of questions about dates...

Given that the Dec 2014 independence requirement was deferred and never actually came into effect, the May 2015 policy update took us from
  no independence requirement

Not quite correct :) The deferred independence requirement from Dec 2014 was "However, at least one must come from a log operated by Google."

 

to
  "with at least one SCT being from a Google­-operated log and at least one SCT being from a non­-Google­-operated log".

Q1: What was (or what will be) the effective date of your May 2015 CT policy update?
(The policy itself doesn't seem to say)

Apologies for the confusion, and I'll make sure future updates are very clear about effective dates for any sorts of changes.

We've debated a lot internally on this. The Dec 2014 policy was clear that the relaxation only applied up to "1 July 2015".

While I'm idealistic and would liked to have thought the May 2015 policy update would have taken force 'immediately', understandably it may have caught CAs by surprise if they thought they had a month before independence kicked in (although ideally they would have already been transitioning).

The result is that we'd like to put the date as "1 July 2015" - any certificates issued before that date would need to comply with the Dec 2014 policy (which could be seen as 'in effect' from Dec 2014 until July 2015), and any certificates issued after that date need to comply with the May policy.

While I realize this ambiguity was caused both by the fact we didn't clearly state the effective date and the independence requirements had a number of known interpretation problems, and though understandable that mistakes happen in CA issuance, the 1 July 2015 should have represented a date where issuance would have to be aligned.

That does suggest that the EV certificates issued between 1 July 2015 and 3 August 2015 will not comply with the policy, and not be granted EV treatment in a future update (see Q2)

 

Q2: What (if any) will be the enforcement date (in Chrome) of your May 2015 CT policy update?

It's being implemented now, so presumably that means around Chrome 47. It was not intentional that it took this long to get around to enforcing that in Chromium. It may be merged into earlier versions (such as Chrome 46), but that remains TBD.

On the topic of whitelisting, there are no plans to extend the whitelist.

As a result, it does suggest that a future Chrome update will no longer treat those certificates (between 1 July 2015 and 3 August 2015) as complying, as they didn't comply with either the March 2014 (full independence), Dec 2014 (relaxed independence - at least one Google, but only until 1 July 2015), or May 2015 (one Google, one non-Google) policies.

You can resolve this with OCSP stapling (rarely a bad idea), the TLS extension, or via reissuing those certificates.

[Rob Stradling]

On 08/09/15 23:02, Ryan Sleevi wrote:
> On Mon, Aug 24, 2015 at 2:31 PM, Rob Stradling wrote:
<snip>

> Apologies for the confusion, and I'll make sure future updates are very
> clear about effective dates for any sorts of changes.
>
> We've debated a lot internally on this. The Dec 2014 policy was clear
> that the relaxation only applied up to "1 July 2015".
>
> While I'm idealistic and would liked to have thought the May 2015 policy
> update would have taken force 'immediately', understandably it may have
> caught CAs by surprise if they thought they had a month before
> independence kicked in (although ideally they would have already been
> transitioning).
>
> The result is that we'd like to put the date as "1 July 2015" - any
> certificates issued before that date would need to comply with the Dec
> 2014 policy (which could be seen as 'in effect' from Dec 2014 until July
> 2015), and any certificates issued after that date need to comply with
> the May policy.
>
> While I realize this ambiguity was caused both by the fact we didn't
> clearly state the effective date and the independence requirements had a
> number of known interpretation problems, and though understandable that
> mistakes happen in CA issuance, the 1 July 2015 should have represented
> a date where issuance would have to be aligned.

Hi Ryan. Understood. All things considered, enforcing from July 1st
2015 does seem justifiable.

> That does suggest that the EV certificates issued between 1 July 2015
> and 3 August 2015 will not comply with the policy, and not be granted EV
> treatment in a future update (see Q2)

Indeed so. :-(

BTW, yesterday I checked all of the certs in the CT logs that have a
notBefore date >= 1st July 2015 and contain >=1 embedded SCT(s).

Whilst the vast majority were issued by Comodo on or before 3rd August
2015, I did find 83 issued by other CAs (see list below - [1]).

> Q2: What (if any) will be the enforcement date (in Chrome) of your
> May 2015 CT policy update?
>
> It's being implemented now, so presumably that means around Chrome 47.
> It was not intentional that it took this long to get around to enforcing
> that in Chromium. It may be merged into earlier versions (such as Chrome
> 46), but that remains TBD.

Thanks for that info.

> On the topic of whitelisting, there are no plans to extend the whitelist.

Well, I figure there's no harm in asking, so let me upgrade my "I do
like the idea" to a formal request...

Please would you extend the whitelist so that it includes the ~1000 EV
certificates that
a) were logged in at least 1 Google-operated CT log between 1st July
2015 and (at least) 3rd August 2015
and that
b) contain embedded SCTs that are on their own sufficient to satisfy the
Dec 2014 policy but not the May 2015 policy

?

Thanks for considering this request.


[1] The list below is grouped by issuing CA. For each affected cert,
I've included the crt.sh ID (see https://crt.sh) and the notBefore date.

Issuer: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=SECOM Passport for
Web EV 2.0 CA
8701339 2015-07-13 07:05:19
8675430 2015-07-13 07:06:25
8751357 2015-07-30 04:21:41
8882389 2015-07-31 08:39:40
8797483 2015-08-03 08:48:36
8918385 2015-08-10 02:34:41
9045923 2015-08-10 02:35:13
8912959 2015-08-11 08:21:13

Issuer: C=JP, O="SECOM Trust Systems CO.,LTD.", CN=SECOM Passport for
Web EV CA
8473510 2015-07-03 02:56:38
8507358 2015-07-06 08:04:22
8442683 2015-07-07 08:48:00
8520134 2015-07-08 06:44:53
8402410 2015-07-09 04:28:04
8576091 2015-07-21 07:07:53
9035799 2015-08-24 02:25:31
9179567 2015-08-27 08:20:46

Issuer: C=PL, O=Unizeto Technologies S.A., OU=Certum Certification
Authority, CN=Certum Extended Validation CA SHA2
8298617 2015-07-02 12:03:18
8326173 2015-07-03 00:00:00
8346703 2015-07-03 12:23:07
8369598 2015-07-04 00:00:00
9224208 2015-07-07 14:39:50
8408056 2015-07-08 00:00:00
8411694 2015-07-08 12:23:39
8409802 2015-07-09 05:33:30
8738617 2015-07-10 13:10:41
8492141 2015-07-12 15:35:08
8475221 2015-07-13 12:58:51
8549748 2015-07-16 08:41:49
8498737 2015-07-16 12:31:28
8553110 2015-07-20 05:18:46
8614583 2015-07-22 11:09:06
8683553 2015-07-22 12:32:35
8613758 2015-07-23 10:29:56
8638408 2015-07-23 11:49:08
8615598 2015-07-24 00:00:00
9045113 2015-07-24 08:34:02
8692041 2015-07-24 12:44:14
8636943 2015-07-24 19:52:42
8644299 2015-07-26 04:07:33
8667997 2015-07-28 05:58:38
8885296 2015-07-31 12:51:29
8739203 2015-08-03 09:23:36
8751220 2015-08-03 09:49:59
8767010 2015-08-03 14:46:47
8757153 2015-08-03 15:27:10
8759799 2015-08-04 05:31:05
8738931 2015-08-04 05:31:45
8777274 2015-08-05 12:13:06
8805004 2015-08-05 13:03:51
9220522 2015-08-09 04:34:31
8838879 2015-08-10 12:24:37
9055128 2015-08-17 15:01:16
9096774 2015-08-18 13:31:20
8981103 2015-08-20 00:00:00
8998284 2015-08-21 12:37:29
9038318 2015-08-24 08:02:52
9094666 2015-08-27 12:37:10
9159295 2015-08-31 06:18:22
9159365 2015-08-31 15:05:25
9156833 2015-09-02 10:35:26
9166755 2015-09-02 13:27:36
9184505 2015-09-03 10:31:17
9195486 2015-09-04 09:53:52

Issuer: C=US, O=Trend Micro Inc, CN=Trend Micro CA
9184575 2015-09-03 07:27:04

Issuer: C=US, O=Trend Micro Inc, CN=Trend Micro S2 CA
8475922 2015-07-08 03:40:05
8481416 2015-07-08 03:42:08
8691303 2015-07-24 00:59:04
8669076 2015-07-24 01:01:04
8672439 2015-07-24 01:03:14
8709501 2015-07-24 01:07:12
8693545 2015-07-24 01:09:05
8680151 2015-07-24 01:13:04
8681833 2015-07-24 01:15:08
8946600 2015-08-17 01:52:03
9032962 2015-08-17 02:28:04
9060760 2015-08-17 02:48:03
9048354 2015-08-17 02:50:03
9100260 2015-08-17 02:52:04
9194165 2015-08-17 02:52:10
9065584 2015-08-17 03:09:04
9068563 2015-08-17 03:09:11
9064390 2015-08-17 03:11:04
9128014 2015-08-17 03:17:04

[Ryan Sleevi]

On Thu, Sep 10, 2015 at 7:33 AM, Rob Stradling <rob.st...@comodo.com> wrote:

> On the topic of whitelisting, there are no plans to extend the whitelist.

Well, I figure there's no harm in asking, so let me upgrade my "I do
like the idea" to a formal request...

Please would you extend the whitelist so that it includes the ~1000 EV
certificates that
a) were logged in at least 1 Google-operated CT log between 1st July
2015 and (at least) 3rd August 2015
and that
b) contain embedded SCTs that are on their own sufficient to satisfy the
Dec 2014 policy but not the May 2015 policy

?

Thanks for considering this request.

On the topic of whitelisting, there are no plans to extend the whitelist :)

Which I guess should have been clearer, which is that we evaluated that request, but could find no reasonable or justifiable reason to extend the whitelist.

While I can understand and appreciate the nuance of b) there - that is, they did conform to the Dec 2014 policy (one Google log) - it should also hopefully be an understandable position that it didn't actually conform to the policy in force. I think as we look (over time) to encourage and improve our logging policies, we'll naturally get to a state where we had previous versions that are more liberal. Certainly, you're familiar with root stores doing this - traditionally, root stores get more restrictive over time, to respond to emerging threats :)

While we do want to allow a time for transition, we have to be careful not to extend the transition period once set. For the Dec -> May policy, while we admittedly didn't explicitly state that transition, it was baked in to the Dec policy as "You must transition by 1 July", so there was a reasonable expectation that every CA relying on the Dec policy's relaxation would have ceased that by 1 July.

Extending the whitelist, while it would admittedly help minimize disruption to Comodo (and several other CAs, as you identified), would have the effect of saying "It's OK to violate the policy", which is something that's unappealing :)

Personally, I'm very opposed to adding anything ever to the whitelist - it should only be pruned over time (as certificates expire). We did recently refresh the whitelist, due to a bug pointed out by Netcraft in our whitelist generation code, but that itself was exceptional and contentious. Though there was a bug in our code (two, really - one related to how multiple-policy-OID'd CAs were handled, and the other related to cross-CA certifications where our whitelist generator's path builder - aka 'raw from the log' - yielded different results than Chrome's certificate path building libraries), we repeatedly engaged CAs to ensure they reviewed the whitelist and their own certificates to ensure we caught such bugs early. As such, it would also have been a defensible point to *not* extend the whitelist, on the basis that it was the issuing CA's responsibility to detect and notice the issue that would potentially affect their customers.

I mention that mostly to provide context for future policy changes, which is that whitelisting is unlikely to really ever be a viable option, except in the most of extreme circumstances. We'll certainly work to ensure that effective dates are clearly communicated and well understood going forward, and of course, there will always be ample discussion of any policy changes, which will hopefully help work through and resolve any issues that might otherwise suggest whitelisting, so that we can avoid whitelisting :)

[Rob Stradling]

On 11/09/15 17:44, Ryan Sleevi wrote:

> On Thu, Sep 10, 2015 at 7:33 AM, Rob Stradling wrote:
>
> > On the topic of whitelisting, there are no plans to extend the whitelist.
>
> Well, I figure there's no harm in asking, so let me upgrade my "I do
> like the idea" to a formal request...
>
> Please would you extend the whitelist so that it includes the ~1000 EV
> certificates that
> a) were logged in at least 1 Google-operated CT log between 1st July
> 2015 and (at least) 3rd August 2015
> and that
> b) contain embedded SCTs that are on their own sufficient to satisfy the
> Dec 2014 policy but not the May 2015 policy
>
> ?
>
> Thanks for considering this request.
>
>
> On the topic of whitelisting, there are no plans to extend the whitelist :)
>
> Which I guess should have been clearer, which is that we evaluated that
> request, but could find no reasonable or justifiable reason to extend
> the whitelist.

Thanks Ryan. That's certainly clear now. :-)

> While I can understand and appreciate the nuance of b) there - that is,
> they did conform to the Dec 2014 policy (one Google log) - it should
> also hopefully be an understandable position that it didn't actually
> conform to the policy in force.

Yes, your position is understandable and perfectly reasonable.

(I wasn't expecting you to say "yes", but I did want to confirm that
your answer would definitely be "no", so that I can relay a clear answer
in the likely event that I get asked the same question).

Understood. Thanks.