[Teep] use case document comments
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 March 2017 01:07 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 4A29B131780 for <teep@ietfa.amsl.com>; Tue, 14 Mar 2017 18:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 FkFsTn4xrU7O for <teep@ietfa.amsl.com>; Tue, 14 Mar 2017 18:07:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536F2129468 for <teep@ietf.org>; Tue, 14 Mar 2017 18:07:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 95F97E1F7 for <teep@ietf.org>; Tue, 14 Mar 2017 21:30:03 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 26E3D636E0 for <teep@ietf.org>; Tue, 14 Mar 2017 21:06:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: teep <teep@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 14 Mar 2017 21:06:59 -0400
Message-ID: <19661.1489540019@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/twmxj2GA_chf5NVme_bdNJ4Fp-w>
Subject: [Teep] use case document comments
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: Wed, 15 Mar 2017 01:07:03 -0000
Thank you for the use case document. I think that there is a need in the use case document to explain who owns the code inside the TEE. (It seems that a device like a smartphone would need a multitude of TEEs) 3.1. Use Case 1 - Payment So on the one hand the document suggests that the TEE will contain personal information relating to payment, so be securely unlocked by the end user via some kind of SecureAttentionKey interface. A private key, or perhaps an anchor for a blockchain signer.... So the end user needs to intimately control what code is inside (i.e: be able to delegate that trust to a party that they trust). Then the document says: For the development of the relevant TA of SP, the use of OTrP can easily send the latest trusted application to the device. I get the impression that the bank is going to send updates to the trust application. But, it's the bank that I'm going to dispute a payment with, so in fact, I can't let them create the audit trail at my end. No use case was given for media, yet that was mentioned. Nor Enterprise. In each case, I think that the contents of the TEE are controlled by a different party. And each party seems to want to control the screen and keyboard. 3.2. Use Case 2 - IoT The only example here given is smart door locks. I think that this is really confused. The most important thing the TEE can do is to provide original bootstrap process, and then yes, storage and update of session keys. After putting all that in the TEE, what's actually left? ==== Based upon what I have read so far, I can't see a role for the IETF, but I continue to read with an open mind. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Teep] use case document comments Michael Richardson
- Re: [Teep] use case document comments Jeremy O'Donoghue
- Re: [Teep] use case document comments Dapeng Liu