CT Enforcement logic on Chrome

[Peter Bowen]

I've been trying to make sure I understand the CT enforcement logic in
Chrome today and realized that is way more complicated than I first
thought. Can someone tell me if I have this right and answer the
questions at the end?

1) Chrome gets the URL for the request, pulls out the host out of the
url[*], opens a connection, and gets the cert chain

2) It passes the chain and host[**] to the cert validator, which is
normally part of the OS

3) If the validator passes, it returns the chain that validated. If
the validator fails, do not load page && GOTO END

4) Chrome checks the CertificateTransparencyEnforcementDisabledForUrls
administrative policy value to determine if the host matches the
administrative policy. This administrative policy can contain
hostname suffixes, for example it can have "example.com", which would
match "foo.ber.example.com". If there is a match then, CT is not
required && GOTO END

5) Chrome checks the Expect-CT list. If the host matches an entry in
the Expect-CT list, CT is required && GOTO END

6) Chrome iterates over a CT ruleset. For each rule in the ruleset:

6a) Chrome iterates of a list of public key hashes that are required
to have CT. If the hash matches any key found in the chain returned
by the validator and the notBefore date of the end certificate is
after the date associated with the hash go to 6b. Otherwise go to
next rule (repeat this step until out of rules; go to 7 if out of
rules)

6b) Chrome iterates of a list of public key hashes that are excluded
from a CT requirement. If the hash matches any key found in the chain
returned by the validator, then CT is not required && GOTO END.
Otherwise, CT is required && GOTO END

7) Do not require CT

[*] This simplifies a little; for example, Chrome turns Unicode
u-labels to punycode A-labels before passing to the resolver.

[**] Again, a little simplification. Chrome removes the trailing '.'
if present from the punycode hostname before sending to the validator
and may case fold labels.

Questions:

1) Did I describe this accurately?

2) Is the intent that, when CT is required for all public roots, that
the hash list for #6a will be all trusted roots and #6b will be empty?
Put another way, #7 will not be changing, right?

3) The policy documentation for
CertificateTransparencyEnforcementDisabledForUrls does not indicate it
is supported on Android System WebView (Android) or Google Chrome
(iOS). What is the plan to resolve this so that all managed devices
have similar capabilities for configuration?

4) https://support.google.com/chrome/a/answer/187202 describes the
Chrome policy model. It notes that policies are available via the
admin console for Chrome OS and available via the G Suite admin
console. I'm unable to find the
CertificateTransparencyEnforcementDisabledForUrls policy in the admin
console. How does one set the policy for Chromebooks and managed
Chrome users?

Because CT is required only when a chain contains a known public key,
anchors added to the local trust store do not require CT. This aligns
with what has been previously stated. However in testing we have
found that this sometimes depends on OS. Specifically, if the CA
added to the trust list has a cross-certificate from a public CA (for
example GIA G2), then it becomes OS (and sometimes OS version)
dependent on whether CT is required or not. This is because different
certificate validation libraries have different path building rules.
Some use the longest trusted path, some the shortest, and others use
more complex logic.

5) We think that it makes sense to add an administrative policy that
allows specifying public key hashes to exclude from CT expectations.
This way a specific subordinate CA can be excluded and work the same
on all Chrome platforms. It also solves the problem of having to list
hundreds or thousands of domains; instead of listing each registered
domain, the administrator can list the specific issuer key. Can
Chrome add an administrative policy for this?

None of the current options provide any method of public opt-out for
CT by domain registrants. A number of proposals have been suggested
over time, but none have hit the mark. While I still don't know the
full right answer, I would like to propose an option that I think is
limited enough to assuage many concerns but also broad enough to
provide value. Chrome already supports public key pinning and name
constrained CAs. We would like to propose that pins that
includeSubDomains can also include an expect-ct directive. When set
to false, this directive tells the browser to not expect CT for
subdomains. This directive would only be honored if the pin matches a
key that is determined by the browser to be name constrained. This
allows a domain owner to clearly indicate that CT should not be
expected for a domain namespace.

6) Does Chrome see enough value in this proposal that we should bring
it to the IETF TRANS WG?

Thanks,
Peter

[Ryan Sleevi]

On Fri, Mar 10, 2017 at 4:50 PM, Peter Bowen <pzb...@gmail.com> wrote:

1) Chrome gets the URL for the request, pulls out the host out of the
url[*], opens a connection, and gets the cert chain

A little more complex - it also canonicalizes and normalizes the host (this is more than just the U-label -> A-label conversion - also involves dropping case, for example)

 

2) It passes the chain and host[**] to the cert validator, which is
normally part of the OS

The ** isn't quite right - we pass the hostname to the validator as-is, the validator removes the trailing '.' internally, only as part of further normalizing the reference name (the hostname to validate) against presented names (the hostnames in the certificate)

There's also a whole host of policy in play here, so 'normally part of the OS' is complicate. Name matching, for example, does not use any OS routine (or, when we have to pass a name to the OS, such as in macOS 10.11+ due to breaking API changes Apple introduced, we mask off the name errors)

 

3) If the validator passes, it returns the chain that validated.  If
the validator fails, do not load page && GOTO END

Sure

 

4) Chrome checks the CertificateTransparencyEnforcementDisabledForUrls
administrative policy value to determine if the host matches the
administrative policy.  This administrative policy can contain
hostname suffixes, for example it can have "example.com", which would
match "foo.ber.example.com".  If there is a match then, CT is not
required && GOTO END

5) Chrome checks the Expect-CT list.  If the host matches an entry in
the Expect-CT list, CT is required && GOTO END

6) Chrome iterates over a CT ruleset.  For each rule in the ruleset:

6a) Chrome iterates of a list of public key hashes that are required
to have CT.  If the hash matches any key found in the chain returned
by the validator and the notBefore date of the end certificate is
after the date associated with the hash go to 6b.  Otherwise go to
next rule (repeat this step until out of rules; go to 7 if out of
rules)

6b) Chrome iterates of a list of public key hashes that are excluded
from a CT requirement. If the hash matches any key found in the chain
returned by the validator, then CT is not required && GOTO END.
Otherwise, CT is required && GOTO END

7) Do not require CT

No, basically 4-7 are wrong :)

I want to note, before describing this algorithm, that NONE of this is considered binding documentation - that is, all of these behaviours can and are subject to change :)

