[ksk-change] Keeping two KSK keys long term

[Richard Lamb]

Security level/controls for all key material must be equal or better.
That's why we don't have a second backup key since the storage of the
additional key would incur the high costs of ensuring it to was equally
secured in a separate facility (5-6 tiers etc...).  But of course I am just
parroting what I learned from the experts on the cc line.  If the community
says they don't care, well.....

-Rick




-----Original Message-----
From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org]
On Behalf Of David Conrad
Sent: Wednesday, October 01, 2014 4:26 PM
To: Paul Hoffman
Cc: ksk-rollover at icann.org
Subject: Re: [ksk-change] Keeping two KSK keys long term

Paul,

On Oct 1, 2014, at 4:03 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
> On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo at gmail.com>
wrote:
>> It will roughly cost around 500k to set up one key ceremony room but 
>> it's more about the overhead to manage the facilities.
> I propose that this additional key need a new key ceremony room;

I presume you meant to write "didn't propose"

> in fact, that idea hadn't even occurred to me. Create the key in one of
the current rooms, then drive the HSM to some other location and plant it
there. 

It might be useful to describe the requirements for the "other location".
Gaining unauthorized access to that HSM would be "bad", so we're probably
not talking about storing the HSM under somebody's bed. It might not need
the full controls used in the KSF, but presumably there would need to be
non-trivial controls (as well as controls related to transfer).

> Again, I'm only proposing this because my reading of 5011 makes it seem
like having a second active KSK would be better if one of the KSKs is
accidentally or purposely made unusable. Mike seems to agree with this; do
others disagree?

Having more than one key would be good.  Having more than one vendor of HSM
would be good.  If we're looking at using the initial key roll as a way of
making changes to the way the root key(s) is(are) managed, it might be
useful to enumerate the good things and bad things.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5456 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141002/0b9d77a0/smime-0001.p7s>