Subject: [Rats] EAT Review Comments

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Dec 2021 11:49:10 +0000

Hi all,

As promised, here are some high-level review comments, which are most important to us:

- The document would benefit from a normative language. Think in the following way: What does a party creating a claim and a party verifying the claim have to do in order to ensure interoperability. Use SHOULDs and MAYs when you can give the reader a decision path.

- Don't put comments into the CDDL since the same text is already in the draft. You are essentially putting the text in the document twice. This will reduce the size of the document.

- Normative vs. informative references: If you need to read a specification as a developer in order to implement a listed claim then this reference is normative. For example, the location claim cannot be implemented without having to open the W3C geolocation API. Hence, that reference becomes normative.

- Aim for consistent use of terminology. An example is the use of "entity", "entity/device", "device/entity", "entity/client device", "device entity", "entity or submod", "entity (typically a device)". In Section 1.4 you seem to suggest that "entity" is the right term. But throughout the text you mix the terms. The  EAT draft should adopt the terminology established in the architecture doc, which would be "attester" rather than "entity". Section 2 should import the vocabulary from the architecture document **by reference** and establish the aliasing "attester" = "entity" (and maybe = "device") by saying something along these lines: "attester and entity are used interchangeably in this document".

- The spec is long and there is a lot of feature creep. This makes it appear very complex. I believe there are two reasons for this, namely (a) there is suddenly a lot of architectural discussion in this document. This is unnecessary given that there is a separate architecture document. There is no need to repeat the content here as well. Do you expect a reader to go through the architecture document before reading this document? (b) There are claims in this specification that may sound good but I wonder whether they are ready for prime time already. This document does not need to collect all claims that relate to attestation. Most likely there is not much experience implementing some of these claims either, which reduces the quality of the specification. Sometimes less is just more.

- Unprotected CWT Claims Sets (UCCS): I see UCCS as an architectural aspect. Normally, the implications for the EAT spec should be quite small. The purpose of the EAT spec is to define claims that go into a CWT. EAT does not mandate a specific way to protect the claims (digital signature, MAC, encryption, etc.) then UCCS has not much implication besides a short mention in the security consideration section. Given that UCCS is a separate working group document we would remove Section 4 along with any reference to UJCS.

Ciao
Hannes & Thomas

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Dec 2021 08:25:02 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > - The spec is long and there is a lot of feature creep. This makes it
    > appear very complex. I believe there are two reasons for this, namely
    > (a) there is suddenly a lot of architectural discussion in this
    > document. This is unnecessary given that there is a separate
    > architecture document. There is no need to repeat the content here as
    > well. Do you expect a reader to go through the architecture document
    > before reading this document? (b) There are claims in this
    > specification that may sound good but I wonder whether they are ready
    > for prime time already. This document does not need to collect all
    > claims that relate to attestation. Most likely there is not much
    > experience implementing some of these claims either, which reduces the
    > quality of the specification. Sometimes less is just more.

Thank you for articulating this.
I feel the same way.
I think that the document could be significantly shorter.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 7 Dec 2021 13:51:37 -0800

First of all, I really appreciate the thorough reading. This is probably the first deep substantive set of comments ever made on EAT.

> On Dec 7, 2021, at 3:49 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> - Aim for consistent use of terminology. An example is the use of "entity", "entity/device", "device/entity", "entity/client device", "device entity", "entity or submod", "entity (typically a device)". In Section 1.4 you seem to suggest that "entity" is the right term. But throughout the text you mix the terms. The  EAT draft should adopt the terminology established in the architecture doc, which would be "attester" rather than "entity". Section 2 should import the vocabulary from the architecture document **by reference** and establish the aliasing "attester" = "entity" (and maybe = "device") by saying something along these lines: "attester and entity are used interchangeably in this document”.

Agree about most of the above and will work through it.

> 
> - The spec is long and there is a lot of feature creep. This makes it appear very complex. I believe there are two reasons for this, namely (a) there is suddenly a lot of architectural discussion in this document. This is unnecessary given that there is a separate architecture document. There is no need to repeat the content here as well. Do you expect a reader to go through the architecture document before reading this document?

OK. I will work to remove some of this.

A few hints and examples of what to remove would be helpful.  

I already made one pass at removing text from EAT that was covered in RATS architecture.  (EAT -01 actually predates RATS architecture, so there was lots of stuff to remove).

> (b) There are claims in this specification that may sound good but I wonder whether they are ready for prime time already. This document does not need to collect all claims that relate to attestation. Most likely there is not much experience implementing some of these claims either, which reduces the quality of the specification. Sometimes less is just more.

Definitely agree that less can be more.

Top of my list of claims to remove are uptime and boot seed.

The other claims have a strong purpose in my mind. They are necessary to describe the device and the attestation results.

- Maybe the DLOA’s claim could be removed, but I think it is important for RP’s to be able to know about certification status in attestation results.

- The description of SW manifests and measurements is a bit difficult, but I’ve tried make use of the best things out there and be flexible / pluggable since it is a moving target.

- The set of UEID/SUEID, HW OEM ID, HW Class and HW Version is what is necessary to identify HW.

