Addressing Note on Attestation of System Components#89
Addressing Note on Attestation of System Components#89fdamato wants to merge 1 commit intoopencomputeproject:mainfrom
Conversation
e479229 to
b21693f
Compare
fdamato
left a comment
There was a problem hiding this comment.
This is just a first pass. I added few comments on the notes
| - *Platforms **MAY** use the message formats for GET\_CAPABILITIES and NEGOTIATE\_ALGORITHMS as described in* [Security Protocol and Data Model (SPDM) Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.0.0.pdf) or *Device Capabilities* *as described in [Project Cerberus Firmware Challenge Specification](https://github.com/opencomputeproject/Project_Olympus/blob/master/Project_Cerberus/Project%20Cerberus%20Challenge%20Protocol.pdf) .* *Where necessary, bridge components may be responsible for translating from the native bus protocol into the GET\_CAPABILITIES/ NEGOTIATE\_ALGORITHMS message formats.* | ||
| - *Platforms **MAY** use the message formats for GET\_CAPABILITIES and NEGOTIATE\_ALGORITHMS as described in* [Security Protocol and Data Model (SPDM) Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.0.0.pdf). | ||
|
|
||
| ***NOTE from Bryan Kelly: "Replace Cerberus with GET_EAT"*** |
There was a problem hiding this comment.
Addressed below:
Attester devices MUST provide attestation evidence using one of the following methods:
- GET_EAT command returning an Entity Attestation Token (EAT) conforming to the OCP EAT Profile, OR
- GET_MEASUREMENTS command with the EAT located at SPDM Measurement Block 0xFD
| guidelines in this section. The OCP SPDM Profile requires support for the following | ||
| algorithms: | ||
|
|
||
| ***NOTE from Jeremy O'Donoghue: "I would prefer to see the requirements on interoperability moved to the verifier - it generally has lower security requirements than RoT and a more performance compute environment. For example: attester must support TPM_ALG_ECDSA_NIST_P384, TPM_ALG_SHA384, AES-256-GCM, TPM_ALG_MLDSA_65 (assuming that's what TCG eventually calls the algorithm). Verifier MAY support other algorithms."*** |
There was a problem hiding this comment.
Addressed below. Attesters have only to support
Tier 1: Mandatory Baseline Algorithms
|
|
||
| ### Required Capabilities for SPDM | ||
|
|
||
| ***NOTE from Bryan Kelly: "Do we need MEAS_CAP if we have GET_EAT support?"*** |
There was a problem hiding this comment.
GET_MEASUREMENTS at slot 0xFD can also return a EAT, using a SPDM 1st class command. I left support for both GET_MEASUREMENTS and GET_EAT, if that works
| | MEAS_FRESH_CAP | 0 (may return cached measurements) | | ||
| | CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET | | ||
| | MEAS_CAP | Supports MEASUREMENTS and should support signed MEASUREMENTS (SPDM MEAS_CAP = 10b). | | ||
| | MEAS_FRESH_CAP | 0 (may return cached measurements) or 1 if EAT freshness is required | |
There was a problem hiding this comment.
I think we still want 0 here. 1 means: "The Responder shall support recomputing all MEASUREMENTS without requiring a Reset". Even if EAT freshness is needed, 1 is an anti-pattern. the measurements should not be recomputed.
There was a problem hiding this comment.
I agree...I`ll remove 1
Signed-off-by: Fabrizio Damato <[email protected]>
b21693f to
b927ecb
Compare
| ### IETF EAT Binding for SPDM | ||
| To ensure interoperability and quantum readiness, this specification defines mandatory | ||
| baseline algorithms that all compliant devices must support. | ||
|
|
There was a problem hiding this comment.
move OCP Crypto Requirement in separate document, and refer to that one
There was a problem hiding this comment.
concern is that there might be some devices (or geos) not able to implement, for example, ML-DSA-87
There was a problem hiding this comment.
Suggestion, to point to the OCP EAT Profile (Defined Algorithms) and remove normative from here...
| | MEAS_CAP | Supports MEASUREMENTS and should support signed MEASUREMENTS (SPDM MEAS_CAP = 10b). | | ||
| | MEAS_FRESH_CAP | 0 (may return cached measurements) | | ||
| | CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET | | ||
| | CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET (required for large certificates and EATs) | |
There was a problem hiding this comment.
This should be conditional on the underlying transport capabilities. For example, PCIe DOE supports chunking of higher layer messages.
No description provided.