[docs] Middleware editorial updates and remove RSA from SPDM.

moidx · moidx · commit 7fa79125aa6e · 2025-10-10T18:19:52.000-07:00
Updates to the middleware section to make the document more consistent.
Removed RSA algos from SPDM.

Signed-off-by: Miguel Osorio &lt;miguelosorio@google.com&gt;
diff --git a/docs/src/specification/middleware/mctp.md b/docs/src/specification/middleware/mctp.md
@@ -11,7 +11,9 @@ The *minimum required* MCTP version is 1.3.1 (DSP0236.) Support for MCTP 2.0.0
 ## Required Bindings
 
 Currently only one binding is *mandatory* in the OpenPRoT specification, though
-this will change in future versions. 1. . MCTP over SMBus (DSP0237, 1.2.0)
+this will change in future versions.
+
+1.  MCTP over SMBus (DSP0237, 1.2.0)
 
 ## Recommended Bindings
 
diff --git a/docs/src/specification/middleware/pldm.md b/docs/src/specification/middleware/pldm.md
@@ -1,69 +1,72 @@
-## PLDM
+# PLDM
 
-PLDM OpenPRoT devices will support Platform Level Data Model as a responder for
-FW updates and platform monitoring. This means that OpenPRoT will respond to
-Type 0, Type 2 and Type 5 as listed in Table 1\.
+OpenPRoT devices support the Platform Level Data Model (PLDM) as a responder for
+firmware updates and platform monitoring. This entails responding to messages of
+Type 0 (Base), Type 2 (Platform Monitoring and Control), and Type 5 (Firmware
+Update).
 
-## PLDM Base Specifications for Supported Types {#pldm-base-specifications-for-supported-types}
+## PLDM Base Specifications
 
 ### Type 0 - Base Specification
 
-*   Purpose: Base Specification and Initialization
-*   Version: 1.2.0
-*   [Platform Level Data Model (PLDM) Base Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.2.0.pdf)
+-   **Purpose**: Base Specification and Initialization
+-   **Version**: 1.2.0
+-   **Specification**:
+    [PLDM Base Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.2.0.pdf)
 
-All responders shall implement the four (4) *spec mandatory* PLDM commands:
+All responders must implement the following mandatory PLDM commands:
 
-*   `GetTID`
-*   `GetPLDMVersion`
-*   `GetPLDMTypes`
-*   `GetPLDMCommands`
+-   `GetTID`
+-   `GetPLDMVersion`
+-   `GetPLDMTypes`
+-   `GetPLDMCommands`
 
-All responders shall implement the following *optional* commands
+All responders must also implement the following optional command:
 
-*   `SetTID`
+-   `SetTID`
 
 ### Type 2 - Platform Monitoring and Control
 
