Subject: Re: [Teep] [EXT] Re: TEEP go forward plan and charter text

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 1 Feb 2018 09:41:53 +0000

Hi Ming,

>> to ensure that interoperability is maintained with the standards from these groups.

There was some prior discussion on scope and definition of “interoperability” in the thread. I think the interoperability with other group standards is desirable but I don’t think we want to strongly put it a strict requirement because of potentially unclear scope and constraints. The previous text looks fine to me in ensuring “proper” use of existing application layer interfaces.

I don’t agree. "proper use of existing TEE-relevant application layer interfaces” is a vague statement that does not represent a clear requirement or constraint on the scope of TEEP work.

Both GlobalPlatform and IETF are starting from the same draft document - of which you and other active participants in TEEP are named as major contributors - so interoperability is an achievable goal.

The work stream in GlobalPlatform has the explicit goal of maintaining interoperability with the version of the OTrP IP that was contributed by its creators (essentially OTrP draft 3.5ish - it is later than 3 but does not include all of draft 4). The technical work of maintaining interoperability within the constraint of other GlobalPlatform specifications is challenging in many respects, but is deemed a worthy goal.

This is not to say that there will not be different emphasis among organisations. As examples, I can see major benefit if IETF completes work on the current draft (without breaking backward compatibility) and then addresses areas such as:
- The use of OTrP with TEEs that have different security models compared to a GlobalPlatform TEE.
- The use of OTrP in constrained devices incapable of supporting the GP technology stack.
- Supporting incorporation of new RFCs into OTrP with backward compatibility.
- Defining clear extension rules to support different use-cases (this may be as simple as reserving namespaces for IETF, GP, others… to use and defining behaviour when these are not recognised by a system)

The main constraint on IETF TEEP specification work should be to avoid breaking changes to the current teep draft due to the existence of other bodies of work relying on it. I want to see strong charter language that reflects this.

Best regards
Jeremy

On 1 Feb 2018, at 01:24, Mingliang Pei <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeremy, Kathleen and TEEP,

>> to ensure that interoperability is maintained with the standards from these groups.

There was some prior discussion on scope and definition of “interoperability” in the thread. I think the interoperability with other group standards is desirable but I don’t think we want to strongly put it a strict requirement because of potentially unclear scope and constraints. The previous text looks fine to me in ensuring “proper” use of existing application layer interfaces.

Best regards,

Ming

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 31, 2018 at 3:13 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, teep <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] Re: [Teep] TEEP go forward plan and charter text

Hi Kathleen, TEEP,

I have a few remarks on the proposed Charter text.

The second of Hannes’ proposed changes (removal of “security domain management”) makes the following paragraph “A security domain allows…” seem out of place.

I suggest that we reject Hannes’ second change.

s/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 ./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 and interoperability with GlobalPlatform OTrP.

Reason: interoperability with other OTrP systems; makes sense given the co-operation with GlobalPlatform proposed below.

s/The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces./The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces and to ensure that interoperability is maintained with the standards from these groups.

Reason: interoperability is the explicit goal of relationships with other groups active in the field.

Best regards
Jeremy

On 31 Jan 2018, at 16:18, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kathleen,

Thanks for the update. It is good to hear that there is progress.

The text below sounds good; I only have a few minor remarks:

---

s/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./ To programmatically install, update, and delete applications in a TEE, this protocol runs between a service 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.

Reason: Just some wording changes to avoid repeated use of "running".

---

---

s/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./
This working group aims to develop an application layer protocol providing TEEs with lifecycle management of trusted applications.

Reason: I would just simplify it and not go into the details. I believe that this functionality is also covered in the  lifecycle management of trusted applications.

---

---

s/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./
The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces.

Reason: I want to explicitly state that this group has to work closely with the SUIT WG to ensure proper alignment.

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

With agreement from IETF 100 that there is sufficient effort to work on TEEP and now a better understanding from GP, I think we are in a position to firm up charter text and to try to charter a working group prior to London.  With that, we'll need to look at the charter text and be sure we have agreement, before I can kick off review within the IESG.

I *think* the last charter text is what was entered on the TEEP page, but am open to be corrected.  That should be our starting point for discussion.  I think the BoF chairs will be able to assist with this process, but I'm not positive on their schedules.  As such it may be a mix of the chairs and AD working on this to see if we can get agreement on charter text.