4) Chrome determines whether or not the certificate chain validated to a 'publicly trusted root'. The mechanism of this varies per platform, and can result in different results for the same keys under some situations, but effectively attempts to distinguish whether or not the certificate was one hardcoded as trusted by the underlying platform. If so, it applies a number of secondary checks to the certificate.

5) Chrome evaluates the CT compliance status on two independent axis - compliant with the DV policy and compliant with the EV policy. The substantive difference between these two mechanisms is that the EV policy is allowed to use a whitelist (the pre-2015 whitelist), while the DV policy is not (no whitelist). Both compliance statuses are measured and independent.

6) If the certificate was not compliant with the EV policy, Chrome masks off any EV status trust bits.

7) If the certificate was not compliant with the DV policy (... and the build is timely), the network stack asks a configurable policy layer about whether or not CT should be required, providing the hostname and validated certificate chain. The policy object provides the following

  7a) A secondary policy object, which is connected to enterprise policy, examines the hostname against the CertificateTransparencyEnforcement[Enabled/Disabled]ForUrls. Yes, there's actually two policies provided (one can only be set via command-line flag or preferences, for now). If either an affirmative or negative response is received, it's used. As noted in the policy description, these policies use the URL Blacklist filter format, with the special provision of forbidding wildcards - requiring you to explicitly specify domain trees.

  7b) Chrome has a list of "CT policies". We examine each policy (in no particular order, and)

    7b1) If the policy isn't 'effective' for the leaf cert's validity period, skip  [This is subject to change, since I just noticed a bug that comes from this logic]

    7b2) If any SPKI hash from the verified certificate chain matches, and no _excluded_ SPKI hashes match, return that CT is required

  7c) Fall back to default processing (do not require CT)

8) If CT was required (from Step #7, this is only examined for non-compliant certs), fail validation

Questions:

1) Did I describe this accurately?

No, the inversion of the logic bits is important to highlight, so hopefully the above helps.

 

2) Is the intent that, when CT is required for all public roots, that
the hash list for #6a will be all trusted roots and #6b will be empty?
 Put another way, #7 will not be changing, right?

No, #7 does change - the default changes to "do require CT", and new code will be introduced to make use of the information from #4. To be clear: This means that, today, CT _is_ checked for all certificate validations in Chrome. (We even had a flag for a while that let you specify your own enterprise CT logs, we removed it for now, who knows, we might reintroduce it)

 

3) The policy documentation for
CertificateTransparencyEnforcementDisabledForUrls does not indicate it
is supported on Android System WebView (Android) or Google Chrome
(iOS).  What is the plan to resolve this so that all managed devices
have similar capabilities for configuration?

There is none at this time.

 

4) https://support.google.com/chrome/a/answer/187202 describes the
Chrome policy model.  It notes that policies are available via the
admin console for Chrome OS and available via the G Suite admin
console.   I'm unable to find the
CertificateTransparencyEnforcementDisabledForUrls policy in the admin
console.  How does one set the policy for Chromebooks and managed
Chrome users?

Thanks for highlighting this. I'll need to get back to you on it, but it looks like an unintentional oversight in allowing the full robustness of ChromeOS policies. We've not had any customer request this, but this is a useful aspect to consider.

 

Because CT is required only when a chain contains a known public key,
anchors added to the local trust store do not require CT.  This aligns
with what has been previously stated. 

See above as to why this conclusion isn't quite right.

 

However in testing we have
found that this sometimes depends on OS.  Specifically, if the CA
added to the trust list has a cross-certificate from a public CA (for
example GIA G2), then it becomes OS (and sometimes OS version)
dependent on whether CT is required or not.  This is because different
certificate validation libraries have different path building rules.
Some use the longest trusted path, some the shortest, and others use
more complex logic.

Correct, the answer includes a degree of variance depending on how the underlying platform both constructs certificate chains and evaluates trust anchors, and then reports these back to Chrome. Aligning these behaviours across platforms is very much a goal of the Chrome Networking Security team.

 

5) We think that it makes sense to add an administrative policy that
allows specifying public key hashes to exclude from CT expectations.
This way a specific subordinate CA can be excluded and work the same
on all Chrome platforms.  It also solves the problem of having to list
hundreds or thousands of domains; instead of listing each registered
domain, the administrator can list the specific issuer key.  Can
Chrome add an administrative policy for this?

It was an intentional decision not to allow this functionality.

 

None of the current options provide any method of public opt-out for
CT by domain registrants.  A number of proposals have been suggested
over time, but none have hit the mark.  While I still don't know the
full right answer, I would like to propose an option that I think is
limited enough to assuage many concerns but also broad enough to
provide value.  Chrome already supports public key pinning and name
constrained CAs.  We would like to propose that pins that
includeSubDomains can also include an expect-ct directive.  When set
to false, this directive tells the browser to not expect CT for
subdomains.  This directive would only be honored if the pin matches a
key that is determined by the browser to be name constrained.  This
allows a domain owner to clearly indicate that CT should not be
expected for a domain namespace.

I'm not sure I understand this proposal sufficiently to comment-on it. Are you proposing adding this as a directive to HPKP? I'm not sure we'd be supportive of this, but it's very likely I've misunderstood the proposal.

 

6) Does Chrome see enough value in this proposal that we should bring
it to the IETF TRANS WG?

Let's figure out what needs to change or be clarified, given the information above, and we can circle back on this question :)

[Peter Bowen]

I get that behaviors can (and do) change, but understanding the the behvaiour is critical to understand how things will appear to Chrome users.

4) Chrome determines whether or not the certificate chain validated to a 'publicly trusted root'. The mechanism of this varies per platform, and can result in different results for the same keys under some situations, but effectively attempts to distinguish whether or not the certificate was one hardcoded as trusted by the underlying platform. If so, it applies a number of secondary checks to the certificate.

"If so, ..." implies that processing stops here if Chrome determines that it did not validate to a 'publicly trusted root'.  Is that right?

 

5) Chrome evaluates the CT compliance status on two independent axis - compliant with the DV policy and compliant with the EV policy. The substantive difference between these two mechanisms is that the EV policy is allowed to use a whitelist (the pre-2015 whitelist), while the DV policy is not (no whitelist). Both compliance statuses are measured and independent.

6) If the certificate was not compliant with the EV policy, Chrome masks off any EV status trust bits.

