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

Michael Richardson mcr+ietf at sandelman.ca
Sun Apr 5 21:05:41 UTC 2020

S Moonesamy <sm+icann at elandsys.com> wrote:
    > At 06:39 PM 04-04-2020, Michael Richardson wrote:
    >> 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.
    >> ---

    > The document which you cited is for the Root Zone Maintainer (Verisign).

yes, I realize that there are two documents.
They are at least 70% identical.

    >> 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.

    > There are four HSMs.  Any one of them can be used for a KSK Ceremony.

Yes, I guess that split material contains the entire context needed, and that
nothing is actually stored in the HSM.

    >> {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.}

    > A Flash Drive is inserted in Step 5 (Page 14).  The KSR is on it.

It seems like the weakest link, btw.

    >> (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.

    > I suggest looking at NIST SP 800-57.

Thank you.
I knew that such a thing existed, but I am very weak in the NIST-fu.

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: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20200405/1369f7b2/signature-0001.asc>

More information about the ksk-rollover mailing list