Subject: [Rats] Review of draft-ietf-rats-eat-01

From: Carl Wallace <[email-masked]>
Date: Mon, 15 Jul 2019 17:31:08 -0400

In section 1.2, it seems odd that the definition of the term "entity" is
limited to things that implement this draft. The last sentence of this
section and the definition of "The Entity" in section 1.3 bear this out.
Generally, 'entity' is used pretty loosely throughout the draft.

In section 1.2, why state "the attestation should be cryptographically
verifiable by the EAT consumer"? Is the intent that some EAT consumers
won't recognize the root of trust or that some EATs need not be
cryptographically verifiable at all? If the former, maybe change from
should to MUST and add qualifying words about root of trust for relying
parties. 

Section 1.4.2 claims to not standardize the "end-end process of
establishing signing attestation key material in the entity, signing the
EAT, and verifying it". However, the election of COSE, for example, does
standardize signing and verifying (see section 4.4 of RFC 8152). Also, the
language here needs to reflect expansion to include JWT.

Section 2 feels incomplete without a definition of claim (as in JWT and
CWT, which include similar definitions as here plus claim) and attestation
(given definition of Attestation Key Material). CWT Claims Set should
probably be renamed Claims Set given expansion to include JWT.

In 3.1, suggest re-phrasing "sent to the entity by any protocol" to
something simpler like "provided to entity".

Should 3.11 be 'nested EATs' or 'aggregated EATs'. In other words, are
these really nested (like signed then encrypted or signed then
countersigned) or are they aggregated into an array then signed? Should
these be wrapped as a bstr (at least for CBOR)?

In 4.4.1, suggest table presentation a la COSE spec.

In 4.4.2, are nested EATs allowed to make different encoding choices?

Throughout the draft, should and must are used in many places where SHOULD
or MUST is probably applicable. Examples include:

	- In section 3.1, the should should be SHOULD
	- In section 3.6, the must instances in bullets 3 and 4 could be MUSTs
	- In section 3.11, the must should be MUST
	- In section 4.3.2, the must instances in bullets 3 and 4 should be MUSTs
	- In section 4.4.2, the must in the last sentence of the second paragraph
should be a MUST (and it may be helpful to enumerate 'all' here)
	- Throughout 4.4.2, there are several instances of 'the server must'.
These must instances should probably be MUSTs and 'the server' should
probably the 'the relying party'.
	- In 5.1, the should should be SHOULD

The draft should probably include claims related to key attestation (I
think this was mentioned on the list as something that would be added).

Typos
- In the intro change "very small IoT device" to "very small IoT devices"
- In section 3 fix formatting of bullets

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 15 Jul 2019 21:04:12 -0700

Hi Carl. Thanks for the comments!

My comments below...

> On Jul 15, 2019, at 2:31 PM, Carl Wallace <[email-masked]> wrote:
> 

Please file a GitHub issue here <https://github.com/ietf-rats-wg/eat/issues>. 

> should to MUST and add qualifying words about root of trust for relying

Please file a GitHub issue here <https://github.com/ietf-rats-wg/eat/issues>. 

> language here needs to reflect expansion to include JWT.

COSE, EAT and CWT do not mandate support for specific algorithms to the degree the interop is guaranteed. For example an entity could implement ECDSA and the relying party could implement the Edwards Curves. This is the intent of this sentence. 

I believe it is up to profile documents to lock this down for guaranteed interop

> probably be renamed Claims Set given expansion to include JWT.

Since an EAT is just a CWT or JWT now, I was thinking the definition from CWT and JWT just carries over. 

> something simpler like "provided to entity”.

OK. 

> these be wrapped as a bstr (at least for CBOR)?

They really are nested. It says:

   The contents of the "eat" claim must be a fully signed, optionally
   encrypted, EAT token.

The nesting is really powerful as it allows multiple subsystems to make EAT tokens (a modern cell phone has lots of CPUs, often well isolated from each other) and for them to be combined and bound to each other.

My thought is that they do not need bstr wrapping. It’s only inputs to hash functions that need that because of the way CBOR decoders work.

If you still think it needs bstr wrapping, please file a GitHub issue.

> In 4.4.1, suggest table presentation a la COSE spec.

That is CDDL. It should not be a table.

But latitude and such should have an “=“. I’ve filed an issue for that. 

> In 4.4.2, are nested EATs allowed to make different encoding choices?

Yes

> 	- In 5.1, the should should be SHOULD

You must use the word should and should use the word must as many times as possible in a sentence. :-)

I’ve heard different philosophies on this and tended to the more mellow ones that imply. I’ve filed an
Issue to resolve this.

> think this was mentioned on the list as something that would be added).

Issue filed a long while ago.

> 
> Typos
> - In the intro change "very small IoT device" to "very small IoT devices”

That is from the -00 draft. It is not in the -01 draft. 

> - In section 3 fix formatting of bullets

The CDDL section header was wrong in 3.3. Is that what you meant?

LL

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

---

From: Carl Wallace <[email-masked]>
Date: Tue, 16 Jul 2019 06:13:48 -0400

From:  Laurence Lundblade <[email-masked]>
Subject:  Re: [Rats] Review of draft-ietf-rats-eat-01

> <snip>
> COSE, EAT and CWT do not mandate support for specific algorithms to the degree
> the interop is guaranteed. For example an entity could implement ECDSA and the
> relying party could implement the Edwards Curves. This is the intent of this
> sentence. 
> 
If the intent is to say algorithms are not specified, say that. This snip
reads much more open ended to me than I think is intended. Not specifying
algorithms is common.
> and JWT just carries over.

The other three were in one or both as well. The absence of claim felt like
a gap, but it's obviously not a big deal either way
> <snip>
> The nesting is really powerful as it allows multiple subsystems to make EAT
> tokens (a modern cell phone has lots of CPUs, often well isolated from each
> other) and for them to be combined and bound to each other.

I understand that nesting is powerful and that encryption or other
signatures can be applied later. However, the language here reads like
aggregation of EATs from various subsystems into a larger composition. Is
nesting really what we want there (vs nesting where additional cryptographic
services are applied)? Even if nesting is appropriate here, is aggregation
something we also want in the toolbox?

> 
> My thought is that they do not need bstr wrapping. It’s only inputs to hash
> functions that need that because of the way CBOR decoders work.
> 
I'd like to hear from others as my consumption of CBOR is limited (but I did
see some interop problems related to bstr usage). Given there are integrity
checks in the embedded pieces, capturing as a bstr seems like the safe play
to me, especially given the potential for differing encoding choices. It
could be that all things that need to be bstr are already handled though.
> But latitude and such should have an “=“. I’ve filed an issue for that.

This is what caught my eye, but I like the COSE presentation better:-)
> that imply. I’ve filed an

I always thought this was drawn along points where interop was relevant and
I tried to limit the places I cited to those.

> <snip>
Yes, I started reading the wrong one. I'm surprised I only missed this
comment when I realized I started with the wrong draft.
> The CDDL section header was wrong in 3.3. Is that what you meant?

I meant: "Note also: * Any claim defined for CWT or JWT may be used in an
EAT
   including those in the CWT [IANA.CWT.Claims
<https://tools.ietf.org/html/draft-ietf-rats-eat-01#ref-IANA.CWT.Claims> ]
and JWT IANA
   [IANA.JWT.Claims
<https://tools.ietf.org/html/draft-ietf-rats-eat-01#ref-IANA.JWT.Claims> ]
claims registries.  * All claims are optional * No
   claims are mandatory * All claims that are not understood by
   implementations MUST be ignored"

Maybe it's presented this way to entice the reader to read it in a super
fast legalese voice:-)

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 16 Jul 2019 10:33:07 -0700

below...

> On Jul 16, 2019, at 3:13 AM, Carl Wallace <[email-masked]> wrote:
> 
> 
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> If the intent is to say algorithms are not specified, say that. This snip reads much more open ended to me than I think is intended. Not specifying algorithms is common.

It is also how the public key is obtained and trust in it is established. We have lots of choices including X.509 hierarchies, some web service, some new service… For example there are extensions to COSE in the works for X.509 now.

> I understand that nesting is powerful and that encryption or other signatures can be applied later. However, the language here reads like aggregation of EATs from various subsystems into a larger composition. Is nesting really what we want there (vs nesting where additional cryptographic services are applied)? Even if nesting is appropriate here, is aggregation something we also want in the toolbox?

I think we want both aggregation and nesting.

To be sure it is clear, nesting means you take a fully formed and signed EAT token and put it in another fully formed and signed EAT token. One of the reasons this might happen is that a device (e.g. a car) is assembled out of multiple components that can’t be modified by the end manufacturer. Subcomponents are capable of generating EATs. Some final component (controlled by the car maker) puts them all together in one token for the car the signature of which binds all the sub tokens together.

The submods claim is the proposed way to do aggregation of claims where the subcomponent set of claims is not separately signed.

> I'd like to hear from others as my consumption of CBOR is limited (but I did see some interop problems related to bstr usage). Given there are integrity checks in the embedded pieces, capturing as a bstr seems like the safe play to me, especially given the potential for differing encoding choices. It could be that all things that need to be bstr are already handled though. 

Yes, I think all things that need bstr are wrapped through compliance with COSE.

> This is what caught my eye, but I like the COSE presentation better:-)

CDDL was not published when COSE was created so the CDDL in the COSE spec is non-normative. 