7) If the certificate was not compliant with the DV policy (... and the build is timely), the network stack asks a configurable policy layer about whether or not CT should be required, providing the hostname and validated certificate chain. The policy object provides the following

  7a) A secondary policy object, which is connected to enterprise policy, examines the hostname against the CertificateTransparencyEnforcement[Enabled/Disabled]ForUrls. Yes, there's actually two policies provided (one can only be set via command-line flag or preferences, for now). If either an affirmative or negative response is received, it's used. As noted in the policy description, these policies use the URL Blacklist filter format, with the special provision of forbidding wildcards - requiring you to explicitly specify domain trees.

  7b) Chrome has a list of "CT policies". We examine each policy (in no particular order, and)

    7b1) If the policy isn't 'effective' for the leaf cert's validity period, skip  [This is subject to change, since I just noticed a bug that comes from this logic]

    7b2) If any SPKI hash from the verified certificate chain matches, and no _excluded_ SPKI hashes match, return that CT is required

  7c) Fall back to default processing (do not require CT)

8) If CT was required (from Step #7, this is only examined for non-compliant certs), fail validation

Questions:

1) Did I describe this accurately?

No, the inversion of the logic bits is important to highlight, so hopefully the above helps.

 

 

2) Is the intent that, when CT is required for all public roots, that
the hash list for #6a will be all trusted roots and #6b will be empty?
 Put another way, #7 will not be changing, right?

No, #7 does change - the default changes to "do require CT", and new code will be introduced to make use of the information from #4. To be clear: This means that, today, CT _is_ checked for all certificate validations in Chrome. (We even had a flag for a while that let you specify your own enterprise CT logs, we removed it for now, who knows, we might reintroduce it)

 

3) The policy documentation for
CertificateTransparencyEnforcementDisabledForUrls does not indicate it
is supported on Android System WebView (Android) or Google Chrome
(iOS).  What is the plan to resolve this so that all managed devices
have similar capabilities for configuration?

There is none at this time.

 

I would encourage Chrome to consider this a blocker for changing the 7c default to true for these platforms.  Mobile device management exists and is widely deployed.  As you wrote on IETF TRANS, and in other places, Law #6: A computer is only as secure as the administrator is trustworthy (from Ten Immutable Laws Of Security) implies that trying to control around the administrator is a futile task.

 

4) https://support.google.com/chrome/a/answer/187202 describes the
Chrome policy model.  It notes that policies are available via the
admin console for Chrome OS and available via the G Suite admin
console.   I'm unable to find the
CertificateTransparencyEnforcementDisabledForUrls policy in the admin
console.  How does one set the policy for Chromebooks and managed
Chrome users?

Thanks for highlighting this. I'll need to get back to you on it, but it looks like an unintentional oversight in allowing the full robustness of ChromeOS policies. We've not had any customer request this, but this is a useful aspect to consider.

As with the prior item, I would encourage Chrome to consider this a blocker for changing the 7c default to true.  Customers have likely not requested this in part because CT is only required for one CA operator today.  I'm sure that many customers solved the CT "problem" by getting certificates from another CA rather than trying to set non-existent policy options.

 

Because CT is required only when a chain contains a known public key,
anchors added to the local trust store do not require CT.  This aligns
with what has been previously stated. 

See above as to why this conclusion isn't quite right.

 

However in testing we have
found that this sometimes depends on OS.  Specifically, if the CA
added to the trust list has a cross-certificate from a public CA (for
example GIA G2), then it becomes OS (and sometimes OS version)
dependent on whether CT is required or not.  This is because different
certificate validation libraries have different path building rules.
Some use the longest trusted path, some the shortest, and others use
more complex logic.

Correct, the answer includes a degree of variance depending on how the underlying platform both constructs certificate chains and evaluates trust anchors, and then reports these back to Chrome. Aligning these behaviours across platforms is very much a goal of the Chrome Networking Security team.

As with the prior items, I would encourage Chrome to consider this a blocker for changing the 7c default to true.  Having mixed behaviour is going to drive Chrome users, web site operators, and help desk technicians nuts and provide a very poor customer experience.

 

5) We think that it makes sense to add an administrative policy that
allows specifying public key hashes to exclude from CT expectations.
This way a specific subordinate CA can be excluded and work the same
on all Chrome platforms.  It also solves the problem of having to list
hundreds or thousands of domains; instead of listing each registered
domain, the administrator can list the specific issuer key.  Can
Chrome add an administrative policy for this?

It was an intentional decision not to allow this functionality.

Can you clarify why?  Given the request for an administrative policy and Law #6 (see above), I'm failing to see the reasoning.  The administrator could hot patch Chrome, a la certain AV, to change the exclusion lists.  Why not allow them to set a policy for it?

 

None of the current options provide any method of public opt-out for
CT by domain registrants.  A number of proposals have been suggested
over time, but none have hit the mark.  While I still don't know the
full right answer, I would like to propose an option that I think is
limited enough to assuage many concerns but also broad enough to
provide value.  Chrome already supports public key pinning and name
constrained CAs.  We would like to propose that pins that
includeSubDomains can also include an expect-ct directive.  When set
to false, this directive tells the browser to not expect CT for
subdomains.  This directive would only be honored if the pin matches a
key that is determined by the browser to be name constrained.  This
allows a domain owner to clearly indicate that CT should not be
expected for a domain namespace.

I'm not sure I understand this proposal sufficiently to comment-on it. Are you proposing adding this as a directive to HPKP? I'm not sure we'd be supportive of this, but it's very likely I've misunderstood the proposal

Yes, adding a directive to HPKP that says "only trust these PINs and if they pass don't require CT".  I suggested only obeying this directive if the pin also matched a name constrained node in the graph of certificates and subjects, but that was a suggestion to further constrain the exclusion rules.

[Ryan Sleevi]

On Fri, Mar 10, 2017 at 6:28 PM, Peter Bowen <pzb...@gmail.com> wrote:

4) Chrome determines whether or not the certificate chain validated to a 'publicly trusted root'. The mechanism of this varies per platform, and can result in different results for the same keys under some situations, but effectively attempts to distinguish whether or not the certificate was one hardcoded as trusted by the underlying platform. If so, it applies a number of secondary checks to the certificate.

"If so, ..." implies that processing stops here if Chrome determines that it did not validate to a 'publicly trusted root'.  Is that right?

Nope. It continues, but just without the secondary checks from #4 applied.

 

3) The policy documentation for
CertificateTransparencyEnforcementDisabledForUrls does not indicate it
is supported on Android System WebView (Android) or Google Chrome
(iOS).  What is the plan to resolve this so that all managed devices
have similar capabilities for configuration?

There is none at this time.

 

