On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor <[email protected]> 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. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
