[cabfpub] Public key pinning (Was: Notes of meeting)

[Chris Palmer]

On Wed, Jul 11, 2012 at 2:18 AM, Gervase Markham <gerv at mozilla.org> wrote:

>> (In fact, you currently *have to* assert a "back-up" pin, but I am
>> probably going to remove that requirement.)
>
> Please don't remove it. Compulsory backup pins is a great idea. It
> raises the barrier to using pinning, which will exclude people who will
> shoot themselves in the foot by locking their customers out of their
> domain, which will give the technology a bad name and have it labelled
> as "risky" by site owners.

Right — but, how can we be sure that enough people who lose control of
their primary key won't also lose control of their backup key at the
same time? They were probably both on the same USB drive that got put
in the washing machine. :)

I'm kind of neutral on the topic and am willing to just take a vote.

But pinning has some other problems that Ryan Sleevi brought to my
attention: building a path from EE to root is "entertaining", in that
there can be more than one valid path. What if the pinned key is in a
certificate that is only sometimes in the path that clients build, or
always in the path that some clients build and never in the path that
other clients build? The result is false failure in the pin validation
process, with bonus non-determinism to make debugging fun.

One way to work around this is to pin to all the known keys that get
you from your EE to your chosen root(s), but it's probably going to be
hard for J. Random Site Operator to know that whole set. They might
learn it in the school of hard knocks. Or maybe CAs can say, "If you'd
like to pin to us, now that you've bought a cert from us, here's our
official set of pins" or something.