Re: [Teep] Charter Text

Dapeng Liu <maxpassion@gmail.com> Tue, 12 September 2017 16:49 UTC

Return-Path: <maxpassion@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749D6133090; Tue, 12 Sep 2017 09:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUtvJqRd12xP; Tue, 12 Sep 2017 09:49:14 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C49133083; Tue, 12 Sep 2017 09:49:14 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id i130so14989480pgc.3; Tue, 12 Sep 2017 09:49:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=m2zL0mzHCdoWxyQ0z9uMZnc/sGPps5MgLpvvYdsG/Hc=; b=nyf8NFNT72suL2eskJGUiSj7ImTcwIzJ1YtKCM/BynX+DyR6bBtKSnC3lO7FNrXevz E2LptKqbuuRc/LYseRUj/ge1+rMDtULhNdZDtnfaUKcs/pdqBN8q/WGP3pxIyabFdvq7 XpZSCBWZCi8MwCQA77+5MOBEyE2feszr0iQU3i7shIPAGvPqzx8RCqXH+n1B+Xrba5v9 wLUT1npd/u4qkSB5/PbEvye2cPr4G1SRlTqDnzhgTzEimtDNkW958cyI9U0XEqnzLZKP 1nCZakyMcvKMSPvgS80xfIzxcBOgPkAxDNppqZXZobBwDcXYVpcS9GZhhgT5/x9bdYYy iWIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=m2zL0mzHCdoWxyQ0z9uMZnc/sGPps5MgLpvvYdsG/Hc=; b=nBuOMnGUaWJyiu12j/U3glKI0camgpOXNgQZMfbXUFJMl5q6l2+fAK6falpb7Dp501 kGjK0xIEJ95pb/vVqpfoIeZeq+nR0q/i6NcJYfA89N6Pf3InvzPKc5f3vfabuNk0TJtY e+BcPzkKGJ9ORUfcyXjZX9NGxljuZ0jNSgsFkxPoRsAw5t/VcrWn6cISG7WrJC6eZJbT 1wFlAaCUGtqCh3p7JYwdjsyG6VJF+UOzJ570euMnex6eQJirawRHi/xeIIvTi2r1MWa4 as1aJ7YHqWyOauwUchLr4LR47LnKVBDQaFe5xnZq3zwZ/trhkuu7+X/HZp0atgSO5NHF Iyqw==
X-Gm-Message-State: AHPjjUhRjoJNeCO0AWnY9UxzjucGob7gKUlGDTVRxPGr3GfAmRLcgBfv KCxVmHXgJK0vvCvFHfW8rN/cz8aHG+JWy+wkGPk=
X-Google-Smtp-Source: ADKCNb5t8ljEa/lP0eMGTzeMi+t8CktzjHQSFHVziiE7geASIEH/Jo4+nfU6tvCpli2Hj+Gqt+0K8emkcQ6IhmVGXWc=
X-Received: by 10.101.90.207 with SMTP id d15mr15038286pgt.423.1505234953447; Tue, 12 Sep 2017 09:49:13 -0700 (PDT)
MIME-Version: 1.0
References: <6EFD27BC-CE56-4112-AD20-C787520BEE87@cisco.com> <DM5PR20MB1228DEC9757FCBDCA4254052AAA70@DM5PR20MB1228.namprd20.prod.outlook.com> <d6015c71-04de-3323-bb08-5ac66a5c21d0@mixmax.com> <35502548-8d02-4af2-b409-d8be73dd6a6d.max.ldp@alibaba-inc.com>
In-Reply-To: <35502548-8d02-4af2-b409-d8be73dd6a6d.max.ldp@alibaba-inc.com>
From: Dapeng Liu <maxpassion@gmail.com>
Date: Tue, 12 Sep 2017 16:49:02 +0000
Message-ID: <CAKcc6AdZV7HsUvTiKnSP7dXf9Q4PMfBmNyWnwMLnGF6re3aKAQ@mail.gmail.com>
To: Lubna Dajani <lubnadajani@gmail.com>, ppeterka@verimatrix.com, teep-bounces@ietf.org, teep <teep@ietf.org>, Mingliang Pei <Mingliang_Pei@symantec.com>, Marc Canel <Marc.Canel@arm.com>, "richard.parris@intercede.com" <richard.parris@intercede.com>, Rob Coombs <rob.coombs@arm.com>, qingyang.meng@beanpodtech.com, brian_witten@symantec.com, "henry.j.lee@samsung.com" <henry.j.lee@samsung.com>, Nick Cook <Nick.Cook@intercede.com>, "Mike.M.Parsel@sprint.com" <Mike.M.Parsel@sprint.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, zhijian.zhang@beanpodtech.com, zhoup@bjleisen.com, maojun.wei@watchdata.com, dominique.bolignano@provenrun.com, "heekwan.lee@samsung.com" <heekwan.lee@samsung.com>, "mike.hendrick@seqlabs.com" <mike.hendrick@seqlabs.com>, xiayubin@trustkernel.com, sangjin.park@hansol.com, lyle.w.paczkowski@sprint.com, Pengcheng Zou <zoupc@thundersoft.com>, fmw@whty.com.cn, philip.attfield@seqlabs.com, Andrew.Atyeo@intercede.com, paromix@sola-cia.com, ppeterkaa@verimatrix.com, 成 鹏 <max.ldp@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="089e08234f7cb42d49055900d28a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/gsoUM_yHjeMkUDShLHpzK4WaUVk>
X-Mailman-Approved-At: Tue, 12 Sep 2017 09:56:25 -0700
Subject: Re: [Teep] Charter Text
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 16:49:17 -0000

