Re: [fetch] Request for support for certificate pinning (#98)

@sleevi, I read the RFC7540 and it does not seem to agree with you. Specifically in the second paragraph it states:
> The certificate presented by the server MUST satisfy any checks that the
> client would perform when forming a new TLS connection for the host in the URI.

This means you can't use a cert that would *not* be the one presented to you if you would have connected to the host in the URI in the first place.

Then in the third paragraph it actually explains the usage with wildcard certificates by stating that a cert can cover more than one URI, but nowhere does it say that a single URI can be covered by two different certs *and that this is allowed to be cached*. I believe this section might be the source of your confusion.

Then in the following two paragraphs it goes on to explain that if a server ends up getting a request to a URI that it is not authorized to serve it should fail the request with 421 (Misdirected Request). This makes very much sense: A server serving a.example.com with a wildcard cert. The cert covers b.example.com, however the server is not actually the right host. b.example.com is a different host and is using a different cert. We actually have this setup in our local network.

But even if this case was allowed, it would be irrelevant to this discussion because as I wrote in the first post the user must be able to pass not only one fingerprint but an array of acceptable fingerprints, and I added that for exactly the case where there is a group of certs that are all considered valid for the connection. The primary use for this is for the case where a cert expires or gets invalidated and the new cert's or the backup cert's fingerprint is used in addition, but can certainly also be used for load balancing or weird cases where routing or caching could end up using one cert or the other.

> You've not established a use case where HPKP doesn't address, other than those that 
> intentionally violate the priority of constituencies (anti-user) or invert control of security policy.

I thought I did that in my second post. Let me extract a specific case for you: 
- A client does a request to a trusted discovery server, asking him to point it to the service it's looking for.
- the discovery server points the client to a server that provides the service it is looking for
- the client has never connected to that server before
- the client must make sure that there is no MITM between it and the service

Please let me how HPKP is solving this problem.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/98#issuecomment-130721019