Migrating a Delegation & Recovery Key

If a keycard is lost, a member of the delegation leaves, or any other situation occurs where you need to form a new delegation, you can do so with the migrate command. As per other disaster recovery activities you will need to get a quorum of members to approve an event allowing this action. This delegation migration procedure will create a new delegation with whatever members you choose using the same secret material as the original delegation (therefore allowing the new delegation to create a recovery key when necessary).

To migrate the delegation, you first need to propose a Migrate event and explicitly provide the --event-type migrate flag (or choose migrate when prompted for the event type):

am  dr propose --event-type migrate
> Select delegation to migrate from: Production: d588e62cb2059e15e9021d212a320553
> Please enter a comment (less than 40 characters): Propose for testing
ⓘ  2 proposal requests saved

After this, run the auto command on each of the remaining cards until you reach a quorum (e.g. one additional card in my example) similar to the process of approving a Usage event:

am  dr auto
There is a pending DR event request for this card (#1002001097)

 ┌─► DR Event Request for #1002001097
 │ Delegation name: Production
 │ Delegation fingerprint: d588e62cb2059e15e9021d212a320553
 │ Proposing keychain: 1002001096
 │ Proposing fingerprint: c2159e9761af9299742530e20401fafe
 │ Signature: VALID
 │ Event type: Migrate
 │ Event ID: 1
 │ Comment: Propose for testing
 └
? Approve the Request? (Y/n) y
ⓘ  approval record saved

After collecting enough approvals, re-insert the initial card that proposed the Migrate event and run auto:

am dr auto
ⓘ  event opened for delegation "Production"

At this point, you have an open event to migrate the original DR private key (aka "recovery key") to a new delegation that will be created. Run the migrate command using the same options you would see when creating a new delegation. After migration, your keycard will have both the original delegation (with an open Migrate event) as well as a new delegation that needs to be affirmed by the potential members.

am dr migrate
> Select delegation to migrate from: Production: d588e62cb2059e15e9021d212a320553
> Delegation name: Production-2
> Delegation comment: Migrated delegation
> Delegation size (between 2 and 16): 3
> Delegation quorum (between 2 and delegation size): 2
> Select the other members of your delegation: 2 members

 ┌─► Delegation name: "Production-2"
 │ Delegation fingerprint: b6849d4c914049df54905fe329ea15c1
 │ Comment: "Migrated delegation"
 │ State: AWAITING_MEMBER_CONFIRMATION
 │ Number of delegates: 3
 │ Approval quorum size: 2
 │ DR public key: BLx4Rt9jWA1pUpMNi1v1cpyskPY6P7JmMLVueHzFcgUZhk+OQizuAI3JQXZVe/3E9AynynVQsOuXZGLzNVifDFE=
 │ DR Event state: NONE
 │ DR Usage counter: N/A
 │ Members:
 ├00┬─► Keychain "#1002001096"
 │  │ Fingerprint: c2159e9761af9299742530e20401fafe (checked)
 │  │ State: CONFIRMED
 │  │ Custodian info v1:
 │  │  Email: bob@example.com
 │  │  Comment: bob
 │  └
 ├01┬─► Keychain "#1002001097"
 │  │ Fingerprint: 97496fbda5c58e904401224238732853 (checked)
 │  │ State: INFO-KNOWN + UNCONFIRMED
 │  │ Custodian info v1:
 │  │  Email: charlie@example.com
 │  │  Comment: charlie
 │  └
 ├02┬─► Keychain "#1002001098"
 │  │ Fingerprint: ad0d780ea62d41a20c2c000823d49a99 (checked)
 │  │ State: INFO-KNOWN + UNCONFIRMED
 │  │ Custodian info v1:
 │  │  Email: alice@example.com
 │  │  Comment: alice
 │  └
 └

Now that you have a new delegation and invitation files, run the auto command on each of the remaining cards so they may join the delegation and participate in future disaster recovery activities. Once members have joined and the affirmation files have been processed, the delegation will be available for disaster recovery events.