There is similar reasoning for the other claims. 

Which claims would you remove?

> - Unprotected CWT Claims Sets (UCCS): I see UCCS as an architectural aspect. Normally, the implications for the EAT spec should be quite small. The purpose of the EAT spec is to define claims that…

There’s strong logic here:
— RATS architecture explicitly calls out composite attestation
— A submodule can be a nested EAT to implement composite attestation
— A nested EAT can be a CWT, UCCS  or DEB
— The CDDL that specifies a nested EAT submodule thus must mention UCCS

So a UCCS is a claim that goes into a CWT. I think UCCS, particularly CDDL for UCCS, must be included because of this.

We decided a long time ago that EAT would support JSON in a normative way. The logic continues:
— An EAT can be a JWT
— EAT specifies claims that go into a JWT (and a CWT)
— A submodule can be an  nested EAT
— A submodule can then be a JWT in a CWT or a CWT in a JWT

If we stay with the idea that EAT has normative support for JSON, then I believe the above logic holds and specification of the above is necessary.

I don’t think we realized the implications of EAT formally supporting JSON/JWT in a normative way a few years back. I certainly didn’t. Trying to write and validate the CDDL for both JSON and CBOR, JWT and CWT brought it to light. Maybe it’s too much? What do people think about completely removing normative JSON support from EAT?

Now on to UJCS. The decision on it can be separate from the above logical conclusion, partly because JWT has the (awkward) null algorithm mode.

My main logic about UJCS is:
— JSON is far more popular than CBOR
— If there is reason to specify UCCS, then there is more reason to specify UJCS
— This also lines up with EAT being used for attestation results, which are likely to be JSON.

Maybe UJCS can be removed from EAT, but it seems like it should then exist somewhere else.

There is still a logic and power in bringing all this highly related stuff (CWT, JWT, UCCS and UJCS) together especially when you try to write CDDL for it where individual claims can be JSON or CBOR and individual tokens can be JSON or CBOR. This goes back to composite devices described in RATS architecture.

LL

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 9 Dec 2021 10:45:23 +0000

Hi Laurence,

Thanks for your quick response.

A few responses below:

-----Original Message-----
From: Laurence Lundblade <[email-masked]>
Sent: Tuesday, December 7, 2021 10:52 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] EAT Review Comments

[Hannes] I can go through the document again and focus on identifying on what could be simplified.

[Hannes] I don't know the history of the DLOA and the SW manifests claim but I wonder whether people will use them in the near future.

There’s strong logic here:
— RATS architecture explicitly calls out composite attestation — A submodule can be a nested EAT to implement composite attestation — A nested EAT can be a CWT, UCCS  or DEB — The CDDL that specifies a nested EAT submodule thus must mention UCCS

[Hannes] I wonder whether everything in the RATS architecture should be covered in the EAT specification for several reasons:
- First, the EAT spec becomes complex and harder to read.
- Second, the RATS architecture enumerates everything that came into someone's mind or, as we later learned, can be patented.
- Given the status of the industry with attestation I believe it will take a while to even get the basic functionality deployed. For more complex use cases it can easily take several years.

We decided a long time ago that EAT would support JSON in a normative way. The logic continues:
— An EAT can be a JWT
— EAT specifies claims that go into a JWT (and a CWT) — A submodule can be an  nested EAT — A submodule can then be a JWT in a CWT or a CWT in a JWT

[Hannes] JSON may be something that is support from the verifier to the relying party because those are probably HTTP-based API. I am wondering whether it would make sense to just have a CBOR-based encoding for the attester-produced EAT tokens. Then, the JSON-based functionality could be published in a companion document, if needed.

My main logic about UJCS is:
— JSON is far more popular than CBOR
— If there is reason to specify UCCS, then there is more reason to specify UJCS — This also lines up with EAT being used for attestation results, which are likely to be JSON.

[Hannes] IMHO the UCCS functionality should be described in the UCCS draft. I doubt that JSON makes a sense for the community proposing it. I got the impression that this is something from the Smart Card/Secure Elements community and those would hopefully use CBOR rather than JSON.

Ciao
Hannes

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 10 Dec 2021 08:44:40 +0100

Hi Hannes & Laurence,
hi list,

a few essential comments in-line.

Viele Grüße,

Henk

>> - The document would benefit from a normative language. Think in the following way: What does a party creating a claim and a party verifying the claim have to do in order to ensure interoperabilit…

As long as additional normative statements are in support of 
deterministic and interoperable evidence generation and appraisal I am 
all for that. I would like to carefully highlight that phrasing such 
statements is a delicate procedure will cost additional time to get 
aligned as WG consensus. In general, I see the necessity and in favor of 
reviewing proposal for these.

>> - Don't put comments into the CDDL since the same text is already in the draft. You are essentially putting the text in the document twice. This will reduce the size of the document.

Yes. Self-descriptive CDDL + English text for human readers outside the 
CDDL elaborating on type semantics is the right direction.

> Agree about most of the above and will work through it.

It would be nice to have a review'able track of issues for each type of 
inconsistency here. But speaking from experience that is the way how 
Laurence works on the document for quite some while now (kudos), so I am 
not worried by that, actually, still I felt the need to highlight that.

> [Hannes] I can go through the document again and focus on identifying on what could be simplified.

Thanks Hannes. I'll review your input and cross-check the proposals.

>> (b) There are claims in this specification that may sound good but I wonder whether they are ready for prime time already. This document does not need to collect all claims that relate to attestat…

Personally, I was under the impression that the content of -08 was 
already good enough.

My biggest point of concern is the scope creep into JWT.

EAT was intended to be a CWT (more on that detail below). The 
implementation complexity of including JWT now is kind of mind-boggling. 
I have been for a while and will continue to be in strong support of 
moving JSON encoding related normative text out of the EAT core doucment 
to supplemental EAT document.

Fundamentally, I am still opposed to EAT being a CWT. It allows to 
include any kind of CWT claims from an increasingly growing CWT Claims 
registry. I am allowed to include a nonce and a cnonce Claim 
simultaneous due to that. Or simply mix an exi Claim in. How shall an 
implementation act on that? That is a valid EAT composition. Is "ignore 
what you do not understand" the strategy here? That is not a really 
useful approach, if your goal is to establish an interoperable way to 
assert trustworthiness. I'd very much prefer a better scoped usage 
scenario for EAT for RATS by making an EAT something more specialized 
than a CWT (on the CBOR tag level). Maybe someone can explain to my why 
this is not an implementer's nightmare as I might miss something obvious 
here.

> [Hannes] I don't know the history of the DLOA and the SW manifests claim but I wonder whether people will use them in the near future.

As rule of a thumb, I'd simple prune anything that was added after -08. 
Maybe we should go from that demarcation line, enumerate the Claim names 
of everything that was added after and then see, if there are candidates 
in that list that the WG is interested in keeping.

I am not saying to abandon the "pruned" Claims, but to put them into the 
next document. All implementation that I know of are based on -08. I 
don't want to sound over-confident here... maybe it's -09 effectively... 
my point is: divide an conquer.

> - Given the status of the industry with attestation I believe it will take a while to even get the basic functionality deployed. For more complex use cases it can easily take several years.

Yes. This. I am in strong support (+1) of moving UCCS implications 
solely into the Security Consideration Section.

> We decided a long time ago that EAT would support JSON in a normative way. The logic continues:

I am not so sure how the group consensus really looks like here. Maybe 
this calls for a dedicated question to the list. Again, I am not talking 
about abandoning the whole JSON nested in CBOR nested in JSON idea. I 
just think as part of the EAT core document it is adding an 
insurmountable amount of complexity that could severely hamper adoption 
in the end.

> [Hannes] JSON may be something that is support from the verifier to the relying party because those are probably HTTP-based API. I am wondering whether it would make sense to just have a CBOR-based…

+1 for companion document, +1 for if needed.

> [Hannes] IMHO the UCCS functionality should be described in the UCCS draft. I doubt that JSON makes a sense for the community proposing it. I got the impression that this is something from the Smar…

+1

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 Dec 2021 07:57:41 +0000

Hi Henk,

> this is not an implementer's nightmare as I might miss something obvious

We are long past the point of deciding that an EAT is a CWT with special claims. Companies have spend a lot of resources implementing it that way. Practically, there is no problem since you will not randomly add claims to an EAT. As stated in the draft, a profile needs to determine what claims must be present and what to do with optional claims. Then, this is not an issue at all.

Can you have a look at how this works in existing implementations and why this is not a problem at all.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 10 Dec 2021 13:08:12 +0000

Let me answer the last point in my email below, namely how do we deal with the claims in our implementation.

We have two places where we store our code for the attestation functionality used by the attester. One is in the Trusted Firmware-M, which is used on M-class devices, and another one is in Trusted Firmware-A, which is used in A-class devices. The architecture of A and M class is different but we managed to use the same codebase in both projects but there are a few differences, namely
* how the interaction between the normal and the secure world works, and
* how the underlying software (bootloader and low level OS) exposes the measurements of software up to the attestation service.

The attestation service, in both cases, waits for incoming requests to provide an EAT back to the calling party. The request comes with a nonce and that nonce is included in the EAT. The attestation service then populates the EAT with claims, as we describe in https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-08. This document describes how to populate the claims so that they make sense in the A- and M-class environment.

Could an implementer add another claim to our implementation? Sure. For example, a location claim would be an option. Obviously it only makes sense if you have a GPS receiver attached to your device and that GPS receiver is accessible to the attestation service. This would not be something most devices have but some may. We don't provide an implementation for it right now and a developer would have to enhance the code.

Here is the code for the trusted services in TF-A:
https://git.trustedfirmware.org/TS/trusted-services.git/?h=integration
(Note the branch "integration")

Here is the code for TF-M:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/

There are several other services included in these two repos besides the attestation service. I have spoken about the bigger picture at this event: https://www.youtube.com/watch?v=rqbYig3aXg0

Ciao
Hannes

