FPKI shouldn't link to download root certificates over plain HTTP

[konklone]

I know this is not a direct function of the PIV Guide, but I think the PIV Guide should not include official guidance that instructs users to download root or intermediate certificates over plain HTTP.

Right now it links to this URL to download the Federal Common Policy CA root:

http://http.fpki.gov/fcpca/fcpca.crt

Any network-based attacker could include a rule that rewrites this content with an incorrect or malicious root certificate in transit. Depending on how the downloaded root certificate is then deployed, it could give the attacker a very privileged attack vantage point going forward.

Since the link is to download a root CA that the user is not expected to already have installed locally, the root certificate should probably be hosted on a subdomain which uses a certificate that does not chain to the Federal Common Policy.

[grandamp]

+1

On Mon, Apr 18, 2016, 22:36 Eric Mill notifications@github.com wrote:

I know this is not a direct function of the PIV Guide, but I think the PIV Guide should not include official guidance that instructs users to download root or intermediate certificates over plain HTTP.

Right now it links to this URL to download the Federal Common Policy CA root:

http://http.fpki.gov/fcpca/fcpca.crt

Any network-based attacker could include a rule that rewrites this content with an incorrect or malicious root certificate in transit. Depending on how the downloaded root certificate is then deployed, it could give the attacker a very privileged attack vantage point going forward.

Since the link is to download a root CA that the user is not expected to already have installed locally, the root certificate should probably be hosted on a subdomain which uses a certificate that does not chain to the Federal Common Policy.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/GSA/piv-guides/issues/10

[lachellel]

@konklone

I definitely had a bit of a challenge when drafting that particular section. As all can see in the commits - I also removed making it a live link (that any browsing user would click on and download potentially inadvertently!).

There is no HTTPS endpoint currently available. Currently there may be one alternate option available I believe (as in Available Today): send an email to the FPKI Management Authority mailbox and ask for a signed email response with the root certificate attached. Or the certificate is signed then attached.

@twbaldridge @weirdscience - Any suggestions? What are the options available?

[konklone]

Send an email to the FPKI Management Authority mailbox and ask for a signed email response with the root certificate attached. Or the certificate is signed then attached.

What certificate would be doing the signing in those cases?

[weirdscience]

The email would be signed by PIV card. The thumbprint for the root should be included with the download instructions so the downloaded can check it is the correct cert.

On Apr 18, 2016, at 23:19, Eric Mill notifications@github.com wrote:

Send an email to the FPKI Management Authority mailbox and ask for a signed email response with the root certificate attached. Or the certificate is signed then attached.

What certificate would be doing the signing in those cases?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[grandamp]

I'm not certain what value the signature of a PIV credential would provide. The trust anchor for PIV is the Common Policy Root CA.

If that is an acceptable distribution mechanism, then distribution via the following would be appropriate too:

https://pki.treasury.gov/crl_certs.htm

On Tue, Apr 19, 2016, 07:15 Ken Myers notifications@github.com wrote:

The email would be signed by PIV card. The thumbprint for the root should be included with the download instructions so the downloaded can check it is the correct cert.

On Apr 18, 2016, at 23:19, Eric Mill notifications@github.com wrote:

Send an email to the FPKI Management Authority mailbox and ask for a signed email response with the root certificate attached. Or the certificate is signed then attached.

What certificate would be doing the signing in those cases?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/GSA/piv-guides/issues/10#issuecomment-211864747

[tkpk]

Please help me understand. Are we trying to protect for confidentiality or integrity? AFAIK, HTTPS will only provide for confidentiality, unless you both trust the root (chicken and egg problem) AND use DNSSEC to ensure that you really are connecting to the appropriate domain. Just putting an SSL cert on a (sub) domain of fpki.gov will not prevent against the original attack, e.g. a network based attacker that sets up their own SSL protected site (using any trusted root) to distribute faux roots.

Treasury's distribution via SSL @ pki.treasury.gov uses a cert that chains to FCPCA as the root.

Without full implementation of DNSSEC, Is there a fool proof, secure way to distribute roots without an out of band component?

[konklone]

@tkpk Even without DNSSEC, HTTPS will guarantee integrity of the contents in transmission. Bear in mind, I am recommending the FPKI use a non-FPKI (probably commercial) certificate that chains to a root the client will already trust. This way the user can download the FPKI root using an alternate trusted path. A network attacker that used their own untrusted root would cause a client which performed certificate validation to balk.

