Add Enterprise Policy for whitelisting hosts as exempt from CT

Add Enterprise Policy for whitelisting hosts as exempt from CT

Add a policy setting that allows hosts to be exempted from any
Certificate Transparency requirements. Some CAs, such as
Symantec and CNNIC at present, are required to disclose their
certificates via CT in order to have them trusted; any certificate
not disclosed will not be trusted.

However, to accomodate some enterprise users who are not yet
prepared to disclose their certificates (e.g. certificates for
"topsecret.internal.example.com"), but wish to use these CAs,
allow some hosts to be whitelisted as exempt from disclosure.

Whether or not this policy is temporary depends on if the IETF
and the CA community can come up with appropriate technical and
procedural safeguards to allow 'redacting' the certificate, hiding
portions of the hostname from disclosure. For now and the
forseeable future, redaction is not viable, so the enterprise
policy offers a suitable release valve.

BUG=620178

[Ryan Sleevi, 2016-06-21 04:10:10]

rsleevi@chromium.org changed reviewers:
+ atwilson@chromium.org

[Ryan Sleevi, 2016-06-21 04:10:10]

Drew: With tnagel and bartfab OOO this week, I sadly must push to you.

Primarily looking to get string review - I haven't actually wired up this CL to
the other CLs in flight (trying to do concurrent independent string reviews;
error page strings is https://codereview.chromium.org/2083913002/ )

Tried to capture sufficient context in the CL description and the CL itself, but
this is the follow-up to
https://security.googleblog.com/2015/10/sustaining-digital-certificate-securi...
and
https://security.googleblog.com/2015/03/maintaining-digital-certificate-secur...

Would like to target M53 with this, trying to get the strings in since they're
the long tail.

[Ryan Sleevi, 2016-06-21 04:32:40]

Also unclear: Whether we want to use the URLBlacklist format if we only care
about hosts and wildcards, or if it should just be something like

host.example.name
*.host.example.name

I couldn't see any precedent in the policy code.

[Andrew T Wilson (Slow), 2016-06-21 08:37:48]

atwilson@chromium.org changed reviewers:
+ tnagel@google.com

[Andrew T Wilson (Slow), 2016-06-21 08:37:48]

LGTM, but adding tnagel to chime in on the policy format (using URLBlacklist
format)

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:7942: This policy allows
certificates for the hostnames in the specified URLs to not be disclosed via
Certificate Transparency. This allows certificates that would otherwise be
untrusted, because they were not properly publicly disclosed, to continue to be
used, but makes it harder to detect misissued certificates for those hosts.
This is fine, but I'm curious why we need this policy - do we still require
certificate transparency even for policies in the local trust root? Couldn't
enterprises who don't want their server certificates exposed via CT just put
them in the local trust root on their managed devices?

[Thiemo Nagel, 2016-06-21 10:54:05]

tnagel@chromium.org changed reviewers:
+ tnagel@chromium.org

[Thiemo Nagel, 2016-06-21 10:54:06]

https://codereview.chromium.org/2087743002/diff/1/chrome/test/data/policy/pol...
File chrome/test/data/policy/policy_test_cases.json (right):

https://codereview.chromium.org/2087743002/diff/1/chrome/test/data/policy/pol...
chrome/test/data/policy/policy_test_cases.json:1872: "test_policy": {
"CertificateTransparencyEnforcementDisabledForUrls": ["google.com"] },
Nit: Please use example.com.

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:7944: A URL pattern is
formatted according to
https://www.chromium.org/administrators/url-blacklist-filter-format, but because
certificates are valid for any port and path on the server, only the hostname
will be considered.
I think it's fair to re-use the blacklist filter format, however please specify
how the scheme part is treated, e.g. if someone sets "http://example.com" (note
the missing "s").  I assume the intention is to ignore the scheme as well?  This
might not work out for all schemes, though, iirc the parsing of some schemes may
yield surprises (eg. "file://example.com/").  Thus maybe it would be best to
explicitly require no scheme or https in the docs.

[Ryan Sleevi, 2016-06-21 17:01:01]

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:7942: This policy allows
certificates for the hostnames in the specified URLs to not be disclosed via
Certificate Transparency. This allows certificates that would otherwise be
untrusted, because they were not properly publicly disclosed, to continue to be
used, but makes it harder to detect misissued certificates for those hosts.
On 2016/06/21 08:37:48, Andrew T Wilson (Slow) wrote:
> This is fine, but I'm curious why we need this policy - do we still require
> certificate transparency even for policies in the local trust root? Couldn't
> enterprises who don't want their server certificates exposed via CT just put
> them in the local trust root on their managed devices?

That's our preferred/recommended path.

However, it's claimed that for interoperability between their managed devices
and their unmanaged devices (e.g. needing to use VOIP phones that talk to the
same server as users, or server-to-server communications to API endpoints on the
same things that clients are interfacing with), they need to have a period where
they're still using a publicly-trusted certificate subject to this policy, but
want Chrome to be exempt.

https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:7944: A URL pattern is
formatted according to
https://www.chromium.org/administrators/url-blacklist-filter-format, but because
certificates are valid for any port and path on the server, only the hostname
will be considered.
On 2016/06/21 10:54:06, Thiemo Nagel wrote:
> I think it's fair to re-use the blacklist filter format, however please
specify
> how the scheme part is treated, e.g. if someone sets "http://example.com"
(note
> the missing "s").  I assume the intention is to ignore the scheme as well? 
This
> might not work out for all schemes, though, iirc the parsing of some schemes
may
> yield surprises (eg. "file://example.com/").  Thus maybe it would be best to
> explicitly require no scheme or https in the docs.

Correct - everything but the hostname is ignored. Scheme, port, path, and
authority - ignored.

[Andrew T Wilson (Slow), 2016-06-21 17:41:16]

On 2016/06/21 17:01:01, Ryan Sleevi wrote:
>
https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
> File components/policy/resources/policy_templates.json (right):
> 
>
https://codereview.chromium.org/2087743002/diff/1/components/policy/resources...
> components/policy/resources/policy_templates.json:7942: This policy allows
> certificates for the hostnames in the specified URLs to not be disclosed via
> Certificate Transparency. This allows certificates that would otherwise be
> untrusted, because they were not properly publicly disclosed, to continue to
be
> used, but makes it harder to detect misissued certificates for those hosts.
> On 2016/06/21 08:37:48, Andrew T Wilson (Slow) wrote:
> > This is fine, but I'm curious why we need this policy - do we still require
> > certificate transparency even for policies in the local trust root? Couldn't
> > enterprises who don't want their server certificates exposed via CT just put
> > them in the local trust root on their managed devices?
> 
> That's our preferred/recommended path.
> 
> However, it's claimed that for interoperability between their managed devices
> and their unmanaged devices (e.g. needing to use VOIP phones that talk to the
> same server as users, or server-to-server communications to API endpoints on
the
> same things that clients are interfacing with), they need to have a period
where
> they're still using a publicly-trusted certificate subject to this policy, but
> want Chrome to be exempt.

So, still LGTM and I trust you to do the right thing. But for the record this
doesn't make any sense to me - any platform that they could set this policy on,
they could also set the trust root on that platform.

The only rationale I could think of would be if they had platforms where they
wanted *chrome* to talk to the server, but for some reason they didn't want the
server cert to be in the trust root for other apps on that same machine. But
that makes zero sense since in theory Symantec's CA would already been in the
set of system trust roots.

[Ryan Sleevi, 2016-06-21 17:52:48]

On 2016/06/21 17:41:16, Andrew T Wilson (Slow) wrote:
> The only rationale I could think of would be if they had platforms where they
> wanted *chrome* to talk to the server, but for some reason they didn't want
the
> server cert to be in the trust root for other apps on that same machine. But
> that makes zero sense since in theory Symantec's CA would already been in the
> set of system trust roots.

I think I explained it poorly.

They have devices and software which require it use a publicly trusted root.
These devices don't run Chrome - they're for various LOB-type activities (and
more esoteric stuff, like "PHP talking to my web server" style)

The first claim (which we cannot independently evaluate) is that these
enterprises can't change CAs - to a non-CT required CA or to an
enterprise-managed CA. The second claim (which we cannot independently evaluate)
is that these enterprises don't wish the hostnames disclosed via CT (which
requires full disclosure).

