Re: [Rats] Entity vs. role

["Smith, Ned" <[e-mail]>]

See inline below

From: "Panwei (William)" <[e-mail]>
Date: Tuesday, March 29, 2022 at 9:10 PM
To: "Smith, Ned" <[e-mail]>, "Eric Voit (evoit)" <[e-mail]>, Laurence Lundblade <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Thomas Fossati <[e-mail]>
Subject: RE: [Rats] Entity vs. role

Hi Ned,

According to the definition of Attester: Attester is a role performed by an entity, Attester generates Evidence which is appraised to infer the trustworthiness of this **Attester**. And in the Evidence are the claims about the attributes of the Target Env and the Evidence is signed by the Attesting Env, so inferring the trustworthiness of the Attester is inferring the trustworthiness of the Attesting Env and the Target Env, so the Attester includes both the Attesting Env and the Target Env.
From the perspective of actions, it is true that an Attester mainly has the two actions (a) and (b). But action (a) involves Attesting Env and Target Env at the same time, because the claims are the attributes about the Target Env, and this action happens within the Attester. So, again, my understanding is that the Attesting Env and Target Env are both included in the Attester.

>But when you say “The Attesting Env implements the Attester role”, it gives me the feeling that Attester collects claims from the Target Env,
>which makes the Target Env become a role at the same level as Attester, Verifier, and Relying Party. So, this is how I’m confused.
[nms] I think it makes sense to qualify use of “Attester” in terms of an entity vs. role. Since the Arch draft defined upper case Attester as a role, one might reasonably infer lower case attester refers to an entity. That may be too subtle hence more pedantic qualification is helpful such as “the attester as an entity” etc…
In my remarks, Target Env always refers to an entity (i.e., a component of the attester entity). Attester Env always refers to a component of the attester entity that implements at least a portion of the Attester role functionality. A combination of Attester Environments may cooperate to implement all of the Attester role functions. I also regard the root of trust functionality to be an Attesting Environment.

I don’t think it is reasonable to assert that a Target Env implements Attester role functionality unless there is an Attesting Env that is a sub-component of the Target Env. This is illustrated in the layered attester example. The composite-device example shows a case where Target Environments don’t have embedded Attesting Environments and in these cases the TEs don’t implement Attester role functions. Hence, it’s reasonable to conclude they don’t need to be considered part of the Attester role. They however are part of the attester entity.

Maybe if you can come up with a set of functionality that the Target Env performs that aligns with the duties of the Attester role, you can convince yourself that it is/isn’t a role?

From the perspective of claims collection, the TE is passive it shouldn’t have the ability to lie to the Attesting Env about it’s claims. A common case where a TE may be perceived as not passive is if the TE is a uController (uC-A) accessed over a bus interface and the Attesting Env is a different uController (uC-B) on the same bus. Since the TE has its own thread of execution and the AE relies on the bus for conveyance of collected claims, the AE is at risk of being lied to by the TE (as well as by a MITM on the bus – but that is a different issue).

A better way to approach this scenario is for uC-A to be considered a distinct root-of-trust (a.k.a. an AE) that applies the layered device pattern. Then uC-B might be used as a “lead” Attester to relay uC-A’s Evidence to a Verifier. uC-A and uC-B are essentially peer nodes rather than a system of AE and TE.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:[e-mail]] On Behalf Of Smith, Ned
Sent: Wednesday, March 30, 2022 12:47 AM
To: Panwei (William) <[e-mail]>; Eric Voit (evoit) <[e-mail]>; Laurence Lundblade <[e-mail]>
Cc: [e-mail]; Thomas Fossati <[e-mail]>
Subject: Re: [Rats] Entity vs. role

If the capabilities or actions that an Attester performs includes (a) collection of claims and (b) creation of evidence which generally implies signing of collected claims. Then a Target Environment doesn’t do either (a) or (b). Target Env appears to be a passive component of the Attester (entity) rather than something that implements the Attester role within the Attester (entity).

It may be reasonably inferred that (b) could include (c) storage of keys / claims or (d) incorporation of freshness and recentness values.

The layering example suggests that if an Attesting Env is included in a Target Env, the target Attesting Env is passive and relies on the outer Attesting Env until evidence is created before the target (passive) Attesting Env becomes active. Hence, it is correct to refer to it as the Target Env until its trustworthiness details have been processed by the outer Attesting Env.