To the extent users will be downloading the root through a browser, HSTS can be used to protect against the case where the user clicks an old http:// link or types the domain into a browser URL bar -- but if the PIV guide updates its link to https://, those don't apply. However, HSTS also stops web browsers from letting users click through certificate warnings, which would further defend against a network attacker who rerouted the connection to use their own root certificate.

Also, using DNSSEC without HTTPS will not guarantee integrity. DNSSEC only controls the resolution of the IP address -- after that, any content that flows along plaintext HTTP is subject to modification by any network node along the way. This is separate from the issue of whether or not the HTTP client downloading the root implements DNSSEC, which most do not.

HTTPS is a requirement for integrity, can be bolstered by HSTS, and isn't reliant on DNSSEC implementation at the server or client level to provide that guarantee.

We have some additional description of this on the https.cio.gov FAQ, since it's a complicated issue.

[lachellel]

Hey giuseppe!

I don't think there is ever a foolproof way to do anything (in my opinion). So instead of trying to be foolproof, I'd like to spend my time on raising the level of awareness across our fellow engineering community and not promoting a particular implementation pattern. And in this scenario - the pattern is: we should not want to promote having engineers download anything from an http only site.

Yes, this does pose a chicken and egg challenge for the fpki common root certificate. If we didn't have challenges like these, then we wouldn't be engineers! Let me propose this:

• I'll update the wording to add the out of band email
• Add a few sentences regarding properly checking the hash

And somehow, we have to get everyone migrating away from HTTP and implementing HTTPS with HSTS - but noone is going to be able to fix this today for the fpki sites.

[konklone]

• Add a few sentences regarding properly checking the hash

:+1: An example of running sha1sum (and/or the Windows equivalent) on the downloaded file would be a help, too.

[tkpk]

For windows, my favorite would be certutil -hashfile filename [algorithm]

On Tue, Apr 19, 2016 at 12:12 PM, Eric Mill notifications@github.com wrote:

• Add a few sentences regarding properly checking the hash

[image: :+1:] An example of running sha1sum (and/or the Windows equivalent) on the downloaded file would be a help, too.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/GSA/piv-guides/issues/10#issuecomment-212000098

[twbaldridge]

First, the download //http.fpki.gov/fcpca/fcpca.crt doesn't comply with M-15-13, it needs the "s".

Second, all PKI objects, certs, crls, etc., are signed and maintain their integrity character at rest - it doesn't matter how the PKI object is obtained because before you ever trust it you perform the object integrity checks.

The trust of any PKI object begins with a root in the possession of the relying party. The root is self-signed so that the alleged attack on the root is not possible, if the a self-signed root is tampered with you always know independently when it is checked. What you cannot know independently is if you should trust a self-signed root, there must be an out-of-band validation before any root is accepted for trust.

I agree with this issue because of M-15-13, but not for any other reason commented on.

Some discussion on mechanisms for how out-of-band self-signed root certificate trust validation is performed, is an interesting and important related topic. Maybe as a new issue?

[grandamp]

Hi Tim!

I can't agree with forcing the referenced URI to be compliant with the memo (specifically HSTS) since the server is the HTTP repository referenced in Common Policy signed certificates. I.e., https://https.cio.gov/guide/#are-federally-operated-certificate-revocation-services-(crl,-ocsp)-also-required-to-move-to-https ?

On Tue, Apr 26, 2016, 16:53 Tim W. Baldridge notifications@github.com wrote:

First, the download //http.fpki.gov/fcpca/fcpca.crt doesn't comply with M-15-13, it needs the "s".

Second, all PKI objects, certs, crls, etc., are signed and maintain their integrity character at rest - it doesn't matter how the PKI object is obtained because before you ever trust it you perform the object integrity checks.

The trust of any PKI object begins with a root in the possession of the relying party. The root is self-signed so that the alleged attack on the root is not possible, if the a self-signed root is tampered with you always know independently when it is checked. What you cannot know independently is if you should trust a self-signed root, there must be an out-of-band validation before any root is accepted for trust.

I agree with this issue because of M-15-13, but not for any other reason commented on.

Some discussion on mechanisms for how out-of-band self-signed root certificate trust validation is performed, is an interesting and important related topic. Maybe as a new issue?

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/GSA/piv-guides/issues/10#issuecomment-214882742

