Subject: [Cbor] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

From: Henk Birkholz <[email-masked]>
Date: Wed, 4 Mar 2020 19:40:52 +0100

Hi RATS enthusiasts,
hi ACE,
hi CBOR,

in the RATS WG we had a lot of discussions about the nature of an Entity 
Attestation Token (EAT):

 > https://datatracker.ietf.org/doc/draft-ietf-rats-eat/

 > https://github.com/ietf-rats-wg/eat/

A bit of (hopefully useful) context: an EAT is one way to convey 
believable evidence from an Attester (a role residing on a device-like 
entity) to a Verifier (another role defined by RATS - the appraiser of 
evidence). All that is done to provide a Relying Party with "simple 
enough" attestation results generated by the Verifier to enable Relying 
Parties (in general, the remote peer) to make an informed decision about 
whether to put trust in the trustworthiness of that Attester or not. In 
summary, an Attester could be compromised in some way and RATS tries to 
inhibit that Attester to lie about that.

There are a lot of benefits if an EAT (representing evidence) is a CWT:

* we avoid conflicting CWT claim index/label definitions in the IANA 
registry, while being able to use the CWT world of claims (existing, cnf 
soon, and such),
* at first glance it seems simpler to use existing code that can process 
CWT, and
* EAT can simply inherit the well defined COSE signing conventions.

Alas, there is also a very specific drawback:

* sometimes RATS might not want to sign a token (maybe that does render 
it not a token anymore, but rather a ticket. But that is just a rather 
minor detail for now)

Why do RATS sometimes not require a signature around their CWT Claims 
Sets? Because the surrounding secure channel between two entities with 
well established authenticity and trustworthiness can be good enough to 
convey useful CWT Claims Sets without a signature (emphasis on: in RATS).

Now - there are multiple options discussed in the RATS WG how to deal 
with this:

1.) go to COSE and ask for a "null signature",
2.) go to ACE and ask for an "unsigned token" option, or
3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that 
are not signed).

At the last RATS virtual interim there was no certainty how to approach 
this. So this is a call out. COSE, ACE, and CBOR, how would you approach 
this "unsigned CWT Claims Set" requirement?

If one of the three options highlighted above is out of the question, 
please say so (and please elaborate on the why for the sake of helping 
the RATS WG understand why that is not a good idea).

If one of the three options looks like a low hanging fruit & viable, 
please say so (and... you know the drill).

I hope that this email contains all the information required to help the 
RATS WG in this call out to other WGs. If it does not, please say so :)

Last but not least, if there are other relevant WGs or experts that 
could lend opinions or alternatives, let us know.

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Mar 2020 20:58:02 +0100

> 1.) go to COSE and ask for a "null signature",

https://en.wikipedia.org/wiki/Just_Say_No

> 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are not signed).

I believe this is pretty much the same option.
I think ACE would come up with a CBOR tag as the obvious technical solution, and CBOR would suggest exactly that to ACE as the group responsible for CWT (and thus CWT Claims Sets).

Apparently the only technical problem we have is that we don’t have a defined way to mark a naked CWT Claims Set (NCCS) as such; EATs would then be either NCCS or CWTs.
CBOR tags are cheap and solve this problem.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Wed, 4 Mar 2020 13:42:08 -0800

Henk,

Well you have definitely written a message designed to get a response from me.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 10:41 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi RATS enthusiasts,
hi ACE,
hi CBOR,

 > https://github.com/ietf-rats-wg/eat/

A bit of (hopefully useful) context: an EAT is one way to convey believable evidence from an Attester (a role residing on a device-like
entity) to a Verifier (another role defined by RATS - the appraiser of evidence). All that is done to provide a Relying Party with "simple enough" attestation results generated by the Verifier to enable Relying Parties (in general, the remote peer) to make an informed decision about whether to put trust in the trustworthiness of that Attester or not. In summary, an Attester could be compromised in some way and RATS tries to inhibit that Attester to lie about that.

