Re: [Rats] [sacm] CoSWID and EAT and CWT

[Thomas Fossati <[e-mail]>]

Hi Henk,

On 27/11/2019, 17:18, "Henk Birkholz" <[e-mail]> wrote:
> we have a coswid extension in the queue that allows for the inclusion of
> hash-entries to very kind of resource-collection type (and also 12-14
> additional indexes, I think, that allow for the creation of Reference
> Integrity Manifests, including hashes for running processes). But this
> will not be submitted this year anymore, I am afraid. Very early next year!

Very interesting, thanks.  If possible, I'd like to have a look at the
proposal.  (No worries, I'll ask around here first, there should be a
couple of colleagues with access to the RIV work-in-progress in the room
next to mine.)

However, if I extrapolate correctly from what you say, this new CoSWID
extension would pop up on the RIM side rather than being a way to wrap
the measurements coming from the device in an attestation report?
If so, it makes a lot of sense to me.

[...]

I've done a bit of reading in the last two days and the more I look at
CoSWID the more I'm persuaded that while they'd work perfectly well for
a "software inventory" claim, the semantic overlap with a TPM/TEE/PSA
measurement is a bit tenuous and probably not enough to justify their
usage in those contexts.

My understanding is that in TPM/TEE/PSA the *measurement*, i.e. the
result of a function computed at {boot,run}-time on a piece of
executable and/or static memory, is the first class object of the
attestation.  A measurement comes with a bunch of optional metadata
attached (e.g., the measured software/firmware component name and
version, its signer, etc.), but these are effectively only metadata, not
necessary attributes -- in fact, our implementation of the verifier
doesn't care if they are not found in the submitted token.  On the other
hand, the entity modelled by a SWID is a *software component*, so using
that to wrap a measurement would look like a slight semantic abuse?

(As a meta comment, it seems to me that the risk associated with
CoSWID's excellent syntactic malleability is its semantics can be
stretched a tad too much.)

OK, concluding this long (and boring) rambling with an arc back to
Laurence's email "More claims? When is EAT done?" [1] and the related
discussion in Singapore, my current take on this is:
1. SW Inventory claim: yes, with CoSWID;
2. Measurements and Integrity Checks claim: yes please, with a new ad
   hoc format.

> The SUIT manifest can look very complex (CDDL-wise), but please keep in
> mind that most members (content items) are optional, so an actual
> instance of SUIT manifest can be quite... concise :) While I see the
> point in doing it "all in one thing" the SUIT manifest is an excellent
> representation for what is needed in updating small and big or cloudy
> things and redundant semantics in data formats often create
> corresponding friction in semantic interoperability later on (iotdir hat
> on opinion). So my first reaction is to combine the functionality of
> both and not to recreate the functionality redundantly on each side.

At the moment it still looks like a stretch to me, but I'd like to take
some more time to mull it over and discuss it with my fellow SUIT
colleagues because I think it's an interesting thought.

Cheers, thanks!

[1] https://mailarchive.ietf.org/arch/msg/rats/LXq1JH-w16L6qXeyBblKTkQ_-FA


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.