You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 29, 2024. It is now read-only.
As much as I like the idea of reusing PSA semantics, I think there's a chance here to "sit on the shoulder of the giant" (poorly paraphrasing Bernard de Chartres) and see what we can improve. In particular, I think there are some low-hanging fruits to be reaped from the work we've done on the verifier side, i.e., the guy who needs to make sense of the evidence blob.
Here are a few observations and proposals for discussion:
software-component is a bit of a misnomer, because it's not just software/firmware that gets measured, it's also other kinds of blobs (e.g., configuration). A better, more generic name for the claim could be measured-component.
Measurement Type is actually the hash algorithm identifier that is used to compute the digest, so using Type is not accurate, and frankly quite confusing. If I were to rewrite the PSA claim today, I'd group the measurement data (digest and algorithm) in a digest type, similar to CoSWID/CoRIM:
In CDDL:
digest = [
hash-alg: int. ; codepoint from the COSE algorithms registry
digest: bstr ; the actual digest
]
In ASN.1:
Digest ::=SEQUENCE {
hashAlgorithm AlgorithmIdentifier, -- OID for the hash algorithm
digest BIT STRING
}
When building the verifier, we learned the importance of stable identifiers for measured components. These identifiers help in tracking the same measured item across updates and enable higher-quality signalling from the appraisal procedure to relying parties. A "component identifier" that provides a stable name along with an optional version is a good start. PSA got that bit right but makes it optional which doesn't promote the best practice. Again, with the benefit of hindsight:
As much as I like the idea of reusing PSA semantics, I think there's a chance here to "sit on the shoulder of the giant" (poorly paraphrasing Bernard de Chartres) and see what we can improve. In particular, I think there are some low-hanging fruits to be reaped from the work we've done on the verifier side, i.e., the guy who needs to make sense of the evidence blob.
Here are a few observations and proposals for discussion:
software-component
is a bit of a misnomer, because it's not just software/firmware that gets measured, it's also other kinds of blobs (e.g., configuration). A better, more generic name for the claim could bemeasured-component
.Measurement Type
is actually the hash algorithm identifier that is used to compute the digest, so usingType
is not accurate, and frankly quite confusing. If I were to rewrite the PSA claim today, I'd group the measurement data (digest and algorithm) in adigest
type, similar to CoSWID/CoRIM:In CDDL:
In ASN.1:
In CDDL:
In ASN.1:
So, to summarise, the data format I'm suggesting for §3.9 is:
In CDDL:
In ASN.1:
The text was updated successfully, but these errors were encountered: