CT Mandate Impact on Govt-Military Networks Using Chrome

[A. Kunz]

Looking for information related to enforcement of CT mandate for Chrome effective next April (?).  Has there been any review or discussion of potential impact to classified systems in the Federal Government or military (DoD) that use Chrome?  These of course are clearly not "public facing" systems and networks. 

[Ryan Sleevi]

Hi,

The Chrome requirement only applies to publicly trusted CAs (that is, those trusted by a default installation). As you note, such systems and networks do not use publicly trusted CAs, and are unaffected.

If those systems do use publicly trusted CAs to issue "internal" certificates, then it goes without saying that having publicly trusted CAs with (effectively) keys to the Internet issuing certificates that cannot be detected or audited by the broader community for compliance (and to ensure no misissuance) is, of course, a non-starter, given the issues that CT has detected and the broader issues in the CA ecosystem.

Does that help address your concerns?

On Tue, Oct 17, 2017 at 2:12 PM, A. Kunz <ak...@mitre.org> wrote:

Looking for information related to enforcement of CT mandate for Chrome effective next April (?).  Has there been any review or discussion of potential impact to classified systems in the Federal Government or military (DoD) that use Chrome?  These of course are clearly not "public facing" systems and networks. 

--
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+unsubscribe@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/a662b6d1-3e57-49e7-b852-5cf82e01d7c9%40chromium.org.

[Alex Gaynor]

I'm almost certain that HTTPS sites on JWICS issue from a private PKI hierarchy; not the publicly trusted (on some platforms) FPKI.

Alex

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

[A. Kunz]

Thanks Ryan!  Yes, it helps. May have additional questions but appreciate this info - confirms my assumptions.

On Tuesday, October 17, 2017 at 1:32:38 PM UTC-5, Ryan Sleevi wrote:

Hi,

The Chrome requirement only applies to publicly trusted CAs (that is, those trusted by a default installation). As you note, such systems and networks do not use publicly trusted CAs, and are unaffected.

If those systems do use publicly trusted CAs to issue "internal" certificates, then it goes without saying that having publicly trusted CAs with (effectively) keys to the Internet issuing certificates that cannot be detected or audited by the broader community for compliance (and to ensure no misissuance) is, of course, a non-starter, given the issues that CT has detected and the broader issues in the CA ecosystem.

Does that help address your concerns?

On Tue, Oct 17, 2017 at 2:12 PM, A. Kunz <ak...@mitre.org> wrote:

Looking for information related to enforcement of CT mandate for Chrome effective next April (?).  Has there been any review or discussion of potential impact to classified systems in the Federal Government or military (DoD) that use Chrome?  These of course are clearly not "public facing" systems and networks. 

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

[Kunz, Andrea A.]

Some time has passed since I raised this question but I’m back with a slight wrinkle to what I originally asked:

 

Using the example Chrome use within the DoD (non-public systems), what would the impact be (if any) when Chrome looks for one of the default CAs that it trusts and cannot reach it?  Will Chrome still want to go to a CT log to see if the CAs are still trustworthy even if the browser never attempts to access a web server/appliance/application that is in the browser’s trust store?  Will there be a way to configure Chrome for use within the DoD so that it does not go looking for a CT Log server?

 

The concern is about wanting to avoid a constant barrage of browser (Chrome or other browsers that have embraced CT) popups when used in DoD closed and classified environments.

 

Andrea

 

Andrea A. Kunz

AFLCMC/HNCIA (MITRE)

AF PKI SPO

DSN 945-9168

Comm (210) 925-9168

NIPR - andrea....@us.af.mil

SIPR - andrea...@mail.smil.mil

[Alex Gaynor]

Hi Andrea,

On Wed, May 2, 2018 at 11:45 AM, Kunz, Andrea A. <AK...@mitre.org> wrote:

Some time has passed since I raised this question but I’m back with a slight wrinkle to what I originally asked:

 

Using the example Chrome use within the DoD (non-public systems), what would the impact be (if any) when Chrome looks for one of the default CAs that it trusts and cannot reach it?  Will Chrome still want to go to a CT log to see if the CAs are still trustworthy even if the browser never attempts to access a web server/appliance/application that is in the browser’s trust store?  Will there be a way to configure Chrome for use within the DoD so that it does not go looking for a CT Log server?

