Skip to content

Update about provisioning ID cert and attestation with ID cert #102

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
+19 −10
Open

Update about provisioning ID cert and attestation with ID cert #102

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e0be691
update per WG discussion
xiaoyuruan Jun 4, 2026
a90cd3d
revert header changes
xiaoyuruan Jul 10, 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
29 changes: 19 additions & 10 deletions specifications/device-identity-provisioning/spec.ocp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,10 @@ The Contributors of this Specification would like to acknowledge the following:
- Steven Bellock (NVIDIA)
- Jeff Andersen (Google)
- Brett Henning (Broadcom)
- Shalini Sharma (Qualcomm)
- Denis Pochuev (Qualcomm)
- Parvathi Bhogaraju (Microsoft)
- Xiaoyu Ruan (Intel)

<!---
Please describe how this Specification complies with the OCP tenets.
Expand Down Expand Up @@ -84,9 +88,9 @@ This specification is applicable to a wide range of devices that support SPDM.

This specification does not impact sustainability.

# Base specification

-->
# Base specification

## Terminology

Expand Down Expand Up @@ -313,6 +317,14 @@ The EnvelopeSignedCSRdata shall adhere to the following requirements:

[^private-claims]: RFC 8392 [@{ietf-cwt}] defines a private claim as one whose key value has an integer value < -65536.

To summarize, the Requester should execute the following sequence for issuing and provisioning an identity certificate chain to the Responder device.

1. Acquire all keypair IDs and their associated OIDs for derivation attributes from the Responder device by issuing `GET_ATTESTED_CSR` request with `KeyPairID` = 0.
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.

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

**OCP Security Branch**: `ocp-security OBJECT IDENTIFIER ::= {1 3 6 1 4 1 42623 1}`
Expand All @@ -332,22 +344,19 @@ These OIDs indicate which inputs contribute to the derivation of the identity ke

Subsequent versions of this specification may be expanded with additional key derivation attribute OIDs.

## Issuing and provisioning an identity certificate {#sec:issuing-and-provisioning-identity-cert}

This will be accomplished via the `SET_CERTIFICATE` SPDM command.

TODO: fill in additional details.

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

This will be accomplished by selecting the correct `SlotIDParam` when invoking SPDM commands.
For attestation, the Requester should first issue SPDM `GET_CERTIFICATE` request with the `SlotID` containing the Responder's identity certificate chain that roots to the Requester's desired trust anchor, then issue SPDM `GET_MEASUREMENTS` request with `SlotIDParam` pointing to this `SlotID`.

TODO: fill in additional details.
<!----

## Confidential compute considerations
# Confidential compute considerations

TODO: fill in

--->


# Appendix

## Clarification of DICE Terminology {#sec:dice-terminology-clarification}
Expand Down