From: Laurence Lundblade <[email protected]> Sent: Friday, March 6, 2020 7:38 AM To: Henk Birkholz <[email protected]> Cc: Jim Schaad <[email protected]>; Smith, Ned <[email protected]>; Michael Richardson <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [Rats] [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? So far, there are three things we have turned up in work on EAT that we would like considered as changes to CWT. 1) Naked CWT’s, probably tagged The point of the tag would be for use in protocols where you can’t tell a naked CWT is a CWT by the context of the protocol. So far we seem to always assign a tag to new CBOR data structures for this purpose. For naked CWT’s, it seems we really should have the tag, even if it makes Jim’s code larger. 2) Disallow floating point dates Right now CWT allows dates like the expiration date to be floating point. The only use of floating point dates is fractional seconds and dates so large they are not human time scale. As it stands a CWT decoder MUST implement floating point. This is a substantial burden for no good reason at all. One option here is an incompatible change to these data items. Another is to define new integer-only data items (new labels/keys) for the same data items. [JLS] As far as I am concerned this is just a profiling effort. I also agree that it makes almost no sense to use floating point for dates in almost all cases where CWT claims have been created. 3) Claims Characteristics for new registered claims A lot of people had a lot of opinions and points on what data formats and types and such were used for claims back in 2019 in EAT. I (hopefully) captured most of that in some recommendations for claims characteristics. Text is currently here in a PR against the EAT draft <https://github.com/ietf-rats-wg/eat/pull/7> , but it seems it really should be for all CWT claims. [JLS] After one fast read, I think that these are good generic suggestions, however I disagree that this should be true for all CWT claims. There is an explicit expert review section that is designed for the registration of extremely explicit claims that will violate these guidelines. jim I don’t know if there are more things EAT would like to change in CWT. Or maybe there are other uses of CWT that would like to change it. I proposed that EAT be an update to the CWT RFC. Dave Thaler said they should probably be separate from EAT and handled in the ACE WG and that made sense to most of us. Seems to me that a new RFC that either updates or obsoletes 8392 would be the thing to do, but maybe there are other ways. LL On Mar 6, 2020, at 2:30 AM, Henk Birkholz <[email protected] <mailto:[email protected]> > wrote: Please let me correct myself: My proposal is to simply assign a single CBOR tag for unsigned (aka "naked") CWT Claims sets. I wrote "EAT" Claims Set before and that made me loose the perspective that an EAT is a CWT (I should read my own subject more often...). I think this is useful outside of RATS as well and will start a corresponding draft in RATS to create a more tangible proposal that elaborates on motivation & background: as with YANG modules, CBOR tags can be defined in any WG. There are multiple benefits to this approach: * parsers can choose to ignore tags in any case, * it is the least invasive approach (next to doing nothing), * we will not be the ones that attempt to reopen RFC8392, and * we detach this effort from progressing EAT as it is CWT-related. Viele Grüße, Henk On 06.03.20 08:35, Henk Birkholz wrote: Hi Jim, from an implementation point of view that is fine. To quote Carsten here "tags are cheap" and you would have to parse the whole structure to make sure it is an EAT Claims Set. My point is, it does not hurt to register a CBOR tag for an unsigned EAT Claims Set that adheres to the some content definitions as EAT, but that is not signed via a COSE array. In contrast, in most cases it does help, I think, and enables a clear semantic equivalence for the content. Viele Grüße, Henk On 06.03.20 03:15, Jim Schaad wrote: I would not claim that a collection of CWT claims is a CWT. I would agree that a CWT does require that some security be applied. I was instead making the argument that there was no need to have a special marking for the collection as oppose to the CWT since it is possible to distinguish the cases apart. In CDDL I would put something like claimsMade = CWT / claimsMap where the CWT is over a claimsMap element. In this case one could easily distinguish between the two cases without additional tagging. Jim -----Original Message----- From: Ace <[email protected] <mailto:[email protected]> > On Behalf Of Smith, Ned Sent: Thursday, March 5, 2020 4:48 PM To: Michael Richardson <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT? My interpretation of this thread was that CWT spec requires at least one of (COSE_Encrypt, COSE_MAC, COSE_Signature) or it isn't valid COSE. That implies the parser should never get to "if input is a map" as it isn't valid COSE. If the above interpretation isn't true then the 'do nothing' option is best. -Ned On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]> > wrote: { I found Jim's very interesting email very hard to read without good quoting, I'm repeating the important part } henk> 2.) go to ACE and ask for an "unsigned token" option, or Jim Schaad <[email protected] <mailto:[email protected]> > wrote: jls> I don't have a problem with this, I am not sure that I see any jls> reason for it however. See below. henk> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., henk> that are not signed). jls> I don't see any difference between this and option #2 jls> 4.) Just write your CWT code in a sensible manner. jls> My CWT code base does not make any assumptions about the number or jls> order of COSE security wrapping layers on a token. It thus looks jls> like jls> while (true) { jls> if input has a COSE_Encrypt tag { decrypt it; set input to the content; save the encryption information if needed e.g. shared key authentication; continue; } jls> if input has a COSE_MAC tag { validate it; set input to the content; save the MAC information if needed e.g. shared key authentication; continue;} jls> if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue } jls> if input is a map - return input as the set of claims; jls> throw an exception because it is not the correct format. jls> } jls> This does not require a tag for a naked set of claims and would jls> allow that set of claims to be pass in the same place as a CWT can jls> be passed. What you are suggesting would require extra code to jls> exist someplace that is going to check for an additional tag. jls> IT IS jls> ALSO GOING TO LEAD TO PEOPLE THINKING THAT THIS NEW TAG SHOULD BE jls> LEGAL TO PLACE INSIDE OF A CWT. After all it makes more sense to jls> always include it than to just sometimes include it. Emphasis mine. So your suggestion is to do nothing. I also wondered why that wouldn't work, but I hadn't written enough code to ask the question intelligently. -- Michael Richardson <[email protected] <mailto:[email protected]> >, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Ace mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace _______________________________________________ CBOR mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cbor _______________________________________________ RATS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rats
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