* we avoid conflicting CWT claim index/label definitions in the IANA registry, while being able to use the CWT world of claims (existing, cnf soon, and such),
* at first glance it seems simpler to use existing code that can process CWT, and
* EAT can simply inherit the well defined COSE signing conventions.

* sometimes RATS might not want to sign a token (maybe that does render it not a token anymore, but rather a ticket. But that is just a rather minor detail for now)

Why do RATS sometimes not require a signature around their CWT Claims Sets? Because the surrounding secure channel between two entities with well established authenticity and trustworthiness can be good enough to convey useful CWT Claims Sets without a signature (emphasis on: in RATS).

Now - there are multiple options discussed in the RATS WG how to deal with this:

[JLS] For suggesting this, you should have all of you security credentials revoked.  The idea of deliberately introducing a way to take the security value of COSE signatures to zero is something that should be staked like a vampire and not allowed to continue.  I strongly believe that this is a fatal flaw in the current JOSE security suite and have several times deliberated writing a document to remove the "null signature" from JOSE.  While it is bad to have signatures which are no longer adequately secure, having one with zero security is just brain dead.

[JLS] I don't have a problem with this, I am not sure that I see any reason for it however.  See below.

3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., 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.  

My CWT code base does not make any assumptions about the number or order of COSE security wrapping layers on a token.  It thus looks like

while (true) {
    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; }
    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;}
    if input has a COSE_Signature tag { validate it; set input to the content; save the signer information; continue }
    if input is a map - return input as the set of claims;
    throw an exception because it is not the correct format.
}

This does not require a tag for a naked set of claims and would allow that set of claims to be pass in the same place as a CWT can be passed.  What you are suggesting would require extra code to exist someplace that is going to check for an additional tag.  It is also going to lead to people thinking that this new tag should be legal to place inside of a CWT.  After all it makes more sense to always include it than to just sometimes include it.  This would be more of an issue if an array rather than a map was being used to carry the claims as there would be a chance to not know what type of security wrapper exists.

[JLS END]

At the last RATS virtual interim there was no certainty how to approach this. So this is a call out. COSE, ACE, and CBOR, how would you approach this "unsigned CWT Claims Set" requirement?

If one of the three options highlighted above is out of the question, please say so (and please elaborate on the why for the sake of helping the RATS WG understand why that is not a good idea).

If one of the three options looks like a low hanging fruit & viable, please say so (and... you know the drill).

I hope that this email contains all the information required to help the RATS WG in this call out to other WGs. If it does not, please say so :)

Last but not least, if there are other relevant WGs or experts that could lend opinions or alternatives, let us know.

Viele Grüße,

Henk

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 4 Mar 2020 23:33:25 +0100

Hi Jim,

I'll take a stake into my heart for the group then :) Please note that I 
claim that there is no evidence that I am a vampire nor that I am the 
provenance of option 1.).

I tried to phrase the output of the last virtual interim as neutral as 
possible and I think your reply is to be categorized as:

Option 1.) is "out of the question" as a reply from a COSE WG chair.

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Mar 2020 23:46:15 +0100

> Option 1.) is "out of the question" as a reply from a COSE WG chair.

Option 1.) is "out of the question" as a reply from the author of the COSE specification.
(And at least one other WG member agrees.)

FTFY…

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 4 Mar 2020 23:48:10 +0100

Oh. Yes. Sorry.

Tired and therefore still claiming #notavampire

---

From: Jim Schaad <[email-masked]>
Date: Wed, 4 Mar 2020 15:01:49 -0800

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Henk Birkholz
Sent: Wednesday, March 4, 2020 2:33 PM
To: Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi Jim,

I'll take a stake into my heart for the group then :) Please note that I claim that there is no evidence that I am a vampire nor that I am the provenance of option 1.).
[JLS]  Please note I was planning on staking the idea not the person, I was just going to de-credential you.  However that does raise the question should I bring salt and a sewing kit (mummies) or a gun with a silver bullet (werewolves)?

