Subject: Re: [Rats] Often Attester == Device?

From: Dave Thaler <[email-masked]>
Date: Mon, 3 Jan 2022 17:32:29 +0000

Ned Smith wrote (in response to Laurence Lundblade):

  *   Note that it is OK in RATS for the target environment and attestation environments to be the same.
  *   <NMS> There was passionate discussion over this and the resolution was to allow them to be the same. For example, a "root of trust" environment could be argued to be both target and attester environments. However, it could also be argued that an Endorser asserts claims about the RoT env. Hence, it seems to follow the pattern of the target env not being the same as the attesting env. That is the Endorser seems to take the role of Attesting Env and RoT takes the role of Target Env. (but applying this terminology too broadly is difficult to follow IMHO but from a philosophical perspective the argument that target and attesting envs should not be the same can be reasonably asserted.)

Section 12.1 of the architecture document says:
  "For example, a
   Target Environment should not be able to tamper with the Attesting
   Environment that measures it, by isolating the two environments from
   each other in some way."

So it's dangerous to allow the Attesting Environment and Target Environment to be the same.   As Ned mentions, an Endorser can be used to attest to the trustworthiness of a hardware Target Environment.  In that sense, one could
consider the Endorser as acting like the attesting environment for the hardware Target Environment.

Dave

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 3 Jan 2022 10:36:02 -0800

> On Jan 3, 2022, at 9:32 AM, Dave Thaler <[email-masked]> wrote:
> 
> Note that it is OK in RATS for the target environment and attestation environments to be the same.
> <NMS> There was passionate discussion over this and the resolution was to allow them to be the same. For example, a “root of trust” environment could be argued to be both target and attester environments. However, it could also be argued that an Endorser asserts claims about the RoT env. Hence, it seems to follow the pattern of the target env not being the same as the attesting env. That is the Endorser seems to take the role of Attesting Env and RoT takes the role of Target Env. (but applying this terminology too broadly is difficult to follow IMHO but from a philosophical perspective the argument that target and attesting envs should not be the same can be reasonably asserted.)
>  
>   “For example, a
>    each other in some way.”
> So it’s dangerous to allow the Attesting Environment and Target Environment to be the same.   As Ned mentions, an Endorser can be used to attest to the trustworthiness of a hardware Target Environment.  In that sense, one could

For certain, separation is required when measuring because this IS the point of measuring (where measuring means something like hashing stuff in the target).

For many claims separation is not required. For example, the Endorser may not know the UEID (serial numbers) of individual devices. The Endorser can never know GPS location. For the most part an Endorsement says “the claims from this Attester can be trusted”.

LL

This sentence is awkward

>   “For example, a Target Environment should not be able to tamper with the Attesting
>    Environment that measures it, by isolating the two environments from each other in some way.”
>  

Better

>   “For example, a Target Environment should not be able to tamper with the Attesting
>    Environment that measures it. There should be isolation between the two environments.”
>  

Best would be clearly discussing security consideration for the measurement case (hashing stuff in a different environment) separate from the reporting case (sending identity info, GPS location,…) and saying there MUST be separation in the measurement case. 

There’s no doubt in my mind that there MUST be separation in the measurement case and that it is separate from the reporting case.

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 3 Jan 2022 10:51:40 -0800

> On Dec 31, 2021, at 12:18 PM, Smith, Ned <[email-masked]> wrote:
> 
> See inline <NMS>
>  
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> Date: Wednesday, December 29, 2021 at 6:49 AM
> To: rats <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [Rats] Often Attester == Device?
>  
> I recently realized the source of my surprise that Attester == Device.
>  
> In normal English use of the word attester, it is just the witness, the informer or the reporter to the exclusion of what is witnessed, what is the subject.
>  
>> Definitions of attester. someone who affirms or vouches for the correctness or truth or genuineness of something. synonyms: attestant. type of: informant, witness, witnesser. someone who sees an event and reports what happened
>  
> However, RATS architecture defines attester to mean both the witness and the witnessed.
> <NMS> RATS arch defines roles (Attester, Verifier, Endorser, RVP, RP,…). Roles are functionalities that are performed (e.g., by an entity). The dictionary definition doesn’t distinguish between the thing and the role.

Right. No distinction between the witness and witnessing, between the person and the role/act, but the dictionary does distinguish between the witness and the witnessed, between the person and what they saw. That we use the term “attester” to include “what they saw” is where my surprise comes from.

> This came up because of this EAT PR <https://github.com/ietf-rats-wg/eat/pull/148> to tighten up the definition of the term entity to address comments by Hannes. At first I thought an EAT entity  was an attester as defined in RATS Architecture, but clearly it is a target environment. Also, there’s some agreement that EAT will continue to use the term “entity” since it is the “E” in EAT. 
> <NMS> I think there are several synonymous or mostly synonymous terms being used between EAT and RATS Arch. EAT uses ‘entity’ as an abstract term for ‘device’ (which is more concrete vs. abstract).

An EAT entity is more than a device. It can be an app, a process or a submodule. It corresponds well to RFC8949 "system component”.

> If you were familiar with TCG specs, they might use ‘platform’ as something synonymous with ‘device’. The issue with ‘entity’ as an abstraction of either ‘device’ or ‘platform’ is RFC4949 allows it to include other things like people or organizations. Hence, it is overly broad. EAT also uses ‘submodule’ but logically could use ‘module’; both are abstract terminology for a decomposition of ‘entity’ (I think?). For example, the corim draft uses “Module” somewhat equivalently to EAT ‘entity’ and/or EAT ‘submod’. ‘Module’ and ‘submodule’ are abstract terms for component/subcomponent, but component/subcomponent seems somewhat abstract also. ‘environment’ is arguably more abstract than either ‘module’ or ‘component’. For example, an environment could consist of multiple physical components. But for the most part I don’t think any of the terminology uses are right or wrong, they’re all somewhat synonymous to “a place where RATS Role functionality can be performed” (e.g., Attesting Environments) or synonymous to “a place that is acted upon by such functionality” (e.g., Target Environments).

I want to keep using the term entity in EAT, but might consider changing the term “submodule”, perhaps to “subcomponent” if that aligns with other work.

>   
> One more thing on the topic. If it were up to me, I’d improve the definition of Attester in RATS architecture to something like this:
>  
>> A central role performed by a system component [RFC4949] that both produces Evidence and is the subject of the an attestation. The Evidence is used to determine the degree of trust in it to perform some operation or receive some data.
>>  
>> <NMS> I get where you’re going. I’m not passionate about including / excluding the definition as I think the existing wording communicates this concept already. I don’t think it’s a good idea for the arch to include multiple definitions of the same thing. The definition above seems to redefine Evidence. The main difference here is use of the phrase “performed by a system component”. The RATS arch does use the role names in sentences that omit the pedantic “perfomed by a <entity term>”. This was discussed and the design team preferred allowing avoidance of pedantic sentence construction for improved readability (at the risk of potentially being imprecise about the relationship between Roles and Entities).
>  
> Note that an attester is never a person so the more appropriate RFC 4949 term for it is system component rather than entity.
> <NMS> Agree. I thought there was wording in EAT draft to this effect?

There will be when the PR merges (soon). 

My comment is that maybe RATS architecture’s definition of Attester should change to using system component instead of entity, or should qualify it the way EAT will qualify it.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 3 Jan 2022 22:17:45 +0000

LL wrote: “For many claims separation is not required. For example, the Endorser may not know the UEID (serial numbers) of individual devices. The Endorser can never know GPS location. For the most part an Endorsement says “the claims from this Attester can be trusted”.”
<NMS> Unless UEID is randomly provisioned, there should be at least one Endorser that knows its value. It may not be possible for an Attesting Environment to be able to collect its measurement, hence might only be available as an Endorsement. I don’t understand the use case where no Endorser knows the UEID – there should be at least one, namely the one that provisioned it.

GPS coordinates is much different from UEID in that it is a value that changes often (especially if the device is mobile). Additionally, it is possible there isn’t a Reference Value that is associated (e.g. it is functioning like a beacon). Hence, neither Endorsement or Reference Value is expected.

Personally, I don’t believe the RATS Arch has good terminology for the class of claims that doesn’t anticipate either Endorsements or Reference Values. The RATS Arch could assert that they exist within the body of Evidence, but it is ambiguous for Verifiers whether to accept or reject the claims IMHO. I could imagine a layering scenario where the Target Environment containing the location sensor is accepted (based on Endorsements and Reference Values) and determined to be trustworthy, then subsequently accept this other type of claim (which is data generated by the Target Env). I have asserted that such claims are an example of “telemetry claims” but some people didn’t like that terminology. However, nobody has proposed alternate/better terminology and the RATS Arch is silent in terms of defining it (as a class of thing).  Quite literally, it is dynamically generated Target Environment data / Claims. If we were to give it a name based on that, we might call it Dynamic Target Environment (DTE) Claims. Endorsements/Expected Values schemas could describe the type of data expected (i.e., it describes a location type rather than actual values). But this would be a case of Reference Types vs. Reference Values.

-Ned

From: Laurence Lundblade <[email-masked]>
Date: Monday, January 3, 2022 at 10:36 AM
To: Dave Thaler <[email-masked]>
Cc: "Smith, Ned" <[email-masked]>, rats <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

