Device Identity Provisioning: Expanding the Spec with Provisioning Flow #75

fdamato · 2025-10-01T00:22:14Z

No description provided.

specifications/device-identity-provisioning/spec.ocp

fdamato · 2025-10-02T03:28:24Z

@bluegate010 while addressing feedback, I also made few changes to GET_ENVELOPE_SIGNED_CSR to make it consistent with the other commands.

specifications/device-identity-provisioning/spec.ocp

bluegate010 · 2025-11-24T15:47:40Z

specifications/device-identity-provisioning/spec.ocp

+
+- MAY omit implementation of `OCP_GET_SLOT_ID_MAPPING`
+- SHALL still support all KeyProvisioningEntity values defined in this specification
+- Focus on entity-based access without exposing slot details


Can this clarify what it means to focus on entity-based access?

I will clarify, however Entity Based access, now that I read back does not seem the most appropriate language

specifications/device-identity-provisioning/spec.ocp

bluegate010 · 2025-11-24T15:51:14Z

specifications/device-identity-provisioning/spec.ocp

+
+- MAY omit implementation of `OCP_GET_SLOT_ID_MAPPING`
+- SHALL still support all KeyProvisioningEntity values defined in this specification
+- Focus on entity-based access without exposing slot details


GET_ENVELOPE_SIGNED_CSR has a SignerSlotIDParam field, which seems to indicate that slots must be exposed in order to call it correctly.

I'm thinking that the SignerSlotIDParam does not have relevance for the GET_ENVELOPE_SIGNED_CSR command in either SPDM or non-SPDM flows. The Envelope CSR is defined to be signed using the RT alias key, and therefore the SignerSlotIDParam does not influence the signing operation. The only requirement is that the requester who's authenticating the Envelope signed CSR has previously retrieved the certificate chain associated with a slot ID that has the RT alias certificate.

The SignerSlotIDParam field is retained in the command structure to maintain compatibility with existing SPDM command formats. However, this field is not critical for the actual operation because the signing key is self-identified within the EAT response. Specifically, the kid claim in the COSE_Sign1 protected header contains the key identifier, allowing verifiers to determine which attestation key signed the EAT without relying on the SignerSlotIDParam value. This design ensures that both SPDM and non-SPDM implementations can process the response correctly - SPDM implementations may use SignerSlotIDParam as a hint, while non-SPDM implementations can treat it as don't-care and rely solely on the kid claim.

I'm okay with keeping the SignerSlotIDParam, even if it's not used. A small clarification - in the current SPDM command format, the GET_CSR command does not have a Slot ID parameter. Instead, the Slot ID–KeyPairID association is established through the SET_CERTIFICATE command.
A requester may treat SignerSlotIDParam as a hint when locating the Attestation Key corresponding to the kid claim, while a responder can validate that the key with this kid is part of the certificate chain associated with the designated slot.

Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

…y to Enum type Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

…nsistency cleanup Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

…NVELOPE_SIGNED_CSR Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

parvathib · 2025-12-03T21:45:33Z

specifications/device-identity-provisioning/spec.ocp

+
+- **SPDM context**: SPDM defines 8 possible slots (0-7) where certificate chains can be stored. When an SPDM requester invokes `GET_CERTIFICATE`, they specify which slot's certificate chain they want to retrieve.
+
+- **Attestation context**: During attestation, the device uses these certificate chains to establish trust. For example, when generating an EAT, the device may include a LEAF certificate that chains to one of the certificates stored in these slots. The verifier can then retrieve the appropriate certificate chain to validate the complete trust path.


Can we say Evidence instead of EAT to avoid any confusion with the Envelope Signed CSR EAT used in this document?

parvathib · 2025-12-03T21:59:29Z

specifications/device-identity-provisioning/spec.ocp

+| 1      | CommandCode             | 1                       | Shall be 05h to indicate                 |
+|        |                         |                         | GET_ENDORSEMENT.                         |
+--------+-------------------------+-------------------------+------------------------------------------+
+| 2      | Reserved                | 4                       | Reserved.                                |


Should the additional 1‑byte Reserved field also be removed?

parvathib · 2025-12-03T22:02:11Z

specifications/device-identity-provisioning/spec.ocp

+For devices that support both SPDM and OCP attestation paths:
+
+- `OCP_SET_ENDORSEMENT` internally manages slot allocation based on the KeyProvisioningEntity
+- `OCP_GET_ENDORSEMENT` retrieves endorsements by entity rather than slot number


Nit: For consistency, update this reference to also use KeyProvisioningEntity