(I don't work on Chrome, so I'm sure I'll be corrected on something or another :-))

Chrome never makes a connection to a CT log, it relies on SCTs being included in either the TLS handshake, a stapled OCSP response, or the certificate itself.

If FPKI (including DoD) is not going to be embedding SCTs in certificates, going forward there are two situations:

- People trusting these certificates via root certificates included with their OS (e.g. the Federal Common Policy CA, included in macOS) -- these people will see an interstitial (for certs issued after April 30), _unless_ the CertificateTransparencyEnforcementDisabledForLegacyCas enterprise option is set to exclude this CA from enforcement.

- People trusting these certificates via root certificates added by their enterprise to the CA. Enterprise CAs do not enforce CT compliance, so these will not show interstitial.

 

The concern is about wanting to avoid a constant barrage of browser (Chrome or other browsers that have embraced CT) popups when used in DoD closed and classified environments.

Within DoD you should be able to address this with the enterprise policies for controlling this. Note that any DoD site intended for public consumption should obtain a publicly trusted certificate with embedded SCTs so the public can access them without needing to ignore an interstial (e.g. iad.gov).

 

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@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/BY1PR09MB091761201161960031D0BAC8A2800%40BY1PR09MB0917.namprd09.prod.outlook.com.

Alex

[Ryan Sleevi]

On Wed, May 2, 2018 at 12:08 PM, Alex Gaynor <aga...@mozilla.com> wrote:

Hi Andrea,

On Wed, May 2, 2018 at 11:45 AM, Kunz, Andrea A. <AK...@mitre.org> wrote:

Some time has passed since I raised this question but I’m back with a slight wrinkle to what I originally asked:

 

Using the example Chrome use within the DoD (non-public systems), what would the impact be (if any) when Chrome looks for one of the default CAs that it trusts and cannot reach it?  Will Chrome still want to go to a CT log to see if the CAs are still trustworthy even if the browser never attempts to access a web server/appliance/application that is in the browser’s trust store?  Will there be a way to configure Chrome for use within the DoD so that it does not go looking for a CT Log server?

(I don't work on Chrome, so I'm sure I'll be corrected on something or another :-))

Chrome never makes a connection to a CT log, it relies on SCTs being included in either the TLS handshake, a stapled OCSP response, or the certificate itself.

If FPKI (including DoD) is not going to be embedding SCTs in certificates, going forward there are two situations:

- People trusting these certificates via root certificates included with their OS (e.g. the Federal Common Policy CA, included in macOS) -- these people will see an interstitial (for certs issued after April 30), _unless_ the CertificateTransparencyEnforcementDisabledForLegacyCas enterprise option is set to exclude this CA from enforcement.

- People trusting these certificates via root certificates added by their enterprise to the CA. Enterprise CAs do not enforce CT compliance, so these will not show interstitial.

The FPKI is a complex case, because of the cross-certifications and variations that exist, so I'll try to distill this a bit more, in the hopes of making sure it's clear and unambiguous:

- If a CA that is publicly trusted appears in the verified certificate path, then it must be disclosed via CT.

- If multiple paths exist, then RFC 5280 does not specify which path is preferred - ergo, if ANY path to a publicly trusted CA exists, then you should expect it to be required to be disclosed via CT. This is the same as the reality that if any publicly trusted path exists for a given certificate, then it's expected to fully comply with the CA/Browser Forum's Baseline Requirements and any Root Store policies that may exist.

- The FPKI is a publicly trusted CA (unfortunately), by virtue of being trusted by default on macOS and Windows versions that Chrome supports.

- The FPKI has cross-certified the DoD PKI

Thus, the DoD should expect that Certificate Transparency information will accompany the certificate - either in the certificate, provided by the (*stapled*) OCSP response, or provided by the TLS server.

Chrome will not go out and fetch CT information. The server must, as part of establishing the connection, provide all the necessary information. If it does not, the certificate will be rejected.

Thus, the DoD PKI should prepare to log its certificates.

Now, for the case of a closed network, in which the DoD PKI wishes to issue publicly trusted certificates, but not log them, the default behaviour of Chrome is that it will not trust such certificates. Setting aside the details of who is operating the CA, it is an explicit goal that all publicly trusted CAs are accountable for all of their publicly trusted certificates, hence this policy.

If an Enterprise wishes to allow a publicly trusted CA to hide the certificates it issues - hiding misissuance or attack, for example - then it can only do so for its own users using Enterprise managed devices or accounts. Such Enterprises can make use of the Enterprise Policy that Alex mentioned. If the Enterprise does not manage/own the device, and the user is not using a managed account, then the Enterprise cannot override these security settings - because the user and device have not consented.

 

The concern is about wanting to avoid a constant barrage of browser (Chrome or other browsers that have embraced CT) popups when used in DoD closed and classified environments.

Within DoD you should be able to address this with the enterprise policies for controlling this. Note that any DoD site intended for public consumption should obtain a publicly trusted certificate with embedded SCTs so the public can access them without needing to ignore an interstial (e.g. iad.gov).

Correct. If used within a closed network, the use of Enterprise Policies to reflect that the closed network is willing to accept the degraded security of not enforcing CT for certain legacy CAs that can't adhere to the security necessary for public trust is appropriate.