Expanding "Issuing and provisioning an identity certificate" in Devic… #70
Conversation
…e Identity Provisioning Specification Signed-off-by: Fabrizio Damato <[email protected]>
| - **SlotID**: | ||
|
|
||
| Identifies the certificate slot (valid range 1-7 for SPDM) |
There was a problem hiding this comment.
We also need to mention Param2, the KeyPairID. Else the Responder won't know where in the slot's cert chain to staple the proffered cert.
There was a problem hiding this comment.
agree. I missed that. Let me add it
|
|
||
| Devices can only accommodate storage for a single tenant certificate at a time due to SRAM limitations. For multi-tenant scenarios, the device is not responsible for certificate provisioning coordination, and tenant certificate management must be handled at a higher layer in the system architecture. | ||
|
|
||
| ### Confidential Virtual Machine (CVM) Considerations |
There was a problem hiding this comment.
I think it would be worthwhile to define an OCP command for configuring the active SPDM cert chain for CVM. I.e., by default any CVM reports would use slot 0's chain that roots back to the vendor. But CSPs could provision their own cert into slot 1 (potentially using SPDM), and then separately send a command that instructs the CVM API surface to use the new chain.
May require defining an enum for {VENDOR, CSP, TENANT}, and requiring SPDM Responders to map their slot numbers to those enum values under the hood. Like, if you provision a cert to slot 1 (CSP) and then invoke OCP_CONFIGURE_CVM_CERT_CHAIN(CSP), then subsequent CVM reports will use slot 1.
…e Identity Provisioning Specification