On Jan 3, 2022, at 9:32 AM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

  *   Note that it is OK in RATS for the target environment and attestation environments to be the same.
  *   <NMS> There was passionate discussion over this and the resolution was to allow them to be the same. For example, a “root of trust” environment could be argued to be both target and attester environments. However, it could also be argued that an Endorser asserts claims about the RoT env. Hence, it seems to follow the pattern of the target env not being the same as the attesting env. That is the Endorser seems to take the role of Attesting Env and RoT takes the role of Target Env. (but applying this terminology too broadly is difficult to follow IMHO but from a philosophical perspective the argument that target and attesting envs should not be the same can be reasonably asserted.)

LL

This sentence is awkward

Better

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 4 Jan 2022 15:31:55 +0100

Hi Laurence,

TL;DR
The RATS architecture does allow for collapsing Attesting Environment 
and Target Environment. The benefits the RATS architecture provides are 
basically nullified, if the Attesting Environment and Target Environment 
are the same. Exactly *zero* claims about trustworthiness can be 
generated. Maybe a few "trusted claims" can be generated - but that is 
already a far stretch.

There is a lot to unpack here. But I'd like to highlight one specific 
point that we never dared to really address explicitly and now that you 
are kinda voicing that for "the third time" (which is a charm), I am 
gonna focus on that one first.

Please find the target of my comment in the quote below.

> environments to be the same.

The reason being: I've been disagreeing with that statement for a long 
time now. And still I've been trying to be neutral on this. But I think 
this starts to become an issue now. While every individual of course can 
have an own opinion on this issue, the working group must now form a 
consensus opinion.

This is and always was a very dangerous assumption that the editors have 
tolerated for quite a while now. Let's start with a controversial 
individual statement: the recent years have shown us that this simply is 
not true - it is not OK. The quality of "Evidence" in such a scenario is 
close to a "signing fool", maybe it suffices for a proof of possession 
and still then...

> consider the Endorser as acting like the attesting environment for the hardware Target Environment.

I 100% agree with Dave (and implicitly Ned) here and would go as far as 
to propose a corresponding addition to the RATS Security Considerations, 
if that has not been made unmistakably clear enough.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 4 Jan 2022 11:16:57 -0800

Hey there, so It is entirely secure to have the Attesting and Target Environments the same for non-measurement use cases.

Measurement Use Cases
The measurer can’t be the same as the measured or there is no value in the measurement so there must be separation between Target and Attestation Environments for these use cases. 

Examples are Linux IMA <https://sourceforge.net/p/linux-ima/wiki/Home/> and the typical layered attestation / staged boot with a TPM.

By measurement I mean one environment taking hashes or such of SW, memory and stored data in another environment. I don’t think reporting a UEID or GPS location is a measurement.

Reporting / Trust Establishment Use Cases
If you can trust an Attesting Environment to correctly measure a target environment, you can also trust it to report its own UEID, GPS location, the results of a biometric authentication and lots and lots of other stuff. 

There are large swaths of valid attestation use cases that do no measurement.

Secure examples, in use by the millions (billions?), today include FIDO and the Android Key store. OMA DRM <https://en.wikipedia.org/wiki/OMA_DRM> is essentially the same architecture. IoT on-boarding is another.

I agree that strong wording about separation in security considerations is a good thing, but only for the measurement use cases. That separation is not needed for huge numbers of other use cases that must be covered by RATS.

LL

> On Jan 4, 2022, at 6:31 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> TL;DR
> The RATS architecture does allow for collapsing Attesting Environment and Target Environment. The benefits the RATS architecture provides are basically nullified, if the Attesting Environment and Target Environment are the same. Exactly *zero* claims about trustworthiness can be generated. Maybe a few "trusted claims" can be generated - but that is already a far stretch.
> 
> There is a lot to unpack here. But I'd like to highlight one specific point that we never dared to really address explicitly and now that you are kinda voicing that for "the third time" (which is a charm), I am gonna focus on that one first.
> 
> The reason being: I've been disagreeing with that statement for a long time now. And still I've been trying to be neutral on this. But I think this starts to become an issue now. While every individual of course can have an own opinion on this issue, the working group must now form a consensus opinion.
> 
> This is and always was a very dangerous assumption that the editors have tolerated for quite a while now. Let's start with a controversial individual statement: the recent years have shown us that this simply is not true - it is not OK. The quality of "Evidence" in such a scenario is close to a "signing fool", maybe it suffices for a proof of possession and still then...
> 
> I 100% agree with Dave (and implicitly Ned) here and would go as far as to propose a corresponding addition to the RATS Security Considerations, if that has not been made unmistakably clear enough.
> 
> 
> Viele Grüße,
> 
> Henk

---

From: Dave Thaler <[email-masked]>
Date: Tue, 4 Jan 2022 19:43:08 +0000

"If you can trust an Attesting Environment to correctly measure a target environment, you can also trust it to report its own UEID, GPS location, the results of a biometric authentication and lots and lots of other stuff."

The GPS point is pretty weak.  Even if you trust the Attesting Environment you can't necessarily trust the GPS location it reports unless you have some mechanism that provides such trust.   E.g., if it just gets the GPS location from an external dongle, then you'd have to measure the external dongle as a target environment.   A similar argument applies to time of day... the Attesting Environment uses a timestamp but doesn't use a secure time protocol to get it, you can't trust the timestamps.  Similarly if it uses a secure time protocol to some other server to get it, you can only trust the timestamps if you trust that other server.   So there is a difference between information that is intrinsic to the Attester vs information that is extrinsic.

My own opinion is that there should be a clean way to distinguish intrinsic claims from extrinsic claims, and I don't think there is in EAT today.

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Tuesday, January 4, 2022 11:17 AM
To: Birkholz, Henk <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Measurement Use Cases
The measurer can't be the same as the measured or there is no value in the measurement so there must be separation between Target and Attestation Environments for these use cases.

Examples are Linux IMA<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&data=04%7C01%7Cdthaler%40microsoft.com%7Cf207ba48db774f46960108d9cfb6cf7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769207390000682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=SuihFbMhcoyI8mm4harGOZWO%2FNsZ47%2Fecp%2FzCyZUZ2E%3D&reserved=0> and the typical layered attestation / staged boot with a TPM.

By measurement I mean one environment taking hashes or such of SW, memory and stored data in another environment. I don't think reporting a UEID or GPS location is a measurement.

Secure examples, in use by the millions (billions?), today include FIDO and the Android Key store. OMA DRM<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&data=04%7C01%7Cdthaler%40microsoft.com%7Cf207ba48db774f46960108d9cfb6cf7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769207390000682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0dB90ccoob%2BZCb7e%2Bvvdh3xXqMNhd3QWoVOdRvGE4KY%3D&reserved=0> is essentially the same architecture. IoT on-boarding is another.

LL

On Jan 4, 2022, at 6:31 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi Laurence,

TL;DR

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 4 Jan 2022 11:46:39 -0800

> <NMS> Unless UEID is randomly provisioned, there should be at least one Endorser that knows its value. It may not be possible for an Attesting Environment to be able to collect its measurement, hen…

Focusing in on this detail, not the general separation issue…

I may have chosen poorly in using UEID as an example. Here are some better ones.

What is being reported is the SUEID, where the SUIED is a UEID that changes on device lifecycle events like when I reset  my phone or device before selling it on eBay. Here the SUEID is randomly generated and the Endorser definitely doesn’t know it.

Some attestation systems use one key that is shared between 100,000 devices so the attestation key doesn’t violate privacy.  One Endorsement is shared between 100,000 devices. In these cases the device is probably not reporting a UEID, but instead is doing something like FIDO or like the Android key store. It is attesting to biometric results or such.

Another more complex example that I actually implemented generates different UEIDs in different tokens. The Attester authenticates whomever is requesting the token and them produces a UEID specific to the requester. This is a privacy preserving strategy that prevents tracking by UEID between requesters, but does allow tracking for one particular requester.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 4 Jan 2022 20:17:13 +0000

> What is being reported is the SUEID, where the SUIED is a UEID that changes on device lifecycle events like when I reset  my phone or device
> before selling it on eBay. Here the SUEID is randomly generated and the Endorser definitely doesn’t know it.
<NMS> Based on this definition, a SUEID could be derived using a DICE CDI value. The way DICE navigates the trustworthiness claims provides important context such that a lower layer Attesting Environment (AE) collects claims about the higher layer (TE) and does the key / ID generation step on behalf of the TE. The AE is assumed to have its own key that is trusted by a Verifier. The Verifier extends trust in the derived key / ID based on the AE trustworthiness context and knowledge that the TE key / ID wasn’t self-generated. The AE key is provisioned by a known trusted process, hence has Endorsements that vouch for that key (which is not randomly changing). If you consider Claims in isolation of their real context then Verifiers will not be able to assess their trustworthiness IMHO.

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, January 4, 2022 at 11:47 AM
To: "Smith, Ned" <[email-masked]>
Cc: Dave Thaler <[email-masked]>, rats <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

On Jan 3, 2022, at 2:17 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 5 Jan 2022 10:49:43 +0100

Hi Dave,

On 04.01.22 20:43, Dave Thaler wrote:
> intrinsic claims from extrinsic claims

This is what some of us where (for a lack of better terms) calling:

* "claims about trustworthiness": this is what you are referring to as 
intrinsic claim, I think, such as a software measurement, e.g. the UEFI 
filesystem content, and

* "trusted claims": this is what you are referring to as extrinsic 
claim, I think, such as the GPS coordinates or any other assertion that 
is now generated by an Attester as Claims in its Evidence as it has 
proven its trustworthiness (for the moment) via the intrinsic claims

