[Teep] Re: Review for draft-ietf-teep-usecase-for-cc-in-network

[Michael Richardson <[e-mail]>]

{Any chance you could include your name in your email?}

[e-mail] <[e-mail]> wrote:
    > A little confused about your case. You mean the appliance is owned by
    > ISP but cannot execute remote attestation because it cannot access
    > reference value and endorsement.

When we started RATS, I had assumed that reference values/endorsements would
be available and public.  That it was to everyone's advantage to have
trustworthy systems.  That's not the case.   Vendors do not release reference
values easily, or publically.

One of the reason for the *three* party architecture is to reduce how many
entities have to negotiate with vendors, or conversely, how many vendors have
to negotiate with Relying Parties.  That's why we have the intermediate role
of the Verifier.

If I, as a customer of an ISP (the RP), ask the ISP "are you trustworthy?", then the
ISP would just say "yes, of course we are".  That's a form of
self-attestation really.
So the ISP can't own/control the signing key for Attestation Results.
It needs to be signed by another party.

    > And the ISP operate the verifyer in a
    > TEE environment which could be attested by OEM. The meaning of this
    > case is to protect the privacy of appliance OEM and the data in that
    > appliance. Is my understanding right?

I'm hesistant to give you a blanket yes, here, but yes.
The ISP could operate the OEM's Verifier in a TEE.
The private appliance data is the OEM's Attestation Results signing key.


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