docs/designs/redfish-spdm-attestation.md

55 2. Identity information, e.g., device identity certificates.
76 certificates.
164 up a connection with the SPDM-capable endpoints to get certificates and
211 6. Exchange SPDM messages to get device certificates.
220 which allows users to install or replace server/client certificates. However,
221 the existing certificates manager is designed for managing server/client
222 certificates for HTTPS/LDAP services. It's not suitable for device certificates.
229 Device certificates have different requirements:
231 - Device certificate manager manages several certificates for a group of
232   devices, for example, four GPUs would have four certificates.
237 For device certificates, we only need to create/replace certificate objects, no
238 need for a global cert manager that "manages" the device certificates. SPDM
239 D-Bus daemon can simply talk to the devices, get the certificates from them, and
240 create D-Bus object for the certificates.
242 In Redfish, device certificates are under Chassis, and are accessible via
243 `/redfish/v1/Chassis/{ChassisId}/Certificates/`. Existing cert manager
246 to put device certificates under
248 device certificates on a chassis, we can find those certificates with its
254 `TrustedComponent` and `Certificates`. The corresponding URI are specified as
260 The TrustedComponent represents a ROT or TPM, and its associated certificates
262 proper URI structure for certificates, please refer to the [Redfish Data Model
266   `Certificates`
268   `Certificates/{CertificateId}`
284 Alternative way to manage device certificates would be modifying existing
287 Device certificates management has two steps:
330 - Get device certificates from device and create D-Bus object.
346 - Follow the resouces link to get the device certificates and verify that they