Address comments from Juergen

Most feedback in Juergen's review in issue #70 are addressed by other
PRs that address other github issues.  This PR covers the rest of
issue #70.

Signed-off-by: Dave Thaler <dthaler@microsoft.com>

draft-ietf-teep-architecture.md

@@ -126,16 +126,16 @@ To simplify the life of developers and service providers interacting
 with TAs in a TEE, an interoperable protocol for managing TAs running in
 different TEEs of various devices is needed. In this TEE ecosystem,
 there often arises a need for an external trusted party to verify the
-identity, claims, and rights of Service Providers(SP), devices, and their TEEs.
+identity, claims, and rights of Service Providers (SP), devices, and their TEEs.
 This trusted third party is the Trusted Application Manager (TAM).
 
 The Trusted Execution Provisioning (TEEP) protocol addresses the following problems:
 
   - A Service Provider (SP) intending to provide services through a TA
     to users of a device needs to determine security-relevant
     information of a device before provisioning their TA to the TEE
-    within the device. Examples include the verification of the device
-    'root of trust' and the type of TEE included in a device.
+    within the device. An example is the verification of 
+    the type of TEE included in a device.
 
   - A TEE in a device needs to determine whether a Service Provider (SP)
     that wants to manage a TA in the device is authorized to manage TAs
@@ -177,7 +177,11 @@ The following terms are used:
     Environment, such as an Android, Windows, or iOS application.
     We sometimes refer to this as the 'Client App'.
 
-  - Device: A physical piece of hardware that hosts a TEE along with
+  - Trusted Application Manager (TAM): An entity that manages Trusted
+    Applications (TAs) running in different TEEs of various devices.
+
+  - Device: A physical piece of hardware that hosts one or more TEEs,
+    often along with
     a Rich Execution Environment. A Device contains a default list
     of Trust Anchors that identify entities (e.g., TAMs) that are
     trusted by the Device. This list is normally set by the Device
@@ -261,54 +265,20 @@ The following terms are used:
 
     There are multiple technologies that can be used to implement
     a TEE, and the level of security achieved varies accordingly.
+    In addition, TEEs typically use an isolation mechanism between Trusted Applications to ensure
+    that one TA cannot read, modify or delete the data and code of another
+    TA.
 
-  - Root-of-Trust (RoT): A hardware or software component in a device
-    that is inherently trusted to perform a certain security-critical
-    function. A RoT should be secure by design, small, and protected
-    by hardware against modification or interference. Examples of
-    RoTs include software/firmware measurement and verification using
-    a Trust Anchor (RoT for Verification), provide signed assertions
-    using a protected attestation key (RoT for Reporting), or protect the
-    storage and/or use of cryptographic keys (RoT for Storage). Other
-    RoTs are possible, including RoT for Integrity, and RoT for Measurement.
-    Reference: NIST SP800-164 (Draft).
-
-  - Trusted Firmware (TFW): A firmware in a device that can be verified
-    with a Trust Anchor by RoT for Verification.
+  - Trusted Firmware (TFW): Firmware that is inherently trusted, or
+    that can be verified by a hardware component that is inherently trusted.
+    Some devices with TEEs have Trusted Firmware, and some do not need
+    Trusted Firmware.
 
   - Bootloader key: This symmetric key is protected by
     electronic fuse (eFUSE) technology. In this context it is used to decrypt a
     TFW private key, which belongs to a device-unique private/public key pair.
     Not every device is equipped with a bootloader key.
 
-This document uses the following abbreviations:
-
-  - CA: Certificate Authority
-
-  - REE: Rich Execution Environment
-
-  - RoT: Root of Trust
-
-  - SP: Service Provider
-
-  - TA: Trusted Application
-
-  - TAM: Trusted Application Manager
-
-  - TEE: Trusted Execution Environment
-
-  - TFW: Trusted Firmware
-
-# Assumptions
-
-This specification assumes that an applicable device is equipped with
-one or more TEEs and each TEE is pre-provisioned with a device-unique
-public/private key pair, which is securely stored.
-
-A TEE uses an isolation mechanism between Trusted Applications to ensure
-that one TA cannot read, modify or delete the data and code of another
-TA.
-
 # Use Cases
 
 ## Payment
@@ -395,16 +365,16 @@ all components are further explained in the following paragraphs.
     with devices. DAs may elect to use a TAM for remote administration
     of TAs instead of managing each device directly.
 
-  - TAM:  A TAM is responsible for performing lifecycle
+  - Trusted Application Manager (TAM):  A TAM is responsible for performing lifecycle
     management activity on TA's on behalf of Service
     Providers and Device Administrators. This includes creation and
-    deletion of TA's, and may include, for example,  over-the-air
+    deletion of TA's, and may include, for example, over-the-air
     updates to keep an SP's TAs up-to-date and clean up when a version
     should be removed. TAMs may provide services that make it easier for
     SPs or DAs to use the TAM's service to manage multiple devices,
     although that is not required of a TAM.
 
