Key forwarding: part 1

[emostov]

This PR implements the key forwarding flow as described in src/qos_core/KEY_FORWARDING.MD. Its worth the time to check that every check in step 4 of the routine is covered by fn validate_manifest (which is in src/qos_core/src/protocol/services/key.rs).

This PR contains the following changes:

• Implement the server side logic for boot_forward_key and request_key (this just leaves server side logic for inject key). The logic lives in ``src/qos_core/src/protocol/services/key.rs`.
• Add qos_attest as a dependency of qos_core so we can attestation doc validation. Note, that this will bring in a bit of dependencies to qos_core since qos_attest has some extra deps to parse the attestation doc and verify the cert chain.
• Pulls out qos_core::protocol::attestor to its own crate, qos_nsm, to avoid cyclical dependencies when we include it qos_attest
• Refactor verify_attestation_doc_against_user_input to not panic and instead return errors.
• Small updates in src/qos_core/KEY_FORWARDING.MD - mostly type renaming

TODO

• Finish tests for request_key
• Add tests for boot_forward_key

Follow up work:

• Implement inject key service logic (Key Forwarding: Part 2 #226 )
• Implement client side logic and use to write integration test (Key Forwarding: Part 2 #226)

[emostov]

GitHub is collapsing this diff - wanted to highlight since its the most important file

[timurnkey]

nit: RequestKeyRequest doesn't provide a whole lot of context. If this is related to the key forward flow maybe there's a better name?

BootKeyForwardRequest
BootKeyForwardResponse
BootKeyRequest
BootKeyResponse

?

[emostov]

I left the Boot* prefix to refer to the route used to first boot an enclave. RequestKey{Request, Response} is the route to literally request a key.

the flow is

• BootKeyForward (boot a new enclave in key forwarding mode
• RequestKey (ask an old enclave for a quorum key)
• InjectKey (inject a quorum key into the new enclave)

Happy to brainstorm more on naming here

[timurnkey]

nit: if the below functions are only used for testing, I'd move them into the mod test so it keeps the biz logic succinct

[emostov]

The comment is poorly worded. Just updated to "Primary logic of request_key pulled out so it can be unit tested." In other words I extracted most of the logic to an "inner" function that can be easily tested.

The "outer" function is hard to test because it needs a valid attestation doc from a nitro secure module which we don't have the facilities to produce on the fly. So I pulled out all the logic that is not validating/extracting the attestation doc into the inner function. Unit tests are performed on the inner function.