Hello Nancy,

Thanks!

Actually, there are lots of companies/experts are very interested in the
proposed TEEP work. But they may not familiar with IETF process, I hope
they would getting more active in the list after the long
summer vacation:)

Note: I have copied to all the experts that are interested in TEEP based on
offline discussions.
To all the experts copied in this mail: Please subscribe to TEEP email list
first if you want to reply.   Here is how to subscribe:
https://www.ietf.org/mailman/listinfo/teep

Thanks,
Max
------------------------------------------------------------------
From:Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>
Send Time:2017年9月12日(星期二) 23:50
To:Lubna Dajani <lubnadajani@gmail.com>; Petr Peterka <
ppeterka@verimatrix.com>
Cc:teep@ietf.org <teep@ietf.org>
Subject:Re: [Teep] Charter Text

Thank you Lubna and Petr!



Would still like to hear from others and also solicit feedback on the
proposed charter text.



Warm regards,

                Nancy



*From: *Lubna Dajani <lubnadajani@gmail.com>


*Date: *Tuesday, September 12, 2017 at 4:40 AM
*To: *Petr Peterka <ppeterka@verimatrix.com>

*Cc: *"ncamwing@cisco.com" <ncamwing@cisco.com>, "teep@ietf.org" <
teep@ietf.org>


*Subject: *Re: [Teep] Charter Text



please allow me to echo Petr's responses.

1. Yes

2. Yes

3. Yes

4. Yes

 I am personally very excited to see this WG form and I look forward to
actively contributing to the evolution of this protocol as I have since the
ideation stages of this protocol …



Thank you Nancy, Petr and everyone here…



Lubna

__________________________________________________

Lubna Dajani  I  Allternet Ltd.

@lubnadajani

@futuristasORG

+ 1 201 982 0934 <(201)%20982-0934>





*Confidentiality Notice:* The information contained in this email and any
attachments is intended only for the recipient[s] listed above and may be
privileged and confidential. Any dissemination, copying, or use of or
reliance upon such information by or to anyone other than the recipient[s]
listed above is prohibited. If you have received this message in error,
please notify the sender immediately at the email address above and destroy
any and all copies of this message.



Sent with Mixmax
<https://mixmax.com/s/Sjmasx74wNoX3uu2B?utm_source=mixmax&utm_medium=email&utm_campaign=signature_link&utm_content=sent_with_mixmax>





On Thu, Jul 20, 2017 2:48 AM, Petr Peterka ppeterka@verimatrix.com wrote:

Hi Nancy

I think we had a very productive meeting yesterday. Here are my answers to
your questions:



1) Do you understand what TEEP is trying to achieve?

ANSWER: Yes, I do. I’d like to add that the charter may re-emphasize that
the proposed WG is not going to define the TEE or the TAM service
themselves but just the protocol between them.



