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
I don't think measured components should replicate CoSWID functionality.
The file-entry and directory-entry structures defined in Section 2.9.2 of RFC9393 are way too complex - i.e., they have too much cruft attached, and are recursive in nature.
Conceptually, what we need to borrow from CoSWID is something like fs-name, but fully qualified, as a component name.
For example:
[
/ id / [
/ name / "/etc/service.conf"
],
/ measurement / [
/ alg / "sha-256",
/ val / h'3996003d486fb91ffb056f7d03f2b2992b215b31dbe7af4b37
3431fc7d319da3'
]
]
Is the use of a file system object a use case we want to support? If so, we need to be more precise of how this works.
E.g. COSWID supports file system item but do we want to reuse the concept from there?
The text was updated successfully, but these errors were encountered: