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