Re: [Rats] Response to Eliot's major issues with EAT

[Laurence Lundblade <[e-mail]>]

Hi Kathleen,

These recent PRs improve profiles significantly and resulted from Eliot’s (and MCR’s) comments:
Improve introduction to profiles <https://github.com/ietf-rats-wg/eat/pull/215>
Make profile issues more prescriptive <https://github.com/ietf-rats-wg/eat/pull/222>
Add standard constrained device profile <https://github.com/ietf-rats-wg/eat/pull/216>
Clarify how a profile can re-define an EAT claim <https://github.com/ietf-rats-wg/eat/pull/210>
Remove most of section 8.3 on CBOR Serialization, redundant with profiles <https://github.com/ietf-rats-wg/eat/pull/218>
Maybe frame it up this way — EAT is kind of the messenger here.  EAT is not the source of these interoperability characteristics of CWT/JWT, COSE and CBOR. They existed before EAT came along. You can see this in the sections in the JWT, COSE and CBOR documents that talk about implementation variability. They aren’t so forward with the word “interoperability” as I was in the EAT section. Agreed, I could have chosen better words in EAT (wording improved improved intro to profiles PR), but please don’t shoot me for that. 

A  another reason for not shooting is that beyond the message, EAT gives a solution — profiles. Seems like there’s pretty good support for the solution to me.  I’m certainly open to improving profiles as I hope the above PR’s show.


Plus, I’ve made a PR <https://github.com/ietf-rats-wg/eat/pull/223> that adds SPDX and CycloneX as manifest formats. Comments please. This is not an area of expertise for me.

A few more answers below. 

LL




> On Jun 28, 2022, at 4:34 AM, Kathleen Moriarty <[e-mail]> wrote:
> 
> Good morning.  I read through the response and have some comments. 
> ...
> 
>> Section 4.1:
>> 
>>    The nonce MUST have 64 bits of entropy as fewer bits are unlikely to
>>    be secure.  A maximum nonce size is set to limit the memory required
>>    for an implementation.
>> 
>> There are two sides to this equation: the generator of the nonce and
>> the consumer.  How is the generator supposed to know how much memory
>> the consumer has?
> The memory use of the nonce for the consumer is capped by the specification of a maximum size. That maximum is 74 bytes per nonce which is a relatively small amount that any implementation should be able to afford.
> 
> I think it is right to cap the size of the nonce and a few other critical and common claims like UEID, but obviously we can’t cap them all.
> 
> Was there any agreement on this? I just see your response? 

There was no discussion on this. There is only my response.

The way it looks to me is that the document addressed the issue clearly, but Eliot missed the text that addressed it when he commented (we all miss things). There is a clear upper bound specified in the the document (74 bytes for JSON, 64 bytes for CBOR) that will limit the amount memory the consumer needs for the nonce.


> 
>> Section 4.2.1:
>> 
>>    UEIDs are variable length.  All implementations MUST be able to
>>    receive UEIDs that are 33 bytes long (1 type byte and 256 bits).  No
>>    UEID longer than 33 bytes SHOULD be sent.
>> 
>> 256/8 = 8.  8+1 = 9.  I don't understand the parenthetical.
> Clarifications here <https://github.com/ietf-rats-wg/eat/pull/196>. No more need to do math.
> 
> What update was made in the draft? What explains the discrepancy in the byte length? The link didn't explain it or the link isn't the right one anymore.

It turns out Eliot’s math was wrong here. 258 / 8 = 32, not 8 so there was nothing technically wrong with the document.

Even so, I made some wording improvements in the document and took out the text “(1 type byte and 256 bits)”, the reason for the math exercise. I think the new text is more clear.