Mock "certification" of mithril keys

[iquerejeta]

Mithril keys will have to be certified by the node hot keys. We should mock this procedure, so that the key registration takes into account this registration validation, and Mithril clients provide a signature for the key they are registering.

When initialising a KeyRegistration, we would include the stake distribution of Cardano, this is, the relation PoolID -> Stake for all Cardano SPOs. The PoolID corresponds to the hash of the cold VK. Therefore, to register a new Mithril key, the SPO needs to provide:

• The latest operational certificate of this particular pool (or do we get this directly from the node?)
• A signature of the Mithril key using the hot KES key

To accept a registration from a particular SPO, the registrar needs to:

1. Verify that the hash of the cold VK is in the initialised set PoolID -> Stake
2. Check the validity of the operational certificate wrt to the cold VK
3. Verify the KES signature of the Mithril key with the KES vk
4. Do additional Mithril checks (e.g. check PoP of Mithril key)

There is no plan, as per the first PoC, to integrate with the Cardano Node or modify the cardano-cli for the purpose of Mithril. Therefore, it is unlikely that we will be able to sign Mithril Keys using hot KES keys from test-net. For this purpose, we need to mock these keys. The purpose is of course to be as close to reality as possible. For that reason, I see two possible options that resemble to the final solution.

Mock PoolIDs

For every SPO that wants to join the Mithril testnet, we generate them a fake cold key. Any entity running the registration procedure will have a hashmap with the relation PoolID -> FakePoolID. Then, to accept the registration, the procedure will be exactly as above, with the additional check of verifying that the cold vk hashes to FakePoolID, and the latter is related to the claimed PoolID.

ToDo:

• [ ] Implement OpCert creation in mithril-client
• [ ] Mock PoolIDs for testnet SPOs
• [ ] Modify the registration procedure to verify KES signatures and OpCerts

Pros

We implement all checks that we would need in the final version

Cons

We have to implement opcert generation/signature in the Mithril client, which is probably something we won't need in the future, as we would reuse that from the node.

Mock opcerts

For every SPO that wants to join the Mithril testnet, we generate them a KES key pair and an operational certificate signed with an IO owned key. Similarly, IO (or any entity running the registration procedure) will have a hashmap with the relation PoolID -> KES hot VK. Then, to accept the registration, the procedure will differ as follows:

1. Check that the KES hot VK in the opcert corresponds to the registering PoolID
2. Check the validity of the certificate wrt to IO's verification key
3. As above
4. As above

Following the steps above we mimic quite closely the expected final procedure, i.e. check that a vk corresponds to PoolID, we verify an opcert and we verify a KES signature.

Pros

We only need to implement what will be in the mithril code base, i.e. KES signature gen/verif, opcert verification

Cons

The registration procedure won't implement the same checks as the main-net version.

ToDo:

• [ ] Create IO's keys used to validate OpCerts
• [ ] Mock OpCerts for testnet SPOs
• [ ] Modify the registration procedure to verify KES signatures and OpCerts

[UPDATE] Use real OpCerts and real hot Signing Keys

Our first iteration will be to try and use the hot secret keys to sign Mithril keys. To this end, the mithril signer CLI will need to be given the hot secret key’s path. Using this key, we will sign mithril keys. Therefore, we use the existing OpCert. Ideally, we would verify the OpCert using the cardano-cli, but we can always implement a parser in mithril-core. Therefore, the changes will be as follows:

• [ ] Change the registration initialisation, such that all PoolID’s are matched with their respective stake
• [ ] Register function now takes as input OpCert bytes, Cold verification key (in case it is not in the certificate), KES signature and mithril key. Then, it:
  • [ ] Parses the OpCert
  • [ ] Verifies the OpCert with the cold vk
  • [ ] Verifies the KES signature with the KES vk taken from the OpCert
  • [ ] Verifies the Mithril Key

If parsing the OpCert turns out to be too complex, maybe we can leverage the cardano-cli.

cc: @jpraynaud @curiecrypt @Alenar @ghubertpalo