I would encourage Chrome to consider this a blocker for changing the 7c default to true for these platforms.  Mobile device management exists and is widely deployed.  As you wrote on IETF TRANS, and in other places, Law #6: A computer is only as secure as the administrator is trustworthy (from Ten Immutable Laws Of Security) implies that trying to control around the administrator is a futile task.

Sure, except none of this applies to iOS, so of course there's no plan there. Due to Apple's restrictions, we are forced to use Apple's certificate validation library on iOS. While this may be detrimental overall to the security of our users, it doesn't make sense :)

As for Android, I would just say its security model values application developers having control, even in the face of device owners. You can see this very clearly in Android's policies related to CA certificate installation - app developers trump mobile device managers with respect to installing custom roots.

 

 

4) https://support.google.com/chrome/a/answer/187202 describes the
Chrome policy model.  It notes that policies are available via the
admin console for Chrome OS and available via the G Suite admin
console.   I'm unable to find the
CertificateTransparencyEnforcementDisabledForUrls policy in the admin
console.  How does one set the policy for Chromebooks and managed
Chrome users?

Thanks for highlighting this. I'll need to get back to you on it, but it looks like an unintentional oversight in allowing the full robustness of ChromeOS policies. We've not had any customer request this, but this is a useful aspect to consider.

As with the prior item, I would encourage Chrome to consider this a blocker for changing the 7c default to true.  Customers have likely not requested this in part because CT is only required for one CA operator today.  I'm sure that many customers solved the CT "problem" by getting certificates from another CA rather than trying to set non-existent policy options.

I think it's great you brought it up, and I'll need to look into what it would take to make this happen, and how that might affect an October 2017 date.

 

Correct, the answer includes a degree of variance depending on how the underlying platform both constructs certificate chains and evaluates trust anchors, and then reports these back to Chrome. Aligning these behaviours across platforms is very much a goal of the Chrome Networking Security team.

As with the prior items, I would encourage Chrome to consider this a blocker for changing the 7c default to true.  Having mixed behaviour is going to drive Chrome users, web site operators, and help desk technicians nuts and provide a very poor customer experience.

I think these are all important points to consider, and I really appreciate you bringing them up. This is exactly the kind of feedback we hoped to receive when I sent out https://cabforum.org/pipermail/public/2016-October/008638.html . While it's much later than the three months suggested, the fact that you brought this up sooner than later is extremely valuable.

 

Can you clarify why?  Given the request for an administrative policy and Law #6 (see above), I'm failing to see the reasoning.  The administrator could hot patch Chrome, a la certain AV, to change the exclusion lists.  Why not allow them to set a policy for it?

I can understand and appreciate that argument, but I think we should be careful in suggesting that every administratively-requested feature should be implemented, "or else". I fully acknowledge we cannot prevent something like that from happening, but that's distinct and different than enabling it to be supported and/or making it easy. There is still a distinction there.

 

I'm not sure I understand this proposal sufficiently to comment-on it. Are you proposing adding this as a directive to HPKP? I'm not sure we'd be supportive of this, but it's very likely I've misunderstood the proposal

Yes, adding a directive to HPKP that says "only trust these PINs and if they pass don't require CT".  I suggested only obeying this directive if the pin also matched a name constrained node in the graph of certificates and subjects, but that was a suggestion to further constrain the exclusion rules.

I see. I think that unnecessarily conflates HPKP with additional policy, in a way that may encourage unnecessarily risky behaviours that negatively impact users - in as much as setting pins requires a significantly greater degree of organizational competence than those who may wish to disable CT - but I also think it represents a subtle, but significant, shift from having the machine administrator set the policy to have the domain administer set the policy.

I'm sure, no doubt, that many domain administrators would like to disable the requirement that the certificate chain to a valid root. This is certainly evident from the many discussions proposing support for DANE or self-signed certificates. And while the objective and goals are understandable, they also undermine the assurances necessary for a browser to successfully and properly indicate it's connecting to the origin it expects and to the level of assurance necessary to enable powerful features or warrant to the user that their connection is sufficiently encrypted.

This gets to the heart of the discussion of redaction - whether the needs for users (to have a minimal level of assurance in the HTTPS connection) trumps the desires of site operators (to lower the level of assurance, such as by opting out of publicly-trusted CAs or opting out of Certificate Transparency). For browsers, we have two useful principles to help guide these discussions:

- Respect the priority of constituencies

- Be secure by design

[Peter Bowen]

(I'm trimming this follow up to only address administrator configured policy)

On Fri, Mar 10, 2017 at 3:42 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
> On Fri, Mar 10, 2017 at 6:28 PM, Peter Bowen <pzb...@gmail.com> wrote:
>>>
>>> 4) Chrome determines whether or not the certificate chain validated to a
>>> 'publicly trusted root'. The mechanism of this varies per platform, and can
>>> result in different results for the same keys under some situations, but
>>> effectively attempts to distinguish whether or not the certificate was one
>>> hardcoded as trusted by the underlying platform. If so, it applies a number
>>> of secondary checks to the certificate.
>>
>>
>> "If so, ..." implies that processing stops here if Chrome determines that
>> it did not validate to a 'publicly trusted root'. Is that right?
>
>
> Nope. It continues, but just without the secondary checks from #4 applied.

"secondary checks" meaning the DV rules? (#4 is a little ambiguous at
this point)

>>>> 3) The policy documentation for
>>>> CertificateTransparencyEnforcementDisabledForUrls does not indicate it
>>>> is supported on Android System WebView (Android) or Google Chrome
>>>> (iOS). What is the plan to resolve this so that all managed devices
>>>> have similar capabilities for configuration?
>>>
>>> There is none at this time.
>>
>> I would encourage Chrome to consider this a blocker for changing the 7c
>> default to true for these platforms. Mobile device management exists and is
>> widely deployed. As you wrote on IETF TRANS, and in other places, Law #6: A
>> computer is only as secure as the administrator is trustworthy (from Ten
>> Immutable Laws Of Security) implies that trying to control around the
>> administrator is a futile task.
>
> Sure, except none of this applies to iOS, so of course there's no plan
> there. Due to Apple's restrictions, we are forced to use Apple's certificate
> validation library on iOS. While this may be detrimental overall to the
> security of our users, it doesn't make sense :)

Just so there is not confusion, are you saying Chrome on iOS is not
part of the announced CT-for-all plan -- Chrome on iOS will not check
implement CT checks?

> As for Android, I would just say its security model values application
> developers having control, even in the face of device owners. You can see
> this very clearly in Android's policies related to CA certificate
> installation - app developers trump mobile device managers with respect to
> installing custom roots.