Dave, does my rephrasing makes sense to you?

Viele Grüße,

henk

On 04.01.22 20:43, Dave Thaler wrote:
> “If you can trust an Attesting Environment to correctly measure a target 
> environment, you can also trust it to report its own UEID, GPS location, 
> the results of a biometric authentication and lots and lots of other stuff.”
> 
> The GPS point is pretty weak.  Even if you trust the Attesting 
> Environment you can’t necessarily trust the GPS location it reports 
> unless you have some mechanism that provides such trust.   E.g., if it 
> just gets the GPS location from an external dongle, then you’d have to 
> measure the external dongle as a target environment.   A similar 
> argument applies to time of day… the Attesting Environment uses a 
> timestamp but doesn’t use a secure time protocol to get it, you can’t 
> trust the timestamps. Similarly if it uses a secure time protocol to 
> some other server to get it, you can only trust the timestamps if you 
> trust that other server.   So there is a difference between information 
> that is intrinsic to the Attester vs information that is extrinsic.
> 
> My own opinion is that there should be a clean way to distinguish 
> intrinsic claims from extrinsic claims, and I don’t think there is in 
> EAT today.
> 
> *From:* RATS <[email-masked]> *On Behalf Of * Laurence Lundblade
> *Sent:* Tuesday, January 4, 2022 11:17 AM
> *To:* Birkholz, Henk <[email-masked]>
> *Cc:* rats <[email-masked]>
> *Subject:* Re: [Rats] Often Attester == Device?
> 
> Hey there, so It is entirely secure to have the Attesting and Target 
> Environments the same for non-measurement use cases.
> 
>     _Measurement Use Cases_
> 
>     The measurer can’t be the same as the measured or there is no value
>     in the measurement so there must be separation between Target and
>     Attestation Environments for these use cases.
> 
>     Examples are Linux IMA
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&data=04%7C01%7Cdthaler%40microsoft.com%7Cf207ba48db774f46960108d9cfb6cf7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769207390000682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=SuihFbMhcoyI8mm4harGOZWO%2FNsZ47%2Fecp%2FzCyZUZ2E%3D&reserved=0> and
>     the typical layered attestation / staged boot with a TPM.
> 
>     By measurement I mean one environment taking hashes or such of SW,
>     memory and stored data in another environment. I don’t think
>     reporting a UEID or GPS location is a measurement.
> 
>     _Reporting / Trust Establishment Use Cases_
> 
>     If you can trust an Attesting Environment to correctly measure a
>     target environment, you can also trust it to report its own UEID,
>     GPS location, the results of a biometric authentication and lots and
>     lots of other stuff.
> 
>     Secure examples, in use by the millions (billions?), today include
>     FIDO and the Android Key store. OMA DRM
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&data=04%7C01%7Cdthaler%40microsoft.com%7Cf207ba48db774f46960108d9cfb6cf7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769207390000682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0dB90ccoob%2BZCb7e%2Bvvdh3xXqMNhd3QWoVOdRvGE4KY%3D&reserved=0> is
>     essentially the same architecture. IoT on-boarding is another.
> 
> I agree that strong wording about separation in security considerations 
> is a good thing, but only for the measurement use cases. That separation 
> is not needed for huge numbers of other use cases that must be covered 
> by RATS.
> 
> LL
> 
> 
> 
>     On Jan 4, 2022, at 6:31 AM, Henk Birkholz
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     Hi Laurence,
> 
>     TL;DR
>     The RATS architecture does allow for collapsing Attesting
>     Environment and Target Environment. The benefits the RATS
>     architecture provides are basically nullified, if the Attesting
>     Environment and Target Environment are the same. Exactly *zero*
>     claims about trustworthiness can be generated. Maybe a few "trusted
>     claims" can be generated - but that is already a far stretch.
> 
>     There is a lot to unpack here. But I'd like to highlight one
>     specific point that we never dared to really address explicitly and
>     now that you are kinda voicing that for "the third time" (which is a
>     charm), I am gonna focus on that one first.
> 
>     The reason being: I've been disagreeing with that statement for a
>     long time now. And still I've been trying to be neutral on this. But
>     I think this starts to become an issue now. While every individual
>     of course can have an own opinion on this issue, the working group
>     must now form a consensus opinion.
> 
>     This is and always was a very dangerous assumption that the editors
>     have tolerated for quite a while now. Let's start with a
>     controversial individual statement: the recent years have shown us
>     that this simply is not true - it is not OK. The quality of
>     "Evidence" in such a scenario is close to a "signing fool", maybe it
>     suffices for a proof of possession and still then...
> 
>         So it’s dangerous to allow the Attesting Environment and Target
>         Environment to be the same.   As Ned mentions, an Endorser can
>         be used to attest to the trustworthiness of a hardware Target
>         Environment.  In that sense, one could
>     I 100% agree with Dave (and implicitly Ned) here and would go as far
>     as to propose a corresponding addition to the RATS Security
>     Considerations, if that has not been made unmistakably clear enough.
> 
> 
>     Viele Grüße,
> 
>     Henk
>

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 5 Jan 2022 17:05:22 +0000

I'm not a big fan of adjective-fying Claims. The claim itself determines what it is / means. Claims (regardless of what it is) can be asserted by different entities and Roles. Who asserts the Claim tells the verifier something about how to trust it.

There are a set of claims that can be measured by an Attesting Env and a set that can't. The set that can't is the closest thing to what might be termed "extrinsic" IMHO. But innovation in how claims are collected could change something in the extrinsic column. So, I still don't like the adjectives. 

-Ned

On 1/5/22, 1:50 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Dave,

    Viele Grüße,

    henk

    >     Considerations, if that has not been made unmistakably clear enough.

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

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 5 Jan 2022 19:13:41 +0100

Hi Ned,

than I am not sure that we apply the same meaning to terms here.

To paraphrase on bilateral terminology:

I was intending to map "intrinsic claim" to "trustworthiness" and to map 
"extrinsic claims" to "telemetry".

Ned, would that make more sense to you?

Viele Grüße,

Henk

---

From: Dave Thaler <[email-masked]>
Date: Wed, 5 Jan 2022 19:08:45 +0000

"trusted claims" does not make sense to me as a term for the same thing, since trust is about what another entity decides, not about the info in the claims.

And when you say "such as the GPS coordinates or any other assertion that is now generated by an Attester as Claims in its Evidence as it has proven its trustworthiness (for the moment) via the intrinsic claims" my point is that the info in the extrinsic claims has _in general_ not been proven by the Attester to be correct.  Just because you have a trustworthy Attester does not mean that a GPS coordinate or a timestamp is actually trusted... you need additional effort to do that, or you have to apply a leap of faith.   Stating they are "trusted claims" because they come from an Attester that itself is trustworthy implies trust is always transitive which is a very dangerous thing to assume.

Dave

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Wednesday, January 5, 2022 1:50 AM
To: Dave Thaler <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: rats <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Hi Dave,

* "claims about trustworthiness": this is what you are referring to as intrinsic claim, I think, such as a software measurement, e.g. the UEFI filesystem content, and

* "trusted claims": this is what you are referring to as extrinsic claim, I think, such as the GPS coordinates or any other assertion that is now generated by an Attester as Claims in its Evidence as it has proven its trustworthiness (for the moment) via the intrinsic claims

Viele Grüße,

henk

On 04.01.22 20:43, Dave Thaler wrote:
> "If you can trust an Attesting Environment to correctly measure a 
> target environment, you can also trust it to report its own UEID, GPS 
> location, the results of a biometric authentication and lots and lots of other stuff."
> 
> Environment you can't necessarily trust the GPS location it reports 
> just gets the GPS location from an external dongle, then you'd have to 
> argument applies to time of day. the Attesting Environment uses a 
> timestamp but doesn't use a secure time protocol to get it, you can't 
> trust that other server.   So there is a difference between 
> information that is intrinsic to the Attester vs information that is extrinsic.
> 
> intrinsic claims from extrinsic claims, and I don't think there is in 
> EAT today.
> 
>     The measurer can't be the same as the measured or there is no value
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0> and
>     memory and stored data in another environment. I don't think
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0> is
> I agree that strong wording about separation in security 
> considerations is a good thing, but only for the measurement use 
> cases. That separation is not needed for huge numbers of other use 
> cases that must be covered by RATS.
> 
> LL
> 
> 
> 
>         So it's dangerous to allow the Attesting Environment and Target

---

From: Ira McDonald <[email-masked]>
Date: Wed, 5 Jan 2022 14:32:34 -0500

Hi,

+1 to Dave's comments.

No matter what system component generates them, they're all inherently just
"claims".

If separate "endorsements" are evaluated by a Verifier, then the Verifier
could advise a
Relying Party that some subset of "claims" is asserted to have some
"trustworthiness"
(not a binary value) - itself a lousy synonym for "assurance".

BTW - the current RATS Architecture uses either "trustworthy" or
"trustworthiness"
28 times!  While it uses "assurance" 4 times.  I consider this a serious
defect.

I also agree with Ned that I don't like the adjectives.  I liked
"intrinsic" and "extrinsic"
(and disliked the obscure synonyms such as "trusted claims"), but I also
agree that
"extrinsic" may not be immutably the right characterization.

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 Wed, Jan 5, 2022 at 2:10 PM Dave Thaler <dthaler=
[email-masked]> wrote:

