Support non DMTF measurement specifications

[sameo]

Some standard bodies like IETF attempt to define formally specified, extensible and compact formats for expressing an attested set of claims describing the state and characteristics of an entity, like e.g. a device. The Entity Attestation Token is one such format, and it is being adopted by multiple silicon vendors on the platform side.

Using common attestation and measurement formats across both platforms and devices makes sense from multiple perspectives: security, complexity, ease of deployment and scalability.

I'm opening this issue to understand how a device manufacturer willing to use an IETF standard like EAT would do so on top of the DMTF-defined measurement specification for SPDM:

• Should such vendor use an unused bit on the SPDM Measurement Specification Field Format during the algorithm negotiation phase?
• Should it nest entire EAT claim sets in single measurement blocks, using a 0x4 Measurement value type?

The same question could be generalized to other attestation/measurement formats that device vendors would prefer to use over the DMTF-defined one.

[steven-bellock]

In the short term you would embed the measurement(s) inside the DMTFSpecMeasurementValue field. The measurement manifest would then specify that the measurement block(s) is EAT, etc. DMTFSpecMeasurementValueType and DMTFSpecMeasurementValueSize are effectively ignored. In the long term you would get the SPDM Working Group to add a new measurement specification to MeasurementSpecification.

@xiaoyuruan might have an opinion as well.

[sameo]

In the short term you would embed the measurement(s) inside the DMTFSpecMeasurementValue field. The measurement manifest would then specify that the measurement block(s) is EAT, etc.

How would that be specified if DMTFSpecMeasurementValueType is ignored?

[steven-bellock]

DMTFSpecMeasurementValueType would be ignored for measurement blocks that contain EAT-formatted data. The measurement manifest itself, if it is transmitted through a measurement block, would have DMTFSpecMeasurementValueType[6:0] set to 0x4 or 0xa.

@bhenning10 too.

[xiaoyuruan]

It's cleaner to allocate a bit in MeasurementSpecification for EAT in SPDM 1.4 than trying to using DMTF format to hold EAT.

Is the need of supporting EAT in SPDM MEASUREMENTS response so urgent that can't wait for SPDM 1.4?

[sameo]

It's cleaner to allocate a bit in MeasurementSpecification for EAT in SPDM 1.4 than trying to using DMTF format to hold EAT.

Is the need of supporting EAT in SPDM MEASUREMENTS response so urgent that can't wait for SPDM 1.4?

There is no urgency, this can wait for 1.4.

[jyao1]

It's cleaner to allocate a bit in MeasurementSpecification for EAT in SPDM 1.4 than trying to using DMTF format to hold EAT.

Do we want to open the door for Measurement format definition using other standard?
Can DMTF depend on a draft of other standard, such as EAT?

Anyway, I think it should be SPDM-WG discussion, and opened https://github.com/DMTF/SPDM-WG/issues/3297

[jyao1]

DMTFSpecMeasurementValueType would be ignored for measurement blocks that contain EAT-formatted data. The measurement manifest itself, if it is transmitted through a measurement block, would have DMTFSpecMeasurementValueType[6:0] set to 0x4 or 0xa.

I believe using 0xa is a better approach, because then we can use SVH format to indicate this is EAT format.
The only difference between this and new bit is that this format is NOT negotiable. Not sure if that is acceptable or not.

[jyao1]

The conclusion is to add IETF as a standards body in SVH, and add SVH support to the measurement block with type 0xA.