The system of Target and Attesting Environments are abstract terminology for ways to deconstruct / compose the Attester entity.

The RATS Arch is both an introduction to attestation concepts (and hence needs to use prose that is consumable by uninitiated readers; and a framework for more formal representation of the parameters and capabilities for assessing trustworthiness. It’s difficult to achieve both objectives in a short document. I think it does a pretty good job of that, but it isn’t perfect.

From: "Panwei (William)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, March 28, 2022 at 9:10 PM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>, "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>>, Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Rats] Entity vs. role

Hi Ned,

I feel confused by this sentence “Th Attesting Env is a component (entity) that implements an Attester role”.

In section 3.1 of the Arch draft, it says:
   As shown in Figure 2, an Attester consists of at least one Attesting
   Environment and at least one Target Environment co-located in one
   entity.
In my understanding, the combination of Attesting Env and Target Env implements the Attester role.

Besides that, the definition of Attester is:
   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.
According to this definition, the Attester is going to be inferred whether it’s trustworthy. And to be specific, its trustworthiness is inferred based on the authenticity of the Attesting Env and the attributes (or claims) of the Target Env. So the Target Env must be a part of an Attester role.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:[e-mail]] On Behalf Of Smith, Ned
Sent: Friday, March 25, 2022 2:07 AM
To: Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>>; Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Thomas Fossati <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] Entity vs. role

Th Attesting Env is a component (entity) that implements an Attester role. Presumably, there is a Target Environment from which the AE collects claims. The TE isn’t implementing the Attester role (hence it isn’t an Attester). The Arch draft takes some liberties to improve readability for a wide audience at the expense of potentially confusing those who want to put a fine point on things.

BTW there are implied entities hosting Verifier A and RP / Verifier B. Otherwise, it wouldn’t be interesting to talk about the message exchange sequences (which are presumably signed by the entities behind the roles).
-N

From: "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 24, 2022 at 2:11 PM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Rats] Entity vs. role

Yes, the four boxes on top enclose RATS architecture roles required for the ar4si "Below Zero Trust" use case.

Eric

From: Laurence Lundblade, March 24, 2022 9:06 AM
Isn’t everything in this diagram a role?  If not, shouldn’t it be?


     .----------------.

     | Attester       |

     | .-------------.|

     | | Attesting   ||             .----------.    .---------------.

     | | Environment ||             | Verifier |    | Relying Party |

     | '-------------'|             |     A    |    |  / Verifier B |

     '----------------'             '----------'    '---------------'

           time(VG)                       |                 |

             |<------Verifier PoF-------time(NS)            |

             |                            |                 |

    time(EG)(1)------Evidence------------>|                 |

             |                          time(RG)            |

             |<------Attestation Results-(2)                |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |<------Relying Party PoF-----------------(3)time(NS')

             |                            |                 |

   time(EG')(4)------AR-augmented Evidence----------------->|

             |                            |   time(RG',RA')(5)

                                                           (6)

                                                            ~

                                                         time(RX')

LL




On Mar 24, 2022, at 12:35 PM, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

Technically, the RATS Architecture is informational. Hence, no normative “requirements” but that doesn’t mean a I-D based on the architecture should assume conceptual messages can be routed to some other role or that some other role can produce a different conceptual message.

The main point of this thread is to highlight the difference between role and entity. And to try to avoid conflating them. But they are intimately related nevertheless. The examples I provided help illustrate how they relate but without conflation.
-Ned

From: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 24, 2022 at 11:45 AM
To: "Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]>>
Cc: Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] Entity vs. role

It seems to me now that we need to sort out some of these use cases a little better as Henk suggested in the room in Vienna.

On Mar 23, 2022, at 1:54 PM, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:

From: Laurence Lundblade, March 23, 2022 4:03 AM
...

Ironic in a way — I want to forward/passthrough Evidence in Results, you are forwarding/passingthrough Results in Evidence :-)

<eric> It is not me that puts Results in Evidence.  It is the definitions in the architecture document which requires it *must* be specified this way.

5.1 describing the passport model does not imply or require (or preclude) two verifiers.

Section 5.1 does not require that AR be embedded in a new AE message when sent from the device to the RP. It puts no requirements on that transmission. I don’t think it even Requires the Results be relayed by something that has security properties.

None of the examples in section 16 work this way.

I think the design is a fine and good, but I don’t see it in my read of the architecture document. (I searched for occurrences of “passport”). Apologies in advance if I’ve missed something in the architecture document.

LL