I tried to phrase the output of the last virtual interim as neutral as possible and I think your reply is to be categorized as:

[JLS] That would be the COSE author and ACE and CBOR WG chair.  I am not a COSE WG chair.  However, I guess I hit all three asks.

Viele Grüße,

Henk

On 04.03.20 22:42, Jim Schaad wrote:
> registry, while being able to use the CWT world of claims (existing, 
> cnf soon, and such),
> * sometimes RATS might not want to sign a token (maybe that does 
> render it not a token anymore, but rather a ticket. But that is just a 
> rather minor detail for now)
> 
> My CWT code base does not make any assumptions about the number or 
> order of COSE security wrapping layers on a token.  It thus looks like
> 
> while (true) {
> I hope that this email contains all the information required to help 
> the RATS WG in this call out to other WGs. If it does not, please say 
> so :)
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Mar 2020 17:43:28 -0500

{ 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-masked]> 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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 6 Mar 2020 00:47:52 +0000

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-masked] on behalf of [email-masked]> wrote:

    

    

        jls> while (true) {

        jls> IT IS
    
    Emphasis mine.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 5 Mar 2020 18:15:54 -0800

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-masked]> On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

-Ned

    

    

    
        jls> while (true) {

        jls> IT IS
    
    Emphasis mine.

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 6 Mar 2020 08:35:11 +0100

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:
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 6 Mar 2020 11:30:52 +0100

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:
>> 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
>>
>> where the CWT is over a claimsMap element.   In this case one could 
>> easily distinguish between the two cases without additional tagging.
>>
>> Jim
>>
>>
>> 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.
>>
>> On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" 
>> <[email-masked] on behalf of [email-masked]> wrote:
>>
>>          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 }

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 6 Mar 2020 07:38:11 -0800

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.

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.

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-masked]> wrote:
> 
> 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.
> 
>> 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
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Jim Schaad <[email-masked]>
Date: Fri, 6 Mar 2020 11:13:10 -0800

Henk,

I want to re-iterate that this is not quite the same no/low cost situation that leads me to say - yes just tag it and be fine.

There is a very high chance that making this change is going to lead one into a situation where they are going to need to change their because people are going to start using this tag all of the time and not just when the claims are bare.  That is the "unsigned CWT Claims Set" could be passed into the a COSE library to be signed and the tag would never be stripped.

There is also a small cost in terms of message size, but I assume that you are willing to absorb that.

Jim

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Thursday, March 5, 2020 11:35 PM
To: Jim Schaad <[email-masked]>; 'Smith, Ned' <[email-masked]>; 'Michael Richardson' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi Jim,

Viele Grüße,

Henk

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Mar 2020 20:24:19 +0100

Hi Jim,

> On 2020-03-06, at 20:13, Jim Schaad <[email-masked]> wrote:
> 
> There is a very high chance that making this change is going to lead one into a situation where they are going to need to change their because people are going to start using this tag all of the time and not just when the claims are bare.  

So it should be made clear that this is not a valid CWT then.

> That is the "unsigned CWT Claims Set" could be passed into the a COSE library to be signed and the tag would never be stripped.

It obviously could, but so could be many other things, which also wouldn’t be a CWT.

Grüße, Carsten

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 6 Mar 2020 19:59:12 +0000

The earlier thread suggested that a naked token could be given to a parser that was programmed correctly and it would 'just work'. But if the definition of a CWT/JWT is that it must have bounding signature, mac, encryption enveloping, then the parser should reject naked tokens (tagged as such or not). 

If the naked token is defined and the map has a tag that indicates it was formed without secure enveloping then the parser should accept it, but the code using the parser needs to find some other way to ensure security. 

If a parser receives a map with both security enveloping and the naked token tag, then it should return both the map and the security envelope context and let the code using the parser decide if the security context satisfies the security requirement.

-Ned

On 3/6/20, 11:24 AM, "RATS on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Jim,

    

    Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Mar 2020 21:04:07 +0100

