Re: [Teep] Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06

[Mingliang Pei <[e-mail]>]

Hi Dave,

Our architecture document starts with the following abstract:

"This architecture document
   motivates the design and standardization of a protocol for managing
   the lifecycle of trusted applications running inside such a TEE."

>> TEEP is for provisioning TEEs
To me, TEEP is to provision trusted applications to TEEs. This scope is
consistent with what architecture doc says.

>> whether that is creating an SD or updating OP-TEE
We have had good elaboration about SD, and decided to not include it in
TEEP. These example artifacts (SD or TEE update) are internal
implementation choices, which TEEP doesn't need to define. They are
underlying dependencies but TEEP doesn't need to cover whether and how a
TEE updates itself and whether a TEE will use SD to host a TA or not.

Agreed that this most probably needs WG consensus. This is one word simple
change but important about getting on the same page. Hope to hear
additional comments.

Thanks,

Ming


On Fri, Jul 17, 2020 at 4:15 PM Dave Thaler <[e-mail]> wrote:

> Mingliang Pei [e-mail] wrote:
>
> > 1) Abstract section says "is used to manage code and configuration data"
>
> >
>
> > Should it just say manage "Trusted Applications" as this can
>
> > assume the context defined in TEEP architecture and TEEP protocol
>
> > document.
>
>
>
> No. TEEP can also be used to manage code that isn't a "TA" per se.
>
> For example, it could also be used to update OP-TEE (or any other TEE
> "OS").
>
>
>
> MP: Non-TA code management is out of scope for TEEP. TEEP architecture doc
> only targets to support TA management per use cases and scope sections; it
> doesn't have design to update OP-TEE or any other TEE OS. TEEP protocol
> doesn't have methods for non-TA code. It defines only two methods:
>
> TrustedAppInstall
> TrustedAppDelete
>
> The transport is to support TEEP protocol doc. I suggest that we limit the
> scope of TA management across all three docs.
>
>
>
> I disagree with the above.   TEEP is for provisioning TEEs, and TEE architectures vary.
> For example, CreateSD in OTrP manages a TEE but is not about a TA per se.
>
> And in the TEEP protocol we use a SUIT manifest which can express dependencies
> among TAs, and dependencies on system components, and install (or install updates to)
>
> such dependencies as part of SUIT manifest processing.  That means if you have
>
> TA1 that depends on TA2 that depends on having the latest version of trusted firmware
> or OP-TEE or whatever, the RATS attestation can include the current state, and the
>
> SUIT workflow can install/update it.   The fact that the TEEP protocol uses a TA
>
> as the leaf/trigger doesn’t mean it can’t also do things that it depends on,
>
> whether that is creating an SD or updating OP-TEE.   Trying to make some dependencies
>
> be out of scope and other dependencies not be out of scope would be arbitrary,
>
> complicate the protocol (by saying some SUIT manifests would be illegal, as opposed
> to just using a SUIT processor), and create discrepancies between TEE implementations
>
> (e.g., SGX vs OP-TEE/TrustZone) that in my opinion would not make sense and provide
>
> no value.
>
>
>
> This sounds like something that needs WG consensus either way but I feel strongly about this one.
>
>
>
> Dave
>
>
>
>