https://datatracker.ietf.org/doc/charter-ietf-teep/<https://clicktime.symantec.com/a/1/EQb_IqctHFt2aRnBsLG9okbnSbsSPP2nm9dA3Un0w3E=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-teep%2F>

Copied here for your convenience:

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.

--

Best regards,
Kathleen

_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/a/1/70vmngcZmPTPWU_c8qcm4Hxu9BtCIo0S3JyHQQjRT_M=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
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.

_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/a/1/70vmngcZmPTPWU_c8qcm4Hxu9BtCIo0S3JyHQQjRT_M=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Feb 2018 11:35:10 +0000

Hi Jeremy,

I have a common on the topic of backwards compatibility. I am wondering whether it is premature to mandate that there will be no breaking changes. There are a few design decisions I would like to discuss in the group, such as

·       The attestation model

·       The use of JSON/JOSE (as opposed to CBOR/COSE)

·       The use of another JOSE signature/encryption format (as raised by Anders)

·       The alignment with the IETF SUIT working group

·       The concept of security domains

Of course, I wouldn’t want to make random changes that cause pain to other organizations or developers.

Ciao
Hannes

From: Jeremy O'Donoghue [mailto:[email-masked]]
Sent: 01 February 2018 10:42
To: Mingliang Pei
Cc: Hannes Tschofenig; Kathleen Moriarty; teep
Subject: Re: [EXT] Re: [Teep] TEEP go forward plan and charter text

Hi Ming,

Best regards
Jeremy

Best regards,

Ming

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 1 Feb 2018 18:42:14 +0000

Thanks Hannes and Jeremy,

What Hannes pointed out were about some of similar concerns I had for keeping “hard backward compatibility”.  I also see Jeremy’s points on the cases that GP already works on. I wanted to keep backward compatibility myself as one of the main contributors of the OTRP. What I see the possible dilemma is as follows if we put it as a hard requirement in the charter context.

I saw some requests for support different encoding and more use cases. Some of enhancement requests can be simply a different profile (as extension) such as CBOR/COSE while we may still keep JSON/JOSE. Putting aside encoding, some additional parameters might be needed in the message itself to support cloud provider app case, attestation variation, and others yet known. Maintaining complete backward compatibility or interoperability will make those addition hard, virtually requiring to make new additions all OPTIONAL, or have two versions of messages within the protocol. Some restructure would make the protocol cleaner. It should be very close to prior version; we should consider existing work and try to not break them.

If there needs some changes that might break existing protocol draft and GP standard work, we should collaborate to seek a possible timely revision. Would it work instead of being a hard requirement?

Thanks,

Ming

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 1, 2018 at 3:35 AM
To: Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>, Mingliang Pei <[email-masked]<mailto:[email-masked]>>
Cc: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, teep <[email-masked]<mailto:[email-masked]>>
Subject: RE: [EXT] Re: [Teep] TEEP go forward plan and charter text

Hi Jeremy,

·       The attestation model

Ciao
Hannes

Hi Ming,

Best regards
Jeremy

Best regards,

Ming

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 2 Feb 2018 15:58:53 +0000

Hi Mingliang, Hannes.

I am not for a moment suggesting that TEEP will not extend and enhance OTrP in a number of ways - there would be no purpose to a WG if this was not the case.

What I am mainly arguing for is:

  *   Hard backward compatibility SHOULD be the engineering goal.
  *   Where hard backward compatibility is genuinely believed to be infeasible, TEEP needs to work collaboratively with other stakeholders such as GP to address the forward path. It will inevitably be much harder to achieve consensus on backward-incompatible changes as different stakeholders will have different constraints (existing deployed systems, GP requirement to build the technology on the existing GP technology stack, IETF not constrained by GP stack, …)

I believe there is sufficient flexibility in my proposed text (which does explicitly make interoperability with GP and others a goal, but does not mandate how - I think it is unfair to characterise this as “hard” backward compatibility) to allow this.

If you are unhappy with my proposed charter text, perhaps a specific counter-proposal addressing some acceptable mid-point between
    “proper use of use of existing TEE-relevant application layer interfaces”
and
    "proper use of existing TEE-relevant application layer interfaces and to ensure that interoperability is maintained with the standards from these groups”
