[dns-operations] Contingency plans for the next Root KSK Ceremony

Robert Kisteleki robert at ripe.net
Tue Mar 31 09:19:59 UTC 2020

>>>  3. Hold the next ceremony using our disaster recovery procedure, which
>>>     provides for a staff-only ceremony (i.e. no TCRs would be physically
>>>     present).
>> Out of curiosity, about option 3: in a DR scenario when TCRs are not
>> physically present, how is their key material / knowledge used? As in:
>> 1. if they hold a physical key(part), how is that used? I suspect it is on only
>> premise in the safe and local hands are used to connect them physically.
> Only on premise, since one of the safes contains a security box that
> is personal to each TCR. Two keys are needed to open the box, the TCR
> key and the CA key, used together.
According to Kim's message the TCR's key is ... well, "optional" :-)

>> 2. if they hold knowledge (passphrase), how is that used? Do they enter it
>> over a secure channel directly into the signer or do they tell someone that
>> can type it in locally and promises to forget it afterwards? Or something else?
> No passphrase. The CA use a pin code to activate the HSM, together with three TCR's smart cards. The pin code is no secret.

Right. So, coming back to Warren's message:

> How can we prove that nothing bad occurred after the ceremony
> concluded and the cameras were turned off? I'm assuming that new locks
> will be installed, and materials returned to their rightful places,
> but this still leaves Kim et al with a big pile-o-keys that they could
> use. We could probably stick (on camera) numbered tamper evident seals
> over the locks, and have Kim sign them, but now we have devolved the
> security to just numbered stickers / numbered bags and the signature
> of the same person/people who have the pile-o-keys.

Given the above I believe this cannot be *proven*. There's a level of
trust that's needed in order to make this work in exceptional
circumstances such that we have nowadays. I don't doubt we have that
trust, but provability is tough.


More information about the dns-operations mailing list