Subject: [Rats] Entity vs. role

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Mar 2022 13:13:03 +0000

(not as chair)
One of the topics discussed during RATS113 session I seemed to focus on architectural considerations for entities vs. roles. The architecture draft summarizes concisely:
“In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.”

This is different from a distributed Verifier that operates on a portion of a conceptual message and (possibly) forwards a portion for some other Verifier to consume. The architecture didn’t attempt to name partially processed conceptual messages distributed across multiple entities.

It may be helpful for drafts to give names to partially processed conceptual messages, but until processing is complete (and therefore becomes a different conceptual message) it should still be correct to refer to the partially processed conceptual message by it’s architectural name (e.g., Evidence that has been authenticated but not appraised would still be regarded as Evidence architecturally. Appraisal results that haven’t been authenticated to a Verifier might still be called Evidence up until all the requirements for being called Attestation Results are satisfied.)

-Ned

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Mar 2022 15:14:46 +0000

hi Ned

> This is different from a distributed Verifier that operates on a portion of a conceptual message and (possibly) forwards a portion for some other Verifier to consume. The architecture didn’t attemp…

I fully agree with this.

> It may be helpful for drafts to give names to partially processed conceptual messages

As you say, a Verifier implementation can fraction and distribute the
appraisal box the way it wants.  It seems to me though that trying to
name these intermediates equates to making the internal
(implementation-specific) interfaces explicit, which is something we
should really avoid at least until we decide it's time to revise the
architecture to break down the Verifier box.

> but until processing is complete (and therefore becomes a different conceptual message) it should still be correct to refer to the partially processed conceptual message by it’s architectural name (e.g., Evidence that has been authenticated but not appraised would still be regarded as Evidence architecturally. Appraisal results that haven’t been authenticated to a Verifier might still be called Evidence up until all the requirements for being called Attestation Results are satisfied.)

I also fully agree with this.

-- 
Thomas

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Mar 2022 17:58:45 +0000

On 3/22/22, 4:15 PM, "Thomas Fossati" <[email-masked]> wrote:

    hi Ned

    I fully agree with this.

[Ned] I'm suggesting that I-Ds qualify the architectural name in some appropriate manner such as "partially evaluated Evidence" rather than make up some new name that appears to be architectural but actually isn't.

    -- 
    Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Mar 2022 19:42:33 +0100

Agree entirely with what’s below, but it doesn’t quite address what I am on about.

RATS architecture clearly separates two polices:
   1) Appraisal Policy for Evidence
   2) Appraisal Policy for Results

The first one is used only by the Verifier role and never by the Relying Party role. It can only be use to process Attestation Evidence, never to process Attestation Results. In a chain of Verifiers all the intermediate results are Attestation Evidence, never Attestation Results.

When all the Verifiers are done, then you have Attestation Results.

Similarly, the Appraisal Policy for Results is used only by the Relying Part role, never by the Verifier role. It can never be applied to Attestation Evidence. 

Since we are talking roles not entities, here, the Relying Party can *never* by definition receive Attestation Evidence. Again, since we’re talking *roles* not entities, a Relying Party can *never* host a Verifier.

Said another way, the definition of the Verifier and Relying Party roles gives a hard one-way transition from Evidence to Results.

I think the Verifier and the Appraisal Policy for Evidence is all about the device/implementation/attester.
 - Who made the device?
 - Is it configured correctly?
 - Is it in the right state?
 - Does it have the right SW?
 - What certifications does it have?

This is represented in the Attestation Results, perhaps in summary or in detail.

Then the RP and the Appraisal Policy for Results is about the application-specific stuff:
  - Is this device OK for this dollar amount (the RP knows the $ amount, not the Verifier)
  - Can this content be played on this device — the RP knows which device and what characteristics it requires for the content
  - Is the sensor data accurate — the RP knows which sensors it can trust

I don’t see this separation as hard as long as we’re open and flexible about what is in Attestation Results. Seems we need to be a bit flexible about what is in Attestation Results because the roles of Verifier and RP are sharp and one-way.

LL

