I think it would depend on the HSMs. In at least some of them, it's the card
keys that are important and you could have a disjoint set of card keys for
K_{n+1}-Ekr On Mon, Oct 4, 2010 at 7:52 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > At 7:31 AM -0700 10/4/10, Eric Rescorla wrote: > >On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley <<mailto:jab...@hopcount.ca> > jab...@hopcount.ca> wrote: > > > > > >On 2010-10-03, at 13:31, Eric Rescorla wrote: > > > >> I'm asking because I'm pretty familiar with cryptography and I know that > keys don't suddenly become > >> worthless just because they get past their intended use lifetime. The > semantics of signature > >> security of old keys is a lot more complicated than that. > > > >The context here is the publication of DNSSEC trust anchors for the root > zone. > > > >At least some of the cases we're talking about involve signatures > necessarily made by keys after an emergency key roll which has taken place > because the old key has been compromised. Such signatures are worthless. > > > > > >I don't think this follows. > > > >It's pretty commonly suggested that at the time you roll out key K_n you > also *immediately* generate > >key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all > that is required for security > >is that the signature itself take place prior to the compromise of K_n > this allows for rollover even > >if K_n is subsequently compromised, provided that the relying party can > verify that the signature > >on K_{n+1} was computed before the compromise date. There are a variety of > techniques for > >doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc. > > Does the "create your next key immediately" process work with HSMs if you > don't have 2x the number you would normally have in production? I'm no fan > of HSMs for a system like DNSSE that often needs operational agility, but it > seems like I'm in the minority here. > > --Paul Hoffman, Director > --VPN Consortium >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
