Skip to content

clarify limitation of multi-tenant #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xiaoyuruan wants to merge 2 commits into
base: main
Choose a base branch
from
Open

clarify limitation of multi-tenant #105

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
511947a
Update spec.ocp
xiaoyuruan Aug 28, 2026
ed946c6
Update spec.ocp
xiaoyuruan Aug 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions specifications/device-identity-provisioning/spec.ocp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -347,8 +347,10 @@ To summarize, the Requester should execute the following sequence for issuing an
1. Issue `GET_ATTESTED_CSR` request with `KeyPairID` = 0 to acquire all keypair IDs and their associated OID and bitfields for derivation attributes from the Responder device.
2. Examine the derivation attributes of the candidate keypair IDs and choose one that matches the Requester's use case.
3. Issue `GET_ATTESTED_CSR` request with the chosen `KeyPairID`. Check the received CSR for validity, including verifying the self-signature if attestation was requested.
4. Construct and sign an identity leaf certificate for the Responder based off the CSR. The leaf certificate is rooted to the Requester's trust anchor.
5. Issue SPDM `SET_CERTIFICATE` request to provision the identity certificate chain to the Responder. The `SlotID` should point to a slot that is currently not provisioned.
4. Look up the subject public key of the CSR in the certificate chains of all provisioned slots. The subject public key of the CSR should match the subject public key of one certificate in a certificate chain. Let the slot of this chain be Slot X.
5. Construct and sign an identity certificate for the Responder based off the CSR.
6. Construct the owner's certificate chain for the Responder rooted to the owner's PKI. The first certificate of the chain is the identity certificate generated in the previous step. The rest of the chain, including the leaf certificate, is same as the chain at Slot X.
7. Optionally, issue SPDM `SET_CERTIFICATE` request to provision the certificate chain generated in the previous step to the Responder. The `SlotID` should point to a slot that is currently not provisioned. A tenant that runs in a multi-tenant environment should not issue `SET_CERTIFICATE`.

### Defined OIDs {#sec:defined-oids}

Expand Down Expand Up @@ -390,11 +392,13 @@ Subsequent versions of this specification may define additional bits in the OCP
To provide a consistent mapping across implementations, the following SPDM certificate slot allocation applies:

| Identity | SPDM certificate slot | Requirement |
|----------|-----------------------|-------------|
|----------|--------|----------------------------|
| Vendor | Slot 0 | As specified by SPDM, slot 0 is the default certificate chain slot and is used for the Vendor identity. |
| Owner | Slot 2 | The device owner identity certificate chain SHALL be provisioned in slot 2. |
| Tenant | Implementation-defined | A tenant identity certificate chain MAY be provisioned in any otherwise available slot. The selected slot SHALL be discoverable by the requester. |

In a multi-tenant envrioment (e.g., when tenants are running in virtual machines), as the Responder device is shared among tenants, the tenants should be blocked from invoking `SET_CERTIFICATE` to provision tenant's owner certificate chain to the Responder. In this case, the tenant's owner certificate chain is not in any of the Responder's certificate slots, but resides in the tenant's context. When invoking `GET_MEASUREMENTS`, the `SlotIDParam` should point to Slot X, as the leaf certificate keypair is common to the tenant's owner certificate chain and the certificate chain at Slot X.

Slot 1 is not allocated by this specification.

## Requesting an identity certificate during attestation {#sec:requesting-identity-cert-during-attestation}
Expand Down