Re: [Rats] Mixed format token collections (was Re: New RATS)

[Simon Frost <[e-mail]>]

Thanks for pointing out the lack of support for mixed formats Laurence, I’ll raise an issue to be fixed in a future draft.

From: Laurence Lundblade <[e-mail]>
Sent: 03 June 2022 19:39
To: Simon Frost <[e-mail]>
Cc: [e-mail]; Thomas Fossati <[e-mail]>
Subject: Mixed format token collections (was Re: [Rats] New RATS)

EAT takes the view that tokens can be either JSON or CBOR, that any attester can use either format and that composite devices might be made up of sub modules that use either. Therefore in any composition scenario mixed format tokens must be accommodated.

In EAT the top-level token must be either CBOR or JSON, but a nested token doesn’t have to be the same format as the top-level. The CDDL in EAT works and the examples of the various combinations do validate using the “cddl” tool.

EAT collections don’t support mixed devices. It’s hard to tell right now if this will be a problem. Most folks are oriented around CBOR tokens, but JSON is very widely used.

A remedy to this would be to defined EAT collections as a collection of Nested-Tokens. Nested-Token is defined in EAT as the thing holds a nested token. The nested token can be either CBOR or JSON. It also accommodates the discovery of whether it is unsigned (e.g., UCCS), signed (e.g. CWT), or a detached bundle (e.g. DEB). On the CBOR side it does this with tags. On the JSON side there is a type string.

I think the format neutral CDDL in collection would probably be this:

   Collection = {
       ? eat-collection-identifier,
       2* Nested-Token
   }

Personally, I think this should be addressed in EAT collections. If it is not addressed it should be called out that it is not addressed. If it is not addressed there is a risk it will have to be addressed by a separate standard in the future.

LL



(CDDL seems reasonably complete when you define a protocol that is always serialized fully in JSON or fully in CBOR, but it is messy when defining a protocol that nests JSON in CBOR and vice versa.

Most of the CDDL in EAT can be serialized as either JSON or CBOR, but in the case of the top-level and token nesting it wasn’t possible, so there’s specific CDDL for JSON and for CBOR for those. The problem is the .feature control used for the JC<> is subject to the greedy matching of a PEG and will always go JSON when the structure represented is the same in CBOR and JSON.

There’s some more details to what the EAT CDDL did to handle all this that I’m not mentioning here).




On May 30, 2022, at 4:33 AM, Simon Frost <[e-mail]<mailto:[e-mail]>> wrote:

FYI. I’ve just submitted a new draft for a proposed extension to the top level object in EAT.

There’s a full justification in the doc, but as a quick summary, there are difficulties in creating a top level ‘envelope’ object for a multi-token system while remaining compatible with EAT. Given the recent move to fix the list of top level objects but embrace extensions, this approach seems to be an appropriate proposal.

See: https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/ & https://github.com/SimonFrost-Arm/draft-frost-rats-eat-collection

Thanks
Simon

Simon Frost
Senior Principal Systems Solution Architect, ATG, Arm
Mob: [phone]

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. _______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats

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.