
Fixing HPKP with Pin Revocation - okket
https://blog.qualys.com/ssllabs/2017/09/05/fixing-hpkp-with-pin-revocation
======
daurnimator
I brought something similar up a while ago:
[https://news.ycombinator.com/item?id=10183444](https://news.ycombinator.com/item?id=10183444)

------
daurnimator
A question I've been meaning to ask for a while is if we could use HPKP to
bootstrap a TOFU (trust on first use) model.

i.e. you get your cert signed by both a traditional CA _and_ a CA you set up
yourself. the traditional CA would work for the first visit. However after
that it gets pinned to your own CA.

You can then sign your own certs at your leisure e.g. offline or with private
key on a yubikey.

~~~
hdhzy
But... What if a new user arrives and doesn't have your pinned CA? Your model
would require to always have a trusted CA and if you always have them why
trouble oneself with pinning custom one?

~~~
daurnimator
The idea is that the cert _must_ be signed by my own CA. But may _also_ be
signed by another CA. Meaning that after the first visit, a user is protected
from a rogue CA issuing a cert for my site.

~~~
hdhzy
Unfortunately X 509 doesn't support multiple signatures. But your model is
very similar to HPKP, just the details on what exactly is signed are
different.

~~~
daurnimator
Thanks: that was the piece of the puzzle I was missing. I was confused by how
people describe cross-signing as an intermediate cert being signed by two CAs.
On further research, it's done via having two intermediate certs.

But effectively: they accomplish cross-signing by having two different roots
for the same leaf cert: we should be able to do that with 1 CA root, and 1
site-admin root (specified via some HPKP-like mechanism)

On the other hand, perhaps the limitation of one cert should be removed
somehow? e.g. via an extension: old user-agents would just see the first
signing cert, but others would see all of them?

