Re: [Rats] Composite Evidence

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

I think the gist is we're looking at cases where submods could be entities that include RATS roles as well as Target and Attesting environments. 
The thread is trying to pull this apart to see if there are ways to simplify by reapplying the basic concepts or if there are new concepts that need to be grappled with.

On 1/23/20, 4:41 PM, "Laurence Lundblade" <[e-mail]> wrote:

    Not up to speed on this thread but two comments:
    
    - It seems the notion of target environment is important here.
    - I am interested in implications for EAT submods. Seems you should be able to express this stuff in EAT.
    
    LL
    
    > On Jan 23, 2020, at 4:12 PM, Eric Voit (evoit) <[e-mail]> wrote:
    > 
    > 
    > 
    >> -----Original Message-----
    >> From: RATS <[e-mail]> On Behalf Of Smith, Ned
    >> Sent: Thursday, January 23, 2020 6:11 PM
    >> To: Michael Richardson <[e-mail]>; [e-mail]
    >> Subject: Re: [Rats] Composite Evidence
    >> 
    >> See [%] marker inline below.
    >> 
    >> On 1/23/20, 12:36 PM, "RATS on behalf of Michael Richardson" <rats-
    >> [e-mail] on behalf of [e-mail]> wrote:
    >> 
    >> 
    >>    Smith, Ned <[e-mail]> wrote:
    >>> The semantics of 'union composite evidence' (below) seems to suggest
    >>> that the local Verifier that produced 'ar' is itself an attestable
    >>> claim. The Attester asserts that the Attestation Results from a local
    >>> Verifier are trustworthy and that they originated from a sub-
    >> component
    >>> of its Target environment.
    >> 
    >>    Yes.
    >>    As explained by Eric in his diagram, the "ar" results might not be produced
    >>    locally, they may be the result of a trip to a different (remote) verifier.
    >>    Or as you suggest, they may be produced within some TEE, for which there
    >> are
    >>    evidence claims about why it's trust worthy.
    >> 
    >>    I think that this all maps to what I understand about TEEP actually.
    >> 
    >>> Another way to think about it is the Attesting environment knows
    >> that
    >>> the Target environment includes a Verifier and wants to assert that
    >> the
    >>> Verifier has trustworthiness properties - possibly by returning its
    >>> SWID tag value. The Remote Verifier can then evaluate the
    >>> trustworthiness of the SWID tag.
    >> 
    >>    Sure, that is a specific way.
    >>    I think that the Chassis+Line Card situation also can work as an example.
    >> 
    >>> Based on that, if the Remote Verifier trusts the Local Verifier then
    >>> the local Attestation Results are not claims asserted by the Attesting
    >>> environment, but claims asserted by the Local Verifier. The only claim
    >>> that seems to make sense from the Attesting environment's
    >> perspective
    >>> is that an 'ar' value from its Target was forwarded to a Remote
    >>> Verifier. Signing the local Verifier's ar payload just asserts that the
    >>> forwarding action has taken place. This is an argument for defining an
    >>> 'Attestation Results forwarded' claim. Maybe this isn't that valuable
    >>> in terms of a trustworthiness claim?
    >> 
    >>    [%] I think you are saying that rather than documenting that we forward a
    >> union
    >>    of evidence and attestation results, that we document that will create a
    >> kind
    >>    of evidence, which includes attestation results?
    >> Maybe. It really is a case of multiplexing several conversations over the same
    >> conveyance mechanism, but otherwise conversations could be de-
    >> multiplexed (without creating unnecessary cross-dependencies). For example
    >> in both Passport and BK-Check topology models, a message is simply relayed.
    >> The endpoints are still the way they're defined in the Roles Arch diagram.
    >> 
    >> Email may not be the best way to try to illustrate but here goes. I assert that
    >> Eric's diagram can be recast into two graphs where graph (a) is the sub-
    >> component attester (A1), the local verifier (V1) and a relying party (RP). The
    >> second graph (b) consists of the top level Attester (A2), a remote verifier (V2)
    >> and the same relying party (RP).
    >> Looks something like:
    >> (a) A1 --- E1 ---> V1 --- AR1 ---> RP;
    >> (b) A2 --- E2 ---> V2 --- AR2 ---> RP.
    >> 
    >> However, since A1 and V1 don't have a conveyance path to RP, they use the
    >> one established by (b). The Combination topological model shows a case
    >> where the Attester is relying/forwarding attestation results. Normally, an
    >> attester doesn't consume attestation results. This same thing is happening in
    >> Eric's example because AR1 is piggy backed with E2 on its way to V2 and AR1
    >> is also piggy backed with AR2 on its way to RP.
    >> 
    >> I don't think we want to position that because AR1 is piggy backed with E2
    >> that this creates a new type of Evidence (E3). It is still just (AR1, E2).
    >> 
    >> If it makes sense to define "routing claims" that assert that A2 intended to
    >> piggy back AR1 with E2 then that should imply that if E2 = (c1) and c2 =
    >> routing claim then E2' = (c1, c2). The conveyance still carries (AR1, E2') , but
    >> possibly the c2 claim names AR1 as the piggy i.e. c2.name = "AR1".
    >> 
    >> V2 can verify the c2 claim and create an AR2' claim c3.name="AR1" and send
    >> (AR1, AR2'); where AR2 = (c4,...,cn) and AR2' = (c3, c4,...,cn). RP can similarly
    >> verify c3. Namely, the c3.name="AR1" claim is inspected to have payload AR1
    >> as piggy.
    >> 
    >> The "routing" claims are ancillary to the basic roles and messages that are
    >> the core basis for trust among the endpoint entities -  IMO. The core flows
    >> are separable from routing. Routing shouldn't lead us down a path of having
    >> new types of evidence (E3).
    > 
    > I agree that routing itself doesn't imply a new type of evidence.   What we do have at Attester is some trigger for when to collect the specific set of claims which are needed by the Relying Party to accomplish a particular use case. 
    > 
    > Eric
    > 
    >>> If however the Attesting environment wanted to make a stronger
    >>> trustworthiness assertion it would have some other way to collect
    >>> Evidence about the Targeted sub-components (who must already
    >> have their
    >>> own Attesting environments). But if the Attesting environment could
    >> do
    >>> this then it must be the same environment as the sub-components'
    >>> Attesting environments. In which case, there is no need for a local
    >>> Verifier - it is just complexity for complexity's sake.
    >> 
    >>    I think that I agree.
    >> 
    >>    It could be that there are competitive or regulatory reasons why the Lead
    >>    Attester does not wish to reveal the types of the line cards attached.
    >>    Consider an automobile (or passenger rail car, or human-rated Rocket)
    >> that
    >>    needs to attest that it has four good tires (which passed their 20,000km
    >>    inspection), but which does not wish to reveal which manufacturer
    >> provided
    >>    those tires.  Passing on evidence directly would be a problem.
    >> [nms] Privacy is an important consideration. If Evidence is privacy sensitive,
    >> then it can be encrypted. The routing claims don't require transparent
    >> Evidence to name them. Could compute a hash of E or AR or if endpoints
    >> have security associations, then E and AR can be encrypted and a digest of
    >> ciphertext becomes its name for the purpose of routing claims (see my
    >> response above).
    >> 
    >>> The case of a local Verifier working with a remote Verifier is
    >>> semantically the same as a Remote Verifier working with another
    >> Remote
    >>> Verifier. So, I don't see why Evidence and Attestation Results formats
    >>> need to do anything special - like 'union composite evidence'.  It just
    >>> says that Verifier1 may evaluate Evidence about Verifier2 before
    >>> trusting Attestation Results from Verifier2.
    >> 
    >>    Thus my query up at [%].
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> RATS mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/rats
    > _______________________________________________
    > RATS mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/rats