Conditional Intent to Deprecate and Remove: Public Key Pinning

[HPKP is dead](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ).

Okay, well not quite yet 😉, but the end looks to be nigh unless something changes to fix it.

[HPKP](https://tools.ietf.org/html/rfc7469) was a standard developed in hope of solving the problem of certificate mis-issuance by allowing a domain owner to "pin" a select set of certificates.
HPKP unfortunately makes it very easy to shoot yourself in the foot by rotating pins too fast, losing access to your backup, locking yourself to a CA (if you pin the CA) and mess up rotation windows, misconfiguration etc... mostly caused by having no mechanism to recover from misconfiguration (other than waiting for the enforcement window to expire).
Unfortunately this also opens up the door to malicious pinning: HPKP based ransom (where an attacker may utilise HPKP along with temporarily gained access to your webserver to set up HPKP with pins to a certificate you do not control – and holding you to ransom, or face users unable to visit your site).

For a comprehensive overview see [this post](https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead) from last year by Ivan Ristic.

HPKP has been part of SecureHeaders since the beginning, but was (deliberately) never really explicitly encouraged (by virtue of not triggering the usual warnings that omitting other security headers will cause).
It was also one of the driving factors for introducing safe mode – in which (if safe mode is enabled) it carries the heaviest neutering value of being capped at 10 seconds of enforcement with policy propagation to subdomains disabled.

Fortunately the problem of certificate mis-issuance is now being tackled by certificate transparency and the `Expect-CT`.

I'll just grab a quote from the first link about it:
> To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs. Site operators can generally deploy Expect-CT on a domain without needing to take any additional steps when obtaining certificates for the domain. Even if the CT log ecosystem substantially changes during the validity period of the certificate, site operators can provide updated SCTs in the form of OCSP responses (if their CA supports it) or via a TLS extension (if they wish for greater control). The combination of these mitigations substantially reduces the risk of DoS (either accidental or hostile) via Expect-CT deployment. By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning.

You can set up and send the `Expect-CT` header using the [`->expectCT`](https://github.com/aidantwoods/SecureHeaders/wiki/expectCT) method, and incase you want some more reading on it – take a look at [this post](https://scotthelme.co.uk/a-new-security-header-expect-ct/) by Scott Helme, or the [latest draft spec](https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct).

---

So that leaves the issue of HPKP in SecureHeaders. The proposal linked first plans to remove support in Chrome by 29th May 2018. I would suggest that if there are no objections to deprecate the following parts of the public API:

```php
SecureHeaders::hpkp
SecureHeaders::hpkpro
SecureHeaders::hpkpSubdomains
SecureHeaders::hpkproSubdomains
```

and then subsequently removing support in a major release that occurs sometime around (but preferably before) the Chrome removal date.

All this hinges on Chrome's intent to deprecate and remove being actioned, and we should also wait to see if Firefox follows suit. This means no date for even the deprecation on the public API, but I'll update this issue when more information is available.

This issue serves as a conditional intent to deprecate and remove, subject to outcome of browser decisions.