Subject: Re: [http-extensions] Security for spoofed certs (#98)

From: HTTP issue updates <[email-masked]>
Date: Tue, 06 Oct 2015 21:33:07 -0700

The text on pinning is fine.  If the intent is expand on the authentication requirements for alternatives, the first sentence would suffice.

I'm concerned that the "additional requirements" you describe here might lead to interoperability problems.  If these aren't specified, we are left to guess what the validation requirements are for any given client.  I recognize that failure to authenticate an alternative doesn't necessarily translate into a fatal error - the alternative is just not used.  However, I'm wondering what the motivation for the change is.

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/98#issuecomment-146074874

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 07 Oct 2015 09:00:56 -0700

This is from #76, which I should have tagged.  You argued against the spec requiring an identical cert, and I agree that synchronization and security of the cert could certainly be an issue.  However, the client might already have some data about the certs used by the origin and could reasonably expect some similarity between them.

As I said in the issue, I think cautious implementations will probably do *something* here, and I'd prefer the possibility to be mentioned in the spec so it's something operators will be aware of.

---
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/98#issuecomment-146243948