PS: FWIW Our code uses t_cose, qcbor and the PSA Crypto API under the hood.

-----Original Message-----
From: Hannes Tschofenig
Sent: Friday, December 10, 2021 8:58 AM
To: Henk Birkholz <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: RE: [Rats] EAT Review Comments

Hi Henk,

> moving JSON encoding related normative text out of the EAT core
> doucment to supplemental EAT document.

> implementation act on that? That is a valid EAT composition. Is
> "ignore what you do not understand" the strategy here? That is not a
> really useful approach, if your goal is to establish an interoperable
> way to assert trustworthiness. I'd very much prefer a better scoped
> usage scenario for EAT for RATS by making an EAT something more
> specialized than a CWT (on the CBOR tag level). Maybe someone can
> explain to my why this is not an implementer's nightmare as I might
> miss something obvious here.

Ciao
Hannes

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 10 Dec 2021 10:11:46 -0800

Below...

> On Dec 9, 2021, at 11:57 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Henk,
> 
> You write:
> 

Yes, I think we are long past on that decision.

The flexibility is necessary for the broad range of use cases, the ones listed in RATS Architecture and more. I doubt we could converge on one set of claims.

We have profiles to address the problem too many and confusing claims.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 13 Dec 2021 10:19:51 +0100

Hi Laurence,
hi Hannes,

(Hannes, weirdly I believe I did not receive your reply, but I assume it 
is quoted in the msg below)

I can accept that we are past that point :-) Please consider this a me 
lamenting about bad choices in the past that we have to live with today. 
I also see the argument that you can "reuse" CWT code (and then teach it 
how to treat as an EAT with extra code).

Viele Grüße,

Henk

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 13 Dec 2021 10:43:01 +0000

Hi list,

My thoughts below

Best regards
Jeremy

On 10/12/2021, 07:45, "RATS" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Hannes & Laurence,
hi list,

Viele Grüße,

Henk

> - Maybe the DLOA’s claim could be removed, but I think it is important for RP’s to be able to know about certification status in attestation results.

[JOD] -1 on removing DLOA claim – it would otherwise go into a GlobalPlatform profile anyway, but I see the applicability as being much broader than the GlobalPlatform ecosystem – it allows a claim about a 3rd party security certification (e.g. PSA Certified / SESIP L3) which can be hosted on any webserver.

[JOD] There are arguments both ways, but I could live with this. It does mean we (UCCS editors) should accelerate progress towards publication of the UCCS draft.

[JOD] My view is that there are two distinct use-cases here:

  *   Attester conveying attestation evidence to a Verifier (likely to be CBOR in most cases)
  *   Verifier conveying results to a Relying Party (likely to be JSON in most cases)

I am not fully convinced that the complexity of allowing an EAT to be almost any arbitrary composition of JSON and CBOR components is really necessary, and maybe it is reasonable to require that an EAT is composed of either CBOR or JSON components. Doing otherwise has potential to make all components in the chain (Attester, Verifier, RP) quite complex, and I’m generally keen on simplicity.

However I do think the need for support of JSON by EAT is widely supported by the group

[JOD] I would rather see document reach consensus and get published sooner – if removing JSON support helps this goal, and I think it does, I’m +1.

+1

[JOD] There is a clear use-case for UCCS in the GlobalPlatform/Smartcard world. If it is not in the IETF document, GlobalPlatform would define it in a profile. We brought it to IETF because it seemed like there might be use-cases beyond GlobalPlatform.

+1 on JSON community can create UJCS , (+1) if required, when work on JSON EAT gets started.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Dec 2021 11:23:19 +0000

Hi Henk,

> (Hannes, weirdly I believe I did not receive your reply, but I assume it is quoted in the msg below)

I was trying to explain how we have implemented the attestation functionality in our TF-M and TF-A.

> I can accept that we are past that point :-) Please consider this a me lamenting about bad choices in the past that we have to live with today.
> I also see the argument that you can "reuse" CWT code (and then teach it how to treat as an EAT with extra code).

I know what you mean. I keep complaining about the past as well.
I guess it's all good as long as we can get across the finish line in a reasonably good state.

Ciao
Hannes

Viele Grüße,

Henk

On 10.12.21 19:11, Laurence Lundblade wrote:
>>> include any kind of CWT claims from an increasingly growing CWT
>>> Claims registry. I am allowed to include a nonce and a cnonce Claim
>>> simultaneous due to that. Or simply mix an exi Claim in. How shall
>>> an implementation act on that? That is a valid EAT composition. Is
>>> really useful approach, if your goal is to establish an
>>> interoperable way to assert trustworthiness. I'd very much prefer a
>>> better scoped usage scenario for EAT for RATS by making an EAT
>>> something more specialized than a CWT (on the CBOR tag level). Maybe
>>> someone can explain to my why this is not an implementer's nightmare
>>> as I might miss something obvious here.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Dec 2021 11:40:25 +0000

Hey Jeremy,

Thanks for your detailed response!

I think we have a common understanding on how EAT is going to be likely used in practice, namely

  *   In a CBOR serialization format for the attester conveying attestation evidence, and
  *   In a JSON serialization format for RESTful Web APIs. JSON is much more accessible to web developers.