-    The TAM performs its management of TA's through  an
+    The TAM performs its management of TA's through an
     interaction with a Device's TEEP Broker. As shown in
     {{notionalarch}}, the TAM cannot directly contact a Device, but must
     wait for the TEEP Broker to contact
@@ -469,9 +439,9 @@ all components are further explained in the following paragraphs.
 There is nothing prohibiting a device from implementing multiple TEEs. In
 addition, some TEEs (for example, SGX) present themselves as separate containers
 within memory without a controlling manager within the TEE. In these cases,
-the rich operating system hosts multiple TEEP brokers, where each broker manages
+the rich operating system hosts multiple TEEP Brokers, where each Broker manages
 a particular TEE or set of TEEs. Enumeration and access to the appropriate
-broker is up to the rich OS and the applications. Verification that the correct TA
+Broker is up to the rich OS and the applications. Verification that the correct TA
 has been reached then becomes a matter of properly verifying TA attestations,
 which are unforgeable. The multiple TEE approach is shown in the diagram below.
 For brevity, TEEP Broker 2 is shown interacting with only one TAM and UA, but
@@ -831,7 +801,7 @@ that is chained to a CA that the TAM trusts.
 ## Keys and Certificate Types
 
 This architecture leverages the following credentials, which allow
-delivering end-to-end security without relying on any transport
+delivering security between a TEEP Agent and a TAM without relying on any transport
 security.
 
 ~~~~
@@ -956,7 +926,7 @@ Messages created by a TAM are used to deliver TA
 management commands to a device, and device attestation and
 messages created by the device TEE to respond to TAM messages.
 
-These messages are signed end-to-end and are typically encrypted such
+These messages are signed end-to-end between a TEEP Agent and a TAM, and are typically encrypted such
 that only the targeted device TEE or TAM is able to decrypt and view
 the actual content.
 
@@ -996,36 +966,25 @@ Step 4: Set up Trust Anchors in devices
 
 # TEEP Broker
 
-A TEE and TAs do not generally have the capability to communicate to the
+A TEE and TAs often do not have the capability to directly communicate
 outside of the hosting device.  For example, GlobalPlatform
 {{GPTEE}} specifies one such architecture.  This calls for a software
-module in the REE world to handle the network communication.  Each
-Client Application in the REE might carry this communication functionality
-but such functionality must also interact with the TEE for the message exchange.
-The TEE interaction will vary according to different TEEs.  In order for
-a Client Application to transparently support different TEEs, it is
-imperative to have a common interface for a Client Application to
-invoke for exchanging messages with TEEs.
-
-A shared module in REE comes to meet this need.  A TEEP broker is an application
+module in the REE world to handle network communication with a TAM.
+
+A TEEP Broker is an application component
 running in the REE of the device or an SDK that facilitates
 communication between a TAM and a TEE.  It also provides interfaces for
 Client Applications to query and trigger TA installation that the
 application needs to use.
 
-It isn't always that a Client Application directly calls such a Broker
-to interact with a TEE. A REE Application Installer might carry out TEE
-and TAM interaction to install all required TAs that a Client Application
-depends. A Client Application may have a metadata file that describes
-the TAs it depends on and the associated TAM that each TA installation
-goes to use. The REE Application Installer can inspect the
-application metadata file and installs TAs on behalf of the Client
+An Untrusted Application might communicate with the TEEP Broker at runtime
+to trigger TA installation itself. Or an Untrusted Application might simply
+have a metadata file that describes the TAs it depends on and the associated TAM(s) for each TA,
+and an REE Application Installer can inspect this
+application metadata file and invoke the TEEP Broker to trigger TA installation
+on behalf of the Client
 Application without requiring the Client Application to run first.
 
-This interface for Client Applications or Application Installers may be
-commonly in a form of an OS service call for an REE OS.  A Client Application
-or an Application Installer interacts with the device TEE and the TAMs.
-
 ## Role of the TEEP Broker
 
 A TEEP Broker abstracts the message exchanges with a TEE in a device.
@@ -1077,7 +1036,7 @@ The following conceptual APIs exist from a TEEP Broker to a TEEP Agent:
 4. ProcessError: A notification that the TEEP Broker could not deliver an outbound
    TEEP message to a TAM.
 
-For comparison, similar APIs may exist on the TAM side, where a broker may or may not
+For comparison, similar APIs may exist on the TAM side, where a Broker may or may not
 exist (depending on whether the TAM uses a TEE or not):
 
 1. ProcessConnect: A notification that an incoming TEEP session is being requested by a TEEP Agent.
@@ -1390,9 +1349,7 @@ trustworthiness of a TA.  A TEEP Broker has a function to allow an
 application to query the information about a TA.
 
 An application in the Rich O/S may perform verification of the TA by
-verifying the signature of the TA.  The GetTAInformation function is
-available to return the TEE supplied TA signer and TAM signer
-information to the application.  An application can do additional
+verifying the signature of the TA.  An application can do additional
 trust checks on the certificate returned for this TA.  It might trust
 the TAM, or require additional SP signer trust chaining.