[Comments-proposal-future-rz-ksk-rollovers-01nov19] KSK Rollover Proposal

[Michael StJohns]

General comments on the timeline:

1) At this point you've defined a process which will have steady state 
of 2 keys in the trust anchor set for about 2/3s of the period.   An 
emergency key revocation is possible during that period of time.   The 
other 1/3 of the time, you have no standby key available.   Why not just 
go ahead and do what 5011 recommends you do and add a third key?   If 
there is a size issue, adding an EC key as the third key allows you to 
get a head start on algorithm rollover.  (Last sentence of 2.5 is 
incorrect "requiring changes ... more often" - you can keep the same 
schedule, the keys just stick around a bit longer).

2) The period of three years is tied to the active period of a key, 
rather than to a specific roll-over (e.g. Key N+1 replacing Key N).   
The operational plan needs to consider whether any delays in taking a 
key out of service will violate general cryptographic guidance.  Make 
sure that you're following both the guidance for key lifetime, and any 
sunset provisions for key strength that show up in the meantime.  E.g. 
NIST SP 800-57Pt1, table 4 sunsets RSA2048 as of 2031 - or roughly at 
the beginning of the 4th key rollover if this schedule is followed.

3) As a consequence of the three year period, there is approximately 
1.75 years between major HSM actions (e.g. key generation and revocation 
- the period D).  Loss of skills by the HSM operators during the long 
period need to be considered.

4) There is no real reason to have the standby key present on the HSM 
after generation until it's ready to start signing stuff.  I'm assuming 
that the AEP has a backup mechanism for generated keys that's used 
between HSM operations (which is pretty obvious as both HSMs must share 
a storage master key to allow for key copying).

5) G and H - Assuming that there is a backup mechanism for the HSMs, 
simply deleting the keys from the HSM won't necessarily cause them to be 
destroyed if any backups were made.  Both HSMs must go through an update 
for the Storage Master Key to complete the deletion of the key material.

6) Consider other mechanisms for co-generation of the private key on two 
different HSMs as opposed to generate/export/import current model.   For 
example    HSM A -> Genkeypair -> ECDH Ka1, HSM B -> Genkeypair -> 
Kb1.     HSMA ECDH (Ka1.private, Kb1.public) -> KDF() -> either RSA gen 
seed or EC private key.      The use of ECDH gets the same secret on 
both HSMs without the need to move sensitive information out of the HSM, 
even in an encrypted form.   The shared secret can be fed into a KDF to 
generate an EC private key, which can then be used to generate a public 
key from the private one.   If you're doing RSA key pair generation, use 
the shared secret as a seed to a PRNG which is used in turn to generate 
the RSA key pairs.

7) Would it help if I made an errata for RFC5011 "In section 5, 
'Missing' state, delete 'This is an abnormal state'"?


Mike StJohns, NthPermutation Security