> On Mar 22, 2022, at 4:14 PM, Thomas Fossati <[email-masked]> wrote:
> 
> hi Ned
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Mar 2022 19:00:24 +0000

> [Ned] I'm suggesting that I-Ds qualify the architectural name in some appropriate manner such as "partially evaluated Evidence" rather than make up some new name that appears to be architectural bu…

OK, thanks for the clarification.  Then the agreement is violent, to
say the least :-)

-- 
Thomas

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 22 Mar 2022 19:11:37 +0000

The RATS architecture purposefully separates application specific aspects of the RP from the attestation specific parts and doesn't try to define the application specific aspect of RP. You might consider the appraisal policy for AR is different from other RP policies that are application specific such as "is this device OK for this dollar amount". 
Appraisal policy for AR would instead focus on whether "who made this device" or "is it in the right state" are meaningful and relevant given the RP's application domain. One might expect the RP and Verifier would negotiate which claims are meaningful and relevant (maybe as part of setup?). 

-Ned

On 3/22/22, 7:42 PM, "Laurence Lundblade" <[email-masked]> wrote:

    LL

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 22 Mar 2022 20:12:00 +0000

>   - Is the sensor data accurate — the RP knows which sensors it can trust

I think that the terminology choice made by the architecture is quite
precise: "AP for attestation results."

The appraisal logic you are describing above covers more ground than
just attestation results.  The way I picture myself the "complete"
appraisal process done by the RP looks more or less like:

          AP for AR
              |
       .------v-------.    .--------------------------------.
 AR -> | AR appraisal | -> | Application-specific appraisal | -> [0..1]
  :    '--------------'    '--^--------^---------^----------'
  :                           :        |         |
  '- - - - - - - - - - - - - -'        other     application-
                                       input     specific
                                                 policy

But otherwise, at least at a high level, I agree with the functional
split between evidence and ARs you are describing above.

There are grey areas though: for example, the RP may need to access
the software inventory in the evidence to decide whether the SW on the
attester needs updating.  And that is where your

> [...] as long as we’re open and flexible about what is in Attestation Results

(e.g., via passthrough) comes in the picture.

-- 
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 22 Mar 2022 21:31:24 +0100

Hi Thomas,

Miss having you here in Vienna.

> On Mar 22, 2022, at 9:12 PM, Thomas Fossati <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Yes, we can depict it like that conceptually, but in reality it could be one big machine learning engine or similar where you can’t separate it (you could even put unverified measurements in AR so they can be fed into a machine learning engine).

And RATS architecture doesn’t care about what’s in AP for AR and shouldn’t care about it. We’re only mentioning AP for AR for the sake of completeness. We’re not going to put any requirements on it or say anything more about it than it exists, right? Hope that right. 

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 22 Mar 2022 21:37:39 +0000

Hi Laurence,

From: Laurence Lundblade, March 22, 2022 4:31 PM

On Mar 22, 2022, at 9:12 PM, Thomas Fossati <[email-masked] <mailto:[email-masked]> > wrote:

On Tue, Mar 22, 2022 at 6:42 PM Laurence Lundblade
< <mailto:[email-masked]> [email-masked]> wrote:

         AP for AR
             |

<eric> Ar4si uses the term "AR-Augmented Evidence" to show what flows into the unified Verifier + Relying Party roles.  Ar4si makes no assertions on what the full set of Evidence might include.

<eric> The RATS architecture doesn't name specific objects.  But where AR flows between devices (e.g., in the passport model), this WG needs to understand how reusable Verifier generated objects/definitions might be consumed.  I.e., the ultimate consumer of RATS is the RP.

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Mar 2022 09:02:51 +0100

> On Mar 22, 2022, at 10:37 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 

Yes, went backed and looked at your slides again. Makes sense. Definitely a use case to support.

When talking in terms of roles, I definitely think that Verifier B is just co-located with the RP, not part of the RP.

I’m not sure if we should consider Verifier A + Verifier B a composite Verifier or not. In my comments above I clearly asserted that all the verifiers (in a composite verifier) must have run before there is any AR. By that criteria it is definitely not, but maybe that definition is too strict? 