I agree that they could centrally distribute a CA where they can set this
policy, but that would only affect their managed systems where they can install
CAs, and the first claim is that there are some subset of platforms for which
they cannot. So the idea here is leveraging the managed systems to ignore the
error that exists in order to satisfy the needs of the unmanaged/non-Chrome
systems.

[Andrew T Wilson (Slow), 2016-06-22 15:01:01]

On 2016/06/21 17:52:48, Ryan Sleevi wrote:
> On 2016/06/21 17:41:16, Andrew T Wilson (Slow) wrote:
> > The only rationale I could think of would be if they had platforms where
they
> > wanted *chrome* to talk to the server, but for some reason they didn't want
> the
> > server cert to be in the trust root for other apps on that same machine. But
> > that makes zero sense since in theory Symantec's CA would already been in
the
> > set of system trust roots.
> 
> I think I explained it poorly.
> 
> They have devices and software which require it use a publicly trusted root.
> These devices don't run Chrome - they're for various LOB-type activities (and
> more esoteric stuff, like "PHP talking to my web server" style)
> 
> The first claim (which we cannot independently evaluate) is that these
> enterprises can't change CAs - to a non-CT required CA or to an
> enterprise-managed CA. The second claim (which we cannot independently
evaluate)
> is that these enterprises don't wish the hostnames disclosed via CT (which
> requires full disclosure).
> 
> I agree that they could centrally distribute a CA where they can set this
> policy, but that would only affect their managed systems where they can
install
> CAs, and the first claim is that there are some subset of platforms for which
> they cannot. So the idea here is leveraging the managed systems to ignore the
> error that exists in order to satisfy the needs of the unmanaged/non-Chrome
> systems.

My point is - if you have a managed system that you want to ignore the error,
there are two ways you can do this:

