[Opendnssec-develop] Creating keys

[John Dickinson]

On 28 Nov 2008, at 17:31, Roy Arends wrote:

> Stephen Morris wrote on 11/28/2008 05:47:32 PM:
>
>> Olaf Kolkman <olaf at NLnetLabs.nl> wrote on 27/11/2008 16:01:26:
>>
>>>
>>> On Nov 27, 2008, at 4:54 PM, John Dickinson wrote:
>>>
>>>>
>>>> So I guess if you have a large zone like co.uk then a couple of
>>>> seconds in the 6 odd minutes that it would take to sign from  
>>>> scratch
>
>>>> is nothing. However, if you have 1000's of small zones or you are
>>>> dynamically updating every minute then it could make a big
> difference.
>>>
>>> But even then... the key-rollover would take place only once per  
>>> month
>
>>> or so. So this 2 second pain per zone only happens once or twice per
>>> month.
>>
>> In this approach, are there any problems in ensuring that the keys  
>> are
>> replicated to a backup HSM before they are used?  Do you need any  
>> type
> of
>> "master" password to export private keys from the HSM?
>
> I guess in a situation where the procedures require that keys need  
> to be
> backed up, it is up to the specific HSM implementation if such a  
> scenario
> is possible. Different HSMs use different methods. For instance, to be
> fully FIPS 140-2 level 3 compliant, the HSM needs to be in complete  
> "do
> not export" state, which guarantees that keys stored on an HSM can't  
> be
> exported. Another requirement is that "do not export" is irreversible.

This means that to allow for backup you might want to have the key  
generation on a separate machine - I did once imagine a system where  
an offline server generated keys in a "master" HSM. The HSM backup  
system was then used to copy those keys to HSMs to be attached to the  
signing server. This would allow the HSMs attached to the signer to be  
locked (backups not possible). (But then again, can you have one HSM  
that is the duplicate of another where one is in FIPS 140-2 level 3  
and one not??)

>
> What I think is fairly common is that a keystore (containing the  
> actual
> private DNSKEY's) is an encrypted filesystem (the individual files are
> encrypted, not the directory structure) on a regular disk, while the
> Keystore Decryption Key (or Master Key, or SuperKey or RootToken, all
> depending on which vendor you talk to) resides physically in the  
> HSM. This

We have had this conversation elsewhere: But WHY? Just use an HSM or  
soft token for all the keys :)

>
> Decryption key can actually be synchronised between the various HSMs  
> (of
> the same brand, as there is currently no standard defined way).  
> There are
> different methods to do this. Once the decrytion key is equal on all  
> HSMs,
> keystores can be read by all involved HSMs, while the same encrypted
> keystores (filesystems) can be backed-up, replicated, etc.
>
>
> However, since the methods on key-retrieval, backup, recovery is so
> incredibly vendor specific, I think that is out of scope. We should  
> just

I agree, key backup is outside the scope of OpenDNSSEC and should be  
done according to the mechanism designed by the HSM manufacturer.  
Ability to do this would be a consideration when selecting an HSM or  
soft token.

However, I do agree with Stephen, an operator might want a chance to  
know that they had backups before deciding to use a key. Given that  
backup is likely to be a manual step maybe pre-creation is needed, at  
least for some people. Maybe we need a backup interval between  
generation and publication.

>
> allow the system to be able to pre-generate keys, in order to allow
> redundant keystores.

I am a bit confused - is that pre-generate the same as the "So, why  
not pre-create as many keys as needed, instead of as much as  
possible?" in the previous email? BTW - how many is "as many keys as  
needed"? Enough for the immediate key rollover that the enforcer is  
trying to do or enough for all the key rollovers planned in the next x  
minutes?

Or should we allow the operator to select pre-generate or only  
generate the minimum needed?
John