Re: [Rats] New RATS

["Smith, Ned" <[e-mail]>]

>> Should a $$EAT-CBOR-Tagged-Token or $$EAT-CBOR-Untagged-Token be signed for integrity protection – for example using COSE/JOSE?
>I’m not sure I fully understand the question, but I don’t think that all tokens require a top level signer, for reasons expressed in this doc (and in UCCS).
I was looking for a definitive starting point for a signed / unsigned object that contains Evidence. It’s OK to say it is a $$EAT-CBOR-[Un]Tagged-Token, but this is an extensibility socket that could be extended to something else (hence isn’t the concrete starting point). If COSE/JOSE is the starting point, then I at least know where to put the Tagged-Collection payload if it should be signed.

It seems there should be conventions for how to extend at a top level socket? For example, MUST/MUST NOT an extension begin with a CBOR global tag and MUST there be a registered content type definition? And should global tagging disambiguate the content that is intended to be used as Evidence (or some other conceptual message type envisaged by the RATS Architecture)?

Not sure requiring collections to start with 2 entries makes sense since a parser that supports collections can already support singletons vs. having to find a singleton-only parser.

Thx,
Ned



From: Simon Frost <[e-mail]>
Date: Wednesday, June 1, 2022 at 12:36 AM
To: "Smith, Ned" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Thomas Fossati <[e-mail]>
Subject: RE: [Rats] New RATS

Ned
> The RATS Arch doesn’t use the term ‘Attestee’…
That’s a typo, thanks for pointing it out, I’ll change it to Attester.

> I didn’t see a reference to DEB objects. Could that be included?
DEB objecta are included, but not deeply discussed because I’ve not really seen a use case for them yet. There is a reference to DEBs as collection entries both in the text and the CDDL


> Should a $$EAT-CBOR-Tagged-Token or $$EAT-CBOR-Untagged-Token be signed for integrity protection – for example using COSE/JOSE?

I’m not sure I fully understand the question, but I don’t think that all tokens require a top level signer, for reasons expressed in this doc (and in UCCS).



Thanks for the review

Simon

From: Smith, Ned <[e-mail]>
Sent: 31 May 2022 18:18
To: Simon Frost <[e-mail]>; [e-mail]
Cc: Thomas Fossati <[e-mail]>
Subject: Re: [Rats] New RATS

Simon,
A couple of comments. The RATS Arch doesn’t use the term ‘Attestee’. Would it be appropriate to use ‘Attester’ or possibly ‘Target Environment’ if the objective is to refer to the environment (object) from which claims are collected by an ‘Attesting Environment’?

I didn’t see a reference to DEB objects. Could that be included?


Should a $$EAT-CBOR-Tagged-Token or $$EAT-CBOR-Untagged-Token be signed for integrity protection – for example using COSE/JOSE?



Thanks,

Ned


From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Simon Frost <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 30, 2022 at 4:34 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Thomas Fossati <[e-mail]<mailto:[e-mail]>>
Subject: [Rats] New RATS

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.
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.