From 511947a96d42b46f65c2a125f38e5eee55796a0a Mon Sep 17 00:00:00 2001 From: Xiaoyu Ruan Date: Thu, 27 Aug 2026 17:21:00 -0700 Subject: [PATCH 1/2] Update spec.ocp --- specifications/device-identity-provisioning/spec.ocp | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/specifications/device-identity-provisioning/spec.ocp b/specifications/device-identity-provisioning/spec.ocp index f93d90a..e59237e 100644 --- a/specifications/device-identity-provisioning/spec.ocp +++ b/specifications/device-identity-provisioning/spec.ocp @@ -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 a certificate in one certificate chain, at Slot X. +5. Construct and sign an identity certificate for the Responder based off the CSR. +6. Construct the owner's certificate chain. The first certificate of the chain is the identify 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 owner's certificate chain to the Responder. The `SlotID` should point to a slot that is currently not provisioned. ### Defined OIDs {#sec:defined-oids} @@ -390,11 +392,14 @@ 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` and provisioning tenant's owner certificate chain to the Responder. In this case, the tenant's certificate chain is not returned in the Responder's response of `GET_CERTIFICATE`, but resides in the tenant's context. +When invoking `GET_MEASUREMENTS`, the `SlotIDParam` should point to Slot X. + Slot 1 is not allocated by this specification. ## Requesting an identity certificate during attestation {#sec:requesting-identity-cert-during-attestation} From ed946c6db22773a2c3041c18d2267b123e267bf7 Mon Sep 17 00:00:00 2001 From: Xiaoyu Ruan Date: Thu, 27 Aug 2026 22:04:00 -0700 Subject: [PATCH 2/2] Update spec.ocp Signed-off-by: Ruan, Xiaoyu --- specifications/device-identity-provisioning/spec.ocp | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/specifications/device-identity-provisioning/spec.ocp b/specifications/device-identity-provisioning/spec.ocp index e59237e..7e6794e 100644 --- a/specifications/device-identity-provisioning/spec.ocp +++ b/specifications/device-identity-provisioning/spec.ocp @@ -347,10 +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. 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 a certificate in one certificate chain, at Slot X. +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. The first certificate of the chain is the identify 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 owner's certificate chain to the Responder. The `SlotID` should point to a slot that is currently not provisioned. +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} @@ -397,8 +397,7 @@ To provide a consistent mapping across implementations, the following SPDM certi | 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` and provisioning tenant's owner certificate chain to the Responder. In this case, the tenant's certificate chain is not returned in the Responder's response of `GET_CERTIFICATE`, but resides in the tenant's context. -When invoking `GET_MEASUREMENTS`, the `SlotIDParam` should point to Slot X. +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.