What is the CT policy going to be for WebView in the announced CT-for-all plan?

>> Can you clarify why? Given the request for an administrative policy and
>> Law #6 (see above), I'm failing to see the reasoning. The administrator
>> could hot patch Chrome, a la certain AV, to change the exclusion lists. Why
>> not allow them to set a policy for it?
>
>
> I can understand and appreciate that argument, but I think we should be
> careful in suggesting that every administratively-requested feature should
> be implemented, "or else". I fully acknowledge we cannot prevent something
> like that from happening, but that's distinct and different than enabling it
> to be supported and/or making it easy. There is still a distinction there.

The biggest driver for this is organizations with hundreds, or even
thousands, of domains. They can exempt a specific subordinate CA
(e.g. one for their exclusive use, a la GIA G2) rather than pushing
policy with thousands of domains. It also gives domain owners more
assurance over the exclusion -- it means that only their designed
issuer is exempt rather than exempting all issuers. So unlogged certs
from a different issuer will not work.

I think offering domain and public key (e.g. issuer) options are
important alternatives for administrators.

Thanks,
Peter

[Ryan Sleevi]

On Fri, Mar 10, 2017 at 10:12 PM, Peter Bowen <pzb...@gmail.com> wrote:

(I'm trimming this follow up to only address administrator configured policy)

On Fri, Mar 10, 2017 at 3:42 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
> On Fri, Mar 10, 2017 at 6:28 PM, Peter Bowen <pzb...@gmail.com> wrote:
>>>
>>> 4) Chrome determines whether or not the certificate chain validated to a
>>> 'publicly trusted root'. The mechanism of this varies per platform, and can
>>> result in different results for the same keys under some situations, but
>>> effectively attempts to distinguish whether or not the certificate was one
>>> hardcoded as trusted by the underlying platform. If so, it applies a number
>>> of secondary checks to the certificate.
>>
>>
>> "If so, ..." implies that processing stops here if Chrome determines that
>> it did not validate to a 'publicly trusted root'.  Is that right?
>
>
> Nope. It continues, but just without the secondary checks from #4 applied.

"secondary checks" meaning the DV rules? (#4 is a little ambiguous at
this point)

#4 is the application of policy that applies to publicly trusted certificates - for example, does it comply with the Baseline Requirements, does its validity period meet Chrome's minimum expectations, are there other per-Enterprise policies in place (for example, SHA-1, revocation checking, or common-name fallback in the absence of SANs) that only run for non-publicly-trusted certificates (modulo the distinction of distinguishing them)

The only _reliable_ path is that if there's no chain to a publicly trusted root, you can be guaranteed they will be properly identified. If the certificate has a path to one or more public roots, then we cannot and do not guarantee it will not be subject to those policies.

 

Just so there is not confusion, are you saying Chrome on iOS is not
part of the announced CT-for-all plan -- Chrome on iOS will not check
implement CT checks?

I'm saying it's complicated and fluid :)

 

> As for Android, I would just say its security model values application
> developers having control, even in the face of device owners. You can see
> this very clearly in Android's policies related to CA certificate
> installation - app developers trump mobile device managers with respect to
> installing custom roots.

What is the CT policy going to be for WebView in the announced CT-for-all plan?

At this moment, it is expected to be the same, but that discussion is ongoing.

 

The biggest driver for this is organizations with hundreds, or even
thousands, of domains.  They can exempt a specific subordinate CA
(e.g. one for their exclusive use, a la GIA G2) rather than pushing
policy with thousands of domains.  It also gives domain owners more
assurance over the exclusion -- it means that only their designed
issuer is exempt rather than exempting all issuers.  So unlogged certs
from a different issuer will not work.

I think offering domain and public key (e.g. issuer) options are
important alternatives for administrators.

I think on this point, we may continue to disagree. It creates the opportunity to exclude one or more trust anchors in a way that may represent a security risk. We should strive to ensure the level of configuration offered is one that is suitable for the use case, but also to avoid configuration options which involve disabling critical security checks.

I think you've touched on an interesting dimension to this. By excluding by domain, as you note, regardless of issuer, the checks are bypassed. If it truly is an enterprise scenario, however, something like HPKP could be sufficient. As HPKP would be disabled for enforcement for the 'enterprise' chaining roots, you could get an HPKP policy to a non-existent key. Any certificate from your enterprise root will be accepted - and not logged (per the domain policy). Any certificate from any other issuer - except an issuer manually installed - will be prevented, because they will chain to publicly trusted certificates, and thus fail the HPKP policy.

Conversely, an improperly applied exclusion policy could create an attractive target for the equivalent of 'self-XSS' targets - excluding one or more publicly trusted certificates, which Chrome absolutely expects to abide by the level and degree of public trust afforded to them, from appropriate policies. Much in the same way that our policies like "EnableSha1ForLocalAnchors" or "EnableCommonNameFallbackForLocalAnchors" only reliably applies for certificates not rooted in any public trust, any sort of exploration of an exclusion per-trust anchor would need a more carefully analyzed risk/reward model.

I'm very careful here about the risk such a control would offer - the number of organizations with thousands of domains is likely a very small (by percentage) population of those who might use enterprise policies, but the risk afforded by a smaller organization with only one or two domains setting such a configuration would be very large. The only way to truly mitigate that is to ensure there is _no_ public trust anchor in the path before allowing such a configuration option to be offered - while the administrator needs to be trusted if they are to administer the machine, we should not make it unduly complex or dangerous for them to do so. 

[Peter Bowen]

On Sat, Mar 11, 2017 at 6:12 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
> On Fri, Mar 10, 2017 at 10:12 PM, Peter Bowen <pzb...@gmail.com> wrote:
>>
>> (I'm trimming this follow up to only address administrator configured
>> policy)
>>
>> On Fri, Mar 10, 2017 at 3:42 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>> >
>> > On Fri, Mar 10, 2017 at 6:28 PM, Peter Bowen <pzb...@gmail.com> wrote:
>> >
>> > Nope. It continues, but just without the secondary checks from #4
>> > applied.
>>
>> "secondary checks" meaning the DV rules? (#4 is a little ambiguous at
>> this point)
>
>
> #4 is the application of policy that applies to publicly trusted
> certificates - for example, does it comply with the Baseline Requirements,
> does its validity period meet Chrome's minimum expectations, are there other
> per-Enterprise policies in place (for example, SHA-1, revocation checking,
> or common-name fallback in the absence of SANs) that only run for
> non-publicly-trusted certificates (modulo the distinction of distinguishing
> them)
>
> The only _reliable_ path is that if there's no chain to a publicly trusted
> root, you can be guaranteed they will be properly identified. If the
> certificate has a path to one or more public roots, then we cannot and do
> not guarantee it will not be subject to those policies.
>
>