might be a good way forward.

Best regards
Jeremy

On 1 Feb 2018, at 18:42, Mingliang Pei <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Ming

Hi Jeremy,

Ciao
Hannes

Hi Ming,

Best regards
Jeremy

Best regards,

Ming

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

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.
_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 9 Feb 2018 22:55:04 +0000

Hi,

It is not clear to me that we need to “explicitly” state interoperability as proposed additions below as it is understood in this community, the idea for standardization is to enable interoperability.

I also do not see any text to explicitly state “hard backward compability” but then, I would argue “hard” is too harsh as we need to provide agility to enable these protocols and interfaces to evolve.  Typically, if compatibility is broken then I would expect explicit text to describe how/where compatibility breaks and a rationale (i.e. a shift in security  trends that force improvements that break compability).

Lastly,  I do like “simplicity” but I think of lifecycle management of the apps as being distinct from management of security domains.  So removing it I think would be too much.

We need to get consensus so we can get the charter approved and the group formed….To that extent, here’s the current proposed charter based on current feedback on the thread:
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 in a TEE, this protocol runs between a service 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 the 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 a 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 IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces.

Please provide feedback on whether we can move with this, or if more updates are needed.

Thanks, Nancy

From: TEEP <[email-masked]> on behalf of Jeremy O'Donoghue <[email-masked]>
Date: Friday, February 2, 2018 at 7:59 AM
To: Mingliang Pei <[email-masked]>
Cc: Kathleen Moriarty <[email-masked]>, Hannes Tschofenig <[email-masked]>, teep <[email-masked]>
Subject: Re: [Teep] [EXT] Re: TEEP go forward plan and charter text

Hi Mingliang, Hannes.

Best regards
Jeremy

Thanks,

Ming

Hi Jeremy,

Ciao
Hannes

Hi Ming,

Best regards
Jeremy

Best regards,

Ming

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

---

From: Mingliang Pei <[email-masked]>
Date: Sat, 10 Feb 2018 01:07:08 +0000

Thanks Kathleen. The charter text is good for me, Ming

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 9, 2018 at 2:55 PM
To: Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>, Mingliang Pei <[email-masked]<mailto:[email-masked]>>
Cc: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>, teep <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] Re: [Teep] [EXT] Re: TEEP go forward plan and charter text

Hi,

Thanks, Nancy

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 2, 2018 at 7:59 AM
To: Mingliang Pei <[email-masked]<mailto:[email-masked]>>
Cc: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>, teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] [EXT] Re: TEEP go forward plan and charter text

Hi Mingliang, Hannes.

Best regards
Jeremy

Thanks,

Ming

Hi Jeremy,

Ciao
Hannes

Hi Ming,

Best regards
Jeremy

Best regards,

Ming

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

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.
_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep<https://clicktime.symantec.com/a/1/KGaUCit9zhfyXKUXMZd3WxCmH78jYG0QTfxrL6m81d0=?d=9b_mgwJfztQfynuNXEPeubDFF3f97DlJIOAQwbduYLnqrj1lgU0CLt8lINKYfUkwU-3xJj8HKdhL9PL7kbyFG1NZT8nzDlVOGqi2vRelEg333z6CXLI_lTbB0QqTT4tOAfyDE7jGPuxtj1c0gEThBO3cZCDuGgKEGjXIQiwdu7mOUwv_SRuptpJyaAjZRvPiYFj_wpXu4KBwrVq_mJGQh0Ljj-Y8_-VoYAcQ5hUYYJq3obeaYPS0AnBJyQ5NF_h327Zys6c8b9LLtR1nNt4cfxM92dLp4qwEM7IDPQKOWOVSPJIdlhCuzbNuPSmKmfYAYkklh0Lfj13YQuZQ7ywXK8S5ROLwSd3fxZlGHf7Ol886bPdbgJSAM1q7-hmLHqqZvYZcd1y7u9JpUvO2vFk8ibQ%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>

---

From: Lubna Dajani <[email-masked]>
Date: Sat, 10 Feb 2018 07:34:24 +0000

Thanks Kathleen.  Looks good.

_____________________________________________________________________
@LubnaDajani  I  allternet.org  I  + 1 201 982 0934 (US)  |  + 44 7 55 77
63092 (UK)