> "trusted claims" does not make sense to me as a term for the same thing,
> since trust is about what another entity decides, not about the info in the
> claims.
>
> And when you say "such as the GPS coordinates or any other assertion that
> is now generated by an Attester as Claims in its Evidence as it has proven
> its trustworthiness (for the moment) via the intrinsic claims" my point is
> that the info in the extrinsic claims has _in general_ not been proven by
> the Attester to be correct.  Just because you have a trustworthy Attester
> does not mean that a GPS coordinate or a timestamp is actually trusted...
> you need additional effort to do that, or you have to apply a leap of
> faith.   Stating they are "trusted claims" because they come from an
> Attester that itself is trustworthy implies trust is always transitive
> which is a very dangerous thing to assume.
>
> Dave
>
> * "trusted claims": this is what you are referring to as extrinsic claim,
> I think, such as the GPS coordinates or any other assertion that is now
> generated by an Attester as Claims in its Evidence as it has proven its
> trustworthiness (for the moment) via the intrinsic claims
>
> >     <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0
> > and
> >     <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0
> > is

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 5 Jan 2022 19:45:58 +0000

+1 on Dave's point. Attestation Results is the name we've given to the output from a Verifier. This is the closes thing to "trusted claims". 

The architecture assumes that for any given AE/TE, there are ARs that satisfy a RP's trustworthiness policy such that it is safe to interact with the Attester (i.e., the AE/TE). What the AE/TE says next is what I assert is 'telemetry' - but it could be any application specific payload really. It just depends on the RP context. 

This is why I don't think of it as Evidence or even Attestation Results. The environment (Attester) is simply speaking (to the RP). 

The use case that got us here is GPS coordinates that are spoken by a Target Environment where the Verifier isn't expected to have Reference Values and it can't have Endorsements because the Endorser can't predict specific coordinates. If you stack all these dependencies up, I think it ends up being application specific data / telemetry that is meaningful to the RP specific context. Maybe the Attester would like the Verifier to forward the claims to the RP (but forwarding is a router function not a Verifier function). If the claims were held a little longer, they wouldn't be confused with attestation Role messages. 

We could call those claims 'ancilary claims'. Ancilary claims are opaque to the Verifier essentially, and are accepted by RP after attestation / trust has been established in the Attester.

-Ned

On 1/5/22, 11:10 AM, "RATS on behalf of Dave Thaler" <[email-masked] on behalf of dthaler=[email-masked]> wrote:

    Dave

    -----Original Message-----
    From: Henk Birkholz <[email-masked]> 
    Sent: Wednesday, January 5, 2022 1:50 AM
    To: Dave Thaler <[email-masked]>; Laurence Lundblade <[email-masked]>
    Cc: rats <[email-masked]>
    Subject: Re: [Rats] Often Attester == Device?

    Hi Dave,

    Viele Grüße,

    henk

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 5 Jan 2022 19:52:06 +0000

I agree with Ira that attestation provides assurance. I wouldn’t however concluded that ‘trustworthy’ or ‘trustworthiness’ are “defective” terminology since the objective of assurance is to enable at least binary decisions about whether or not to proceed. Even a fuzzy logic approach to assurance will draw threshold buckets that effectively accomplish decidable actions – maybe there are more than two buckets however.

From: RATS <[email-masked]> on behalf of Ira McDonald <[email-masked]>
Date: Wednesday, January 5, 2022 at 11:33 AM
To: Dave Thaler <dthaler=[email-masked]>, Ira McDonald <[email-masked]>
Cc: rats <[email-masked]>, Henk Berkholz <[email-masked]>, Laurence Lundblade <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Hi,

+1 to Dave's comments.

No matter what system component generates them, they're all inherently just "claims".

If separate "endorsements" are evaluated by a Verifier, then the Verifier could advise a
Relying Party that some subset of "claims" is asserted to have some "trustworthiness"
(not a binary value) - itself a lousy synonym for "assurance".

BTW - the current RATS Architecture uses either "trustworthy" or "trustworthiness"
28 times!  While it uses "assurance" 4 times.  I consider this a serious defect.

I also agree with Ned that I don't like the adjectives.  I liked "intrinsic" and "extrinsic"
(and disliked the obscure synonyms such as "trusted claims"), but I also agree that
"extrinsic" may not be immutably the right characterization.

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 WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]<mailto:[email-masked]>
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Jan 5, 2022 at 2:10 PM Dave Thaler <dthaler=[email-masked]<mailto:[email-masked]>> wrote:
"trusted claims" does not make sense to me as a term for the same thing, since trust is about what another entity decides, not about the info in the claims.

Dave

-----Original Message-----
From: Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 5, 2022 1:50 AM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>; Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Often Attester == Device?

Hi Dave,

Viele Grüße,

henk

On 04.01.22 20:43, Dave Thaler wrote:
> *From:* RATS <[email-masked]<mailto:[email-masked]>> *On Behalf Of * Laurence
> Lundblade
> *To:* Birkholz, Henk <[email-masked]<mailto:[email-masked]>>
> *Cc:* rats <[email-masked]<mailto:[email-masked]>>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Laurence,
>
>     TL;DR

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

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 5 Jan 2022 21:21:21 +0100

Hi Ira,

I see where you are going here and that is a good point of view. I 
actually agree. I was rephrasing statements to understand what the 
individual replies actually meant and I now have a better understanding 
of "intrinsic" and "extrinsic".

It seems to me that these qualities cannot be asserted by an Attester in 
a believable way.

I agree with "No matter what system component generates them, they're 
all inherently just "claims".

Corresponding endorsements up-level these claims to a certain 
trustworthiness that can be expressed in an Attestation Result to 
Relying Parties.

Thank you for all your comments that was very helpful to understand the 
current topic/issue. For me, it was difficult to grasp. Hence all my 
questions.

I also agree that a signed claims set originating from an Attester is 
just that. Only with the use of the appraisal procedure of a Verifier it 
can be established, if that signed claims set is actually evidence, a 
proof of possession, or simply an arbitrarily signed statement.

Viele Grüße,

Henk

On 05.01.22 20:32, Ira McDonald wrote:
> /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 WG
> <http://sites.google.com/site/blueroofmusic>
> <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434/
> 
> 
> On Wed, Jan 5, 2022 at 2:10 PM Dave Thaler 
> <dthaler=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     "trusted claims" does not make sense to me as a term for the same
>     thing, since trust is about what another entity decides, not about
>     the info in the claims.
> 
>     And when you say "such as the GPS coordinates or any other assertion
>     that is now generated by an Attester as Claims in its Evidence as it
>     has proven its trustworthiness (for the moment) via the intrinsic
>     claims" my point is that the info in the extrinsic claims has _in
>     general_ not been proven by the Attester to be correct.  Just
>     because you have a trustworthy Attester does not mean that a GPS
>     coordinate or a timestamp is actually trusted... you need additional
>     effort to do that, or you have to apply a leap of faith.   Stating
>     they are "trusted claims" because they come from an Attester that
>     itself is trustworthy implies trust is always transitive which is a
>     very dangerous thing to assume.
> 
>     Dave
> 
>     From: Henk Birkholz <[email-masked]
>     <mailto:[email-masked]>>
>     To: Dave Thaler <[email-masked]
>     <mailto:[email-masked]>>; Laurence Lundblade
>     <[email-masked] <mailto:[email-masked]>>
>     Cc: rats <[email-masked] <mailto:[email-masked]>>
>     * "claims about trustworthiness": this is what you are referring to
>     as intrinsic claim, I think, such as a software measurement, e.g.
>     the UEFI filesystem content, and
> 
>     claim, I think, such as the GPS coordinates or any other assertion
>     that is now generated by an Attester as Claims in its Evidence as it
>     has proven its trustworthiness (for the moment) via the intrinsic claims
> 
>     GPS
>      > *From:* RATS <[email-masked]
>     <mailto:[email-masked]>> *On Behalf Of * Laurence
>      > Lundblade
>      > *To:* Birkholz, Henk <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* rats <[email-masked] <mailto:[email-masked]>>
>       <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0>> and
>       <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0>> is
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Laurence,
>      >
>      >     TL;DR
>      >         consider the Endorser as acting like the attesting
>     environment
>      >         for the hardware Target Environment.
>      >
>      >
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rats>
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 5 Jan 2022 21:26:36 +0100

Hi Ira (again),

I do not think the separate use of "assurance" (a term that was intended 
to be avoided the more the architecture matured) in combination with 
"trustworthiness" (a term that seems to express exactly what is intended 
to be assessed about the Attester) renders the document defective. Could 
you elaborate a bit on that point of view?

I agree that assurance is a framework'ish term that has to filled with 
meaning when operationalized in an actual implementation, while 
trustworthiness is a commonly understood term that you can use without 
further definition.

Viele Grüße,

Henk

---

From: Ira McDonald <[email-masked]>
Date: Wed, 5 Jan 2022 15:51:26 -0500

Hi Henk,

Different experiences are reflected here.

I've seen hundreds of questionable uses of "trustworthiness" (without any
local definition) in public standards, that were typically understood by
readers
to be describing a binary property.

But I've used the ITU-T X.1254 concept of Levels of Assurance for a decade
in editing public standards to make obvious that "trustworthiness" is *not*
a
binary property.

Obviously, the RATS Architecture editors don't like "assurance".  Oh well.

Cheers,
- Ira