[konklone]

I can't agree with forcing the referenced URI to be compliant with the memo (specifically HSTS) since the server is the HTTP repository referenced in Common Policy signed certificates.

HSTS only affect user-initiated browsing sessions, and shouldn't affect any OCSP or CRL-fetching client behavior. HTTPS could also be supported, as long as you didn't set up an http:// -> https:// redirect, because existing OCSP/CRL clients would keep hitting the http:// links.

I.e., https://https.cio.gov/guide/#are-federally-operated-certificate-revocation-services-(crl,-ocsp)-also-required-to-move-to-https?

Worth noting, that section also says at the bottom:

Agencies are encouraged to operate OCSP and CRL services via hostnames specifically reserved for those services, so that other related information and functionality can be served securely and privately.

Though I do understand that can be a hassle. However, if any agency for some reason put their OCSP and CRL info on the same domain as their primary agency flagship site, I think you would expect the agency to separate them or at least enforce HTTPS for everything except the OCSP/CRL URLs.

[konklone]

Second, all PKI objects, certs, crls, etc., are signed and maintain their integrity character at rest - it doesn't matter how the PKI object is obtained because before you ever trust it you perform the object integrity checks.

The trust of any PKI object begins with a root in the possession of the relying party. The root is self-signed so that the alleged attack on the root is not possible, if the a self-signed root is tampered with you always know independently when it is checked. What you cannot know independently is if you should trust a self-signed root, there must be an out-of-band validation before any root is accepted for trust.

The issue is how the integrity checks are performed. In this case, the user isn't expected to be in possession of the FPKI root, so they would not be able to verify the signature until it's already downloaded, after which it could have been compromised.

However, you could at least do a content check. @lachellel added the SHA-1 hash to the download instructions:

SHA1 Hash: 90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1

However, then you have to trust that hash. As I understand it, those instructions will be accessed over HTTPS guaranteed by a commercial certificate, at https://gsa.github.io/piv-guides/. So, at least the SHA-1 hash will be transmitted over a connection secured by a commercial CA, and then the user can follow one of @lachellel's example commands in order to validate that the integrity is as intended.

However, what I'm noting is that it's fully incumbent on the user to perform that check, when the root is delivered insecurely at the transport layer. Even if the root were downloaded over https:// using a commercial cert, the user should still probably check the signature or hash, but if they fail to do so, the use of https:// makes the chances of the certificate being tampered with in transit drastically lower.

[twbaldridge]

Thank's to @grandamp and @konklone for the reference to the cio.gov FAQ for the exception language for PKI objects, re: HSTS.

I will point out that the self-signed roots are not included in repository referenced by URIs included in the AIA extension of certificates for the FPKI, as well as almost all of other providers I have ever examined.

For all of the reasons you have cited, it is just not practical - at scale - to assume the end-user can manage their trust store. A few PKI savvy folks in the wild cannot solve this problem. It is incumbent on all PKI stakeholders to use PKI services scoped to their community of interest (COI).

This means we need two policy concerns addressed: 1) How to determine the COI for Federal Internet facing web sites and services and the appropriate determination for a commercial PKI issued device certificate. 2) Impartial qualification of commercial PKI providers of certificates and services as providers to the U.S. Federal Executive Branch Departments and Agencies.

[weirdscience]

I think it's also an important consideration that someone mention if an agency should verify if commercial SSL meet NIST FISMA standards. This is may be a similar case to 2005 and why Common Policy and the Shared Service Provider program was established. Commercial SSL follow commercial standards which may or may not align with federal security requirements.

On Apr 27, 2016, at 09:58, Tim W. Baldridge notifications@github.com wrote:

Thank's to @grandamp and @konklone for the reference to the cio.gov FAQ for the exception language for PKI objects, re: HSTS.

I will point out that the self-signed roots are not included in repository referenced by URIs included in the AIA extension of certificates for the FPKI, as well as almost all of other providers I have ever examined.

For all of the reasons you have cited, it is just not practical - at scale - to assume the end-user can manage their trust store. A few PKI savvy folks in the wild cannot solve this problem. It is incumbent on all PKI stakeholders to use PKI services scoped to their community of interest (COI).

This means we need two policy concerns addressed: 1) How to determine the COI for Federal Internet facing web sites and services and the appropriate determination for a commercial PKI issued device certificate. 2) Impartial qualification of commercial PKI providers of certificates and services as providers to the U.S. Federal Executive Branch Departments and Agencies.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[konklone]

