Add GET_EAT Support to OCP Profile #60

fdamato · 2025-08-23T00:02:29Z

No description provided.

Signed-off-by: Fabrizio Damato <[email protected]>

- Updated Contributors list Signed-off-by: Fabrizio Damato <[email protected]>

raghuncstate · 2025-08-26T02:10:46Z

specifications/ietf-eat-profile/spec.ocp

+=====================+=====================+=====================+==============================================+
+| 0                   | CommandCode         | 1                   | Shall be 02h to indicate GET_EAT.            |
+---------------------+---------------------+---------------------+----------------------------------------------+
+| 1                   | CommandVersion      | 1                   | The version of this request structure.       |


Generally better to put the CommandVersion first in case the command is parsed and we need to key off-of that.

I dont disagree w/ the comment in general, but I dont have strong opinion as well for this specific case. Followed same convention of GET_ENVELOPE_SIGNED_CSR (https://github.com/opencomputeproject/Security/blob/main/specifications/device-identity-provisioning/spec.ocp).

might be worth changing there too. Generally version and size being the first two fields of the structure helps with maximum versioning compatiblity, and easier to write code for.

Ack, @bluegate010 any thoughts on this ?

Shuffling thusly sounds good to me.

specifications/ietf-eat-profile/spec.ocp

raghuncstate · 2025-08-26T02:15:22Z

specifications/ietf-eat-profile/spec.ocp

+---------------------+---------------------+---------------------+----------------------------------------------+
+| 8                   | EATToken            | EATLength           | Shall be the Entity Attestation Token        |
+|                     |                     |                     | conforming to this OCP Profile. This         |
+|                     |                     |                     | field shall be CBOR-encoded                  |


Nit: is the encoding necessary to be specified as a shall? can be a stream of bytes i nthe response and specify elsewhere what the format of the EATToken is, which we already specify ?

Why not being prescriptive ? I have no issue to remove SHALLL if you feel strong about it

no strong opinion either way. being prescriptive in a single place generally means you only need to change one place. i think CBOR encoding is implied for EAT token in other parts of the spec, so didnt think it was needed.

Ack. I can remove

raghuncstate · 2025-08-26T02:20:58Z

specifications/ietf-eat-profile/spec.ocp

+- Certificate chain validation **MUST** be performed according to the requester's trust policy
+- The x5-chain in the unprotected header **MUST** be validated before trusting the EAT contents
+
+### Replay Protection


hmmm not sure i follow this section. i realize all of this is should, but i'm not sure this is necessary since "requesters" may implement something unnecessary. If the nonce requirements are met, this shouldnt be required at all right? this feels like it leads to temptation to do something non standard.

I agree requester is misleading, would it replacing to "verifier" sound more reasonable ?

i was questioning the need for this section at all? If a verifier follows the nonce requirements, not sure what maintaining the cache would help with, and the SHOULD NOT makes it sound like it is okay to reuse a nonce within some time window (which should never be the case?)

I agree, it is redundant...will strip out

raghuncstate · 2025-08-26T02:22:41Z

specifications/ietf-eat-profile/spec.ocp

+
+## Overview
+
+The GET_EAT command enables requesters to obtain attestation evidence from a device in the form of an Entity Attestation Token (EAT) that conforms to this OCP Profile. This command is designed to be transport-agnostic while providing a standardized interface for attestation requests.


requester is confusing, specially in the context of SPDM. SPDM has a very specific meaning for requester, here you really mean verifier?
might be good to delineate SPDM requester from this specs requester.

I agree. I will replace with verifier

raghuncstate · 2025-08-26T02:23:45Z

specifications/ietf-eat-profile/spec.ocp

+
+2. **Requesters** using GET_EAT:
+   - **SHOULD** implement appropriate timeout handling
+   - **MUST** be prepared to handle ERROR responses


SPDM ERROR responses?

SPDM is not the only supported transport layer.

ack, might be good to clarify "error responses from the trasport". the capitalized ERROR sounds like it is referring to something specific.

- Replace Requester with Verifier - Swap Command Version and Command Code - Strip unnecessary description of Security Considerations - Add Clarification for large buffer handling Signed-off-by: Fabrizio Damato <[email protected]>

steven-bellock · 2025-08-26T19:22:45Z

specifications/attestation-of-system-components/spec.ocp

@@ -552,6 +553,76 @@ algorithms:

 See <https://github.com/opencomputeproject/Security/tree/main/specifications/ietf-eat-profile>.

+## OCP Command Registry {#sec:ocp-command-registry}


If this registry is at the level of OCP, not OCP Security, then it should go in (something like) https://github.com/opencomputeproject/ocp-oid-registry. Maybe @bluegate010 can rename that repository to ocp-registry and not make it specific to OIDs.

Agreed, on reflection I think it at least needs to be in a separate document, and it's possible that other projects will want to define their own. Will ask OCP to change the registry repo name.

It sounds good... I`ll move to https://github.com/opencomputeproject/ocp-registry. Is a markdown document the right place to include the OCP Command Registry, or are you expecting a different format ?

Markdown is fine, yeah.

I will create a separate commit, as it is a separate github repo

Let's drop the changes to this spec from the PR?

… from Attestation Main Spec Signed-off-by: Fabrizio Damato <[email protected]>

bluegate010 · 2025-08-27T19:17:01Z

specifications/attestation-of-system-components/spec.ocp

@@ -552,6 +553,76 @@ algorithms:

 See <https://github.com/opencomputeproject/Security/tree/main/specifications/ietf-eat-profile>.

+## OCP Command Registry {#sec:ocp-command-registry}


Let's drop the changes to this spec from the PR?

bluegate010 · 2025-08-27T19:18:48Z

specifications/ietf-eat-profile/spec.ocp

+| 2                   | Status              | 1                   | Response status.                             |
+|                     |                     |                     | 0x00 = SUCCESS                               |
+|                     |                     |                     | 0x01 = ERROR                                 |


The transport protocol should have an error reporting mechanism that we can use?

I`m not really convinced on this one... because we would lose control on ERROR type, if we want to expand more.

We should be able to use SPDM's ExtendedErrorData field for vendor-defined errors.

I see this is a heavy requirement to bring for NON SPDM adopters... don`t you agree?

As discussed offline, we can define in the transport binding how error codes should be returned. For SPDM we can avail ourselves of their existing machinery, and for other transports we can do something else.

bluegate010 · 2025-08-27T19:19:40Z

specifications/ietf-eat-profile/spec.ocp

+2. The EAT Profile claim (265) **MUST** be present and contain the OCP Profile OID
+3. The Nonce claim (10) **MUST** be present and contain the nonce value from the request
+4. The Measurements claim (273) **MUST** be present and contain concise evidence
+5. The issuer claim (1) **SHALL** be present if binding to a certificate chain


Any reason this line uses SHALL instead of MUST?

I would prefer consistency and move everything to MUST

bluegate010 · 2025-08-27T19:20:02Z

specifications/ietf-eat-profile/spec.ocp

+- The Responder **MUST** use the SPDM VENDOR_DEFINED_RESPONSE format
+- The StandardID field **MUST** contain 4 (IANA)
+- The VendorID field **MUST** contain 42623 (OCP)
+- The first byte of the VendorDefinedReqPayload/VendorDefinedRespPayload is the Command Code, and must contain the value 02h to indicate GET_EAT


Suggested change

- The first byte of the VendorDefinedReqPayload/VendorDefinedRespPayload is the Command Code, and must contain the value 02h to indicate GET_EAT

- The first byte of the VendorDefinedReqPayload/VendorDefinedRespPayload is the Command Code, and **MUST** contain the value 02h to indicate GET_EAT

bluegate010 · 2025-08-27T19:20:47Z

specifications/ietf-eat-profile/spec.ocp

+TSM engines and other transport mechanisms **MAY** define their own bindings for the GET_EAT command, provided they:
+- Maintain semantic equivalence of request and response structures


Will need a blank line between these two in order for the bullet points to render properly. Here and above.

steven-bellock · 2025-08-28T18:13:43Z

specifications/ietf-eat-profile/spec.ocp

GET_EAT should go in (something like) OCP Attestation. How the EAT is transported should decoupled from the EAT itself.

I have no problem with that, but we initially discussed to keep it together with the profile. @bluegate010 you ok to move to OCP Attestation 1.1 spec ?

Yeah, works for me.

Add GET_EAT Support to OCP Profile

42474e5

Signed-off-by: Fabrizio Damato <[email protected]>

fdamato requested review from bluegate010 and steven-bellock August 23, 2025 00:02

- Create central registry for OCP VENDOR_DEFINED command codes

ce34bd0

- Updated Contributors list Signed-off-by: Fabrizio Damato <[email protected]>

raghuncstate reviewed Aug 26, 2025

View reviewed changes

specifications/ietf-eat-profile/spec.ocp Show resolved Hide resolved

raghuncstate reviewed Aug 26, 2025

View reviewed changes

Address Reviews:

16e6a32

- Replace Requester with Verifier - Swap Command Version and Command Code - Strip unnecessary description of Security Considerations - Add Clarification for large buffer handling Signed-off-by: Fabrizio Damato <[email protected]>

fdamato requested a review from raghuncstate August 26, 2025 14:36

steven-bellock reviewed Aug 26, 2025

View reviewed changes

steven-bellock added the EAT OCP Entity Attestation Token spec label Aug 26, 2025

Merge branch 'opencomputeproject:main' into fadamato/get_eat_support

92ac383

fdamato force-pushed the fadamato/get_eat_support branch 2 times, most recently from 2d07c0d to 6101b25 Compare August 27, 2025 18:07

Address OCP Feedback on NONCE length, and remove OCP Command Registry…

65a9c1a

… from Attestation Main Spec Signed-off-by: Fabrizio Damato <[email protected]>

fdamato force-pushed the fadamato/get_eat_support branch from 6101b25 to 65a9c1a Compare August 27, 2025 18:08

bluegate010 reviewed Aug 27, 2025

View reviewed changes

steven-bellock reviewed Aug 28, 2025

View reviewed changes


		## Overview

		The GET_EAT command enables requesters to obtain attestation evidence from a device in the form of an Entity Attestation Token (EAT) that conforms to this OCP Profile. This command is designed to be transport-agnostic while providing a standardized interface for attestation requests.

		@@ -552,6 +553,76 @@ algorithms:

		See <https://github.com/opencomputeproject/Security/tree/main/specifications/ietf-eat-profile>.

		## OCP Command Registry {#sec:ocp-command-registry}

	- The first byte of the VendorDefinedReqPayload/VendorDefinedRespPayload is the Command Code, and must contain the value 02h to indicate GET_EAT
	- The first byte of the VendorDefinedReqPayload/VendorDefinedRespPayload is the Command Code, and MUST contain the value 02h to indicate GET_EAT

		TSM engines and other transport mechanisms MAY define their own bindings for the GET_EAT command, provided they:
		- Maintain semantic equivalence of request and response structures

Add GET_EAT Support to OCP Profile #60

Are you sure you want to change the base?

Add GET_EAT Support to OCP Profile #60

Conversation

fdamato commented Aug 23, 2025

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!

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!

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!

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!

fdamato Aug 27, 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!

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!

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

fdamato Aug 27, 2025 •

edited

Loading