On Wed, Jan 5, 2022 at 3:26 PM Henk Birkholz <
[email-masked]> wrote:

> claims
> >      >     There are large swaths of valid attestation use cases that do
> no
> >      >     measurement.
> >      >

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 5 Jan 2022 21:56:01 +0100

Hi Ira,

maybe the lesson learned here is to also express in the architecture 
document explicitly that trustworthiness is not a binary decision. The 
Attestation Results for Secure Interactions I-D really makes that clear, 
but that might not exclude adding a sentence about that early on in the 
architecture text. Thanks!

Viele Grüße,

Henk

On 05.01.22 21:51, Ira McDonald wrote:
> in editing public standards to make obvious that "trustworthiness" is 
> *not* a
> binary property.
> 
> On Wed, Jan 5, 2022 at 3:26 PM Henk Birkholz 
>      > No matter what system component generates them, they're all
>     inherently
>      > just "claims".
>      >
>      > <http://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] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Laurence Lundblade
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >     Cc: rats <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > intrinsic claims from extrinsic claims
>      >
>      >      > "If you can trust an Attesting Environment to correctly
>     measure a
>      >      > target environment, you can also trust it to report its
>     own UEID,
>      >     GPS
>      >      > location, the results of a biometric authentication and
>     lots and
>      >     lots of other stuff."
>      >      >
>      >      > The GPS point is pretty weak.  Even if you trust the Attesting
>      >      > Environment you can't necessarily trust the GPS location
>     it reports
>      >      > unless you have some mechanism that provides such trust.  
>     E.g.,
>      >     if it
>      >      > just gets the GPS location from an external dongle, then you'd
>      >     have to
>      >      > measure the external dongle as a target environment.   A
>     similar
>      >      > argument applies to time of day. the Attesting Environment
>     uses a
>      >      > timestamp but doesn't use a secure time protocol to get
>     it, you
>      >     can't
>      >      > trust the timestamps. Similarly if it uses a secure time
>     protocol to
>      >      > some other server to get it, you can only trust the
>     timestamps if
>      >     you
>      >      > trust that other server.   So there is a difference between
>      >      > information that is intrinsic to the Attester vs
>     information that
>      >     is extrinsic.
>      >      >
>      >      > My own opinion is that there should be a clean way to
>     distinguish
>      >      > intrinsic claims from extrinsic claims, and I don't think
>     there
>      >     is in
>      >      > EAT today.
>      >      >
>      >      > *From:* RATS <[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> *On Behalf Of * Laurence
>      >      > Lundblade
>      >      > *Sent:* Tuesday, January 4, 2022 11:17 AM
>      >      > *To:* Birkholz, Henk <[email-masked]
>     <mailto:[email-masked]>>>
>      >      > *Cc:* rats <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      > *Subject:* Re: [Rats] Often Attester == Device?
>      >      >
>      >      > Hey there, so It is entirely secure to have the Attesting
>     and Target
>      >      > Environments the same for non-measurement use cases.
>      >      >
>      >      >     _Measurement Use Cases_
>      >      >
>      >      >     The measurer can't be the same as the measured or
>     there is no
>      >     value
>      >      >     in the measurement so there must be separation between
>     Target and
>      >      >     Attestation Environments for these use cases.
>      >      >
>      >      >     Examples are Linux IMA
>      >      >
>      >     
>       <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Hu%2FBXjzjz8wg%2BHtmldY97%2BL%2Fywbg%2FXd%2BwS1oZM9VNg8%3D&amp;reserved=0>>> and
>      >      >     the typical layered attestation / staged boot with a TPM.
>      >      >
>      >      >     By measurement I mean one environment taking hashes or
>     such
>      >     of SW,
>      >      >     memory and stored data in another environment. I don't
>     think
>      >      >     reporting a UEID or GPS location is a measurement.
>      >      >
>      >      >     _Reporting / Trust Establishment Use Cases_
>      >      >
>      >      >     If you can trust an Attesting Environment to correctly
>     measure a
>      >      >     target environment, you can also trust it to report
>     its own UEID,
>      >      >     GPS location, the results of a biometric
>     authentication and
>      >     lots and
>      >      >     lots of other stuff.
>      >      >
>      >      >     There are large swaths of valid attestation use cases
>     that do no
>      >      >     measurement.
>      >      >
>      >      >     Secure examples, in use by the millions (billions?), today
>      >     include
>      >      >     FIDO and the Android Key store. OMA DRM
>      >      >
>      >     
>       <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C2f0288808d9a4744591d08d9d030b896%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769730603940661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QoTn6%2B5rX0yRTOCBq6bKPV%2BAFdSAXvoeptX%2FpWGIRQ4%3D&amp;reserved=0>>> is
>      >      >     essentially the same architecture. IoT on-boarding is
>     another.
>      >      >
>      >      > I agree that strong wording about separation in security
>      >      > considerations is a good thing, but only for the
>     measurement use
>      >      > cases. That separation is not needed for huge numbers of
>     other use
>      >      > cases that must be covered by RATS.
>      >      >
>      >      > LL
>      >      >
>      >      >
>      >      >
>      >      >     On Jan 4, 2022, at 6:31 AM, Henk Birkholz
>      >      >     <[email-masked]
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >     Hi Laurence,
>      >      >
>      >      >     TL;DR
>      >      >     The RATS architecture does allow for collapsing Attesting
>      >      >     Environment and Target Environment. The benefits the RATS
>      >      >     architecture provides are basically nullified, if the
>     Attesting
>      >      >     Environment and Target Environment are the same.
>     Exactly *zero*
>      >      >     claims about trustworthiness can be generated. Maybe a few
>      >     "trusted
>      >      >     claims" can be generated - but that is already a far
>     stretch.
>      >      >
>      >      >     There is a lot to unpack here. But I'd like to
>     highlight one
>      >      >     specific point that we never dared to really address
>      >     explicitly and
>      >      >     now that you are kinda voicing that for "the third time"
>      >     (which is a
>      >      >     charm), I am gonna focus on that one first.
>      >      >
>      >      >     Please find the target of my comment in the quote below.
>      >      >
>      >      >     On 29.12.21 15:48, Laurence Lundblade wrote:
>      >      >
>      >      >         Note that it is OK in RATS for the target
>     environment and
>      >      >         attestation environments to be the same.
>      >      >
>      >      >
>      >      >     The reason being: I've been disagreeing with that
>     statement for a
>      >      >     long time now. And still I've been trying to be neutral on
>      >     this. But
>      >      >     I think this starts to become an issue now. While every
>      >     individual
>      >      >     of course can have an own opinion on this issue, the
>     working
>      >     group
>      >      >     must now form a consensus opinion.
>      >      >
>      >      >     This is and always was a very dangerous assumption
>     that the
>      >     editors
>      >      >     have tolerated for quite a while now. Let's start with a
>      >      >     controversial individual statement: the recent years have
>      >     shown us
>      >      >     that this simply is not true - it is not OK. The
>     quality of
>      >      >     "Evidence" in such a scenario is close to a "signing
>     fool",
>      >     maybe it
>      >      >     suffices for a proof of possession and still then...
>      >      >
>      >      >     I would like to quote Dave's final comment in his recent
>      >     reply here:
>      >      >
>      >      >
>      >      >         So it's dangerous to allow the Attesting
>     Environment and
>      >     Target
>      >      >         Environment to be the same.   As Ned mentions, an
>      >     Endorser can
>      >      >         be used to attest to the trustworthiness of a
>     hardware Target
>      >      >         Environment.  In that sense, one could
>      >      >         consider the Endorser as acting like the attesting
>      >     environment
>      >      >         for the hardware Target Environment.
>      >      >
>      >      >
>      >      >     I 100% agree with Dave (and implicitly Ned) here and
>     would go
>      >     as far
>      >      >     as to propose a corresponding addition to the RATS
>     Security
>      >      >     Considerations, if that has not been made unmistakably
>     clear
>      >     enough.
>      >      >
>      >      >
>      >      >     Viele Grüße,
>      >      >
>      >      >     Henk
>      >      >
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <https://www.ietf.org/mailman/listinfo/rats
>     <https://www.ietf.org/mailman/listinfo/rats>>
>      >
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 5 Jan 2022 13:53:48 -0800

There’s a lot to unpack in this discussion, so it will take a few messages...

> On Jan 4, 2022, at 11:43 AM, Dave Thaler <[email-masked]> wrote:
> 
> “If you can trust an Attesting Environment to correctly measure a target environment, you can also trust it to report its own UEID, GPS location, the results of a biometric authentication and lots and lots of other stuff.”
>  
> The GPS point is pretty weak.  Even if you trust the Attesting Environment you can’t necessarily trust the GPS location it reports unless you have some mechanism that provides such trust.   E.g., if it just gets the GPS location from an external dongle, then you’d have to measure the external dongle as a target environment. 

Theres a whole range of ways the GPS receiver could be bound to the Attesting Environment:
- On the same chip in the same TEE that is the Attesting Environment
- Same chip in a subsystem securely booted by the TEE (no measurement necessary)
- Same chip and measured by the TEE
- Same chip, but in Android, GPS debug off
- Same chip, but in Android, GPS debug allowed
- Same PCB
- Connected via serial cable and provides attestation to the TEE 
- Connected via a serial cable 

An RP using the GPS claim probably wants to know a little about which it is to know how much to trust it. Characterizing that is probably beyond the scope of EAT. It’s just too complex and variable by use case.

Qualcomm had a product that provided Trusted Location and was roughly in the middle of this range. It guaranteed that the GPS was not coming from an external dongle, that the user couldn’t fake it by turning on Android location service debugging and such.

Of course any GPS location is subject to RF spoofing since GPS satellite signals aren’t signed. The user of Trusted Location needs to recognize this. OTOH a Location Claim could be more secure if it combined several input signals or used some special high security input signal. The military spec trusted location?

>   A similar argument applies to time of day… the Attesting Environment uses a timestamp but doesn’t use a secure time protocol to get it, you can’t trust the timestamps.  Similarly if it uses a secure time protocol to some other server to get it, you can only trust the timestamps if you trust that other server.   So there is a difference between information that is intrinsic to the Attester vs information that is extrinsic.

I think you can make all the same arguments for a time stamp. It could be that the time stamp claim is implemented so that it only ever uses a secure time protocol and a trusted server. The timestamp claim could be very secure even though it came from outside the device, but you as an RP would have to somehow know that. I think trying to specify a claim for such degrees of security in EAT or RATS would be big overreach.

>  
> My own opinion is that there should be a clean way to distinguish intrinsic claims from extrinsic claims, and I don’t think there is in EAT today.

So, not possible to classify the degree of security of claims, especially as intrinsic or extrinsic IMO.

LL

> Examples are Linux IMA <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Flinux-ima%2Fwiki%2FHome%2F&data=04%7C01%7Cdthaler%40microsoft.com%7Cf207ba48db774f46960108d9cfb6cf7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769207390000682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=SuihFbMhcoyI8mm4harGOZWO%2FNsZ47%2Fecp%2FzCyZUZ2E%3D&reserved=0> and the typical layered attestation / staged boot with a TPM.
>  
> Secure examples, in use by the millions (billions?), today include FIDO and the Android Key store. OMA DRM <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FOMA_DRM&data=04%7C01%7Cdthaler%40microsoft.com%7Cf207ba48db774f46960108d9cfb6cf7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637769207390000682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0dB90ccoob%2BZCb7e%2Bvvdh3xXqMNhd3QWoVOdRvGE4KY%3D&reserved=0> is essentially the same architecture. IoT on-boarding is another.
>  
> On Jan 4, 2022, at 6:31 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Laurence,
> 
> TL;DR

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 6 Jan 2022 11:55:49 -0800

TLDR — I agree with Ira that we could rely less on trusted/untrusted in RATs. 

“Trust" really works to market and promote security. It says “we know what we’re doing and you should use our stuff." 

Trusted Execution Environment
Trusted Computing Group
Trusted Firmware
Root of Trust
Trusted Platform Module

“Assured" doesn’t have the same ring. 

It’s a lot easier to think about complicated things in black and white terms so we like trusted/untrusted.

SW can theoretically be made completely correct, but the cost to make SW so is high (e.g., Common Criteria certification). What drove it home for me is the realization that HW can never be made impervious to all attacks because of things like focused ion beams, glitching attacks and such.

I think it is OK to use “trust” as long as it is qualified correctly. s/trust/assure/ is probably not the right approach  There is nothing wrong with saying “trust in Attestation Evidence is based on Endorsements”. The definition of Attester seems like an OK use because it is put in context.

   Attester:  A role performed by an entity (typically a device) whose
      Evidence must be appraised in order to infer the extent to which
      the Attester is considered trustworthy, such as when deciding
      whether it is authorized to perform some operation.

LL

> On Jan 5, 2022, at 11:32 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> +1 to Dave's comments.
> 
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> On Wed, Jan 5, 2022 at 2:10 PM Dave Thaler <dthaler=[email-masked] <mailto:[email-masked]>> wrote:
> From: Henk Birkholz <[email-masked] <mailto:[email-masked]>> 
> To: Dave Thaler <[email-masked] <mailto:[email-masked]>>; Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> > *From:* RATS <[email-masked] <mailto:[email-masked]>> *On Behalf Of * Laurence 
> > Lundblade
> > *To:* Birkholz, Henk <[email-masked] <mailto:[email-masked]>>
> >     <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> > 
> >     Hi Laurence,
> > 
> >     TL;DR
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 11 Jan 2022 10:03:45 -0800

In reworking the EAT introduction section <https://github.com/ietf-rats-wg/eat/pull/149> to address comments by Hannes, I reviewed the RATS architecture introduction section. In theory they should be fairly similar.

The RATS architecture introduction is more about classifying the Attester as either good or bad, trusted/untrusted. EAT is (and always was) oriented around providing attested input to the RP. Both are important, but if it were up to me, I’d add adjust RATS Architecture, particularly the first paragraphs to be less about a “good state” by including comments about RP inputs.

I gave UEID and GPS location as examples of useful attestations that do not involve measurement. They weren’t the best examples.

FIDO and the Android Key store are both good examples of attestation use cases that do not involve measurement.

For FIDO the Attester is the FIDO Authenticator. Its job is to authenticate the human with biometrics and generate a signature on success. Attestation is important for the RP to know that the Authenticator/Attester is doing the proper biometric checks before generating the signature. The attestation is thus “this is a valid FIDO authenticator”. The RP decides which authenticators to trust based on public keys (endorsements) from the FIDO authenticator vendors.

The Android key store is similar in many ways. Here Google acts as the Endorser.

There are many independent implementations of these with 100’s of millions of deployments of these in broad use. Deep formal security analysis has been done of the architecture of these. They are perfectly fine attestation use cases that do not involve measurement and are not about determining if the Attester is in a good state.

LL

P.S., Below I was giving some of the reasons we like to use the term “trust” in a binary way to acknowledge them, and then hopefully to move on to a more useful less binary use of “trust”.

> On Jan 6, 2022, at 11:55 AM, Laurence Lundblade <[email-masked]> wrote:
> 
>> On Jan 5, 2022, at 11:32 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> +1 to Dave's comments.
>>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Jan 2022 11:42:30 -0500

Laurence Lundblade <[email-masked]> wrote:
    > In reworking the EAT introduction section
    > <https://github.com/ietf-rats-wg/eat/pull/149> to address comments by
    > Hannes, I reviewed the RATS architecture introduction section. In
    > theory they should be fairly similar.

    > The RATS architecture introduction is more about classifying the
    > Attester as either good or bad, trusted/untrusted.

Yes, I would say that this is the entire point of Remote Attestation.

    > EAT is (and always
    > was) oriented around providing attested input to the RP.
    > Both are
    > important, but if it were up to me, I’d add adjust RATS Architecture,
    > particularly the first paragraphs to be less about a “good state” by
    > including comments about RP inputs.

I don't want to do this, because the point of the Attester/Verifier/RP
architecture is that we can have interoperability even when there are
different designs for the Verifier.

If we have to qualify things for the RP, then the Verifier really isn't doing
it's job.

Sure, there may be many quantities and/or qualities that the RP cares about beyond a boolean, "is secure according to contract XYZ".

For instance, a movie theatre or other event venue might care about
    "ticket holder is > 18", or "ticket holder is > 13"

while not really caring whether the ticket holder's birth name/birth gendre
of "Tanya"/"female" is the same as the ticket holder's presentation as "Tony"/"male"
(an example of PII that the theatre doesn't need to know).

But, I don't think that it's useful to annotate the the "ticket holder is >
18" claim with any other comment.

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

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 13 Jan 2022 16:50:49 +0000

Laurence,
    	> including comments about RP inputs.
Currently the RP inputs are Attestation Results and Appraisal Policy for Attestation Results. Are you saying the introduction in arch should talk to these inputs sooner in the document?
Thx,
Ned

On 1/12/22, 8:46 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 13 Jan 2022 11:48:13 -0800

Hi Ned,

Here’s the text from RATS architecture Intro:

Systems that have been attested and verified to be in a good state (for some value of "good") can improve overall system posture. Conversely, systems that cannot be attested and verified to be in a good state can be given reduced access or privileges, taken out of service, or otherwise flagged for repair.

Here’s text from the EAT intro PR <https://github.com/ietf-rats-wg/eat/pull/149>:

EAT provides the definition of a base set of claims that can be made about an entity, a device, some software and/or some hardware. This claims set is received by a relying party who uses it to decide if and how it will interact with the remote entity.

I think it is possible for a device to be in a good state (e.g., all the measurements check out) and for the device still to be not trusted. It produces a valid attestation, but it is made by an untrusted manufacturer, debugging is enabled, it didn’t receive the necessary certifications or it is in the wrong geographic location.

I also think it is fine for attestation to do no measurement. It accepted by the Verifier to be in a good state if it is producing valid attestations. This is how FIDO and the Android Key Store attestation work.

It is not critical to me that the RATS Architecture Introduction be changed. 

I will continue to periodically mention FIDO and Android use cases, non-TPM/TCG use cases and non-measurement use cases because they are big, widely-deployed remote attestation use cases that are in scope for the charter.

LL

(By measurement I mean hashing some or all of the code, memory, file system or configuration and comparing to expected values)

> On Jan 13, 2022, at 8:50 AM, Smith, Ned <[email-masked]> wrote:
> 
> Laurence,

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 13 Jan 2022 22:20:47 +0000

> I think it is possible for a device to be in a good state (e.g., all the measurements check out) and for the device still to be not trusted. It produces a valid attestation, but it is made by an un…
[nms] The RATS Arch expects Appraisal Policy for Evidence will identify untrusted manufacturers which rules that out as a possible way for RP to invalidate an Attestation Result. Endorsements might say whether or not debug enable was fused off/on at manufacturing time making evidence to the contrary mute. Endorsements might also give the Verifier reasons to fail the appraisal. I don’t think it is an expectation that a Verifier would return an appraisal (aside from accidental or malicious events) that contradicts RP expectations. The RP could, based on AR, make decisions resulting in a change to privileges/access etc – as the text below suggests. I don’t believe the RATS Arch intends to say that a RP must second guess Verifier results based on Verifier inputs. It might be reasonable for RP to expect to see AR entailment that documents how the Verifier arrived at a conclusion. The Verifier and RP/RPOwner are assumed to have worked out beforehand what Verifier inputs are acceptable to the RP. Otherwise, the RP and Verifier could end up in a guess-and-check interaction that is potentially never ending.
>I also think it is fine for attestation to do no measurement. It accepted by the Verifier to be in a good state if it is producing valid attestations. This is how FIDO and the Android Key Store atte…
[nms] Agree. An Attester might only authenticate and Verifier might obtain trustworthiness claims from Endorsers. That could be sufficient to arrive at a satisfactory attestation result.

[nms] I don’t see an issue with EAT or any other draft reinforcing these concepts through example or deeper clarification. The main concern of this thread was that someone reading both EAT and RATS Arch would observe conflicting statements. But it appears that isn’t the case?

>> EAT is (and always was) oriented around providing attested input to the RP.
>> Both are important, but if it were up to me, I’d add adjust RATS Architecture, particularly the first paragraphs to be less about a “good state” by including comments about RP inputs.
>
>  I don't want to do this, because the point of the Attester/Verifier/RP architecture is that we can have interoperability even when there are different designs for the Verifier.
[nms] Correct me if I’m wrong, but EAT was about defining claims. The RATS Arch makes a point of making claims uppercase (Claims) and asserts they can exist as Evidence, Reference Values, Endorsements or Attestation Results. The point of having Claims defined in a standard addresses MCR’s point about Verifier interoperability.
[nms] As a designer of a claims collection algorithm in an Attester, it’s possible that claims collection for some Claims would not be straight forward or possible. It might make more sense to included them in Endorsements or Reference Values. I don’t think it was a goal of EAT to bias the Claims it defines one way or the other. Maybe I’m mistaken?

From: Laurence Lundblade <[email-masked]>
Date: Thursday, January 13, 2022 at 11:48 AM
To: "Smith, Ned" <[email-masked]>
Cc: Michael Richardson <[email-masked]>, rats <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Hi Ned,

Here’s text from the EAT intro PR<https://github.com/ietf-rats-wg/eat/pull/149>:

LL

On Jan 13, 2022, at 8:50 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

Laurence,

On 1/12/22, 8:46 AM, "RATS on behalf of Michael Richardson" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

   Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

EAT is (and always

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

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 14 Jan 2022 09:48:04 +0100

Hi Laurence,

a few comments in-line:

On 13.01.22 20:48, Laurence Lundblade wrote:
>     Systems that have been attested and verified to be in a good state
>     (for some value of "good") can improve overall system posture.
>     Conversely, systems that cannot be attested and verified to be in a
>     good state can be given reduced access or privileges, taken out of
>     service, or otherwise flagged for repair.
> 
> 
> Here’s text from the EAT intro PR 
> <https://github.com/ietf-rats-wg/eat/pull/149>:
> 
>     EAT provides the definition of a base set of claims that can be made
>     about an entity, a device, some software and/or some hardware. This
>     claims set is received by a relying party who uses it to decide if
>     and how it will interact with the remote entity.
> 
> 
> I think it is possible for a device to be in a good state (e.g., all the 
> measurements check out) and for the device still to be not trusted. It 
> produces a valid attestation, but it is made by an untrusted 
> manufacturer, debugging is enabled, it didn’t receive the necessary 
> certifications or it is in the wrong geographic location.

Well, then that device actually is not in a good state, as "untrusted 
manufacturer, debugging is enabled, etc." are asserted. The 
"measurements that check out" are actually not really claims about 
trustworthiness as they are not really believable in this scenario. 
Maybe I am missing something.

> 
> I also think it is fine for attestation to do no measurement. It 
> accepted by the Verifier to be in a good state if it is producing valid 
> attestations. This is how FIDO and the Android Key Store attestation work.

While that is technically viable according to the architecture, in this 
scenario the use of an Attesting Environment boils down to a "trust us". 
That is fine, as it is efficient and fast. Maybe you cannot produce 
Evidence about trustworthiness and have to rely solely on trusted 
claims, such as "debug mode" and endorsed values (that are not coming 
from the Attester, but are about the Attester and believable/trusted). 
In this scenario the Verifier does mostly signature checking and 
policies that process the claims can build on an assumption that the 
Attester is trustworthy.

> I will continue to periodically mention FIDO and Android use cases, 
> non-TPM/TCG use cases and non-measurement use cases because they are 
> big, widely-deployed remote attestation use cases that are in scope for 
> the charter.

Exactly. We made sure that the FIDO scenario is in direct interoperable 
support. Meanwhile, webauthn-2 brought a lot of improvements, too, as 
the RATS architecture evolved (and it feels to me that it now also 
aligns much more with the RATS work).

I actually like the slightly different scopes of the two intros, tbh.

Viele Grüße,

Henk

> 
> LL
> 
> 
> (By measurement I mean hashing some or all of the code, memory, file 
> system or configuration and comparing to expected values)
> 
> 
> 
> 
>> Currently the RP inputs are Attestation Results and Appraisal Policy 
>> for Attestation Results. Are you saying the introduction in arch 
>> should talk to these inputs sooner in the document?
>> Thx,
>> Ned
>>
>> On 1/12/22, 8:46 AM, "RATS on behalf of Michael Richardson" 
>> <[email-masked] <mailto:[email-masked]> on behalf of 
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>> <https://github.com/ietf-rats-wg/eat/pull/149 
>>> <https://github.com/ietf-rats-wg/eat/pull/149>> to address comments by
>>    Sure, there may be many quantities and/or qualities that the RP 
>> cares about beyond a boolean, "is secure according to contract XYZ".
>>
>>    Michael Richardson <[email-masked] 
>> <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 14 Jan 2022 13:27:12 +0000

[LL] >>> I also think it is fine for attestation to do no measurement. It accepted by the Verifier to be in a good state if it is producing valid attestations. This is how FIDO and the Android Key Store attestation work.

[TH] I think the RATS-Arch is flexible enough to cover this use-case, but there needs to be some way for the Verifier to communicate to the RP that no measurement was done (of the Attesting Environment or even the key-store environment in the Attester). So this scenario becomes simply a signed claim by the device (Attester) of proof-of-key-possession via a challenge nonce.

Would it be useful for EATS to refer to the notion of “Trustworthiness Tier” from draft-rats-ar4si ?

--thomas

From: RATS <[email-masked]> on behalf of Ned Smith <[email-masked]>
Date: Thursday, January 13, 2022 at 5:21 PM
To: Laurence Lundblade <[email-masked]>
Cc: Michael Richardson <[email-masked]>, rats <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Hi Ned,

LL

Laurence,

EAT is (and always

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 18 Jan 2022 09:11:23 -0800

> On Jan 14, 2022, at 5:27 AM, Thomas Hardjono <[email-masked]> wrote:
> 

It is much more than proof of possession. In the case of FIDO, it is also biometric authentication and all FIDO rules and procedures. Whomever is trusting the FIDO authenticator wants to know that all this is being done to know the end user was properly authenticated. They know this because it is attested as being a FIDO Authenticator.

Another class of cases is DRM, content protection, IP protection and such. The RP wants to know that device will protect the content before it gives the content to it. An Attester might be good at protecting videos, but bad a protecting corporate secrets and bad at biometric authentication.

> Would it be useful for EATS to refer to the notion of “Trustworthiness Tier” from draft-rats-ar4si ?

Basically, I think we can do a little bit of trust characterization in RATS, but the space is too big and varied by use case to do anything comprehensive.

Even just for measurement and non-measurement there’s a range. Some attesters will measure badly, some will measure partially really well and some that don’t measure at all will be excellent and very trusted.

The TCG may want to create some claims, root certificate or such to indicate that the measurements made conform to some criteria they set, because all measurement will not be done the way it thinks it should be done.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 18 Jan 2022 18:41:53 +0100

Hi Laurence,

please find replies in-line:

On 18.01.22 18:11, Laurence Lundblade wrote:
> 
>> On Jan 14, 2022, at 5:27 AM, Thomas Hardjono <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> [LL] >>> I also think it is fine for attestation to do no measurement. 
>> It accepted by the Verifier to be in a good state if it is producing 
>> valid attestations. This is how FIDO and the Android Key Store 
>> attestation work.
>> [TH] I think the RATS-Arch is flexible enough to cover this use-case, 
>> but there needs to be some way for the Verifier to communicate to the 
>> RP that no measurement was done (of the Attesting Environment or even 
>> the key-store environment in the Attester). So this scenario becomes 
>> simply a signed claim by the device (Attester) of 
>> proof-of-key-possession via a challenge nonce.
> 
> It is much more than proof of possession. In the case of FIDO, it is 
> also biometric authentication and all FIDO rules and procedures. 
> Whomever is trusting the FIDO authenticator wants to know that all this 
> is being done to know the end user was properly authenticated. They know 
> this because it is attested as being a FIDO Authenticator.

While it is of course more (otherwise it would be just RFC 7800 - not 
trying to belittle RFC 7800 here; that one is great!), but I think what 
Thomas was trying to say here is that the trust relationship is 
basically boiled down to proof of possession: "if signed by this private 
key - that you can check via public key and corresponding trust anchor - 
than all assertions are up-leveled to Evidence Claims".

In essence, it is actually proof-of-possession with various modular 
means how to handle the key that you possess and well-defined procedures 
and policies around it. That is the core of FIDO.

That is literally why the slogan of FIDO is "simpler stronger 
authentication". Remote attestation is an option (for example as defined 
in webauthn-2), which is why it was so important to the working group to 
align these concepts with FIDO.

> Another class of cases is DRM, content protection, IP protection and 
> such. The RP wants to know that device will protect the content before 
> it gives the content to it. An Attester might be good at protecting 
> videos, but bad a protecting corporate secrets and bad at biometric 
> authentication.
> 
> Basically, I think we can do a little bit of trust characterization in 
> RATS, but the space is too big and varied by use case to do anything 
> comprehensive.

I do not agree with the notion related to “Trustworthiness Tiers”, 
because these are targeting exactly that: comprehensive trust 
characterization. Sorry, but I fundamentally disagree with that comment 
and would need some in-depth explanation how you arrived at that conclusion.

> 
> Even just for measurement and non-measurement there’s a range. Some 
> attesters will measure badly, some will measure partially really well 
> and some that don’t measure at all will be excellent and very trusted.

And the Verifier's policy will make sense of that spectrum.

> 
> The TCG may want to create some claims, root certificate or such to 
> indicate that the measurements made conform to some criteria they set, 
> because all measurement will not be done the way it thinks it should be 
> done.

Referring here to TCG and FIDO in the same context of course could be 
interpreted as the "space is too big". But that is taking topics out of 
context in order to portrait that feeling. Pronounce as "they" and "it" 
also do not help. In contrast, I think that we layed out very well in 
the architecture how the appraisal of evidence that includes 
measurements asserting the trustworthiness of a device and based on that 
the appraisal of trusted claims (such as "debug mode" or "gps 
coordinates") work in RATS.

Viele Grüße,

Henk

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 18 Jan 2022 21:23:50 +0000

(not as chair)
I'm trying to assess if this thread is leading somewhere concrete.
It seems LL was observing that it should be possible for Evidence to be the empty set and cited a FIDO use case.
TH seems to be saying that the RATS Arch doesn't prevent this interpretation.
HB seems to concur, but acknowledges something needs to be signed in Evidence, since signing the empty set doesn't work, if for no other reason than the Verifier needs to know who the Attester is.

What possibly is missing is the acknowledgement that the Verifier might receive Claims directly from an Endorser that adds the "FIDO" claim which presumably implies a bunch of properties about the Attester. (The RATS Arch suggests is an expected property of the arch).

TH seems to be saying that having standardized ARs is useful to RPs because RPs might not (want?) to know about the "FIDO" claim as it implies a bunch of things, but rather wants to know if those things reasonably implies a particular 'tier' as defined by one of the drafts. To which I agree. That seems reasonable.

Is this thread basically an expression of us being in agreement then?
-Ned

On 1/18/22, 9:42 AM, "Henk Birkholz" <[email-masked]> wrote:

    Hi Laurence,

    Viele Grüße,

    Henk

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 18 Jan 2022 22:01:43 +0000

> HB seems to concur, but acknowledges something needs to be signed in
> Evidence, since signing the empty set doesn't work, if for no other reason than
> the Verifier needs to know who the Attester is.

Yes.  And the signature also could be spanning a proof-of-freshness.

> What possibly is missing is the acknowledgement that the Verifier might receive
> Claims directly from an Endorser that adds the "FIDO" claim which presumably
> implies a bunch of properties about the Attester. (The RATS Arch suggests is an
> expected property of the arch).
> 
> TH seems to be saying that having standardized ARs is useful to RPs because RPs
> might not (want?) to know about the "FIDO" claim as it implies a bunch of
> things, but rather wants to know if those things reasonably implies a particular
> 'tier' as defined by one of the drafts. To which I agree. That seems reasonable.

AR4SI Section 2.2 intentionally does not provide guidance on all the possible identity types so that the Trustworthiness Claims can be independent of identity format.
 
> Is this thread basically an expression of us being in agreement then?

I like this interpretation.

Eric

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 18 Jan 2022 18:24:13 -0800

> On Jan 18, 2022, at 1:23 PM, Smith, Ned <[email-masked]> wrote:
> 
> (not as chair)

I’m asserting that measurement is not necessary for many attestation use cases, one of which is FIDO.

(Where measurement is hashing some code, memory, config… and comparing to reference values. Reporting location, UEID, manufacturer, proof of passion is not measurement to me).

I’m OK with Evidence that is almost empty, only a nonce, Evidence with tons of claims that aren’t measurement claims, Evidence with tons of claims that are measurements, combos and so on.

> TH seems to be saying that the RATS Arch doesn't prevent this interpretation.

Agreed.

> What possibly is missing is the acknowledgement that the Verifier might receive Claims directly from an Endorser that adds the "FIDO" claim which presumably implies a bunch of properties about the…

I don’t think this is missing. Certainly not for the FIDO use case.

The FIDO protocol has extensible/pluggable attestation with a typing mechanism for different formats of attestation. EAT will hopefully be one of those. The FIDO Server knows what is going on before looking into the EAT. FIDO is the dog, Attestation/RATS/EAT is the tail. :-) 

It’s often the root certificates that the FIDO Server trust that tells it that the Authenticator/Attester is FIDO and does FIDO stuff. So maybe that is an implicit claim in the endorsement?

> TH seems to be saying that having standardized ARs is useful to RPs because RPs might not (want?) to know about the "FIDO" claim as it implies a bunch of things, but rather wants to know if those t…

I’m fine with defining some trust tiers in this WG and they will be useful depending on the use case, but don’t see them as universal.

> Is this thread basically an expression of us being in agreement then?

Sort of :-)

LL

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 19 Jan 2022 11:22:57 +0100

Hi Laurence,

comments again in-line.

> It’s often the root certificates that the FIDO Server trust that tells it that the Authenticator/Attester is FIDO and does FIDO stuff. So maybe that is an implicit claim in the endorsement?

I am sorry to berate that point, but what you are describing here is 
exactly what we meant. You start with a proof of possession. In the FIDO 
scenario that enables the individual identification of a device (in a 
subset of cases identifying Claims are included in the otherwise rather 
sparse Evidence Claims Set), and thereby:

1.) the Verifier/FIDO Service knows that the Authenticator/Attester is 
FIDO and does FIDO stuff, and
2.) external "endorsed values" about an Attester can be associated with 
that now identified Attester