2) Is this work that should be done in general?

ANSWER: Yes, it should since there are going to be more and more trusted
execution environments (lower case) especially with the proliferation of
IoT devices which will need more security than what they have today.



3) Is this work that should be done in the IETF, or does it belong to
somewhere else?

ANSWER: Since we are trying to define a protocol that is independent of the
different TEE implementations, I believe that IETF is the right home for it.



4) Should we form a WG with given charter to work on this?

ANSWER: Yes, that is my recommendation.



Thanks

          Petr

  <#m_4019887533134155472_this>

*From:* TEEP [mailto:teep-bounces@ietf.org] *On Behalf Of *Nancy Cam-Winget
(ncamwing)
*Sent:* Thursday, July 20, 2017 11:13 AM
*To:* teep@ietf.org
*Subject:* Re: [Teep] Charter Text



All,

Please provide feedback on the results of yesterday’s side meeting.  In
particular, we’d like to get feedback on whether this the right scope and
if we have captured it appropriately. If it is not, also please comment and
if possible, provide suggestions for improvement.



We would like to continue discussion over email and get consensus around
the 2nd week of September so that we can have a path forward.  In
particular we would like to get answers for:



1) Do you understand what TEEP is trying to achieve?

2) Is this work that should be done in general?

3) Is this work that should be done in the IETF, or does it belong to
somewhere else?

4) Should we form a WG with given charter to work on this?



Warm regards,

    Nancy & Tero (TEEP BoF Chairs)



*From: *TEEP <teep-bounces@ietf.org> on behalf of Hannes Tschofenig <
Hannes.Tschofenig@arm.com>
*Date: *Wednesday, July 19, 2017 at 5:56 AM
*To: *"teep@ietf.org" <teep@ietf.org>
*Subject: *[Teep] Charter Text



Here is the charter text we came up in the side-meeting today.



------



TEEP -- A Protocol for Dynamic Trusted Execution Environment Enablement
Charter



The Trusted Execution Environment (TEE) is a secure area of a processor.
The TEE provides security features, such as isolated execution, integrity
of Trusted Applications along with confidentiality of their assets. In
general terms, the TEE offers an execution space that provides a higher
level of security than a "rich" operating system and more functionality
than a secure element. For example, implementations of the TEE concept have
been developed by ARM, and Intel using the TrustZone and the SGX
technology, respectively.



To programmatically install, update, and delete applications running in the
TEE, this protocol runs between a service running within the TEE, a relay
application or service access point on the device's network stack and a
server-side infrastructure that interacts with and optionally maintains the
applications. Some tasks are security sensitive and the server side
requires information about the device characteristics in form of
attestation and the device-side may require information about the server.



Privacy considerations have to be taken into account with authentication
features and attestation.



This working group aims to develop an application layer protocol providing
TEEs with the following functionality,

* lifecycle management of trusted applications, and

* security domain management.



A security domain allows a service provider's applications to be isolated
so that one security domain cannot be influenced by another, unless it
exposes an API to allow it.



The solution approach must take a wide range of TEE and relevant
technologies into account and will focus on the use of public key
cryptography.



The group will produce the following deliverables. First, an architecture
document describing the involved entities, their relationships,
assumptions, the keying framework and relevant use cases. Second, a
solution document that describes the above-described functionality. The
choice of encoding format(s) will be decided in the working group. The
group may document several attestation technologies considering the
different hardware capabilities, performance, privacy and operational
properties.



The group will maintain a close relationship with the GlobalPlatform,
Trusted Computing Group,  and other relevant standards to ensure proper use
of existing TEE-relevant application layer interfaces.



Milestones



Dec 2017     Submit "TEEP Architecture" document as WG item.



Feb 2018     Submit "TEEP Protocol" document as WG item.



July 2018     Submit "TEEP Architecture" to the IESG for publication as an
Informational RFC.



Feb 2019     Submit "TEEP Protocol" to the IESG for publication as a
Proposed Standard.



Additional calendar items:



Nov 2017     IETF #100 Hackathon to work on TEEP protocol prototype
implementations.



Mar 2018     1st interoperability event (at IETF #101).



Jul 2018       2nd interoperability event (at IETF #102).



IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.