I am trying to do differently here and make the CDDL normative to specify the information model and allow the data model to be derived for CBOE and JSON.

I’ve fixed the missing “=“. Thanks for catching it.

>> The CDDL section header was wrong in 3.3.. Is that what you meant?
> 
> 
> I meant: "Note also: * Any claim defined for CWT or JWT may be used in an EAT
>    including those in the CWT [IANA.CWT.Claims <https://tools.ietf.org/html/draft-ietf-rats-eat-01#ref-IANA.CWT.Claims>] and JWT IANA
>    [IANA.JWT.Claims <https://tools.ietf.org/html/draft-ietf-rats-eat-01#ref-IANA.JWT.Claims>] claims registries.  * All claims are optional * No
> Maybe it's presented this way to entice the reader to read it in a super fast legalese voice:-)

I’ve fixed this.

LL

---

From: Carl Wallace <[email-masked]>
Date: Tue, 16 Jul 2019 14:22:43 -0400

>> I understand that nesting is powerful and that encryption or other signatures
>> can be applied later. However, the language here reads like aggregation of
>> EATs from various subsystems into a larger composition. Is nesting really
>> what we want there (vs nesting where additional cryptographic services are
>> applied)? Even if nesting is appropriate here, is aggregation something we
>> also want in the toolbox?
> 
> To be sure it is clear, nesting means you take a fully formed and signed EAT
> token and put it in another fully formed and signed EAT token. One of the
> reasons this might happen is that a device (e.g. a car) is assembled out of
> multiple components that can’t be modified by the end manufacturer.
> Subcomponents are capable of generating EATs. Some final component (controlled
> by the car maker) puts them all together in one token for the car the
> signature of which binds all the sub tokens together.
> 
> The submods claim is the proposed way to do aggregation of claims where the
> subcomponent set of claims is not separately signed.

So that leaves the question of aggregation of signed EATs. There's enough
flexibility that can be added later if it's not viewed as necessary now but
turns out to be useful later. The CMS ContentCollection is what I was
thinking of.

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 22 Jul 2019 17:55:46 +0000

Right now the scope of RATS focuses on Attester to Verifier and Verifier to Relying Party flows. Flows from Asserter (supply chain entity) to Verifier are out of scope currently. The use cases for counter signing and multiple signing may relate more to supply chain than Attester to Verifier.

Aggregation (if I’m not mistaken) is when a Verifier communicates to a Relying Party. A simple aggregation might be to “allow” or “deny” (or maybe I’m misunderstanding what is meant by aggregation).

On 7/16/19, 2:23 PM, "RATS on behalf of Carl Wallace" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

<snip>

   encrypted, EAT token.

So that leaves the question of aggregation of signed EATs. There's enough flexibility that can be added later if it's not viewed as necessary now but turns out to be useful later. The CMS ContentCollection is what I was thinking of.

<snip>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 22 Jul 2019 14:33:55 -0400

The intent of aggregation is within an entity. For example a phone contains a secure element, a TEE and a Linux kernel all supplied by different vendors. The secure element generates an EAT its keys. The TEE generates an EAT with its keys. The Linux kernel generates an EAT that aggregates the two previously and signs with the Linux kernel’s keys.

LL

> On Jul 22, 2019, at 1:55 PM, Smith, Ned <[email-masked]> wrote:
> 
> On 7/16/19, 2:23 PM, "RATS on behalf of Carl Wallace" <[email-masked] <mailto:[email-masked]> on behalf [email-masked] <mailto:[email-masked]>> wrote:
>  
>> 
>> <snip>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 22 Jul 2019 19:25:38 +0000

I’ve seen this concept described as “component nesting” and “device composition”. Not sure there is an accepted industry term for it. Maybe it makes sense to consider adding it to a terminology section in the architecture?

On 7/22/19, 2:34 PM, "Laurence Lundblade" <[email-masked]<mailto:[email-masked]>> wrote:

LL

On Jul 22, 2019, at 1:55 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

On 7/16/19, 2:23 PM, "RATS on behalf of Carl Wallace" <[email-masked]<mailto:[email-masked]> on behalf [email-masked]<mailto:[email-masked]>> wrote:

<snip>

   encrypted, EAT token.

<snip>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2019 12:39:25 -0400

Smith, Ned <[email-masked]> wrote:
    > Right now the scope of RATS focuses on Attester to Verifier and
    > Verifier to 
    > Relying Party flows. Flows from Asserter (supply chain entity) to Verifier
    > are out of scope currently. The use cases for counter signing and multiple
    > signing may relate more to supply chain than Attester to Verifier.

(I don't know yet if I agree with you)

Should the use case document explain use cases like this, in order to clearly
mark them as out-of-scope?  (And to avoid repeating the conversation)?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-