I’m also not sure what we should call the intermediate results between Verifier in a composite verifier. By my criteria above it can’t be AR-Augmented Evidence, but again, maybe that criteria is too strict.

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

LL

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 23 Mar 2022 08:45:20 +0000

hi Laurence

> Miss having you here in Vienna.

next year in Jerusalem :-)

> And RATS architecture doesn’t care about what’s in AP for AR and shouldn’t care about it. We’re only mentioning AP for AR for the sake of completeness. We’re not going to put any requirements on it…

I think the only important thing that the architecture implies is that
the AP for AR needs to understand the AR format.  Other than that I
don't think there are any further requirements.

cheers,
-- 
Thomas

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 23 Mar 2022 08:53:42 +0000

From: Laurence Lundblade <[email-masked]>
Date: Wednesday, March 23, 2022 at 9:03 AM
To: "Eric Voit (evoit)" <[email-masked]>
Cc: Thomas Fossati <[email-masked]>, "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>
Subject: Re: [Rats] Entity vs. role

On Mar 22, 2022, at 10:37 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Eric

Ironic in a way — I want to forward/passthrough Evidence in Results, you are forwarding/passingthrough Results in Evidence :-)
[ned] Maybe it is helpful to describe swim lanes between entities where each pairwise role interaction can be represented? It might also be helpful to qualify entities vs. roles in diagrams where both are needed such as passport and background check as it would seem the entity name is overloaded with the role name in the RATS architecture.
e.g., given a verifier entity (V-E) that is connected to a relying party entity (RP-E), a hybrid model might have swimlanes as follows:
V-E           RP-E
---           ----
V  ----AR----> RP
A  ----E-----> V

LL

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 23 Mar 2022 09:43:00 +0000

hi Ned

> e.g., given a verifier entity (V-E) that is connected to a relying party entity (RP-E), a hybrid model might have swimlanes as follows:

I like this.

Just a note: in this case, the existence of a Verifier role at RP-E is
predicated on the RP-E having access to, at least, the key material to
verify E - e.g., the public key of the attester A.  Otherwise, E is
just "passthrough/forwarded" and the RP role is all there is at RP-E.

cheers,
-- 
Thomas

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 23 Mar 2022 12:54:16 +0000

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

On Mar 22, 2022, at 10:37 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

Eric

<eric>  There is no term "Composite Verifier" in the architecture.  And if there was, I wouldn't consider Verifier A + Verifier B composite because: 

* Verifier A will often not even know about Verifier B.

* Verifier A & Verifier B will often be managed by different organizations.

<eric> Verifier A does not know that it is creating "intermediate results".  It is delivering exactly the evaluation promised.  This is why what is coming from the Verifier A must be known as Attestation Results.  

It is up to the end-to-end use case as understood by the Verifier B + RP to determine how to handle the full set of Evidence receives.

<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.

Others should chime in on whether they agree with my interpretation of the architecture document.  To me it is perfectly clear.

Eric

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 23 Mar 2022 20:33:45 +0000

See inline [nms] – warning long reply

From: RATS <[email-masked]> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]>
Date: Wednesday, March 23, 2022 at 1:54 PM
To: Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>, Thomas Fossati <[email-masked]>
Subject: Re: [Rats] Entity vs. role

Eric

<eric>  There is no term "Composite Verifier" in the architecture.  And if there was, I wouldn't consider Verifier A + Verifier B composite because:
* Verifier A will often not even know about Verifier B.
* Verifier A & Verifier B will often be managed by different organizations.
[nms] The term ‘composite’ is defined in the context of ‘composite device’ which is an entity (not a role). The architecture didn’t define ‘composite verifier’ but if it did it would likely(?) define it as an entity (lower case verifier) – or some other name that avoids collisions with Verifier. Maybe I-Ds that describe different compositions of entities should be careful to use names that are well qualified such as a ‘distributed entity’(de)? Then it would be easier to talk about a Verifier on de-A or a Verifier on de-B. It may seem pedantic but it helps clear up “ambiguities” in the architecture by separating issues related to managing entities from those pertaining to role semantics and appraisal processing / interpretation. Roles focus attention on what can be said while entities focus on who is speaking.

[nms] +1

