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 <ace-boun...@ietf.org> On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson <mcr+i...@sandelman.ca>; r...@ietf.org;
ace@ietf.org; c...@ietf.org
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"
<rats-boun...@ietf.org on behalf of mcr+i...@sandelman.ca> 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 <i...@augustcellars.com> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
CBOR mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/cbor
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
