Standard measurement format #3155
Conversation
Signed-off-by: Steven Bellock <[email protected]>
jyao1
force-pushed
the
meas_report
branch
4 times, most recently
from
ddf9a5c to
7e459d2
Compare
|
@jyao1 since this is not an official DMTF specification the document should not have normative language like "should", "shall", and "must"; it is a descriptive document. A Verifier's documentation can use normative language if it wants, to specify that this must be followed. I might be able to discuss this with a wider audience at OCP Security on 29-July-2025. In particular to get feedback on where a document like this should reside, as well as the |
Rename existing one to Standard All-Measurements Report Definition. Signed-off-by: Jiewen Yao <[email protected]>
I changed |
| For SPDM 1.2 and later, the byte buffer is {`VCA`, `GET_MEASUREMENTS`(0), `MEASUREMENTS`(0), | ||
| `GET_MEASUREMENTS`(1), `MEASUREMENTS`(1), ..., `GET_MEASUREMENTS`(n), `MEASUREMENTS`(n)}. | ||
|
|
||
| The `GET_MEASUREMENTS`(0) request has the following properties: |
There was a problem hiding this comment.
Why put this in the L1/L2 transcript? Presumably the Verifier knows exactly how many measurement indices a device reports.
There was a problem hiding this comment.
What do you mean "this"? Would you please be specific?
If you are asking why we need to send command to get Total Number (n), the answer is: The requester needs to know when to send SignatureRequested - that is after (n-1) successful response is received.
There was a problem hiding this comment.
What do you mean "this"? Would you please be specific?
GET_MEASUREMENTS(0) and MEASUREMENTS(0).
If you are asking why we need to send command to get Total Number (n),
No, the question is why is it present in the measurement report when the Verifier already knows how many measurement indices a device has? The Requester can use this information, but, barring a good reason to keep it, it probably can be omitted from the report.
There was a problem hiding this comment.
The logic is as follows:
- First, the requester must send it, in order to send the last
SignatureRequested. - Second, if the requester sends it, then it is in the L1/L2 transcript for signature calculation.
- Third, if it is in L1/L2 transcript for signature calculation, then it must be passed to verifier. As such, the verifier can reproduce the L1/L2 signature.
There was a problem hiding this comment.
I think it is good, because it passed what happened honestly.
For example, the verifier can check param to know what it is. The verifier can compare the total number to see if the total is expected, and fail immediately. Or if verifier does not care, then verifier can just skip.
What is the concern to add this message pair?
There was a problem hiding this comment.
What is the concern to add this message pair?
There needs to be some rationale for delivering this information to the Verifier, else it should be omitted. In particular the Verifier can parse the messages without it, as it does with the "All-Measurements Report".
If it is omitted from the Measurement Report then Requester would query the number of indices and have that signed. Once it has determined the number of indices, then it would begin a new L1/L2 transcript that then becomes the Measurement Report.
There was a problem hiding this comment.
It is omitted in "All-Measurement Report" because the requester does not send it.
It is totally different from the "One-by-one Measurement Report", where the requester does send it.
Omitting message means the verifier must reconstruct the GetTotalNumber to L1/L2, in order to reproduce the signature.
I don't think it is good idea to let verifier make assumption on how the requester sends message, and let verifier modify the transcript - that overloads too much on the verifier.
There was a problem hiding this comment.
Discussed this at the 3-Nov-2025 meeting. Will keep this in the report. @jyao1 will file an issue against the specification regarding Content changed and the NumberOfBlocks field.
There was a problem hiding this comment.
2 participants
This is based on https://github.com/steven-bellock/libspdm/tree/fix-3108, and add One-by-One Measurement Report format.
Ref #3108