The big question for me is whether both need to be described in a single document. The audience will be different because the use case is different. The question about the DLOA claim relates to this aspect as well since its usage for attester outbound communication is unlikely at best.

Regarding the UCCS topic I was hoping that the fact that there is a dedicated WG item in the group will help to move some of the text into that document. As an author of EAT it is a bit annoying to first write all the text and then to have to move it. I fully understand that this is important work for GP and the smartcard industry and, as I commented on the list, I believe that their deployment model is good.

Ciao
Hannes

From: Jeremy O'Donoghue <[email-masked]>
Sent: Monday, December 13, 2021 11:43 AM
To: Henk Birkholz <[email-masked]>; Hannes Tschofenig <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] EAT Review Comments

Hi list,

My thoughts below

Best regards
Jeremy

On 10/12/2021, 07:45, "RATS" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes & Laurence,
hi list,

Viele Grüße,

Henk

On 09.12.21 11:45, Hannes Tschofenig wrote:
> From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
> To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
>> On Dec 7, 2021, at 3:49 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>

> - Maybe the DLOA's claim could be removed, but I think it is important for RP's to be able to know about certification status in attestation results.

[JOD] -1 on removing DLOA claim - it would otherwise go into a GlobalPlatform profile anyway, but I see the applicability as being much broader than the GlobalPlatform ecosystem - it allows a claim about a 3rd party security certification (e.g. PSA Certified / SESIP L3) which can be hosted on any webserver.

>
> - The description of SW manifests and measurements is a bit difficult, but I've tried make use of the best things out there and be flexible / pluggable since it is a moving target.
>

> There's strong logic here:
> - RATS architecture explicitly calls out composite attestation - A submodule can be a nested EAT to implement composite attestation - A nested EAT can be a CWT, UCCS  or DEB - The CDDL that specifies a nested EAT submodule thus must mention UCCS
>

I am not fully convinced that the complexity of allowing an EAT to be almost any arbitrary composition of JSON and CBOR components is really necessary, and maybe it is reasonable to require that an EAT is composed of either CBOR or JSON components. Doing otherwise has potential to make all components in the chain (Attester, Verifier, RP) quite complex, and I'm generally keen on simplicity.

> - An EAT can be a JWT
> - EAT specifies claims that go into a JWT (and a CWT) - A submodule can be an  nested EAT - A submodule can then be a JWT in a CWT or a CWT in a JWT
>
> I don't think we realized the implications of EAT formally supporting JSON/JWT in a normative way a few years back. I certainly didn't. Trying to write and validate the CDDL for both JSON and CBOR, JWT and CWT brought it to light. Maybe it's too much? What do people think about completely removing normative JSON support from EAT?
>

[JOD] I would rather see document reach consensus and get published sooner - if removing JSON support helps this goal, and I think it does, I'm +1.

> - JSON is far more popular than CBOR
> - If there is reason to specify UCCS, then there is more reason to specify UJCS - This also lines up with EAT being used for attestation results, which are likely to be JSON.
>

+1

> [email-masked]<mailto:[email-masked]>

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 13 Dec 2021 12:28:34 +0000

Hi Hannes,

I can confirm that Secure Elements are likely to include outbound DLOA as attestation evidence.

This is required because some use-cases have RP-controlled verifiers where RP does not wish or require relationships with many vendor-supplied verifiers to determine certification state(*). One such example would be UICC/eUICC where MNO will only download a profile to a security-certified eUICC, and there are many, many hardware vendors.

(*) DLOA points to a server which is typically operated by a National Certification Body or similar trusted body.

Best regards
Jeremy

On 13/12/2021, 11:40, "Hannes Tschofenig" <[email-masked]> wrote:

·         In a CBOR serialization format for the attester conveying attestation evidence, and

·         In a JSON serialization format for RESTful Web APIs. JSON is much more accessible to web developers.

Ciao
Hannes

Hi list,

My thoughts below

Best regards
Jeremy

Hi Hannes & Laurence,
hi list,

Viele Grüße,

Henk

-          Attester conveying attestation evidence to a Verifier (likely to be CBOR in most cases)

-          Verifier conveying results to a Relying Party (likely to be JSON in most cases)

+1

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Dec 2021 12:55:24 +0000

Hi Jeremy,

Thanks for this additional information. That's very helpful.

To me it appears tricky to have the device provide this information. The problem I can see is that you cannot really rely on it. A compromised device would lie about its certificate level. Hence, whoever verifies this information has to keep to a copy around to check the received data against. This consequently makes the device-provided DLOA information of limited value.

Ciao
Hannes

From: Jeremy O'Donoghue <[email-masked]>
Sent: Monday, December 13, 2021 1:29 PM
To: Hannes Tschofenig <[email-masked]>; Henk Birkholz <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] EAT Review Comments

Hi Hannes,

Best regards
Jeremy

On 13/12/2021, 11:40, "Hannes Tschofenig" <[email-masked]<mailto:[email-masked]>> wrote:

Ciao
Hannes

