Closed ameba23 closed 2 months ago
I don't totally understand your comments around using Intel's public key once to avoid storing the whole cert, but this might be a bigger conversation around the quote/attestation flow from my end
@HCastano i think we should chat about this as i have some code for handling the certificates when a validator initially joins (or changes their endpoint later), which should probably link in with what you are doing in 1063.
As part of the attestation feature https://github.com/entropyxyz/entropy-core/issues/982 we need to handle PCK certificates when a validator joins. These contain the public key used to sign attestations, and are signed by Intel.
Rather than storing the whole certificate, my current proposal is to verify it once with Intel's public key, and then only store the public key with which we need to verify quotes.
However it could be argued we should keep the whole certificate including the signature - i am open to discuss this.
This PR handles these public keys and uses them in quote verification, but it does not handle extracting them from a PCK certificate when a validator joins, or verifying that the certificate is signed by Intel. This will come in another PR.
PCKs are stored as a field in the staking extension pallet's
ServerInfo
struct. This might not seem like the best home for them - i could have made a mapping of TSS account IDs to PCKs in the attestation pallet. But i deliberately did it like this because i want it to be impossible that an active validator does not have an associated PCK.When generating mock quotes, the PCK keypair is derived from the TSS account ID. This saves us having to generate and store them somewhere, and makes it easy to compute the keypairs for the test accounts.