On 09/13/2011 05:55 PM, Chris Palmer wrote: > 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.
Actually, if your certificate policy requires key rotation at
certificate expiry, you can generate key N+1 at any time (preferably
early in the life of the cert corresponding to key N), and introduce the
secondary pin at that point, without having gotten certificate N+1 yet.
Then, as certificate N approaches expiration, get a certificate made
from key N+1 -- your pin is already well-known. Generate key N+2
(stored safely offline someplace?), deploy key N+1, and update your pin
list to be (N+1,N+2). There's no waiting required. And this approach
dovetails nicely with your recommendations for backup resiliency as well.
It still looks to me like pinning a CA does nothing more than give them
the chance to hold you hostage at certificate renewal time, and to
expose you to vulnerability should the CA itself be compromised.
> 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.
Yep; the only reason you'd need the more-complex approach above is if
you require key rotation at certificate expiry. If all you care about
is convenience and simplicity of operation, just get the existing key
re-certified by any CA. In this case, there's still no need or
advantage (and significant disadvantages) to pin to a CA instead of
pinning to your EE.
> Again, that's fine and one size does not fit all.
Sure, one size does not fit all, but it looks like the document is
(reasonably) trying to outline some common patterns of reasonable
behavior to encourage best practices. I still don't see any best
practice that involves pinning to a CA unless that CA is itself under
the control of your own organization.
I recommend that the draft make this explicit, to avoid encouraging
system operators binding themselves even more tightly to a CA by
misapplication of this mechanism.
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