From: Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 13, 2021 11:43 AM
To: Henk Birkholz <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] EAT Review Comments

Hi list,

My thoughts below

Best regards
Jeremy

Hi Hannes & Laurence,
hi list,

Viele Grüße,

Henk

+1

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 13 Dec 2021 12:31:21 -0800

On Dec 13, 2021, at 4:55 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Jeremy, 
>  
> Thanks for this additional information. That’s very helpful.
>  

The EAT claim is just for a pointer (a URL) to the certification info.

Also, DLOA is more intended for use in Attestation Results so it comes from the Verifier.

I actually think certification info is pretty important in characterizing security of something. Just as important as the number of bits in an algorithm or the amount of side-channel defenses and such. Certification is where that all gets cross-checked into a coherent set of defenses and where effort is put into finding wholes and gaps. We don’t just say “use big I-beams” when building a sky scraper or bridge. We have a building department and inspector that makes sure they are used right.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 13 Dec 2021 21:37:41 +0100

On 13.12.21 21:31, Laurence Lundblade wrote:
> On Dec 13, 2021, at 4:55 AM, Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Jeremy,
>> To me it appears tricky to have the device provide this information. 
>> The problem I can see is that you cannot really rely on it. A 
>> compromised device would lie about its certificate level. Hence, 
>> whoever verifies this information has to keep to a copy around to 
>> check the received data against. This consequently makes the 
>> device-provided DLOA information of limited value.

This characterization sounds more like the use of endorsements to me 
than the use of evidence.

> Also, DLOA is more intended for use in Attestation Results so it comes 

And while an Attester can "cache" its own endorsements, typically they 
can also be conveyed to a Verifier from an Endorser, correspondingly

> 
> 
> I actually think certification info is pretty important in 
> characterizing security of something.

+1

> Just as important as the number of 
> bits in an algorithm or the amount of side-channel defenses and such. 
> Certification is where that all gets cross-checked into a coherent set 
> of defenses and where effort is put into finding wholes and gaps. We 
> don’t just say “use big I-beams” when building a sky scraper or bridge. 
> We have a building department and inspector that makes sure they are 
> used right.
> 
> LL
> 
> 
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 15 Dec 2021 11:01:16 -0800

Lots discussion on EAT. :-)

Chunking through it...

> On Dec 9, 2021, at 2:45 AM, Hannes Tschofenig <[email-masked]> wrote:
>> Laurence wrote:

In the above, I said that RATS architecture has composite attestation and therefor we need EAT submods. Hannes is maybe suggesting we don’t need submods because they add too much complexity.

Here’s a few more reasons for submods:

- Complex devices like phones, routers and cars have a large number of subsystems. For the router case, you may have individual attestation from cards in the router and one for the chassis. A mobile phone has like 10 major compute environments (TEE, camera, modem, low power audio, CPU/GPU…) We need a way to express and organize claims for all sorts of complex devices.

- submods give EAT a very substantial expressive power for all sorts of use cases. Not having them would result in people inventing ad hoc schemes for their use cases.

- I recall a few conversations with various folks that see important for submods in their use cases

I have a strong conviction that submods, including nested tokens, are necessary for EAT now and are worth the complexity they add. 

LL

(Happy to consider improvements to the submods design)
(Submods != UCCS/UJCS; UCCS and UJCS are related, but can be a separate decision)

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 15 Dec 2021 12:55:10 -0800

At this point I’m in favor of leaving the DLOAs claim in EAT.

- It doesn’t add a lot of complexity as it independent of all the other claims. Any EAT implementor can safely ignore it entirely.

- Certification is really important in trusted/confidential/… compute. It’s good that it has some presence in our attestation standards and brings attention to this existing standard.

- The design seems solid and correct, by carrying only a reference

- Could work with Arm PSA certified, FIDO certified, TCG certified, GP Certified. EMVCo, NIST, and the CC certifications...

I think it can come into play in many ways. Here’s a few scenarios, all of which are supported.
- The Attester passes the DLOAs claim to the Verifier which passes to the RP in AR who’s machine learning risk engine processes it
- The Verifier figures out which DLOA based on identify info in the Evidence and passes it to the the RP in AR
- The Attester passes the DLOAs claim to the Verifier. The Verifier evaluates it and does NOT pass it to the RP. They just give a thumbs up to the RP.
- The Attester passes the DLOAs claim directly to the RP because the RP is the Verifier

The line between Endorsement and Reference value is a bit hazy for me, but a DLOA is never THE endorsement. Maybe it is part of the Endorsement or maybe it fits better classified as a Reference value. It doesn’t seem critical to say precisely which.

In some cases the DLOAs claim is in Evidence and sometimes it is in AR and sometimes neither because it is an Endorsement process by the Verifier. It’s all good and OK.

LL