Hi Ned,

What I was trying to say is that the Unprotected CWT Claims Set (UCCS) is not a CWT, but an UCCS.  So I wouldn’t call it a token (which implies some form of protection to me).  But it is still a useful data structure to carry around.

> On 2020-03-06, at 20:59, Smith, Ned <[email-masked]> wrote:
> 

A CWT decoder would diagnose an UCCS as “not a CWT”.
A CWT/UCCS decoder would diagnose it as “UCCS”.

> If the naked token is defined and the map has a tag that indicates it was formed without secure enveloping then the parser should accept it, but the code using the parser needs to find some other w…

Right.  An UCCS is only a useful assertion if received over a secure channel with the right properties to make it a useful assertion.

> If a parser receives a map with both security enveloping and the naked token tag, then it should return both the map and the security envelope context and let the code using the parser decide if th…

Well, it should diagnose this as “not a CWT” (and not an UCCS either).

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 6 Mar 2020 12:04:34 -0800

From: Laurence Lundblade <[email-masked]> 
Sent: Friday, March 6, 2020 7:38 AM
To: Henk Birkholz <[email-masked]>
Cc: Jim Schaad <[email-masked]>; Smith, Ned <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Rats] [Cbor] [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

 

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

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

 

LL

On Mar 6, 2020, at 2:30 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Viele Grüße,

Henk

Hi Jim,

Jim

-----Original Message-----
From: Ace <[email-masked] <mailto:[email-masked]> > On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

-Ned

On 3/5/20, 2:43 PM, "RATS on behalf of Michael Richardson" <[email-masked] <mailto:[email-masked]>  on behalf of [email-masked] <mailto:[email-masked]> > wrote:

     Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:
     Michael Richardson <[email-masked] <mailto:[email-masked]> >, Sandelman Software Works

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
CBOR mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/cbor

_______________________________________________
RATS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 7 Mar 2020 00:56:34 +0100

Hi Jim,

I never intended an unprotected CWT Claims Set to be a CWT anymore, 
because by definition it would not be one any more, today. I'll try to 
be more explicit and clear: An unprotected CWT Claims Set is not a 
change to CWT, but a new thing based on the definition of CWT Claims Set 
in RFC8392 and that new thing cannot be a CWT. The semantics of the 
registered claims are the same though, because a CWT Claims Set is 
composed of claims defined in the CWT Claims registry.

I also agree with your point that simply replacing CWT with unprotected 
CCS would be nonsense in implementation/practice. Assuming that this 
leads to a very high chance of unprotected CCS taking over all the CWT 
use cases (which should also result in "not a CWT", I think) seems to be 
a bit of a drastic projection, don't you think? Especially, considering 
that CWT are intended be always appropriately identifiable (I assume you 
are very familiar with https://tools.ietf.org/html/rfc8392#section-6). 
Unprotected CCS must be unmistakably & appropriately identifiable as 
what they are, analogously.

I do not quite follow the reasoning why anyone using CWT or intending to 
use CWT today would be "lead into a situation where to change their tag" 
all of the sudden? Could you elaborate on that please?

If you put a tagged unprotected CCS in a COSE that would of course again 
be a violation - that is simply not a viable CWT anymore and a very 
weird way to interpret "unprotected", if I may add. If a minimal set of 
normative requirements (based on the topics discussed previously) are 
added, I am rather certain that implementers will not start to omit COSE 
from CWT Claims Sets and try to send these as CWT. Maybe I am still 
missing something very obvious that you are trying to tell me, though :)

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 6 Mar 2020 18:27:29 -0800

Pretty sure UCCS as Carsten describes below works for me provided:

- All the rules and requirements from CWT explicilty apply except signing/encryption
- It uses the same registry
- There is a tag defined for it
- You get an (untagged) UCCS when you remove all signing and encryption layers

LL

> On Mar 6, 2020, at 12:04 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Ned,
>