Skip to main content

Minutes interim-2019-teep-01: Fri 08:00
minutes-interim-2019-teep-01-201905170800-00

Meeting Minutes Trusted Execution Environment Provisioning (teep) WG
Date and time 2019-05-17 15:00
Title Minutes interim-2019-teep-01: Fri 08:00
State Active
Other versions plain text
Last updated 2019-06-11

minutes-interim-2019-teep-01-201905170800-00
# Meeting Minutes of the TEEP WG meeting, 17th May 2019

## Participants:
     Anders Rundgren
     Ming Pei
     Hannes Tschofenig
     Roman Danyliw
     Rich Salz
     Sorin Faibish
     Brendan Moran
     Andy Atyeo
     Dave Thaler
     Michael Richardson
     David Wheeler

## 1. Introduction

 The chairs introduced and bashed the agenda.

## 2.  SUIT Manifest Introduction
draft: draft-moran-suit-manifest
presenter: Brendan Moran

Brendan presented -v4 of the manifest specification.

Sorin asked a question about the the device class. Brendan explained that the
device class is an identifier agreed by the entity that create firmware &
manifest and the device itself. It is a go/no-go decision for the design to
make the update.

Dave talked about the dependency concept of the relationship between binaries,
such as "firmware", "optee", "ta1", and "ta2". There is nothing in the SUIT
manifest that constraints its use on firmware. There is also the ability to
create a dependency on system aspects (such as on a specific TPM hardware),
although with extensions.

Sorin asks for the support of an edge gateway use case. Brendan explains the
ability to attach the firmware to the manifest.  Alternative, the manifest
itself can be split into parts and the gateway could be given the ability to
overwrite certain information in the manifest. In yet another case, the gateway
is allowed to perform the verification on behalf of constrained IoT devices.

Dave Wheeler noted that the TEEP has a few more attestations challenges not
evident in this SUIT introduction. He prepared some slides to explain how the
EAT token relates/combines to the manifest. Attestation talks about what is
already on the device (such as lower-level firmware) and in the context of a
manifest these may show up as conditions in a manifest.  Brendan believes that
the functionality is already present to enable these dependencies (via the use
of digests of software). DaveW. was looking for funtionality that is attesting
of what is on the device (components of software and a signature over the
information).

We had a clarification regarding the reporting of attestation information,
which is related to the work in RATS, and the installation instruction (which
is about SUIT). DaveW. is there a need for a message that provides the
combination of the two?

Ming & DaveT suggested to explore the case where there is a dependency between
a normal world and a secure world app.

Actions
- Sorin Faibish will send a description of the edge gateway use case to the
mailing list - Dave Wheeler will send a description of the use case for
combining attenstation reporting and software installation (and their
relationships to RATS+SUIT)

## 3. draft-ietf-teep-architecture Issues
draft: draft-ietf-teep-architecture
presenter: Hannes Tschofenig
issues: https://github.com/ietf-teep/architecture/issues

Hannes presented on the implications of making security domains optional.

Ming noted that there is a need for security domains for lifecycle management

The WG discussed the origin of the personalization data.  The following
agreeement reached: - The ability to have personalization data in a device is
an optional requirement.  However, if supported personalization data must be
encrypted - Personalization data may come from TAM (viable by no one else) or
the the Service Provider (viable by no one).