> On Dec 13, 2021, at 12:37 PM, Henk Birkholz <[email-masked]> wrote:
> 
> 
>> On Dec 13, 2021, at 4:55 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Jeremy,
> This characterization sounds more like the use of endorsements to me than the use of evidence.
> 
> And while an Attester can "cache" its own endorsements, typically they can also be conveyed to a Verifier from an Endorser, correspondingly
> 
>> I actually think certification info is pretty important in characterizing security of something.
> 
> +1
> 
>> Just as important as the number of bits in an algorithm or the amount of side-channel defenses and such. Certification is where that all gets cross-checked into a coherent set of defenses and where effort is put into finding wholes and gaps. We don’t just say “use big I-beams” when building a sky scraper or bridge. We have a building department and inspector that makes sure they are used right.
>> LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 15 Dec 2021 22:02:44 +0000

(speaking not as chair)
My reading of DLOA section in the EAT draft leads me to believe it is describing a conveyance (or part of a conveyance) method of a DLOA. The EAT draft describes DLOA as an "XML document that describes a certification that a device or entity has received." That definition fits with the RATS Architecture description of an Endorser because it describes a trustworthiness property of the Attester. Presumably, it’s a static / immutable property. 

However, my characterization of DLOA as being an Endorsement is an opinion that is open to discussion. Given our current charter status, it would be a discussion that is a lower priority I think?

Nevertheless, the DLOA Claim in the EAT draft could reasonably be described as an Endorsement conveyance mechanism and therefore could be considered in terms of WG scope.

Thx,
Ned

On 12/15/21, 12:55 PM, "RATS on behalf of Laurence Lundblade" <[email-masked] on behalf of [email-masked]> wrote:

    LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 15 Dec 2021 22:36:17 +0000

[NMS](speaking not as chair)
--snip--
Here’s a few more reasons for submods:

[NMS] More correctly, the vendor community who creates the TEE, camera, modem, lp audio, CPU/GPU etc… need a way to express and originate claims for all sorts of complex devices. The presumed way to achieve this using CWT/JWT (that contains EAT claims) is that the ‘sub’ claim describes the ‘module’ and the ‘iss’ claim describes the vendor (although this isn’t specifically defined in the EAT draft. It is possible, using submod, to use the submod name ‘submods-label’ to refer to the component, which is a component of the device. Additionally, it isn’t clear how, in a multi-vendor supply chain, the submod name is supposed to be unique (not have the same name). This is especially concerning given a module could have multiple instances of the same type of module.

There has been discussion that EAT as a standalone spec can’t reasonably be implemented without a profile. Possibly, the profile context addresses some of these concerns? The PSA draft goes further to define a profile, but I don’t see it directly addressing the consideration for multi-vendor device composition.

The other EAT claims (not submod) seem to imply a simple composition where the thing (module) to which the CWT/JWT is issued / bound is the thing (module) that has the EAT claim.
--snip--

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 16 Dec 2021 11:37:38 +0000

hi Laurence,

I agree with you that submods exist for a very good reason. They have
particular value if the composition pattern is static and known
a-priori (Ned's email has some interesting points in this regard). The
existence of submods has enabled some interesting expression during
prototyping efforts here.  Note also that I would be concerned
that if submods did not exist then that might result in multiple custom
solutions emerging to express nesting, which would be a poor result for
the wider RATS standardisation efforts.

The current definition is nice and simple, though I would like to
explore some extra functionality at some point. The small trouble I have
with it is that the string type limits the expressiveness of the submod
identifier.  Ideally, one could have a composite, more powerful type on
the LHS of the submod definition.  Note that this would be possible in
CBOR but not in JSON, so if we want interworking between the two formats
we'd need to find another solution. For example one where the RHS
clearly separates identification information from the measurements.  At
that point the string key would be redundant, or left as a hint.  At the
moment I don't have a very concrete proposal (i.e., code) though, so
this is just a thought.

cheers,

--
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Dec 2021 10:11:21 -0500

Smith, Ned <[email-masked]> wrote:
    > There has been discussion that EAT as a standalone spec can’t
    > reasonably be implemented without a profile. Possibly, the profile
    > context addresses some of these concerns? The PSA draft goes further to
    > define a profile, but I don’t see it directly addressing the
    > consideration for multi-vendor device composition.

That's unfortunate if that is really the case.  Profiles of profiles of profiles.
I think of EAT as the profile of COSE that let's us do attestation.
If there is a profile, then it would address the naming concern that you
raised.

In general, I think that every single vendor/integrator who puts the right
manufacturer supports (Endorsements, Reference Values) and/or operates a
Verifier (likely in Background Check model) will need to solve the naming and
profile problem.    I'm not sure that we need standardization here: it's all
under control of the manufacturer.

    > The other EAT claims (not submod) seem to imply a simple composition
    > where the thing (module) to which the CWT/JWT is issued / bound is the
    > thing (module) that has the EAT claim.

I would prefer that the EAT document was simplified/shortened, that anything
we do not presently have running code for be removed to another document.
I'd like to see EAT published by Summer 2022, even if that means four or five
extension documents come later.

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 17 Dec 2021 11:25:55 -0800

> On Dec 16, 2021, at 7:11 AM, Michael Richardson <[email-masked]> wrote:
> 
>> reasonably be implemented without a profile.

The same is true for CBOR, CWT, JWT, COSE and JOSE (more comments below).

>> Possibly, the profile

Do you mean EAT as a profile of CWT, not COSE?

> under control of the manufacturer.

Agreed, submod naming is left to the manufacturer, specifically the maker of the Attester. I haven’t been able to come up with anything better so far.

More below in response to Thomas.

> extension documents come later.

There is running code for submodules (CToken & Xclaim) and most other claims, but not for DEB.

> On Dec 16, 2021, at 3:37 AM, Thomas Fossati <[email-masked]> wrote:
> 
> hi Laurence,
> 

So, unless a strong consensus emerges, I will keep submods in EAT.

> moment I don't have a very concrete proposal (i.e., code) though, so

Maps with labels that are not strings or integers are generally a bit scary and off the beaten path. I suspect many CBOR libraries (like QCBOR) have built-in support for maps with string and integer labels, but not for arbitrarily complex labels. So some aggregate type in the label would up the implementation cost a lot, particular on the decode side.

I don’t know what sort of submods you are trying to implement.

Best I can think of is that you pack some structure into the string label. Maybe we also allow byte string labels to help. The Verifier and RP usually have ample CPU power and memory so multiple scans of the submods section are OK. The implementation can unpack the whole submods section into memory including unpacking the structure in the label and do whatever it needs to do to get to the submod it wants. Maybe in the extreme, the byte string labels are wrapped CBOR.

LL

A few more comments on interoperability and profiles:

- One CBOR implementation sends indefinite lengths and a receiver only decodes definite lengths —> no interoperability
- There are no required algorithms and no handshake for COSE and JOSE so the —> no interoperability is possible
- There are no required claims in CWT or JWT —> —> no interoperability is possible
- Even the PSA profile of EAT is not locked down enough to guarantee interoperability

Though it is common, all this lack of guaranteed interoperability seems a bit odd for the IETF in a way. It was a main motivator for me to put profiles in EAT.

FIDO has a conformance certification program. The FIDO spec is therefor tight on this. In theory vendors on different planets that can’t talk to each other can produce interoperable and conformance-passing FIDO implementations.

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 17 Dec 2021 23:42:13 +0000

(speaking not as chair)
If submods claim is Evidence, then there is an expected Reference Values expression that matches it. The RV schema could contain more richly typed expressions that the Verifier might rely on for interpretation of the submods label value. If it is a string, but the RV typing expects binary ('bstr') then the label should be an ascii-fied encoding of the binary label. If the label were however a choice (CDDL type choice) that permitted both 'str' and 'bstr' forms then the Verifier can rely on the encoding to tell it which form to compare against.
-Ned 

    LL

---

From: Ira McDonald <[email-masked]>
Date: Fri, 17 Dec 2021 18:55:53 -0500

Hi Laurence,

+1 to keeping submods in EAT spec.

A proliferation of vendor-specific "solutions" to claims for composite
systems
would be a nightmare and defeat interoperability.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Dec 17, 2021 at 2:26 PM Laurence Lundblade <[email-masked]>
wrote:

> Agreed, submod naming is left to the manufacturer, specifically the maker
> of the Attester. I haven’t been able to come up with anything better so far.
>
> Maps with labels that are not strings or integers are generally a bit
> scary and off the beaten path. I suspect many CBOR libraries (like QCBOR)
> have built-in support for maps with string and integer labels, but not for
> arbitrarily complex labels. So some aggregate type in the label would up
> the implementation cost a lot, particular on the decode side.
>
> Best I can think of is that you pack some structure into the string label.
> Maybe we also allow byte string labels to help. The Verifier and RP usually
> have ample CPU power and memory so multiple scans of the submods section
> are OK. The implementation can unpack the whole submods section into memory
> including unpacking the structure in the label and do whatever it needs to
> do to get to the submod it wants. Maybe in the extreme, the byte string
> labels are wrapped CBOR.
>
> LL
>
>
>
> - One CBOR implementation sends indefinite lengths and a receiver only
> decodes definite lengths —> no interoperability
> Though it is common, all this lack of guaranteed interoperability seems a
> bit odd for the IETF in a way. It was a main motivator for me to put
> profiles in EAT.
>
> FIDO has a conformance certification program. The FIDO spec is therefor
> tight on this. In theory vendors on different planets that can’t talk to
> each other can produce interoperable and conformance-passing FIDO
> implementations.
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 18 Dec 2021 11:04:56 -0800

On Dec 17, 2021, at 3:42 PM, Smith, Ned <[email-masked]> wrote:
> 
> (speaking not as chair)
> If submods claim is Evidence, then there is an expected Reference Values expression that matches it.

Note that a submod might be a whole other EAT token. Maybe the Verifier knows how to look into it, maybe the Verifier just knows to send it to another Verifier. For example, it might be for Secure Element that is soldered on to the circuit board and you might send it to a service that Verifies Secure Element attestations.

We could support both bstr and tstr for the submod name if it is really needed.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 20 Dec 2021 21:45:10 +0000

I think its needed. 

On 12/18/21, 11:05 AM, "Laurence Lundblade" <[email-masked]> wrote:

    LL