Others should chime in on whether they agree with my interpretation of the architecture document.  To me it is perfectly clear.
[nms] If entity-A says Evidence-1, AR-1 and Endorsement-1 then we can refer to entity-A as an Attester or Verifier or Endorser or combinations of these roles. But that may lead to confusion if the design needs to describe properties of both the entity and the role(s) it performs. The architecture takes some liberties for readability when describing RATS roles conceptually. Sometimes the roles read like entities. But the terminology section clearly describes the difference between role and entity. Nevertheless, I-D authors may need to be rigorous about distinguishing between properties that apply to entities and those that apply to roles.

Given Evidence is a logical statement that relates “who says what”, the following is an example of a RATS conceptual message:
“entity-X says conceptual message”

There is an implied assertion that “IF entity-X says Evidence THEN entity-X must be an Attester”. However, it is ambiguous whether conceptual message is either Evidence, Attestation Result, RV etc…

A credential that deliberately assigns the Attester role to entity-X would make the role assignment explicit and provable. The logical statement would be something like ‘entity-X has role Attester and says Evidence’. This statement would be cryptographically verifiable if ‘says’ is interpreted as use of a key.

The ‘says’ statement can be used for both role assignments and conceptual message construction.
E.g.,
Statement 1: “owner-entity-Y says entity-X has role Attester”
Statement 2: “entity-X says Evidence”

If statement 2 happened before statement 1 then that would be a security flaw.

Assuming the roles assignment happens in the right order, it is possible for an Evidence passthrough case to be expressed as:
     Setup steps:
Statement a: “owner-Y says entity-X has role Attester”
Statement b: “owner-Y says entity-Z1 has role Verifier”
Statement c: “owner-Y says entity-Z2 has role Verifier”
Statement d: “owner-Y says entity-RP has role Relying Party”

     Operational steps:
Statement 1: “entity-X says Evidence”
Statement 2: “entity-Z1 says (entity-X says Evidence)” ; passthrough evidence
Statement 3: “entity-Z2 says AR” ; and includes entailment for Statement 2

Alternatively, statement 3 could include the entailment in a single statement:
Statement 4: “entity-Z2 says (entity-Z1 says (entity-X says Evidence))”

The first parenthetical is the partial attestation result expressed as passthrough evidence. The RP might want AR claims expressed using the same format as was expressed by the Attester Evidence. Let’s say the claim is 264 (which is the IANA code point for location) with x,y,z coordinates.

    e.g.: Statement 4: “entity-Z2 says (entity-Z1 says (entity-X says 264=(x,y,z)))”

The RP might want to consume a claim in the ‘264’ format, but also wants to know that it was intended as AR and NOT Evidence that was routed through entity-Z1 or entity-Z2 where it picked up a signature as a consequence of secure routing protocols.

Based on this, Statement 2 and Statement 4 are passing evidence through, but it is partially appraised Evidence.

For example, Entity-Z1 might have an appraisal policy that requires Evidence to contain 3 different location sensing techniques (GPS, triangulated cell towers, and Bluetooth RSSI). The result of Z1 appraisal might result in only GPS location because Z2 expects Z1 to apply data reduction resulting in an intermediate form of Evidence that is a singleton location and partially appraised.

Entity-Z2 might process the location claim based on a Reference Value in the form of a geo-fence. If inside the fence, the location claim is propagated otherwise not. If propagated then it becomes an AR.

Even though the claim delivered to the RP is the same value encoding (264) as originally produced by entity-X as Evidence. The RP can determine that it is indeed Attestation Results in two ways.

(a)     By evaluating policy about who can say what (refers to the setup steps).

(b)     By evaluating a log of the statements (1-4) and determining if the statements have logic or sequencing errors.

Since Z1 and Z2 behavior are modified by appraisal policy. Statement 4 should include the policies they applied. Something like the following:

Statement 4: (entity-Z2 says (entity-Z1 says (entity-X says 264) by policy-Z1) by RV-Z2)

Since reference values are provided by RVPs. A RV is a statement of the form:
     (RVP says RV1) where RV1 is a geo-fence with four corners (264=c1, 264=c2, 264=c3, 264=c4)

