Re: [Rats] Entity vs. role

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

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]>
Date: Monday, March 28, 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,

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]>; Laurence Lundblade <[e-mail]>
Cc: [e-mail]; Thomas Fossati <[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