Subject: [Teep] Adam Roach's No Objection on charter-ietf-teep-00-04: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 21 Feb 2018 23:04:13 -0800

Adam Roach has entered the following ballot position for
charter-ietf-teep-00-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-teep/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

> The group will produce the following deliverables. The first draft is an
> architecture document describing the involved entities, their relationships,
> assumptions, the keying framework and relevant use cases.

Given the guidance at
<https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html>, I
would like to see the charter specifically indicate whether this deliverable
will be sent to the IESG for publication, or simply produced for the working
group's internal use.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 22 Feb 2018 10:21:32 +0000

> will be sent to the IESG for publication, or simply produced for the working

I think TEEP may a case where publication of the architecture document may be justified.

Here is my rationale:

Much discussion on the TEEP list prior to chartering has been around the scope of TEEP and how it might complement and extend work done at GlobalPlatform.

One aspect on which we were agreed is that it would be beneficial to have TEEP address systems that are not built on the GlobalPlatform TEE architecture - in particular to address trust relationships other than those rooted in a trusted/secure boot. This is in part because it is a reasonable requirement to support such systems and in part because it will be beneficial to document how the support and PKI for such architectures necessarily differs from the support for GlobalPlatform TEEs as this might be a source of confusion.

While it would be possible to base TEEP architecture and technical decisions entirely on the GlobalPlatform system architecture (which exists and is well documented), I believe that there is consensus that we should aim to support systems constructed on the GlobalPlatform TEE architecture and systems which are not.