What about combing such an option with some requirements on the
certificate that matches the public key hash? For example require
that it not be a trust anchor. Or the requirement could be that the
certificate be a CA certificate with a name constraint extension that
has at least one directoryName in the permittedSubtrees and the CA
certificate be publicly logged. Or create a new extension that is
used to declare the CA certificate as being the equivalent of a ICANN
spec9 or spec13 gTLD -- only for use by a defined group. Or require
some combination of these.

> I'm very careful here about the risk such a control would offer - the number
> of organizations with thousands of domains is likely a very small (by
> percentage) population of those who might use enterprise policies, but the
> risk afforded by a smaller organization with only one or two domains setting
> such a configuration would be very large. The only way to truly mitigate
> that is to ensure there is _no_ public trust anchor in the path before
> allowing such a configuration option to be offered - while the administrator
> needs to be trusted if they are to administer the machine, we should not
> make it unduly complex or dangerous for them to do so.

Given the variability of path building across platforms, the only way
today to "ensure there is _no_ public trust anchor in the path" is to
use a locally trusted CA that is completely outside the WebPKI graph.
Given that these are already excluded from the CT requirement, this
isn't a very interesting case to discuss.

Thanks,
Peter

[Ryan Sleevi]

On Sat, Mar 11, 2017 at 10:15 AM, Peter Bowen <pzb...@gmail.com> wrote:

What about combing such an option with some requirements on the

certificate that matches the public key hash?  For example require
that it not be a trust anchor. 

Why is this desirable?

 

Or the requirement could be that the
certificate be a CA certificate with a name constraint extension that
has at least one directoryName in the permittedSubtrees and the CA
certificate be publicly logged. 

Why is this desirable?

 

Or create a new extension that is
used to declare the CA certificate as being the equivalent of a ICANN
spec9 or spec13 gTLD -- only for use by a defined group.  Or require
some combination of these.

To self-answer the above two questions, or at least to make sure I'm understanding, your goal is to explore ways to make it less likely to be misconfigured, correct?

I'm still back to the central question - why is it at all necessary for a certificate that roots in a public trust anchor to have this capability? Why is enterprise management insufficient to this?

My understanding, perhaps incorrectly, is because the enterprise administrator wants it to apply to hundreds or thousands of domains. I personally think that's counter to the general goals for a 'simply secure' browser, but I want to make sure to understand and articulate the use case. I'm also questioning whether or not this is realistically common for all but the largest of organizations - generally, organizations who by virtue of size need a degree of technical savvy anyways.

 

> I'm very careful here about the risk such a control would offer - the number
> of organizations with thousands of domains is likely a very small (by
> percentage) population of those who might use enterprise policies, but the
> risk afforded by a smaller organization with only one or two domains setting
> such a configuration would be very large. The only way to truly mitigate
> that is to ensure there is _no_ public trust anchor in the path before
> allowing such a configuration option to be offered - while the administrator
> needs to be trusted if they are to administer the machine, we should not
> make it unduly complex or dangerous for them to do so.

Given the variability of path building across platforms, the only way
today to "ensure there is _no_ public trust anchor in the path" is to
use a locally trusted CA that is completely outside the WebPKI graph.
Given that these are already excluded from the CT requirement, this
isn't a very interesting case to discuss.

I think it's relevant to the general goal - which is to ensure the level of system configuration afforded is unlikely to be misused, whether through enterprise misconfig or through user 'self-xss' style.

To put a different spin on it, consider the desire (but not yet implemented), where installing an 'enterprise' trust anchor can be name constrained to a specific set of domains. This allows organizations to self-host their sites' certificates (generally, internal sites), without _also_ granting that trust anchor the keys to the enterprise. That's an example where trusting by a key - the only solution offered - results in meaningfully worse security than being able to trust by name.

Is there any other use case for this, besides the 'organization with a large number of domains' case? Setting aside the domain operator case, and focusing just on the enterprise case, it at least helps inform discussions regarding Chrome's management capabilities. 

[Ryan Sleevi]

Peter,

I realized I may have misunderstood your proposal, so I wanted to try and check to see if I'm understanding the different parts and requests from the threads:

1) Allow CT enterprise policies to be managed via G Suite Admin Console, as captured in https://support.google.com/a/answer/2657289?hl=en

  a) This aligns ChromeOS policy support with that of other Chrome platforms.

  b) This also applies to users who sign-in to the Chrome browser on their own devices with their GSuite-managed account information ("BYOD")

2) Support the ability to exclude (now) and include (future) SPKI hashes (in the format HPKP describes) from CT policy requirements, in addition to the already provided capabilities for domain names.

  a) Implicitly, this policy should apply to all Enterprise-installed trust anchors that are not certified by "publicly trusted CAs", as consistent with RFC 6962/RFC 6962-bis' advice on spam mitigation preventing such roots from being added to logs.

  b) However, there's two nuances here to this policy:

    i) Intermediate certificates with one or more paths that terminate in a 'publicly trusted' CA certificate, and which are installed locally as trust anchors/"trusted roots".

    ii) Intermediate certificates with one or more paths that terminate in a 'publicly trusted' CA certificate, and which are _not_ installed locally as trust anchors

3) In order for #2 to be implemented, better documentation and guidance about what Chrome decides is a publicly trusted CA, so that an enterprise can distinguish whether 2.a implicitly applies, or whether any of the options in 2.b need explicit configuration.

The questions about Chrome's certificate path building and logic seemed to be related to distinguishing 2.b.i from 2.b.ii, and relate to the need to understand 3 - is that correct?

Further, 2.b.i only applies to Enterprises that have installed the CA as an enterprise TA, so the security "footgun" risk is not really meaningfully different than 2.a.

However, since 2.b.ii represents a potentially large footgun - such as accidentally excluding a root (or cross-signed) CA, or significant portions of its issuance infrastructure in a way that may leave the Enterprises' users at unrecognized risk - you suggested that it may be possible to limit the set of keys excluded in 2.b.ii to those associated with certificates that are technically identifiable and limited in some way of their scope of issuance or impact.

Examples:

- If the certificate is nameConstrained to a set of DNS names