This is literally how FIDO works. Or what essential discrepancy am I 
missing here? Maybe we are still in some unwittingly limbo of 
disconnect, but I read the fido and webauthn-2 specs and this is how it 
seems to work. SO I am really interested, if there is a distinguishing 
feature that I am not seeing today.

> c

Today, I do not share that assessment with the exception that the work 
is not finished by the WG of course - but that is actually the goal. 
Having said that: this kind of universally understood Attestation 
Results is not suitable for any scenario, I think. But it will be there 
and everybody can chose to conform - or not (and now help to extend it).

Viele Grüße,

Henk

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 19 Jan 2022 15:04:22 +0000

>>> and everybody can chose to conform - or not (and now help to extend it).

Since we are in the process of considering re-chartering of RATS, is this the opportune moment to talk about “Device Profiles” or “Attester Profiles”?   By “attester profiles” I mean the Attester construction and device compositions (HW/SW/FW) that may be relevant to certain industry verticals.

Clearly a physical router is different from consumer smartphone and different from IoT sensors and from VM stack using DICE, etc. etc.

The reason I bring-up “profiles” is to make the point that the correct interpretation by the (dumb) RP of the “Trustworthiness Tiers” (or any kind of Appraisal Results easy-to-parse labeling) involves the RP understanding the nature of the device that is the Attester.

