> On 28 Nov 2016, at 23:23, Alice Wonder <[email protected]> wrote: > > And that is exactly why I never use HPKP - it does not give the system > administrator any flexibility when a new cert / key is needed. > > In theory there should be a backup key already with a pin to take care of > cases where the private key is compromised, but as soon as you have to use it > you are vulnerable to bricking the site for some users if that key needs to > be revoked. > > It also gives no flexibility whatsoever when you have to fire a system > administrator who may have had access to private keys. Normally in that > situation you generate new keys, but with HPKP you are stuck keeping the old > keys active until the new keys have had their pins in the header longer than > the TTL. > > Why people like HPKP so much is a real mystery to me.
I think this is based on a common misunderstanding of the capabilities that lie in HPKP. You don’t have to pin your keys, you can also pin CAs for example. One idea might be to do something such as: - Pin your current and backup key - Pin your two most trusted CAs That way, you wouldn’t have a problem if you switch CAs with the same key (such as what StartCom-customers need to do now), and you can still obtain new certificates from either of those two CAs should you have to. IOW; You haven’t ruled out switching to any other CA, as long as it’s your pinned keys. You haven’t ruled out switching to any other key, as long as there’s a cert from a CA you trust. But you have ruled out certs from all other CAs. That’s a pretty decent flexible setup in my book. It both takes care of rouge CAs (with the exception of your trust being entirely misplaced), and it also takes care of things like MitM HTTPS-proxies. The *idea* behind HPKP is to get both of those two issues mitigated, yet be able to retain enough flexibility. As an idea, I really like that. All of that said, I do agree that there’s a potential for foot-gunning, but I don’t think it’s more than a competent sysadmin should be able to handle with some careful though. Terje _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