parvathib · 2025-12-03T22:06:25Z

specifications/device-identity-provisioning/spec.ocp

+
+1. **The chain SHALL terminate with a certificate for an advertised identity keypair** - The end-entity certificate in the chain MUST correspond to one of the keypairs for which the device can generate CSRs (e.g., IDevID, LDevID, or other device-specific identity keys).
+
+2. **Chain validation** - The device SHALL validate that:


Looks like this info is already covered in the Certificate Chain Validation section below, so it might redundant.

parvathib · 2025-12-03T22:30:26Z

specifications/device-identity-provisioning/spec.ocp

 ## 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.
+This will be accomplished by selecting the correct `SignerSlotIDParam` when invoking SPDM commands.


If this attestation is meant to establish trust before endorsement, could we make that a bit clearer? It’d be helpful to add this detail to the ‘Example provisioning sequence’ section above too.

fdamato mentioned this pull request Oct 1, 2025

Expanding "Issuing and provisioning an identity certificate" in Devic… #70

Closed

fdamato requested review from bluegate010, gmandyam and steven-bellock October 1, 2025 00:25

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch 4 times, most recently from 4e77756 to e248543 Compare October 1, 2025 02:53

bluegate010 reviewed Oct 1, 2025

View reviewed changes

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch from c35aace to f28f146 Compare October 2, 2025 03:27

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch 13 times, most recently from fb292a4 to e968925 Compare October 2, 2025 04:57

fdamato requested a review from bluegate010 October 2, 2025 04:58

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch 2 times, most recently from 62c84ca to 81aa721 Compare October 2, 2025 05:06

bluegate010 reviewed Oct 3, 2025

View reviewed changes

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch 2 times, most recently from ccda53d to 3fb2354 Compare October 3, 2025 20:36

parvathib reviewed Nov 20, 2025

View reviewed changes

specifications/device-identity-provisioning/spec.ocp Show resolved Hide resolved

bluegate010 reviewed Nov 24, 2025

View reviewed changes

fdamato added 3 commits December 1, 2025 16:34

Device Identity Provisioning: Expanding the Spec with Provisioning Flow

80a591b

Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

Device Identity Provisioning: Replace OIDs for Key Provisioning Entit…

7c13939

…y to Enum type Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

Device Identity Provisioning: Set Certificate, address reviews and co…

7ff9f8c

…nsistency cleanup Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch from 3fb2354 to 7ff9f8c Compare December 2, 2025 23:28

fdamato requested a review from parvathib December 2, 2025 23:31

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch 6 times, most recently from 1b592f4 to 70a0bff Compare December 3, 2025 05:08

Device Identity Provisioning: Update Details on EAT response to GET_E…

7ec11f4

…NVELOPE_SIGNED_CSR Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch 2 times, most recently from ca2905d to a0d3fb1 Compare December 3, 2025 05:20

Small fix in the GetEnvelopeSignedCSR

6b9f6ba

Signed-off-by: Fabrizio Damato <fabrizio.damato@amd.com>

fdamato force-pushed the fadamato/dip_update_provisioning_flow branch from a0d3fb1 to 6b9f6ba Compare December 3, 2025 05:36

parvathib reviewed Dec 3, 2025

View reviewed changes


		- SPDM context: SPDM defines 8 possible slots (0-7) where certificate chains can be stored. When an SPDM requester invokes `GET_CERTIFICATE`, they specify which slot's certificate chain they want to retrieve.

		- Attestation context: During attestation, the device uses these certificate chains to establish trust. For example, when generating an EAT, the device may include a LEAF certificate that chains to one of the certificates stored in these slots. The verifier can then retrieve the appropriate certificate chain to validate the complete trust path.


		1. The chain SHALL terminate with a certificate for an advertised identity keypair - The end-entity certificate in the chain MUST correspond to one of the keypairs for which the device can generate CSRs (e.g., IDevID, LDevID, or other device-specific identity keys).

		2. Chain validation - The device SHALL validate that:

Device Identity Provisioning: Expanding the Spec with Provisioning Flow #75

Are you sure you want to change the base?

Device Identity Provisioning: Expanding the Spec with Provisioning Flow #75

Uh oh!

Conversation

fdamato commented Oct 1, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fdamato commented Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fdamato Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fdamato Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

parvathib Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fdamato commented Oct 2, 2025 •

edited

Loading

fdamato Dec 1, 2025 •

edited

Loading

fdamato Dec 3, 2025 •

edited

Loading

parvathib Dec 3, 2025 •

edited

Loading