Statement 4 then might be:

(entity-Z2 says (entity-Z1 says (entity-X says 264=(x,y,z) by policy-Z1) by (RVP says (264=c1, 264=c2, 264=c3, 264=c4)))

Note: Everything to the right of a “says” operator is a conceptual message.

Architecturally, statement 4 isn’t Attestation Results until the outer parenthesis is applied. Prior to that it is Evidence. I.e., (signed) appraised Evidence = AR.

From a RP perspective it is “un-appraised Attestation Results” until statement 4 is evaluated (appraised). It isn’t actionable by a RP-entity before then. It might make sense to call it “appraised AR” to clarify within the RP-entity what phase of processing it is in. From an RP-entity perspective, the line where the RATS RP Role crosses over to the RP-entity’s enforcement role occurs when an appraised AR exists. Prior to that it is just Attestation Results.

Eric

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Mar 2022 11:44:55 +0100

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) <[email-masked]> wrote:
> 
> ...

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

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 24 Mar 2022 11:35:40 +0000

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

Date: Thursday, March 24, 2022 at 11:45 AM

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

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 24 Mar 2022 14:06:13 +0100

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 <[email-masked]> wrote:
> 
>> On Mar 23, 2022, at 1:54 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 24 Mar 2022 13:11:23 +0000

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

     .----------------.
     | Attester       |
     | .-------------.|

LL

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

-Ned

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

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

...

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 24 Mar 2022 18:06:47 +0000

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)" <[email-masked]>
Date: Thursday, March 24, 2022 at 2:11 PM
To: Laurence Lundblade <[email-masked]>, "Smith, Ned" <[email-masked]>
Cc: Thomas Fossati <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Rats] Entity vs. role

Eric

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

     | Attester       |

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

           time(VG)                       |                 |

             |                            |                 |

             |                          time(RG)            |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |                            |                 |

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

                                                           (6)

                                                            ~

                                                         time(RX')

LL

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

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

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 29 Mar 2022 04:10:39 +0000

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:[email-masked]] On Behalf Of Smith, Ned
Sent: Friday, March 25, 2022 2:07 AM
To: Eric Voit (evoit) <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] Entity vs. role

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

Eric

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

     | Attester       |

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

           time(VG)                       |                 |

             |                            |                 |

             |                          time(RG)            |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |                            |                 |

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

                                                           (6)

                                                            ~

                                                         time(RX')

LL

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 29 Mar 2022 16:46:33 +0000

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)" <[email-masked]>
Date: Monday, March 28, 2022 at 9:10 PM
To: "Smith, Ned" <[email-masked]>, "Eric Voit (evoit)" <[email-masked]>, Laurence Lundblade <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Thomas Fossati <[email-masked]>
Subject: RE: [Rats] Entity vs. role

Hi Ned,

Regards & Thanks!
Wei Pan (潘伟)

Eric

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

     | Attester       |

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

           time(VG)                       |                 |

             |                            |                 |

             |                          time(RG)            |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |                            |                 |

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

                                                           (6)

                                                            ~

                                                         time(RX')

LL

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 30 Mar 2022 04:10:14 +0000

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.

Regards & Thanks!
Wei Pan (潘伟)

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

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

Hi Ned,

Regards & Thanks!
Wei Pan (潘伟)

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

Eric

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

     | Attester       |

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

           time(VG)                       |                 |

             |                            |                 |

             |                          time(RG)            |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |                            |                 |

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

                                                           (6)

                                                            ~

                                                         time(RX')

LL

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 30 Mar 2022 17:23:31 +0000

See inline below

Date: Tuesday, March 29, 2022 at 9:10 PM

Hi Ned,

>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 (潘伟)

Hi Ned,

Regards & Thanks!
Wei Pan (潘伟)

Eric

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

     | Attester       |

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

           time(VG)                       |                 |

             |                            |                 |

             |                          time(RG)            |

             ~                            ~                 ~

           time(VG')?                     |                 |

             ~                            ~                 ~

             |                            |                 |

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

                                                           (6)

                                                            ~

                                                         time(RX')

LL

LL