Measurements encoding clarifications

[thomas-fossati]

https://www.ietf.org/archive/id/draft-ietf-rats-eat-25.html#section-4.2.16 should have something like this to make sure the right encoding is picked up:

$fmt-cbor = bstr .cbor $FMT
$fmt-json = tstr .json $FMT

EAT CBOR (.feature "cbor")

$measurements-body-cbor /= $fmt-cbor            ; native
$measurements-body-cbor /= tstr .b64u $fmt-json ; tunnel

EAT JSON (.feature "json")

$measurements-body-json /= $fmt-json            ; native
$measurements-body-json /= tstr .b64u $fmt-cbor ; tunnel

CWT

content-type (CoAP C-F equivalent)	content-format
application/measured-component+cbor	$fmt-cbor
application/measured-component+json	tstr .b64u $fmt-json

JWT

content-type (CoAP C-F equivalent)	content-format
application/measured-component+json	$fmt-json
application/measured-component+cbor	tstr .b64u $fmt-cbor

[laurencelundblade]

I see where you are going, but it makes my head hurt, especially when validating with the cddl tool. An MC can be either CBOR or JSON itself and then can inserted into either a CBOR or JSON EAT. CDDL for MC is neutral.

Have you tried to construct the four combos and validate with the cddl tool? I'm not sure it's possible.

Do you mean $fmt-cbor and $FMT to be sockets?

If we do this for measurements, we have to do the same for manifests and maybe bundles.

[thomas-fossati]

I've tried to plug in untagged-coswid and it works:

$FMT /= untagged-coswid
$fmt-cbor = bstr .cbor $FMT
$measurements-body-cbor /= $fmt-cbor            ; native
$measurements-body-json /= tstr .b64u $fmt-cbor ; tunnel

Since untagged-coswid does not have a native JSON serialisation, I had to drop $fmt-json = tstr .json $FMT & friends.

[gmandyam]

If we do this for measurements, we have to do the same for manifests and maybe bundles.

Agreed. There was no such request during WGLC, so this may have to be taken back to WG as well. Current definition is passing validation so I don't see a reason to change them.

I see where you are going, but it makes my head hurt, especially when validating with the cddl tool. An MC can be either CBOR or JSON itself and then can inserted into either a CBOR or JSON EAT. CDDL for MC is neutral.

Also I am not sure what is being proposed is the only suitable alternative to what is already in the spec. For instance, a switch could be used (e.g. Figure 9 and associated description of tool requirements in https://datatracker.ietf.org/doc/html/rfc9165 for sensor measurements). If the validation tool cannot support a switch within a claim that seems to be a problem with the tool, because I could not find a prohibition in the CDDL specification.

[laurencelundblade]

I wouldn't do anything here that requires recycle with the WG, but I don't think this would have to go back to the WG. It's not a change to semantics, just a change to the CDDL to do better validation and take advantage of tool improvements. We were on the bleeding edge of the tool with the CBOR/JSON stuff.

The point of this would be to make the cddl validation of EATs work better. In particular to be able to validate that an MC in an EAT is a valid MC, and then on for all measurements and manifests in CBOR or JSON.

I don't think there's anything wrong with what's there now, but it is crude and it doesn't easily accommodate the full validation and might be a little confusing for some. @thomas-fossati, does that seem right to you?

I could see doing a substantial rework of the EAT CDDL at some point when things like import/include and stuff are standard and in the tool. We could even start on it now to understand what all is possible. Maybe it isn't published with the RFC and just stays in GitHub. It might also be part of reword of the CDDL for COSE and CWT and JOSE and JWT.

[thomas-fossati]

I don't think there's anything wrong with what's there now, but it is crude and it doesn't easily accommodate the full validation and might be a little confusing for some. @thomas-fossati, does that seem right to you?

Yes, that'd be my assessment too. With the description in draft-25 one has to work a bit harder than usual to figure out the details. I had to do the exercise twice to get it right, also because the first time I missed the fact that Measurements reuse the mechanics from Manifests (so there's maybe a missing ref that can be added without going through the WG.)

I could see doing a substantial rework of the EAT CDDL at some point when things like import/include and stuff are standard and in the tool. We could even start on it now to understand what all is possible. Maybe it isn't published with the RFC and just stays in GitHub. It might also be part of reword of the CDDL for COSE and CWT and JOSE and JWT.

That seems like a very good idea and I'd be happy to work with you on that.

[gmandyam]

wouldn't do anything here that requires recycle with the WG, but I don't think this would have to go back to the WG. It's not a change to semantics, just a change to the CDDL to do better validation and take advantage of tool improvements. We were on the bleeding edge of the tool with the CBOR/JSON stuff.

OK - just saw the revised proposal with untagged-coswid re-introduction. So I agree that semantics are not changing.

With the description in draft-25 one has to work a bit harder than usual to figure out the details. I had to do the exercise twice to get it right, also because the first time I missed the fact that Measurements reuse the mechanics from Manifests (so there's maybe a missing ref that can be added without going through the WG.)

Is this the reason new measurement claims were defined for CCA - see Section III.D of https://ieeexplore.ieee.org/document/10373038 If so, as an alternative I would've just overloaded the result-id subclaim in https://www.ietf.org/archive/id/draft-ietf-rats-eat-25.html#name-measres-software-measuremen.

[gmandyam]

@thomas-fossati

Can you respond to previous question? Want to make sure there are no showstopper issues with measurements claim that would prevent adoption. Reproducing here:

s this the reason new measurement claims were defined for CCA - see Section III.D of https://ieeexplore.ieee.org/document/10373038 If so, as an alternative I would've just overloaded the result-id subclaim in https://www.ietf.org/archive/id/draft-ietf-rats-eat-25.html#name-measres-software-measuremen.

[thomas-fossati]

@thomas-fossati

Can you respond to previous question? Want to make sure there are no showstopper issues with measurements claim that would prevent adoption. Reproducing here:

Sorry @gmandyam, I'd missed that. Thanks for the heads up.

s this the reason new measurement claims were defined for CCA - see Section III.D of https://ieeexplore.ieee.org/document/10373038 If so, as an alternative I would've just overloaded the result-id subclaim in https://www.ietf.org/archive/id/draft-ietf-rats-eat-25.html#name-measres-software-measuremen.

No, the main reason for using PSA's software-components in CCA is code reuse (from TF-M to TF-A).

We are currently working on an extension of EAT's Measurement claim to capture software-components semantics (and more) in a more standard-friendly fashion.

[laurencelundblade]

Also, the measurement results claim is not for measurements. It's for reporting whether the measurements compared correctly, not for carrying the measurements themselves.

[gmandyam]

laurencelundblade commented 10 hours ago Also, the measurement results claim is not for measurements. It's for reporting whether the measurements compared correctly, not for carrying the measurements themselves.

The CoSWID payload can allow for carriage of hashes (see https://www.rfc-editor.org/rfc/rfc9393.html#name-the-hash-entry-array), but there is no JSON equivalent. That is why I suggested overloading the ID field in swmeasres as a workaround, but I can see why extending the measurement claim would be desirable.