DMTF
Raw public key provisioning is using certificate chain
According to SPDM ver 1.2.1 section 7.2.2 Raw public keys
Alternatively to certificate chains, the vendor can provision the raw public key of the Responder to the Requester in a trusted environment; for example, during the secure manufacturing process. In this case, trust of the public key of the Responder is established without the need for a certificate-based public key infrastructure. The definition of a trusted environment is outside of the scope of this specification. The format of the provisioned public key is out of scope of this specification. Vendors can use proprietary formats or public key formats that other standards define, such as RFC7250 and RFC4716.
Libspdm uses certificate chain even in the raw public key provisioning (slot 0xFF) scenario. Would you mind to let me know your opinion about this?
Libspdm uses certificate chain
Only the leaf certificate is required.
My opinion is that until the SPDM specification mandates a single raw public key format it will be difficult for a general purpose library like libspdm to provide support. I would be fine if it was a simple ASN.1 data structure that came with a simple parser and not an entire certificate chain parsing library. Maybe the specification could have its blessed format that it recommends everyone, including libspdm, use, but allow implementers to use their own format if, for example, ASN.1 doesn't work for them.
Only the leaf certificate is required.
Yes though, it is still a certificate instead of the raw public key. How about change to use just ASN.1 SubjectPublicKeyInfo of a certificate, as the specification claims (RFC7250)? as you mentioned:
a simple ASN.1 data structure that came with a simple parser and not an entire certificate chain parsing library.
11/7/2022 - One possible option - libspdm can include an ASN.1 parser, knowing it will only parse the raw public key. Not a full parser. Hope it is small portion of code. Also, we assume the provisioned public key is good, not malicious.
@xiangfeima, will you please take this issue and submit patch?
I closed #1486 because recently some merged and incoming patches changed a lot of the slot_id checking logic (#1520 and #1524). I will make a new PR base on them.