So yes, a “universally understood attestation result” is difficult (impossible) to understand if there is no context for the RP. The “profile” is part of this background context.

--thomas

From: Henk Birkholz <[email-masked]>
Date: Wednesday, January 19, 2022 at 5:23 AM
To: Laurence Lundblade <[email-masked]>, Ned Smith <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Often Attester == Device?

Hi Laurence,

comments again in-line.

On Jan 18, 2022, at 1:23 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

(not as chair)

Agreed.

c

Sort of :-)

LL

Viele Grüße,

Henk

-Ned

On 1/18/22, 9:42 AM, "Henk Birkholz" <[email-masked]<mailto:[email-masked]>> wrote:

     Hi Laurence,

On Jan 14, 2022, at 5:27 AM, Thomas Hardjono <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

Would it be useful for EATS to refer to the notion of “Trustworthiness
Tier” from draft-rats-ar4si ?

LL

     Viele Grüße,

     Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Jan 2022 11:28:24 -0500

Smith, Ned <[email-masked]> wrote:
    > (not as chair) I'm trying to assess if this thread is leading somewhere
    > concrete.

I don't think so.

    > It seems LL was observing that it should be possible for
    > Evidence to be the empty set and cited a FIDO use case.

That's fine.

    > TH seems to be
    > saying that the RATS Arch doesn't prevent this interpretation.

Agreed.