Add Enterprise Policy for whitelisting hosts as exempt from CT

components/policy/resources/policy_templates.json

 {
 # policy_templates.json - Metafile for policy templates
 #
 # The content of this file is evaluated as a Python expression.
 #
 # This file is used as input to generate the following policy templates:
 # ADM, ADMX+ADML, MCX/plist and html documentation.
 #
 # Policy templates are user interface definitions or documents about the
 # policies that can be used to configure Chrome. Each policy is a name-value
@@ skipping 119 matching lines @@
 #   templates and documentation. The policy definition list that Chrome sees
 #   will include policies marked with 'future'. If a WIP policy isn't meant to
 #   be seen by the policy providers either, the 'supported_on' key should be set
 #   to an empty list.
 #
 # IDs:
 #   Since a Protocol Buffer definition is generated from this file, unique and
 #   persistent IDs for all fields (but not for groups!) are needed. These are
 #   specified by the 'id' keys of each policy. NEVER CHANGE EXISTING IDs,
 #   because doing so would break the deployed wire format!
-#   For your editing convenience: highest ID currently used: 333
+#   For your editing convenience: highest ID currently used: 334
 #
 # Placeholders:
 #   The following placeholder strings are automatically substituted:
 #     $1 -> Google Chrome / Chromium
 #     $2 -> Google Chrome OS / Chromium OS
 #     $3 -> Google Chrome Frame / Chromium Frame
 #     $6 is reserved for doc_writer
 #
 # Device Policy:
 #   An additional flag 'device_only' (optional, defaults to False) indicates
@@ skipping 7760 matching lines @@
       'tags': ['system-security'],
       'desc': '''Warning: The TLS version fallback will be removed from <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> after version 52 (around September 2016) and this policy will stop working then.
 
       When a TLS handshake fails, <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> would previously retry the connection with a lesser version of TLS in order to work around bugs in HTTPS servers. This setting configures the version at which this fallback process will stop. If a server performs version negotiation correctly (i.e. without breaking the connection) then this setting doesn't apply. Regardless, the resulting connection must still comply with SSLVersionMin.
 
       If this policy is not configured or if it is set to "tls1.2" then <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> no longer performs this fallback. Note this does not disable support for older TLS versions, only whether <ph name="PRODUCT_NAME">$1<ex>Google Chrome</ex></ph> will work around buggy servers which cannot negotiate versions correctly.
 
       Otherwise, if compatibility with a buggy server must be maintained, this policy may be set to "tls1.1". This is a stopgap measure and the server should be rapidly fixed.''',
     },
     {
+      'name': 'CertificateTransparencyEnforcementDisabledForUrls',
+      'type': 'list',
+      'schema': {
+        'type': 'array',
+        'items': { 'type': 'string' },
+      },
+      'supported_on': [
+        'chrome.*:53-',
+        'chrome_os:53-',
+        'android:53-',
+      ],
+      'features': {
+        'dynamic_refresh': True,
+        'per_profile': False,
+      },
+      'example_value': ['example.com', '[.*].example.com'],
+      'id': 334,
+      'caption': '''Disable Certificate Transparency enforcement for a list of URLs''',
+      'tags': ['system-security'],
+      'desc': '''Disables enforcing Certificate Transparency requirements to the listed URLs.
+
+      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.

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

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?

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

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.

+
+      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.

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

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]

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

+
+      If this policy is not set, any certificate that is required to be disclosed via Certificate Transparency will be treated as untrusted if it is not disclosed.''',
+    },
+    {
       'name': 'RC4Enabled',
       'type': 'main',
       'schema': {
         'type': 'boolean',
       },
       'supported_on': [
         'chrome.*:48-52',
         'chrome_os:48-52',
         'android:48-52',
         'ios:48-52',
@@ skipping 823 matching lines @@
       'desc': '''Text appended in parentheses next to the policies top-level container to indicate that those policies are of the Recommended level''',
       'text': 'Default Settings (users can override)',
     },
     'doc_complex_policies_on_windows': {
       'desc': '''Text pointing the user to a help article for complex policies on Windows''',
       'text': '''encoded as a JSON string, for details see <ph name="COMPLEX_POLICIES_URL">https://www.chromium.org/administrators/complex-policies-on-windows<ex>https://www.chromium.org/administrators/complex-policies-on-windows</ex></ph>''',
     },
   },
   'placeholders': [],
 }