Use Case: This is merely an optimization over the existing policy, by allowing an Enterprise to manage its set of domains in a central location (the certificate), and then use Enterprise Policies to simply refer to the key in that certificate/certificates. This reduces the number of times the list of domains have to be typed, optimizes memory usage, and hopefully reduces the risk of typos or other misconfiguration.

- If the certificate is nameConstrained to a set of Directory Names

Use Case: Assuming the CA is properly adhering to the Baseline Requirements, and the nameConstraint requires an OV vetting by including an O field, all certificates issued from this intermediate MUST be affiliated with the organizational information present in the certificate. An Enterprise that adds an Enterprise Policy to exempt this key is accepting the risk that the CA may violate the Baseline Requirements (and issue certificates to parties outside of their organization, without their approval), but barring misissuance (which they're explicitly indicating they're not concerned about), it's effectively only to domains within their organization.

- Both 2.a and 2.b.i are really just a variants of this principle, except they are 'implicit' attributes derived from the client machine ("installed as trust anchor"), rather than an explicit attribute like a nameConstraint

Hopefully I got it right this time, and if so, apologies for being so dense. And if not, also apologies for being so dense, and let's see where I messed up.

[Peter Bowen]

On Tue, Mar 14, 2017 at 2:08 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> Peter,
>
> I realized I may have misunderstood your proposal, so I wanted to try and
> check to see if I'm understanding the different parts and requests from the
> threads:
>
> 1) Allow CT enterprise policies to be managed via G Suite Admin Console, as
> captured in https://support.google.com/a/answer/2657289?hl=en
> a) This aligns ChromeOS policy support with that of other Chrome
> platforms.
> b) This also applies to users who sign-in to the Chrome browser on their
> own devices with their GSuite-managed account information ("BYOD")

Yes. If I understand correctly, this means Windows group policy,
Apple Profile Manager, G Suite admin console, and various MDM
solutions all can set the Chrome CT policy. This ensures policy can
be set on all platforms and does not lock customers into any specific
management technology.

> 2) Support the ability to exclude (now) and include (future) SPKI hashes (in
> the format HPKP describes) from CT policy requirements, in addition to the
> already provided capabilities for domain names.
> a) Implicitly, this policy should apply to all Enterprise-installed trust
> anchors that are not certified by "publicly trusted CAs", as consistent with
> RFC 6962/RFC 6962-bis' advice on spam mitigation preventing such roots from
> being added to logs.
> b) However, there's two nuances here to this policy:
> i) Intermediate certificates with one or more paths that terminate in a
> 'publicly trusted' CA certificate, and which are installed locally as trust
> anchors/"trusted roots".
> ii) Intermediate certificates with one or more paths that terminate in a
> 'publicly trusted' CA certificate, and which are _not_ installed locally as
> trust anchors

Yes, using the any of the policy options in #1.

> 3) In order for #2 to be implemented, better documentation and guidance
> about what Chrome decides is a publicly trusted CA, so that an enterprise
> can distinguish whether 2.a implicitly applies, or whether any of the
> options in 2.b need explicit configuration.
>
> The questions about Chrome's certificate path building and logic seemed to
> be related to distinguishing 2.b.i from 2.b.ii, and relate to the need to
> understand 3 - is that correct?

Yes. Due to Chrome involving the OS in path building and variations
in different libraries what is 2.b.i on platform might be considered
as 2.b.ii on another.

> Further, 2.b.i only applies to Enterprises that have installed the CA as an
> enterprise TA, so the security "footgun" risk is not really meaningfully
> different than 2.a.
>
> However, since 2.b.ii represents a potentially large footgun - such as
> accidentally excluding a root (or cross-signed) CA, or significant portions
> of its issuance infrastructure in a way that may leave the Enterprises'
> users at unrecognized risk - you suggested that it may be possible to limit
> the set of keys excluded in 2.b.ii to those associated with certificates
> that are technically identifiable and limited in some way of their scope of
> issuance or impact.

Bingo.

> Examples:
>
> - If the certificate is nameConstrained to a set of DNS names
> Use Case: This is merely an optimization over the existing policy, by
> allowing an Enterprise to manage its set of domains in a central location
> (the certificate), and then use Enterprise Policies to simply refer to the
> key in that certificate/certificates. This reduces the number of times the
> list of domains have to be typed, optimizes memory usage, and hopefully
> reduces the risk of typos or other misconfiguration.
>
> - If the certificate is nameConstrained to a set of Directory Names
> Use Case: Assuming the CA is properly adhering to the Baseline Requirements,
> and the nameConstraint requires an OV vetting by including an O field, all
> certificates issued from this intermediate MUST be affiliated with the
> organizational information present in the certificate. An Enterprise that
> adds an Enterprise Policy to exempt this key is accepting the risk that the
> CA may violate the Baseline Requirements (and issue certificates to parties
> outside of their organization, without their approval), but barring
> misissuance (which they're explicitly indicating they're not concerned
> about), it's effectively only to domains within their organization.
>
> - Both 2.a and 2.b.i are really just a variants of this principle, except
> they are 'implicit' attributes derived from the client machine ("installed
> as trust anchor"), rather than an explicit attribute like a nameConstraint

Yes. It also allows the Enterprise choosing to set the policy some
level of assurance over what scope of certificates they are excluding.
On many systems today the 2.b.i option (adding an entry to the trust
list) results in an "uber-CA" which has no scope; it is trusted for
every name and every key usage, which is far less than ideal. 2.b.ii
allows using the existing constraint mechanisms (e.g. EKUs and SAN
subtrees) to scope the CT exclusion.

> Hopefully I got it right this time, and if so, apologies for being so dense.
> And if not, also apologies for being so dense, and let's see where I messed
> up.

I think you got it right!

[Ryan Sleevi]

On Tue, Mar 14, 2017 at 5:54 PM, Peter Bowen <pzb...@gmail.com> wrote:

> Hopefully I got it right this time, and if so, apologies for being so dense.
> And if not, also apologies for being so dense, and let's see where I messed
> up.

I think you got it right!

Fantastic! 

This is all incredibly useful, valuable, and actionable feedback - exactly the kind of feedback being solicited in https://cabforum.org/pipermail/public/2016-October/008638.html . Thanks for taking the time to explain these issues and explore solutions that finds the right balance for these use cases. 

I'll need to take these suggestions back to the various teams that would need to be involved to better understand what impact, if any, this might have on the timeline outlined in the above thread.

[Ryan Dickson]

Hi,

I've found this thread's dialogue very helpful - thanks for the discussion.

I was wondering if someone in the Group could please help me better understand the new CertificateTransparencyEnforcementDisabledForLegacyCas policy, a configuration that I believe materialized as a result of the discussion earlier in the thread between Ryan and Peter.

I was attempting to test the new policy configuration with https://fpki-graph.fpki-lab.gov/, a site which I know can chain to the USG's Federal Common Policy CA (COMMON) or IdenTrust Public Sector Root CA 1. I figured this would give me two chances of confirming the policy (once for each root), as both of the chaining Root SPKIs exist in root_stores.json. I am using Canary Version 67.0.3394.0.

Root SPKIs in Question:

8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5 (COMMON) 58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477 (IdenTrust Public Sector Root CA 1)

Targeted Registry Configurations:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\CertificateTransparencyEnforcementDisabledForLegacyCas] "1"="sha256/8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5" "2"="sha256/58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477"

