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