-*   Purpose: Platform Monitoring and Control
-*   Version: 1.3.0
-*   [Platform Level Data Model (PLDM) for Platform Monitoring and Control
-    Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0248_1.3.0.pdf)
+-   **Purpose**: Platform Monitoring and Control
+-   **Version**: 1.3.0
+-   **Specification**:
+    [PLDM for Platform Monitoring and Control](https://www.dmtf.org/sites/default/files/standards/documents/DSP0248_1.3.0.pdf)
 
-OpenPRoT will support PLDM Monitoring and Control by providing a PDR, Platform
-Descriptor Record, repository to a prospective PDLM Manageability Access Point
-Discovery Agent’s primary PDR. These PDRs will be defined via Json files and
-included into OpenPRoT at build time. OpenPRoT will not support any dynamic
-adjustments to the PDR repository. These PDRs should be limited to security
-features and as such, will only support PLDM sensors and not effectors. PLDM
-Monitoring PDRs
+OpenPRoT supports PLDM Monitoring and Control by providing a Platform Descriptor
+Record (PDR) repository to a prospective PLDM manageability access point
+discovery agent. These PDRs are defined in JSON files and included in OpenPRoT
+at build time, with no support for dynamic adjustments. The PDRs are limited to
+security features and will only support PLDM sensors, not effectors.
 
-*   Terminus Locator PDR
-*   Numeric Sensor PDR
+#### PLDM Monitoring PDRs
+
+-   Terminus Locator PDR
+-   Numeric Sensor PDR
 
 ### Type 5 - Firmware Update
 
-*   Purpose: Firmware Update
-*   Version: 1.3.0
-*   [Platform Level Data Model (PLDM) for Firmware Update Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.3.0.pdf)
+-   **Purpose**: Firmware Update
+-   **Version**: 1.3.0
+-   **Specification**:
+    [PLDM for Firmware Update](https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.3.0.pdf)
 
-Required Inventory Commands:
+#### Required Inventory Commands
 
-*   `QueryDeviceIdentifiers`
-*   `GetFirmwareParameters`
+-   `QueryDeviceIdentifiers`
+-   `GetFirmwareParameters`
 
-Required Update Commands:
+#### Required Update Commands
 
-*   `RequestFirmwareUpdate`
-*   `PassComponentTable`
-*   `UpdateComponent`
-*   `TransferComplete`
-*   `VerifyComplete`
-*   `ApplyComplete`
-*   `ActivateFirmware`
-*   `GetStatus`
+-   `RequestFirmwareUpdate`
+-   `PassComponentTable`
+-   `UpdateComponent`
+-   `TransferComplete`
+-   `VerifyComplete`
+-   `ApplyComplete`
+-   `ActivateFirmware`
+-   `GetStatus`
 
-All responders shall implement the following optional commands
+All responders must also implement the following optional commands:
 
-*   `GetPackageData`
-*   `GetPackageMetaData`
+-   `GetPackageData`
+-   `GetPackageMetaData`
diff --git a/docs/src/specification/middleware/spdm.md b/docs/src/specification/middleware/spdm.md
@@ -3,109 +3,116 @@
 SPDM OpenPRoT devices shall use SPDM to conduct all attestation operations both
 with downstream devices (as a requester) and upstream devices (as a responder.)
 Devices may choose to act as a requester, a responder, or both. All SPDM version
-references assume alignment with the most recently released versions of the spec
-(i.e. 1.2.1, 1.3.2.)
-
-1.  [OCP Attestation Spec 1.1](https://github.com/google/spdm-accelerator-requirement/blob/main/OCP-Attestation-v1.1.docx.pdf)
-    Alignment OpenPRoT implementations of SPDM must align with the OCP
-    Attestation Spec 1.1, linked above. All following sections have taken this
-    spec into account. Please refer to that specification for details on
-    specific requirements.
-2.  Baseline Version OpenPRoT sets a baseline version of SPDM 1.2.
-3.  Requesters OpenPRoT devices implementing an SPDM requester will implement
-    support for SPDM 1.2 minimum and may implement SPDM 1.3 and up. The minimum
-    and maximum supported SPDM versions can be changed if support for other
-    versions is not necessary.
-4.  Responders OpenPRoT devices implementing an SPDM responder must implement
-    support for SPDM 1.2 or higher. Responders may only report (via
-    `GET_VERSION`) a single supported version of SPDM.
-5.  Required Commands All requesters and responders shall implement the four (4)
-    *spec mandatory* SPDM commands:
-
-    *   `GET_VERSION`
-
-    *   `GET_CAPABILITIES`
-
-    *   `NEGOTIATE_ALGORITHMS`
-
-    *   `RESPOND_IF_READY`
-
-    All requesters and responders shall implement the following *spec optional*
-    commands:
-
-    *   `GET_DIGESTS`
-    *   `GET_CERTIFICATE`
-    *   `CHALLENGE`
-    *   `GET_MEASUREMENTS`
-    *   `GET_CSR`
-    *   `SET_CERTIFICATE`
-    *   `CHUNK_SEND`
-    *   `CHUNK_GET`
-
-    Requesters and responders may implement the following recommended *spec
-    optional* commands:
-
-    *   Events
-        *   `GET_SUPPORTED_EVENT_TYPES`
-        *   `SUBSCRIBE_EVENT_TYPES`
-        *   `SEND_EVENT`
-    *   Encapsulated requests
-        *   `GET_ENCAPSULATED_REQUEST`
-        *   `DELIVER_ENCAPSULATED_RESPONSE`
-    *   `GET_KEY_PAIR_INFO`
-    *   `SET_KEY_PAIR_INFO`
-    *   `KEY_UPDATE`
-    *   `KEY_EXCHANGE`
-    *   `FINISH`
-    *   `PSK_EXCHANGE`
-    *   `PSK_FINISH`
-
-    All other *spec optional* commands may be implemented as the integrator sees
-    fit for their use case.
-
-6.  Required Capabilities
-
-    *   `CERT_CAP` (required for `GET_CERTIFICATE`)
-    *   `CHAL_CAP` (required for `CHALLENGE`)
-    *   `MEAS_CAP` (required for `GET_MEASUREMENT`)
-    *   `MEAS_FRESH_CAP`
-
-7.  Algorithms The following cryptographic algorithms are accepted for use
-    within OpenPRoT, but may be further constrained by hardware capabilities. At
-    a minimum OpenPRoT hardware must support:
+references assume alignment with the most recently released versions of the spec.
 
+## OCP Attestation Spec 1.1 Alignment
+
+OpenPRoT implementations of SPDM must align with the
+[OCP Attestation Spec 1.1](https://github.com/google/spdm-accelerator-requirement/blob/main/OCP-Attestation-v1.1.docx.pdf).
+All following sections have taken this spec into account. Please refer to that
+specification for details on specific requirements.
+
+## Baseline Version
+
+OpenPRoT sets a baseline version of SPDM 1.2.
+
+## Requesters
+
+OpenPRoT devices implementing an SPDM requester will implement support for SPDM
+1.2 minimum and may implement SPDM 1.3 and up. The minimum and maximum supported
+SPDM versions can be changed if support for other versions is not necessary.
+
+## Responders
+
+OpenPRoT devices implementing an SPDM responder must implement support for SPDM
+1.2 or higher. Responders may only report (via `GET_VERSION`) a single supported
+version of SPDM.
+
+## Required Commands
+
+All requesters and responders shall implement the four (4) *spec mandatory* SPDM
+commands:
+
+*   `GET_VERSION`
+*   `GET_CAPABILITIES`
+*   `NEGOTIATE_ALGORITHMS`
+*   `RESPOND_IF_READY`
+
+All requesters and responders shall implement the following *spec optional*
+commands:
+
+*   `GET_DIGESTS`
+*   `GET_CERTIFICATE`
+*   `CHALLENGE`
+*   `GET_MEASUREMENTS`
+*   `GET_CSR`
+*   `SET_CERTIFICATE`
+*   `CHUNK_SEND`
+*   `CHUNK_GET`
+
+Requesters and responders may implement the following recommended *spec
+optional* commands:
+
+*   Events
+    *   `GET_SUPPORTED_EVENT_TYPES`
+    *   `SUBSCRIBE_EVENT_TYPES`
+    *   `SEND_EVENT`
+*   Encapsulated requests
+    *   `GET_ENCAPSULATED_REQUEST`
+    *   `DELIVER_ENCAPSULATED_RESPONSE`
+*   `GET_KEY_PAIR_INFO`
+*   `SET_KEY_PAIR_INFO`
+*   `KEY_UPDATE`
+*   `KEY_EXCHANGE`
+*   `FINISH`
+*   `PSK_EXCHANGE`
+*   `PSK_FINISH`
+
+All other *spec optional* commands may be implemented as the integrator sees fit
+for their use case.
+
+## Required Capabilities
+
+*   `CERT_CAP` (required for `GET_CERTIFICATE`)
+*   `CHAL_CAP` (required for `CHALLENGE`)
+*   `MEAS_CAP` (required for `GET_MEASUREMENT`)
+*   `MEAS_FRESH_CAP`
+
+## Algorithms
+
+The following cryptographic algorithms are accepted for use within OpenPRoT, but
+may be further constrained by hardware capabilities. At a minimum OpenPRoT
+hardware must support:
+
+*   `TPM_ALG_ECDSA_ECC_NIST_P384`
+*   `TPM_ALG_SHA3_384`
+
+All others are optional and may be used if supported.
+
+*   Asymmetric
+    *   `TPM_ALG_ECDSA_ECC_NIST_P256`
     *   `TPM_ALG_ECDSA_ECC_NIST_P384`
+    *   `EdDSA ed25519`
+    *   `EdDSA ed448`
+    *   `TPM_ALG_SHA_384`
+*   Hash
+    *   `TPM_ALG_SHA_256`
+    *   `TPM_ALG_SHA_384`
+    *   `TPM_ALG_SHA_512`
+    *   `TPM_ALG_SHA3_256`
     *   `TPM_ALG_SHA3_384`
+    *   `TPM_ALG_SHA3_512`
+*   AEAD Cipher
+    *   `AES-128-GCM`
+    *   `AES-256-GCM`
+    *   `CHACHA20_POLY1305`
+
+## Attestation Report Format
+
+Devices will support either RATS EAT (as CWT) or an SPDM evidence manifest TOC
+per the *TCG DICE Concise Evidence for SPDM* specification.
+
+## Measurement block 0xF0
 
-    All others are optional and may be used if supported.
-
-    *   Asymmetric
-        *   `TPM_ALG_RSASSA_2048`
-        *   `TPM_ALG_RSAPSS_2048`
-        *   `TPM_ALG_RSASSA_3072`
-        *   `TPM_ALG_RSAPSS_3072`
-        *   `TPM_ALG_ECDSA_ECC_NIST_P256`
-        *   `TPM_ALG_RSASSA_4096`
-        *   `TPM_ALG_RSAPSS_4096`
-        *   `TPM_ALG_ECDSA_ECC_NIST_P384`
-        *   `EdDSA ed25519`
-        *   `EdDSA ed448`
-        *   `TPM_ALG_SHA_384`
-    *   Hash
-        *   `TPM_ALG_SHA_256`
-        *   `TPM_ALG_SHA_384`
-        *   `TPM_ALG_SHA_512`
-        *   `TPM_ALG_SHA3_256`
-        *   `TPM_ALG_SHA3_384`
-        *   `TPM_ALG_SHA3_512`
-    *   AEAD Cipher
-        *   `AES-128-GCM`
-        *   `AES-256-GCM`
-        *   `CHACHA20_POLY1305`
-
-8.  Attestation Report Format Devices will support either RATS EAT (as CWT) or
-    an SPDM evidence manifest TOC per the *TCG DICE Concise Evidence for SPDM*
-    specification.
-
-9.  Measurement block 0xF0 Devices that do not provide a Measurement Manifest
-    shall locate RATS EAT at SPDM measurement block 0xF0
+Devices that do not provide a Measurement Manifest shall locate RATS EAT at SPDM
+measurement block 0xF0
