[ksk-rollover] Policies and procedures for Root KSK operations

[Micha Bailey]

Is there any estimate for when updated versions of the [various policies,
procedures, etc.](https://www.iana.org/dnssec/procedures) are expected to
be published, addressing the changes that are necessary to accommodate the
HSM migration? It seems to me that significant parts of the concept need to
be reworked.

If I understand correctly, today the RKSHs hold a copy of the SMK, which
otherwise exists only on (and is exportable from) the HSMs, and is used to
allow for the use of the key backup that only exists in the KMFs alongside
the HSMs, such that the only scenario in which RKSHs are in play would be
some catastrophic event that destroys/tampers all HSMs while not physically
destroying the KMFs to the extent that the application backup cards are
inaccessible.

With the new HSMs seemingly allowing backups exclusively to other HSMs,
which presumably would not be any more hardened/less volatile than the main
operational ones when it comes to environmental factors, is the RKSH role
still relevant? As far as I can tell, the new HSMs don’t have any type of
credential that would be required in a backup recovery situation that
wouldn’t be similarly required in more mundane scenarios such as normal
replacement of HSMs over the lifespan of the keys.

Hypothetically there could be dedicated backup HSMs, with CO credentials
held exclusively by the RKSHs, but that would seem to not align with the
general concepts that seem to underlie the processes in place, which
prioritize availability and tamper-*evidence *over strict security (e.g.
with the CO credentials themselves all being stored onsite, in order to
explicitly allow for forced entry, drilling, etc. when there’s no better
option). The only scenario that comes to mind is would be if backup HSMs
were introduced that would be stored offsite, outside the KMFs, whereby the
RKSHs would provide an additional level of security, but that doesn’t sound
particularly likely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ksk-rollover/attachments/20240304/16cd85e2/attachment.html>