*Does your personal data matter to you? please visit www.digital20.com
<http://www.digital20.com> *

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

On Sat, Feb 10, 2018 at 1:07 AM, Mingliang Pei <[email-masked]>
wrote:

> From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
> To: Jeremy O'Donoghue <[email-masked]>, Mingliang Pei <
> [email-masked]>
> Cc: Kathleen Moriarty <[email-masked]>, Hannes
> Tschofenig <[email-masked]>, teep <[email-masked]>
> It is not clear to me that we need to “explicitly” state interoperability
> as proposed additions below as it is understood in this community, the idea
> for standardization is to enable interoperability.
>
>
>
> I also do not see any text to explicitly state “hard backward compability”
> but then, I would argue “hard” is too harsh as we need to provide agility
> to enable these protocols and interfaces to evolve.  Typically, if
> compatibility is broken then I would expect explicit text to describe
> how/where compatibility breaks and a rationale (i.e. a shift in security
> trends that force improvements that break compability).
>
>
>
> Lastly,  I do like “simplicity” but I think of lifecycle management of the
> apps as being distinct from management of security domains.  So removing it
> I think would be too much.
>
>
>
> We need to get consensus so we can get the charter approved and the group
> formed….To that extent, here’s the current proposed charter based on
> current feedback on the thread:
>
> 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 in a TEE,
> this protocol runs between a service 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 the form of
> attestation and the device-side may require information about the server.
>
> This working group aims to develop an application layer protocol providing
> TEEs with a 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 IETF SUIT working
> group, GlobalPlatform, Trusted Computing Group, and other relevant
> standards to ensure proper use of existing TEE-relevant application layer
> interfaces.
>
>
>
> *From: *TEEP <[email-masked]> on behalf of Jeremy O'Donoghue <
> [email-masked]>
> *Date: *Friday, February 2, 2018 at 7:59 AM
> *To: *Mingliang Pei <[email-masked]>
> *Cc: *Kathleen Moriarty <[email-masked]>, Hannes
> Tschofenig <[email-masked]>, teep <[email-masked]>
> *Subject: *Re: [Teep] [EXT] Re: TEEP go forward plan and charter text
>
>
>
> Hi Mingliang, Hannes.
>
>
>
> I am not for a moment suggesting that TEEP will not extend and enhance
> OTrP in a number of ways - there would be no purpose to a WG if this was
> not the case.
>
>
>
>    - Hard backward compatibility SHOULD be the engineering goal.
>    - Where hard backward compatibility is genuinely believed to be
>    infeasible, TEEP needs to work collaboratively with other stakeholders such
>    as GP to address the forward path. It will inevitably be much harder to
>    achieve consensus on backward-incompatible changes as different
>    stakeholders will have different constraints (existing deployed systems, GP
>    requirement to build the technology on the existing GP technology stack,
>    IETF not constrained by GP stack, …)
>
>
>
> I believe there is sufficient flexibility in my proposed text (which does
> explicitly make interoperability with GP and others a goal, but does not
> mandate how - I think it is unfair to characterise this as “hard” backward
> compatibility) to allow this.
>
>
>
> If you are unhappy with my proposed charter text, perhaps a specific
> counter-proposal addressing some acceptable mid-point between
>
>     "proper use of existing TEE-relevant application layer interfaces and
> to ensure that interoperability is maintained with the standards from these
> groups”
>
> On 1 Feb 2018, at 18:42, Mingliang Pei <[email-masked]> wrote:
>
>
>
> What Hannes pointed out were about some of similar concerns I had for
> keeping “hard backward compatibility”.  I also see Jeremy’s points on the
> cases that GP already works on. I wanted to keep backward compatibility
> myself as one of the main contributors of the OTRP. What I see the possible
> dilemma is as follows if we put it as a hard requirement in the charter
> context.
>
>
>
> I saw some requests for support different encoding and more use cases.
> Some of enhancement requests can be simply a different profile (as
> extension) such as CBOR/COSE while we may still keep JSON/JOSE. Putting
> aside encoding, some additional parameters might be needed in the message
> itself to support cloud provider app case, attestation variation, and
> others yet known. Maintaining complete backward compatibility or
> interoperability will make those addition hard, virtually requiring to make
> new additions all OPTIONAL, or have two versions of messages within the
> protocol. Some restructure would make the protocol cleaner. It should be
> very close to prior version; we should consider existing work and try to
> not break them.
>
>
>
> If there needs some changes that might break existing protocol draft and
> GP standard work, we should collaborate to seek a possible timely revision.
> Would it work instead of being a hard requirement?
>
>
>
> Thanks,
>
>
>
> Ming
>
>
>
> *From: *Hannes Tschofenig <[email-masked]>
> *Date: *Thursday, February 1, 2018 at 3:35 AM
> *To: *Jeremy O'Donoghue <[email-masked]>, Mingliang Pei <
> [email-masked]>
> *Cc: *Kathleen Moriarty <[email-masked]>, teep <
> [email-masked]>
> *Subject: *RE: [EXT] Re: [Teep] TEEP go forward plan and charter text
>
>
>
> Hi Jeremy,
>
>
>
> I have a common on the topic of backwards compatibility. I am wondering
> whether it is premature to mandate that there will be no breaking changes.
> There are a few design decisions I would like to discuss in the group, such
> as
>
> ·       The attestation model
>
> *From:* Jeremy O'Donoghue [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 01 February 2018 10:42
> *To:* Mingliang Pei
> *Cc:* Hannes Tschofenig; Kathleen Moriarty; teep
> *Subject:* Re: [EXT] Re: [Teep] TEEP go forward plan and charter text
>
>
>
> Hi Ming,
>
>
>
> There was some prior discussion on scope and definition of
> “interoperability” in the thread. I think the interoperability with other
> group standards is desirable but I don’t think we want to strongly put it a
> strict requirement because of potentially unclear scope and constraints.
> The previous text looks fine to me in ensuring “proper” use of existing
> application layer interfaces.
>
>
>
> I don’t agree. "proper use of existing TEE-relevant application layer
> interfaces” is a vague statement that does not represent a clear
> requirement or constraint on the scope of TEEP work.
>
>
>
> Both GlobalPlatform and IETF are starting from the same draft document -
> of which you and other active participants in TEEP are named as major
> contributors - so interoperability is an achievable goal.
>
>
>
> The work stream in GlobalPlatform has the explicit goal of maintaining
> interoperability with the version of the OTrP IP that was contributed by
> its creators (essentially OTrP draft 3.5ish - it is later than 3 but does
> not include all of draft 4). The technical work of maintaining
> interoperability within the constraint of other GlobalPlatform
> specifications is challenging in many respects, but is deemed a worthy goal.
>
>
>
> This is not to say that there will not be different emphasis among
> organisations. As examples, I can see major benefit if IETF completes work
> on the current draft (without breaking backward compatibility) and then
> addresses areas such as:
>
> - Defining clear extension rules to support different use-cases (this may
> be as simple as reserving namespaces for IETF, GP, others… to use and
> defining behaviour when these are not recognised by a system)
>
>
>
> The main constraint on IETF TEEP specification work should be to avoid
> breaking changes to the current teep draft due to the existence of other
> bodies of work relying on it. I want to see strong charter language that
> reflects this.
>
>
>
> Best regards
>
> Jeremy
>
>
>
>
> On 1 Feb 2018, at 01:24, Mingliang Pei <[email-masked]> wrote:
>
>
>
> There was some prior discussion on scope and definition of
> “interoperability” in the thread. I think the interoperability with other
> group standards is desirable but I don’t think we want to strongly put it a
> strict requirement because of potentially unclear scope and constraints.
> The previous text looks fine to me in ensuring “proper” use of existing
> application layer interfaces.
>
>
>
> Best regards,
>
>
>
> Ming
>
>
>
> *From: *TEEP <[email-masked]> on behalf of Jeremy O'Donoghue <
> [email-masked]>
> *Date: *Wednesday, January 31, 2018 at 3:13 PM
> *To: *Hannes Tschofenig <[email-masked]>
> *Cc: *Kathleen Moriarty <[email-masked]>, teep <
> [email-masked]>
> *Subject: *[EXT] Re: [Teep] TEEP go forward plan and charter text
>
>
>
> Hi Kathleen, TEEP,
>
>
>
> The second of Hannes’ proposed changes (removal of “security domain
> management”) makes the following paragraph “A security domain allows…” seem
> out of place.
>
>
>
> s/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 ./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 and interoperability with GlobalPlatform OTrP.
>
> Reason: interoperability with other OTrP systems; makes sense given the
> co-operation with GlobalPlatform proposed below.
>
>
>
> s/The group will maintain a close relationship with the IETF SUIT working
> group, GlobalPlatform, Trusted Computing Group, and other relevant
> standards to ensure proper use of existing TEE-relevant application layer
> interfaces./The group will maintain a close relationship with the IETF SUIT
> working group, GlobalPlatform, Trusted Computing Group, and other relevant
> standards to ensure proper use of existing TEE-relevant application layer
> interfaces and to ensure that interoperability is maintained with the
> standards from these groups.
>
>
>
> On 31 Jan 2018, at 16:18, Hannes Tschofenig <[email-masked]>
> wrote:
>
>
>
> Hi Kathleen,
>
> s/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./
> To programmatically install, update, and delete applications in a TEE, this
> protocol runs between a service 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.
>
> s/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./
> This working group aims to develop an application layer protocol providing
> TEEs with lifecycle management of trusted applications.
>
> Reason: I would just simplify it and not go into the details. I believe
> that this functionality is also covered in the  lifecycle management of
> trusted applications.
>
> ---
>
> ---
>
> s/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./
> The group will maintain a close relationship with the IETF SUIT working
> group, GlobalPlatform, Trusted Computing Group, and other relevant
> standards to ensure proper use of existing TEE-relevant application layer
> interfaces.
>
> Reason: I want to explicitly state that this group has to work closely
> with the SUIT WG to ensure proper alignment.
>
> ---
>
> Ciao
> Hannes
>
>
> From: TEEP [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Kathleen Moriarty
> With agreement from IETF 100 that there is sufficient effort to work on
> TEEP and now a better understanding from GP, I think we are in a position
> to firm up charter text and to try to charter a working group prior to
> London.  With that, we'll need to look at the charter text and be sure we
> have agreement, before I can kick off review within the IESG.
>
> I *think* the last charter text is what was entered on the TEEP page, but
> am open to be corrected.  That should be our starting point for
> discussion.  I think the BoF chairs will be able to assist with this
> process, but I'm not positive on their schedules.  As such it may be a mix
> of the chairs and AD working on this to see if we can get agreement on
> charter text.
>
> https://datatracker.ietf.org/doc/charter-ietf-teep/
> <https://clicktime.symantec.com/a/1/EQb_IqctHFt2aRnBsLG9okbnSbsSPP2nm9dA3Un0w3E=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-teep%2F>
>
> 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.
>
> 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.
>
>
> --
>
> Best regards,
> Kathleen
>
> [email-masked]
> https://clicktime.symantec.com/a/1/70vmngcZmPTPWU_
> c8qcm4Hxu9BtCIo0S3JyHQQjRT_M=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQs
> DTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_
> jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1Q
> zpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-
> S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPB
> i6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX
> 2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=
> https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
> 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.
>
> [email-masked]
> https://clicktime.symantec.com/a/1/70vmngcZmPTPWU_
> c8qcm4Hxu9BtCIo0S3JyHQQjRT_M=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQs
> DTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_
> jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1Q
> zpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-
> S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPB
> i6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX
> 2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=
> https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>
>
>
>
>
> 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.
>
> [email-masked]
> <https://clicktime.symantec.com/a/1/KGaUCit9zhfyXKUXMZd3WxCmH78jYG0QTfxrL6m81d0=?d=9b_mgwJfztQfynuNXEPeubDFF3f97DlJIOAQwbduYLnqrj1lgU0CLt8lINKYfUkwU-3xJj8HKdhL9PL7kbyFG1NZT8nzDlVOGqi2vRelEg333z6CXLI_lTbB0QqTT4tOAfyDE7jGPuxtj1c0gEThBO3cZCDuGgKEGjXIQiwdu7mOUwv_SRuptpJyaAjZRvPiYFj_wpXu4KBwrVq_mJGQh0Ljj-Y8_-VoYAcQ5hUYYJq3obeaYPS0AnBJyQ5NF_h327Zys6c8b9LLtR1nNt4cfxM92dLp4qwEM7IDPQKOWOVSPJIdlhCuzbNuPSmKmfYAYkklh0Lfj13YQuZQ7ywXK8S5ROLwSd3fxZlGHf7Ol886bPdbgJSAM1q7-hmLHqqZvYZcd1y7u9JpUvO2vFk8ibQ%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
>
>
>
> [email-masked]

---

From: "Wheeler, David M" <[email-masked]>
Date: Sun, 11 Feb 2018 14:46:56 +0000

Nancy,
This looks good from my end.
Thanks,
Dave Wheeler

From: TEEP [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, February 9, 2018 3:55 PM
To: Jeremy O'Donoghue <[email-masked]>; Mingliang Pei <[email-masked]>
Cc: Kathleen Moriarty <[email-masked]>; Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] [EXT] Re: TEEP go forward plan and charter text

Hi,

Thanks, Nancy

Hi Mingliang, Hannes.

Best regards
Jeremy

Thanks,

Ming

Hi Jeremy,

Ciao
Hannes

Hi Ming,

Best regards
Jeremy

Best regards,

Ming

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 14 Feb 2018 13:37:27 -0500

Thank you, Nancy for updating the text and others for your review.
There is still time to provide comments through the review process,
but it looks like we are at a pretty stable version.  As such, I'll
kick off the process for charting TEEP.

What are the milestones?

Best regards,
Kathleen

On Sun, Feb 11, 2018 at 9:46 AM, Wheeler, David M
<[email-masked]> wrote:
> Cc: Kathleen Moriarty <[email-masked]>; Hannes Tschofenig
> <[email-masked]>; teep <[email-masked]>
>
>
> It is not clear to me that we need to “explicitly” state interoperability as
> proposed additions below as it is understood in this community, the idea for
> standardization is to enable interoperability.
>
>
>
> but then, I would argue “hard” is too harsh as we need to provide agility to
> enable these protocols and interfaces to evolve.  Typically, if
> formed….To that extent, here’s the current proposed charter based on current
> feedback on the thread:
>
> 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.
>
> applications. Some tasks are security sensitive and the server side requires
> information about the device characteristics in the form of attestation and
> the device-side may require information about the server.
>
> TEEs with a 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.
>
> 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.
>
> group, GlobalPlatform, Trusted Computing Group, and other relevant standards
> to ensure proper use of existing TEE-relevant application layer interfaces.
>
>
>
> Cc: Kathleen Moriarty <[email-masked]>, Hannes Tschofenig
> <[email-masked]>, teep <[email-masked]>
> I am not for a moment suggesting that TEEP will not extend and enhance OTrP
> in a number of ways - there would be no purpose to a WG if this was not the
> case.
>
>
>
> Hard backward compatibility SHOULD be the engineering goal.
> Where hard backward compatibility is genuinely believed to be infeasible,
> TEEP needs to work collaboratively with other stakeholders such as GP to
> address the forward path. It will inevitably be much harder to achieve
> consensus on backward-incompatible changes as different stakeholders will
> have different constraints (existing deployed systems, GP requirement to
> build the technology on the existing GP technology stack, IETF not
> constrained by GP stack, …)
>
>
>
>     "proper use of existing TEE-relevant application layer interfaces and to
> ensure that interoperability is maintained with the standards from these
> groups”
>
> I saw some requests for support different encoding and more use cases. Some
> of enhancement requests can be simply a different profile (as extension)
> such as CBOR/COSE while we may still keep JSON/JOSE. Putting aside encoding,
> some additional parameters might be needed in the message itself to support
> cloud provider app case, attestation variation, and others yet known.
> Maintaining complete backward compatibility or interoperability will make
> those addition hard, virtually requiring to make new additions all OPTIONAL,
> or have two versions of messages within the protocol. Some restructure would
> make the protocol cleaner. It should be very close to prior version; we
> should consider existing work and try to not break them.
>
>
>
> If there needs some changes that might break existing protocol draft and GP
> standard work, we should collaborate to seek a possible timely revision.
> From: Hannes Tschofenig <[email-masked]>
> To: Jeremy O'Donoghue <[email-masked]>, Mingliang Pei
> <[email-masked]>
> Cc: Kathleen Moriarty <[email-masked]>, teep
> <[email-masked]>
> strict requirement because of potentially unclear scope and constraints. The
> previous text looks fine to me in ensuring “proper” use of existing
> interfaces” is a vague statement that does not represent a clear requirement
> or constraint on the scope of TEEP work.
>
>
>
> Both GlobalPlatform and IETF are starting from the same draft document - of
> which you and other active participants in TEEP are named as major
> interoperability with the version of the OTrP IP that was contributed by its
> creators (essentially OTrP draft 3.5ish - it is later than 3 but does not
> include all of draft 4). The technical work of maintaining interoperability
> within the constraint of other GlobalPlatform specifications is challenging
> in many respects, but is deemed a worthy goal.
>
>
>
> - Defining clear extension rules to support different use-cases (this may be
> as simple as reserving namespaces for IETF, GP, others… to use and defining
> behaviour when these are not recognised by a system)
>
>
>
> strict requirement because of potentially unclear scope and constraints. The
> previous text looks fine to me in ensuring “proper” use of existing
> To: Hannes Tschofenig <[email-masked]>
> Cc: Kathleen Moriarty <[email-masked]>, teep
> <[email-masked]>
> s/A security domain allows a service provider's applications to be isolated
> cryptography ./A security domain allows a service provider's applications to
> be isolated so that one security domain cannot be influenced by another,
> group, GlobalPlatform, Trusted Computing Group, and other relevant standards
> to ensure proper use of existing TEE-relevant application layer
> requires information about the device characteristics in form of attestation
> and the device-side may require information about the server./ To
> programmatically install, update, and delete applications in a TEE, this
> 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.
>
> s/This working group aims to develop an application layer protocol providing
> applications, and * security domain management./
> Reason: I would just simplify it and not go into the details. I believe that
> this functionality is also covered in the  lifecycle management of trusted
> applications.
>
> ---
>
> ---
>
> group, GlobalPlatform, Trusted Computing Group, and other relevant standards
> to ensure proper use of existing TEE-relevant application layer interfaces.
>
> With agreement from IETF 100 that there is sufficient effort to work on TEEP
> and now a better understanding from GP, I think we are in a position to firm
> up charter text and to try to charter a working group prior to London.  With
> that, we'll need to look at the charter text and be sure we have agreement,
> before I can kick off review within the IESG.
>
> I *think* the last charter text is what was entered on the TEEP page, but am
> open to be corrected.  That should be our starting point for discussion.  I
> think the BoF chairs will be able to assist with this process, but I'm not
> positive on their schedules.  As such it may be a mix of the chairs and AD
> working on this to see if we can get agreement on charter text.
>
> 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.
>
> 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.
>
> 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.
>

-- 

Best regards,
Kathleen

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 15 Feb 2018 11:38:30 +0000

I remain unconvinced that the proposed text is strong enough on backward compatibility, but as no-one else seems to agree I will leave things as-is. My concerns are on record and that is sufficient. Please go ahead with the proposed text if that is what the rest of the group prefers as I seem to the only hold-out to consensus.

The proof point will in any case be in the creation of the technical standards rather than the charter text itself.

For information, my personal understanding of the GlobalPlatform position on backward compatibility is that its work will be backward-compatible with the version of OTrP contributed to GlobalPlatform by the OTPA and it will track IETF work to the extent that it remains backward-compatible with the original contribution to GlobalPlatform, provided that appropriate liaison arrangements are in place. 

This policy was made on the basis that at the time of contribution to GP the Open Trust Protocol Alliance (the contributor) indicated that deployed OTrP systems already exist and that backward compatibility was therefore a strong goal in making the contribution to GlobalPlatform.

Best regards
Jeremy

> On 14 Feb 2018, at 18:37, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 20 Feb 2018 18:43:24 +0000

HI Jeremy,
Thanks for the feedback and note that the notion of backward compatibility is imho an organic responsibility that the WG members must agree on in the actual protocols and interfaces adopted.  I also suspect that this will also hold as we did state in the charter expectations to maintaining a connection with GP (and SUIT).

We look forward to your active participation!

Warm regards, Nancy

On 2/15/18, 3:38 AM, "TEEP on behalf of Jeremy O'Donoghue" <[email-masked] on behalf of [email-masked]> wrote:

    

    Best regards
    Jeremy