1) Add this policy to your managed system running chrome
2) Add the specific server certificate to your list of trust roots on your
managed system running chrome (because I presume this would circumvent chrome's
CA CT check, because we wouldn't need to follow the chain of trust up to a
public CA)

Given that #2 would be sufficient for their needs, why do we need to support #1?

[chromium-reviews, 2016-06-22 15:25:56]

On Wed, Jun 22, 2016 at 8:01 AM, <atwilson@chromium.org> wrote:

> On 2016/06/21 17:52:48, Ryan Sleevi wrote:
> > On 2016/06/21 17:41:16, Andrew T Wilson (Slow) wrote:
> > > The only rationale I could think of would be if they had platforms
> where
> they
> > > wanted *chrome* to talk to the server, but for some reason they didn't
> want
> > the
> > > server cert to be in the trust root for other apps on that same
> machine. But
> > > that makes zero sense since in theory Symantec's CA would already been
> in
> the
> > > set of system trust roots.
> >
> > I think I explained it poorly.
> >
> > They have devices and software which require it use a publicly trusted
> root.
> > These devices don't run Chrome - they're for various LOB-type activities
> (and
> > more esoteric stuff, like "PHP talking to my web server" style)
> >
> > The first claim (which we cannot independently evaluate) is that these
> > enterprises can't change CAs - to a non-CT required CA or to an
> > enterprise-managed CA. The second claim (which we cannot independently
> evaluate)
> > is that these enterprises don't wish the hostnames disclosed via CT
> (which
> > requires full disclosure).
> >
> > I agree that they could centrally distribute a CA where they can set this
> > policy, but that would only affect their managed systems where they can
> install
> > CAs, and the first claim is that there are some subset of platforms for
> which
> > they cannot. So the idea here is leveraging the managed systems to
> ignore the
> > error that exists in order to satisfy the needs of the
> unmanaged/non-Chrome
> > systems.
>
> My point is - if you have a managed system that you want to ignore the
> error,
> there are two ways you can do this:
>
> 1) Add this policy to your managed system running chrome
> 2) Add the specific server certificate to your list of trust roots on your
> managed system running chrome (because I presume this would circumvent
> chrome's
> CA CT check, because we wouldn't need to follow the chain of trust up to a
> public CA)
>
> Given that #2 would be sufficient for their needs, why do we need to
> support #1?
>

I presume that they don't want to run two parallel PKIs, one private that
they can install on systems running Chrome, and one public that is used on
systems not running chrome but that can't have their trust stores updated.


> https://codereview.chromium.org/2087743002/
>

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

[Ryan Sleevi, 2016-06-22 15:38:14]

On 2016/06/22 15:25:56, chromium-reviews wrote:
> > 2) Add the specific server certificate to your list of trust roots on your
> > managed system running chrome (because I presume this would circumvent
> > chrome's
> > CA CT check, because we wouldn't need to follow the chain of trust up to a
> > public CA)
> >
> > Given that #2 would be sufficient for their needs, why do we need to
> > support #1?
> >
> 
> I presume that they don't want to run two parallel PKIs, one private that
> they can install on systems running Chrome, and one public that is used on
> systems not running chrome but that can't have their trust stores updated.

Right, I think the issue Drew is that #2 isn't sufficient for their needs. You
can't just add the specific server list to the set of CAs - that doesn't change
the logic and enforcement (it also doesn't work if done at a server-certificate
and not intermediate) level.

They would have to fully change their system to a private PKI and *then* use #2.
But if they change to the private PKI, then that breaks those LOB systems they
don't manage, so they claim, and so they claim they can't change to a private
PKI and use #2. So that's why this is offered - it adds the exception to the
managed system, since they can't add the trust to the unmanaged systems.

[Andrew T Wilson (Slow), 2016-06-23 08:28:15]

On 2016/06/22 15:38:14, Ryan Sleevi wrote:
> On 2016/06/22 15:25:56, chromium-reviews wrote:
> > > 2) Add the specific server certificate to your list of trust roots on your
> > > managed system running chrome (because I presume this would circumvent
> > > chrome's
> > > CA CT check, because we wouldn't need to follow the chain of trust up to a
> > > public CA)
> > >
> > > Given that #2 would be sufficient for their needs, why do we need to
> > > support #1?
> > >
> > 
> > I presume that they don't want to run two parallel PKIs, one private that
> > they can install on systems running Chrome, and one public that is used on
> > systems not running chrome but that can't have their trust stores updated.
> 
> Right, I think the issue Drew is that #2 isn't sufficient for their needs. You
> can't just add the specific server list to the set of CAs - that doesn't
change
> the logic and enforcement (it also doesn't work if done at a
server-certificate
> and not intermediate) level.
> 
> They would have to fully change their system to a private PKI and *then* use
#2.
> But if they change to the private PKI, then that breaks those LOB systems they
> don't manage, so they claim, and so they claim they can't change to a private
> PKI and use #2. So that's why this is offered - it adds the exception to the
> managed system, since they can't add the trust to the unmanaged systems.

OK, I understand now why #2 doesn't work - thanks for clarifying.