When navigating to chrome://policy/ in Canary, the CertificateTransparencyEnforcementDisabledForLegacyCas policy appears with a Status of OK and Policy Value of sha256/8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5,sha256/58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477,which appears to be consistent with the expected configuration.

That said, despite when browsing to the FPKI graph and chaining to either of the SPKI values listed above, I still get hit with the NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error.

I have not seen the new configuration posted to the Chrome Policies page, which appears to be last updated for Chrome 67.0.3364.0, so it is very possible my configuration is incorrect.

Thanks for any help you might be able to offer.

- Ryan

[Ryan Sleevi]

On Mon, Apr 16, 2018 at 9:06 AM, Ryan Dickson <ryan.d...@gmail.com> wrote:

Hi,

I've found this thread's dialogue very helpful - thanks for the discussion.

I was wondering if someone in the Group could please help me better understand the new CertificateTransparencyEnforcementDisabledForLegacyCas policy, a configuration that I believe materialized as a result of the discussion earlier in the thread between Ryan and Peter.

I was attempting to test the new policy configuration with https://fpki-graph.fpki-lab.gov/, a site which I know can chain to the USG's Federal Common Policy CA (COMMON) or IdenTrust Public Sector Root CA 1. I figured this would give me two chances of confirming the policy (once for each root), as both of the chaining Root SPKIs exist in root_stores.json. I am using Canary Version 67.0.3394.0.

Root SPKIs in Question:

8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5 (COMMON) 58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477 (IdenTrust Public Sector Root CA 1)

Targeted Registry Configurations:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\CertificateTransparencyEnforcementDisabledForLegacyCas] "1"="sha256/8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5" "2"="sha256/58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477"

When navigating to chrome://policy/ in Canary, the CertificateTransparencyEnforcementDisabledForLegacyCas policy appears with a Status of OK and Policy Value of sha256/8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5,sha256/58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477,which appears to be consistent with the expected configuration.

No, it's base64-encoded, not hex encoded. See below.

 

That said, despite when browsing to the FPKI graph and chaining to either of the SPKI values listed above, I still get hit with the NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED error.

I have not seen the new configuration posted to the Chrome Policies page, which appears to be last updated for Chrome 67.0.3364.0, so it is very possible my configuration is incorrect.

The policies page is updated, now that M67 has formally branched. https://www.chromium.org/administrators/policy-list-3#CertificateTransparencyEnforcementDisabledForLegacyCas has documentation.

[Ryan Sleevi]

On Mon, Apr 16, 2018 at 10:14 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Mon, Apr 16, 2018 at 9:06 AM, Ryan Dickson <ryan.d...@gmail.com> wrote:

Hi,

I've found this thread's dialogue very helpful - thanks for the discussion.

I was wondering if someone in the Group could please help me better understand the new CertificateTransparencyEnforcementDisabledForLegacyCas policy, a configuration that I believe materialized as a result of the discussion earlier in the thread between Ryan and Peter.

I was attempting to test the new policy configuration with https://fpki-graph.fpki-lab.gov/, a site which I know can chain to the USG's Federal Common Policy CA (COMMON) or IdenTrust Public Sector Root CA 1. I figured this would give me two chances of confirming the policy (once for each root), as both of the chaining Root SPKIs exist in root_stores.json. I am using Canary Version 67.0.3394.0.

Root SPKIs in Question:

8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5 (COMMON) 58DD61FEB36EA7D258724371709149CB121337864CACB2D0999AD20739D06477 (IdenTrust Public Sector Root CA 1)

As an aside, the "IdenTrust Public Sector Root CA 1" is not a Legacy CA. It is valid on both ChromeOS and Android, and as such, everything issued by it (or cross-certified by it) MUST be Baseline Requirements compliant. 

That certificate is https://crt.sh/?caid=5737 , which is recorded as having issued https://crt.sh/?caid=5738

While https://crt.sh/?caid=5738 has been cross-certified by the Federal Bridge CA 2016, everything issued below 5738 MUST be disclosed via Certificate Transparency after April 30 in order to continue to be trusted by Chrome, and regardless, MUST comply with the Baseline Requirements. As such, there's no need to excluded that root, or that intermediate. So you only need to worry about https://crt.sh/?spkisha256=8E8B56F5918A25BD85DCE76663FD94CC23690F10EA9586613171C6F8378890D5 (the Federal Common Policy CA)

Using a tool like https://report-uri.com/home/pubkey_hash to use the PEM from https://crt.sh/?id=788 yields an HPKP policy of pin-sha256="jotW9ZGKJb2F3OdmY/2UzCNpDxDqlYZhMXHG+DeIkNU="

As expressed using the documented syntax, the policy configuration is:

sha256/jotW9ZGKJb2F3OdmY/2UzCNpDxDqlYZhMXHG+DeIkNU=

[Ryan Sleevi]

Oh, and one last note:

You can verify that common is a legacy CA by searching for the hex of the SPKI:
https://chromium.googlesource.com/chromium/src/+/ef6fc42bdc561722ddb2c0fbb0eec6d2f1d568ba/net/data/ssl/root_stores/root_stores.json#24892

And that IdenTrust is not:
https://chromium.googlesource.com/chromium/src/+/ef6fc42bdc561722ddb2c0fbb0eec6d2f1d568ba/net/data/ssl/root_stores/root_stores.json#24209

[Ryan Dickson]

Thanks for the clarification, Ryan! It is very much appreciated - and has put this into better context for me. 

I am now able to confirm the configuration.

Thanks again,

Ryan