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

[Laurence Lundblade]

I have created a PR  against the 
EAT draft for UCCS and UJCS.  I’m not sure this really belongs in the EAT 
draft, but I thought I’d start by putting it there.

LL

P.S. If we were do an update to CWT to accommodate this, it would also be good 
to add CDDL describing CWT. That is another thing I’ve got in the EAT draft, 
that probably belongs elsewhere.



> On Mar 6, 2020, at 6:27 PM, Laurence Lundblade  wrote:
> 
> 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  wrote:
>> 
>> 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  wrote:
>>> 
>>> 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). 
>> 
>> 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 way to ensure security. 
>> 
>> 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 the security context 
>>> satisfies the security requirement.
>> 
>> Well, it should diagnose this as “not a CWT” (and not an UCCS either).
>> 
>> Grüße, Carsten
>> 
>> ___
>> RATS mailing list
>> r...@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
> 
> ___
> 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

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

[Henk Birkholz]

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

On 06.03.20 20:13, Jim Schaad wrote:

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 
Sent: Thursday, March 5, 2020 11:35 PM
To: Jim Schaad ; 'Smith, Ned' ; 'Michael 
Richardson' ; r...@ietf.org; ace@ietf.org; c...@ietf.org
Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a 
CWT or not to be a CWT?

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  On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson ; 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"  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  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 

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

[Carsten Bormann]

Hi Jim,

> On 2020-03-06, at 20:13, Jim Schaad  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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Jim Schaad]

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  
Sent: Thursday, March 5, 2020 11:35 PM
To: Jim Schaad ; 'Smith, Ned' ; 
'Michael Richardson' ; r...@ietf.org; ace@ietf.org; 
c...@ietf.org
Subject: Re: [Cbor] [Ace] [Rats] RATS Entity Attestation Tokens (EAT) - to be a 
CWT or not to be a CWT?

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  On Behalf Of Smith, Ned
> Sent: Thursday, March 5, 2020 4:48 PM
> To: Michael Richardson ; 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" 
>  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  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 

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

[Henk Birkholz]

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  On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson ; 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" 
 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  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 , Sandelman Software Works
  -= IPv6 IoT consulting =-

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Henk Birkholz]

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  On Behalf Of Smith, Ned
Sent: Thursday, March 5, 2020 4:48 PM
To: Michael Richardson ; 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"  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  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 , 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