[ksk-rollover] ceremonies in April, and managing things less critical and the KSK.

[Russ Housley]

Michael:

IANA has emergency procedures that can be used to obtain the needed three shares.  It is clear from the text that you quote, that emergency planning was considered fro the start.  I assume that IANA will declare such an emergency in the next few days, and then generate the next KSK under those procedures.  As I understand it, the auditor will be able to tell that the emergency procedure were properly followed.

Russ


> On Apr 4, 2020, at 9:39 PM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:
> 
> Signed PGP part
> 
> Michael Richardson <mcr+ietf at sandelman.ca> wrote:
>> I am unclear from reading things over again how the ZSK gets to the ceremony.
>> Is a new ZSK keypair generated during the KSK, or is it generated elsewhere
>> and only the public part brought?
> 
> This is probably the wrong list to ask on.
> 
> https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf says:
> 
> 5.2.2. Private key (m-of-n) multi-person control
> Verisign has implemented technical and procedural mechanisms that
> require the participation of multiple trusted individuals to perform
> sensitive cryptographic operations. Verisign uses "Secret Sharing"
> to split the activation data needed to make use of a RZ ZSK private
> key into separate parts called "Secret Shares" which are held by
> trained and trusted individuals called "Shareholders." A threshold
> number of Secret Shares (m) out of the total number of Secret Shares
> created and distributed for a particular HSM (n) is required to
> activate a RZ ZSK private key stored on the module. The threshold
> number of shares needed to sign a root Zone File is 3. It should be
> noted that the number of shares distributed for disaster recovery
> tokens may be less than the number distributed for operational HSMs,
> while the threshold number of required shares remains the same.
> Secret Shares are protected in accordance with this DPS.
> 
> ---
> 
> I think that the HSM keeps the private key (RSA) encrypted.
> The key that is used to do this encryption (probably AES256) is the thing
> that is secret-split among the n-shareholders.  I understand that m=3.
> 
> It says "a particular HSM", so does this mean that the encryption key
> used to encrypt the private RSA key is different in different HSMs (at
> different locations), and a *different* m people are required to activate it?
> 
> I would think that the different HSM would synchornize the encrypted copy of
> the private key, and thus the split secret would be the same n pieces.
> Of course, the key could be moved to another HSM by the initial m-of-n
> people, it could be *re*-encrypted to n' pieces and some other m' people
> required.   The n and n' people could completely or partially overlap.
> 
> {BTW: When I read the KSK ceremony script, at:
>     https://data.iana.org/ksk-ceremony/40/20200216-KC40-Ceremony_Script_Annotated.pdf
> 
> I see that the KSR arrives on a smartcard.}
> 
> It seems that the secrets which are split up are kept in the/a safe, using a
> safety deposit box, and it is further in a tamper resistant bag.
> The TCR retains the key to the safety deposit box.  Am I correct that the
> secret split never leaves the room, so "m" TCRs can not actually reconstruct
> she key on their own?   I'm unclear what kind of media the secret is stored
> on, but I understand it plugs straight into the HSM, not the control laptop.
> 
> (BTW: I recognize that I'm reading KSK and ZSK documents at the same time)
> 
> I was surprised at the lack of references in the dps documents to any theory
> about how this process was created.   This is what I am looking for: a
> palette of ways to make key ceremonies for a variety of different threat
> levels.
> 
> Still I learned something by actually watching the entire video (at 1.75x
> speed..) and reading the entire ceremony through.
> 
> --
> Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20200405/03f39d0d/signature.asc>