A few PKI savvy folks in the wild cannot solve this problem. It is incumbent on all PKI stakeholders to use PKI services scoped to their community of interest (COI).

:100:

Commercial SSL follow commercial standards which may or may not align with federal security requirements.

It's not clear to me that federal security requirements, in a general sense, are any better than the standards to which the CA/B Forum holds commercial CAs. It's also not clear to me that even the largest commercial CAs operate without risk.

But the bigger issue is that from the perspective of serving the public, there is nothing to be gained from limiting what commercial CAs are used by federal staff. You can't restrict public users' trust stores, and so even if you limit federal staff to getting certificates from the Top 10 Most Secure CAs, if one of the less secure CAs gets compromised, their systems can still be used to issue fraudulent certificates for .gov and .mil domains that public users will trust.

That is why a program to determine "approved" or "qualified" commercial PKI providers for the federal government wouldn't be helpful. All it would do is limit the marketplace that federal staff can employ and slow the pace at which new and innovative services are introduced to the federal community, without reducing the actual threat that users of federal services would face.

Instead, we can protect users from weak or compromised CAs by using other measures:

• Certificate Transparency, which has already demonstrated success many times at surfacing misissuance in the commercial space. There's not currently a dedicated effort I'm aware of to watch CT logs for .gov misissuance. crt.sh is a great (and open source) CT log viewer. CT also contributed to finding the undisclosed Identrust and Symantec cross-signs of the FPKI which have been discussed in other threads. Momentum is building in CA/B to make CT mandatory for all commercial CAs, and Symantec is going to be required by Chrome to use CT for all certificates by June 1, 2016.
• HTTP Public Key Pinning, which allows site owners to specify one or more intermediate or root keys or certificates that are authorized to be in the chain the site presents. While hard enforcement of public key pinning is potentially dangerous and could lead to a site becoming inaccessible in the case of site owner error, you can very easily set up reporting mechanisms that would start sending pinning failure reports to a URL of your choice, so you could get some visibility into potential misissuance or other issues. (Note that a full and targeted network attack could also choose to suppress HPKP reports.)

There's also CAA records, which lets you set a DNS record saying which CAs can issue for your domain, though support in the commercial CA community for this facility is poor, and in fact, some CAs may refuse to honor it.

Anyway, I would strongly caution against moving towards approval processes limiting commercial CA use within the federal government, and instead use the modern mechanisms we have at hand to control and detect misissuance, and to participate in the CA/B Forum as is helpful to ensure that the standards commercial CAs are held to are strong, reasonable, and serve the public's interest.

[twbaldridge]

I suggest avoiding qualifiers of better or worse when it comes to Federal vs. Commercial standards regarding cybersecurity - I believe we can agree that they are different. When we consider international standards and sovereign positions we know that what we must do is to manage risk. It's clear that residual risk will never diminish to zero.

The statement "there is nothing to be gained from limiting what commercial CAs are used by federal staff." wholly mischaracterizes my intent. The FAR/DFAR is very specific about competition and impartiality. By Federal Law Departments and Agency have processes and procedure to follow in acquiring goods and services that are fair and equitable and open to all.

Let me be clear, I support Certificate Transparency and HTTP Public key Pinning they are new capabilities that enhance Cybersecurity. However technology, no matter how cool, does not relieve the acquisition requirements imposed by law. It is a pragmatic approach I offer for 1) " appropriate determination for a commercial PKI issued device certificate" and provide 2) "Impartial qualification of commercial PKI providers of certificates and services" for improving efficiency and effectiveness of Gov't operations. This approach is not a limitation, but rather an enabler. It is important that we collectively insure both the logistics and technology remain in step with each other against all threats.

[lachellel]

Adore the conversations - and agree with everyone!

Any help on some of the other issues I've opened? :+1:

[konklone]

The statement "there is nothing to be gained from limiting what commercial CAs are used by federal staff." wholly mischaracterizes my intent. The FAR/DFAR is very specific about competition and impartiality. By Federal Law Departments and Agency have processes and procedure to follow in acquiring goods and services that are fair and equitable and open to all.

You're right, I misunderstood your intent -- I didn't realize you were talking about acquisition processes and fairness. Of course, agencies should follow regulations and the spirit of fairness in all acquisitions.