Skip to content

Commit a47569a

Browse files
bluegate010bluegate010
authored
Capture feedback from Aug 26 2025 meeting
1 parent cf98656 commit a47569a

File tree

1 file changed

+28
-22
lines changed
  • specifications/attestation-of-system-components

1 file changed

+28
-22
lines changed

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

Lines changed: 28 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -418,7 +418,7 @@ This protocol is highly dependent on the specific technology of the platform, bu
418418

419419
- *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.*
420420

421-
***NOTE from Alberto Munoz: "Should we remove this reference to Cerberus, or are there devices that still support it?"***
421+
***NOTE from Bryan Kelly: "Replace Cerberus with GET_EAT"***
422422

423423
## Authentication, Attestation, and Enrollment protocol {#sec:authentication-attestation-and-enrollment-protocol}
424424

@@ -466,8 +466,6 @@ Example message formats and content are as described in [Security Protocol and D
466466

467467
To conform to the OCP SPDM profile the following requirements must be met:
468468

469-
***NOTE from Brett Henning: "We should have a command to discover OCP profile support, and presumably a version for the profile. This could be an SPDM vendor defined (we'll have to create a vendor ID for OCP, but we just made that process much simpler)."***
470-
471469
10. *Attester devices that support the SPDM standard **MUST** conform to the set of capabilities as defined in the table “Required Capabilities for SPDM.”*
472470

473471
11. *Attester devices that support the SPDM standard **SHOULD** support the set of algorithms as defined in the table “Recommended Algorithms for SPDM”.*
@@ -484,18 +482,18 @@ To conform to the OCP SPDM profile the following requirements must be met:
484482

485483
### Required Capabilities for SPDM
486484

487-
***NOTE from Alberto Munoz: "We need to update (add) capabilities required to support 1.1 and 1.2 commands listed in 8.5.2.2 to this section (e.g., KEY_EX_CAP, CSR_CAP, CHUNK_CAP)"***
485+
***NOTE from Bryan Kelly: "Do we need MEAS_CAP if we have GET_EAT support?"***
488486

489487
The following table lists the SPDM capabilities, as defined in the CAPABILITIES response, that are required for attester devices that are compliant with this specification. Note, this table is based on version 1.1.0 of the SPDM specification, and capabilities that are only defined in version 1.1.0 are not required if the attester device does not support version 1.1.0.
490488

491-
| Capability | Description |
492-
| :--------------- | :----------------------------------------------------------------------------------- |
493-
| CERT\_CAP | Supports certificate exchanges |
494-
| CHAL\_CAP | Supports challenge |
495-
| MEAS\_CAP | Supports MEASUREMENTS and should support signed MEASUREMENTS (SPDM MEAS\_CAP \= 10b) |
496-
| MEAS\_FRESH\_CAP | 1 (always return fresh measurements) |
497-
498-
***NOTE from Jeff Andersen: "To discuss, MEAS\_FRESH\_CAP is a bit problematic."***
489+
| Capability | Description |
490+
| :------------- | :----------------------------------------------------------------------------------- |
491+
| CERT_CAP | Supports certificate exchanges |
492+
| CHAL_CAP | Supports challenge |
493+
| MEAS_CAP | Supports MEASUREMENTS and should support signed MEASUREMENTS (SPDM MEAS\_CAP \= 10b) |
494+
| MEAS_FRESH_CAP | 0 (may return cached measurements) |
495+
| CHUNK_CAP | Supports CHUNK_SEND/CHUNK_GET |
496+
| CSR_CAP | Supports GET_CSR |
499497

500498
### Required Commands for SPDM
501499

@@ -504,15 +502,15 @@ Attestor devices are allowed to implement a large number of commands under the S
504502
Table: Required SPDM Commands
505503

506504
| SPDM  Version | Command |
507-
| :------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
508-
| **1.0** | GET\_CERTIFICATE |
509-
| | GET\_MEASUREMENTS |
510-
| **1.2** | GET\_CSR  Note: the SPDM 1.2 specification states that the key within the CSR is the Device Certificate CA key. To satisfy this OCP specification, the key within the CSR may instead be (directly or indirectly) endorsed by the DeviceID key. The key within the CSR should change infrequently, to avoid triggering frequent re-enrollment flows. The CSR may be null-signed rather than self-signed. The key within the CSR must be endorsed (directly or indirectly) by the vendor’s PKI. See CSR in note below. |
511-
| | SET\_CERTIFICATE |
512-
| | CHUNK\_SEND |
513-
| | CHUNK\_GET |
505+
| :------------ | :--------------- |
506+
| **1.0** | GET_CERTIFICATE |
507+
| | GET_MEASUREMENTS |
508+
| **1.2** | GET_CSR |
509+
| | SET_CERTIFICATE |
510+
| | CHUNK_SEND |
511+
| | CHUNK_GET |
514512

515-
Note: SPDM GET\_CSR assumes responders have access to the signing key corresponding to the public key in the CSR. For devices where the SPDM responder operates at a locality where the signing key is not accessible, it is acceptable for the end entity to omit the signature from the CSR. In this instance, the burden of verifying the CSRs integrity falls upon the PKI owner. Evidence from the device vendor's certificate chain and endorsement of the CSR may be used in the verification.
513+
Note: see <https://github.com/opencomputeproject/Security/tree/master/specifications/device-identity-provisioning> for additional requirements around GET_CSR.
516514

517515
### Recommended Algorithms for SPDM
518516

@@ -523,6 +521,16 @@ algorithms:
523521

524522
***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."***
525523

524+
***Aug 26 2025: Let's refine this list, add PQC, and state that devices need to support at least one of a set. Examples:***
525+
526+
- secp384r1
527+
- AES-256-GCM
528+
- TPM_ALG_SHA_384
529+
- [ml-dsa-xxx]
530+
- [ml-kem-xxx]
531+
532+
May call these "(strongly) recommended"
533+
526534
| Algorithm Type | Required Algorithm |
527535
| :-------------- | :------------------------------- |
528536
| **Asymmetric** | TPM\_ALG\_RSASSA\_2048 |
@@ -546,8 +554,6 @@ algorithms:
546554
| | AES-256-GCM |
547555
| | CHACHA20\_POLY1305 |
548556

549-
***NOTE from Bryan Kelly: "Is there an ML-DSA yet?"***
550-
551557
### IETF EAT Binding for SPDM
552558

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

0 commit comments

Comments
 (0)