Re: [websec] Certificate Pinning via HSTS

[Chris Palmer <[e-mail]>]

On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor
<[e-mail]> wrote:

> From my perspective, i see no advantage to pinning any of the CAs -- if
> your EE is compromised, you're sunk.  And since the mechanism provides a
> mechanism (and nice instructions, thanks) for transition to an emergency
> offline backup EE key+cert, that is all handled well.

In the case of normal EE certificate expiration — as opposed to
compromise — if you are pinned to (say) an intermediary signer, you
can just get a fresh certificate from the same signer, deploy it, and
change nothing else.

Conversely, if you had pinned to an EE, you'd need to follow a
procedure something like this near expiration time:

0. Generate the new cert.
1. Change your pins directive to include the new and the old public
key fingerprints.
2. Wait long enough for "most, surely?" of your users to have received
the new pins, or for their pins to expire by the normal maxAge means.
3. Decommission the old EE cert and deploy the new.

Maybe that sounds reasonably easy to you, and you just never want to
pin to a signer's public key. That's ok. Our goal with the "you can
pin to any public key(s) in your cert chain" idea was to maximize
flexibility and enable a range of policies and practices, knowing that
one size does not fit all but that all achieve the goal.

You could, of course, also just re-use your old key pair and get it
re-signed, and no need to migrate keys as well as certs. In that case,
no problem. Again, that's fine and one size does not fit all.