ietf-teep / teep-protocol

TEEP Protocol Specification

TEEP Protocol

TEEP Protocol Draft

• draft-ietf-teep-protocol

Converting draft

Prerequisite packages

Requires two packages:

kramdown-rfc2629 by Ruby
xml2rfc by Python

Installing required packages on Fedora

sudo dnf makecache
sudo dnf -y install python3-pip git make gem
gem install kramdown-rfc2629
pip3 install xml2rfc

Installing required packages on Ubuntu

sudo apt-get update
sudo apt-get -y install python3-pip ruby git curl
pip3 install xml2rfc
gem install kramdown-rfc2629

Installing cddl tool https://rubygems.org/gems/cddl

gem install cddl
gem update

Note that the cddl validation uses this cddl tool, not the one from https://github.com/anweiss/cddl.

Generating draft from a markdown file

git clone https://github.com/ietf-teep/teep-protocol.git
cd teep-protocol/
make

It will create draft-ietf-teep-protocol-latest.txt and draft-ietf-teep-protocol-latest.xml.

Checking cddl syntax

Creating concatenated cddl file for TEEP Protocol.

The file name 'check-draft-ietf-teep-protocol.cddl' will be created under directory 'cddl'. The cddl file for TEEP Protocol requires cddl files from suit-report and suit-manifest. This command downloads cddl files from respected repos and concatenates them to one cddl file usable to run with the cddl tool.

make -C cddl

Perform cddl syntax check with cddl tool.

The command to run FULL cddl syntax check.

make validate-cddl

To check syntax cddl syntax in TEEP file and not suit which is useful during debugging teep by using only QueryRequest which do not contain SUIT part.

make validate-teep-cddl

Push both md and cddl file to git repo every time revising md file.

The cddl file will be updated from the md file every time when running make.

You must push the changes of commit of both md file and cddl file even if you only have changed md file.

teep-protocol's Issues

Is challenge mandatory or optional when attestation bit set

The QueryResponse message has an optional “challenge” field used in creating Evidence, with the description:

When a challenge is provided in the QueryRequest and an EAT is returned with the QueryResponse message then the challenge contained in this request MUST be copied into the nonce claim found in the EAT.

Q1: RATS attestation architecture doc explains attestation can use nonces, timestamps, or handles. Does TEEP require nonce approach or is any of the approaches ok?

The original intent of the TEEP text was: any is ok, attestation bit can be set with challenge absent

Q2: But then how do Verifier & Agent agree on freshness approach?

The Evidence in the QueryResponse is sufficient to convey what the Agent used. For example, EAT has separate claims for nonce vs timestamp (and presumably in the future, handle). But how does the Verifier convey what it expects?

Some potential options include:

Option 1: force use of a single approach (narrows TEEP applicability)
Option 2: force Agent to support all (hard for constrained Agents)
Option 3: add field in QueryRequest like we did for supported ciphersuites (but TAM is just a passthrough, like for challenge, so like challenge the actual content would be obtained from the Verifier)
Option 4: overload challenge field and make the challenge field mandatory when attestation bit set

My preference would be option 3.

This issue is partially related to issue #127

QueryResponse without QueryRequest

In Hannes's review of the teep-over-http draft, he said:

FWIW the note that the TEEP Agent can start with a QueryResponse if it has the TAM public key is IMHO incorrect

This came from previous OTrP text where OTrP allowed such an optimization in order to minimize RTTs and bandwidth for constrained devices. Shouldn't we add this optimization into the TEEP protocol?

Which ciphersuite(s) are mandatory to implement

The current draft defines values for 2 ciphersuites, but is ambiguous as to whether both are mandatory to implement for agents, and whether both are mandatory to implement for TAMs.

Mandatory SUIT_Envelope attributes in TEEP

In SUIT manifest I-D, there are 2 attributes mandatory of SUIT_Envelope.

• suit-authentication-wrapper
• suit-manifest

And TEEP has own "security wrapper".
So, it will be signed twice by TEEP's "security wrapper" and SUIT's "suit-authentication-wrapper".

Would like to clarify who is going to be signer of each of them.
The TEEP's "security wrapper" is signed by TAM?
The SUIT's "suit-authentication-wrapper" is signed by TC singer?
Or we could omit either and use only one wrapper for singing?

[hackathon] Intel SGX attestation requires challenge to be 512 bytes

To use Intel's native SGX attestation, the challenge is sgx_target_info_t:

typedef struct _sgx_target_info
{
    /* (0) MRENCLAVE (hash of target enclave) */
    uint8_t mrenclave[OE_SHA256_SIZE];

    /* (32) ATTRIBUTES of target enclave */
    sgx_attributes_t attributes;

    /* (48) Reserved */
    uint8_t reserved1[4];

    /* (52) MISCSELECT field of target enclave */
    uint32_t misc_select;

    /* (56) Reserved */
    uint8_t reserved2[456];
} sgx_target_info_t;

OE_CHECK_SIZE(sizeof(sgx_target_info_t), 512);

But currently the doc has:

     ? challenge => bstr .size (8..64),

The issue is that the max size needs to be increased from 64 to 512

Consistancy of tc-list type in TEEP-TYPE-update

We have introduced tc-list in TEEP-TYPE-update message after combining messages from Install and Delete.
I would like to change the typo of tc-list in Update message as an arrays of tc-info which would be the same type of tc-list in other messages. This changes will make the implantation simpler when parsing tc-list.

These are the different types of tc-list.
(1) query-response message definition

query-response = [
  type: TEEP-TYPE-query-response,
  options: {
    ? tc-list => [ + tc-info ],

(2) update message defination

update = [
  type: TEEP-TYPE-update,
  options: {
    ? tc-list => [ + bstr ],

(3) update message in cddl section

update = [
  type: TEEP-TYPE-update,
  options: {
    ? tc-list => [ + SUIT_Component_Identifier ],

My proposal is just changing all of them as the same

    ? tc-list => [ + tc-info ],

I have created the PR #94.

@hannestschofenig @dthaler Do you mind considering this changes?

Trusted Component identifiers in SUIT manifests

Hannes reports that the SUIT component id is not a unique identifier, and we may need something else in the SUIT manifest to reference as a unique identifier.

Version in QueryRequest

The draft currently says:

version
The version field parameter the version(s) supported by the TAM.
For this version of the specification this field can be omitted.

The problem with the last sentence above arises once the version changes. If the TAM only supports the newer version, it has no way to indicate that the initial version is not supported, since the TEEP Agent as currently implemented will ignore the field and respond expecting the TAM to support the initial version. At a minimum, text explaining what the expected behavior is, is needed.

CBOR type for TOKEN

This is feedback from the virtual hackathon last week.
The CBOR type of TOKEN in the current draft is bstr (byte strings).
The TOKEN is used to match requests to responses.
For most of computer language, comparing the string is more inconvenient than the int.
The string matching in c language have to use strcmp() function instead of regular if (token==1).
Might good considering to changing to int?
If the TOKEN do not expecting to have negative number, then CBORE unit type might be better/

I made a pull request for changing to int.
#14

Please let me know if you prefer uint. I will make the pull request.

teep-message-framework may need update

The teep-message-framework in cddl section is not used consistently between query-request and teep-error.
And also current teep-message-framework does not allow having no options even it is empty.
We found that it existed from draft 03. https://tools.ietf.org/html/draft-ietf-teep-protocol-03

Description of teep-message-framework in cddl section.

teep-message-framework = [
  type: 0..23 / $teep-type-extension,
  token: uint,
  options: { * teep-option },
  * int; further integers, e.g. for data-item-requested
]

Description of query-request which matches the teep-message-framework in cddl section by having data-item-requested after the options.

query-request = [
  type: TEEP-TYPE-query-request,
  token: uint,
  options: {
    ? supported-cipher-suites => [ + suite ],
    ? challenge => bstr .size (8..64),
    ? versions => [ + version ],
    ? ocsp-data => bstr,
    * $$query-request-extensions
    * $$teep-option-extensions
  },
  data-item-requested  
]

Description of teep-error has err-code before the options.

teep-error = [
  type: TEEP-TYPE-teep-error,
  token: uint,
  err-code: uint,
  options: {
     ? err-msg => text,
     ? supported-cipher-suites => [ + suite ],
     ? versions => [ + version ],
     ? suit-reports => [ + suit-report ],
     * $$teep-error--extensions,
     * $$teep-option-extensions
  }
]

I prefer revising the teep-message-framework as following.

teep-message-framework = [
  type: 0..23 / $teep-type-extension,
  token: uint,
  * int; further integers, e.g. for data-item-requested
  ? options: { * teep-option },
]

Then additional int array-values in any teep messages will be parsed before options to make the programmer friendly.
Also options options itself could be deleted from the teep message when entire options is empty.

Or alternately:

teep-message-framework = [
  type: 0..23 / $teep-type-extension,
  token: uint,
  ? options: { * teep-option },
  * int; further integers, e.g. for data-item-requested
]

Keep the additional int array-values after the options but still delete the options when the options is empty.

I would like to have comments and opinion here :)

ta_id: does teep-device have to match all members to

We are in the middle of prototyping the teep over http.

The current draft specifies the ta_id with three members.

https://github.com/ietf-teep/teep-protocol/blob/master/draft-ietf-teep-protocol.xml#L327

At our initial protyping we are matching all three strings when tam received the requested ta from the teep-broker.

Vendor_ID=ietf-teep-wg
Class_ID=uuid or ta-name
Device_ID=teep-device

We are not sure matching all three member all the time is the expected behaviour, since ta-name or uuid matters most of the time.

Any recommendation is helpful for us.

Or Vender_ID and Device_ID are expected as only information only?

Can't build, XML broken

Error: Unable to parse the XML document: draft-ietf-teep-protocol.xml
 <string>: Line 305: Opening and ending tag mismatch: t line 289 and list
 <string>: Line 305: Opening and ending tag mismatch: t line 289 and list
 <string>: Line 306: Opening and ending tag mismatch: list line 282 and t
 <string>: Line 308: Opening and ending tag mismatch: t line 281 and section
 <string>: Line 847: Opening and ending tag mismatch: section line 228 and middle
 <string>: Line 907: Opening and ending tag mismatch: middle line 104 and rfc
 <string>: Line 908: Premature end of data in tag rfc line 26
*** xml2rfc failed, status 1 (possibly try with -r)

TEEP message format in CDDL

Akira suggested the following message format:

    TEEP_msg-authenc-wrapper = 1
    TEEP_message = 2

    TEEP_Msg_AuthEnc_Wrapper = [ *(COSE_Mac_Tagged /
                                   COSE_Sign_Tagged /
                                   COSE_Mac0_Tagged /
                                   COSE_Sign1_Tagged)]

    TEEP_Outer_Wrapper = {
        TEEP_msg-authenc-wrapper    => bstr .cbor
                                       TEEP_Msg_AuthEnc_Wrapper / nil,
        TEEP-message                => bstr .cbor
                                       (TEEP_QueryRequest /
                                        TEEP_QueryResponse /
                                        TEEP_TrustedAppInstall /
                                        TEEP_TrustedAppDelete /
                                        TEEP_Error /
                                        TEEP_Success ),
    }

TEEP_TYPE_QueryRequest      = 1
TEEP_TYPE_QueryResponse     = 2
TEEP_TYPE_TrustedAppInstall = 3
TEEP_TYPE_TrustedAppDelete  = 4
TEEP_TYPE_TEEP_Error        = 5
TEEP_TYPE_TEEP_Success      = 6

TEEP_attestation   = 1
TEEP_trusted_apps  = 2
TEEP_extensions    = 3
TEEP_suit_commands = 4

TEEP_REQUEST_COMMAND /= TEEP_attestation TEEP_REQUEST_COMMAND /= TEEP_trusted_apps TEEP_REQUEST_COMMAND /= TEEP_extensions TEEP_REQUEST_COMMAND /= TEEP_suit_commands

TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA = 1
TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256  = 2

TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA
TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256

TEEP_version = uint .size 4

TEEP_TYPE         = 1
TEEP_TOKEN        = 2
TEEP_REQUEST      = 3
TEEP_CIPHER_SUITE = 4
TEEP_NONCE        = 5
TEEP_VERSION      = 6
TEEP_OCSP_DATA    = 7

    TEEP_QueryRequest = {
         TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryRequest,
         TEEP_TOKEN => uint .size 4,
         TEEP_REQUEST => uint .size 1 TEEP_REQUEST_COMMAND,
         ? TEEP_CIPHER_SUITE => uint .size 1 [+TEEP_suite],
         ? TEEP_NONCE => bstr .size (8..64),
         ? TEEP_VERSION => [+TEEP_version],
         ? TEEP_OCSP_DATA => bstr,
         * $$extensions
    }

TEEP_install = 1
TEEP_delete  = 2
TEEP_update  = 3

TEEP_DEVICE_DESIRE /= TEEP_install
TEEP_DEVICE_DESIRE /= TEEP_delete
TEEP_DEVICE_DESIRE /= TEEP_update

TEEP_SELECTED_CIPHER_SUITE = 8
TEEP_SELECTED_VERSION      = 9
TEEP_EAT                   = 10
TEEP_TA_LIST               = 11
TEEP_EXT_LIST              = 12

    TEEP_QueryResponse = {
         TEEP_TYPE =>  uint .size 1 TEEP_TYPE_QueryResponse,
         TEEP_TOKEN => uint .size 4,
         ? TEEP_DEVICE_REQUEST => uint .size 1 TEEP_DEVICE_DESIRE,
         ? TEEP_SELECTED_CIPHER_SUITE => uint .size 1 TEEP_suite,
         ? TEEP_SELECTED_VERSION => TEEP_version,
         ? TEEP_EAT => bstr,
         ? TEEP_TA_LIST  => [+bstr],
         ? TEEP_EXT_LIST => [+ext_info],
         * $$extensions
    }

Text needed to describe the use of X.509 certificates

Currently, the text in the spec does not talk about the use of X.509 certificates. We should give an example on how this is accomplished with COSE (i.e. it will probably boil down to the use of https://tools.ietf.org/html/draft-ietf-cose-x509-06)

Support for multiple evidence formats

As shown in Figure 9 of the RATS architecture, there are in general multiple evidence formats and multiple attestation result formats. A design common to a couple companies is to use EAT as the attestation result format, but allow heterogeneous evidence formats, mainly because various ones already exist with currently deployed TEEs. Thus, the Verifier shown in that figure accepts multiple evidence formats and generates attestation results in one standard format (EAT) that can be used by Relying Parties.

As shown in Figure 5 of the TEEP architecture, the TAM is the Relying Party, and evidence is treated as opaque to the TAM, just forwarded on to the Verifier. As such, there isn't any technical reason the TAM implementation really has to care about the evidence format, only the attestation result format (for which EAT is fine).

As such, the ask is for the TEEP protocol to also be able to work with evidence formats other than EAT.

Client APP bound to particular TA

Feedback from the SECIoT hackathon in Berlin,

Some client APP which is already installed on Device, require particular TA to work togather.

This is related to "TA Binary in a Client App Installation Implications"
ietf-teep/architecture#11

With the TA install procedure on page 11 from IETF 105 slides
https://datatracker.ietf.org/meeting/105/materials/slides-105-teep-sessa-teep-architecture-draft

Would like to have a way to specify the TA in QueryResponse message from Device to TAM.

JSON format for teep protocol

Feedback from the SECIoT hackathon in Berlin.

These are the format I sued in our prototype in JSON for teep protocol.
The current draft has CBOR example and this is to helping to have JSON examples.

Device -> TAM, Empty HTTP

method: POST
url: /api/tam
httpVersion: 1.1
headers: {"pragma":"no-cache","cache-control":"no-cache","host":"example.com","origin":"http://192.168.11.3","connection":"close","accept":"application/teep+json","content-length":"0","content-type":"application/teep+json"}
body: 
empy

TAM -> Device, QueryRequest

status code: 200 OK
headers: HTTP/1.1 200 OK
Content-Type: application/teep+json
Content-Length: 36
Date: Wed, 19 Feb 2020 08:21:11 GMT
Connection: close
body: 
{"TYPE":1,"REQUEST":[2],"TOKEN":"1"}

Device -> TAM, QueryResponse

method: POST
url: /api/tam
httpVersion: 1.1
headers: {"pragma":"no-cache","cache-control":"no-cache","host":"example.com","origin":"http://192.168.11.3","connection":"close","accept":"application/teep+json","content-length":"139","content-type":"application/teep+json"}
body:
{ TYPE: 2,
  TOKEN: '1',
  TA_LIST: 
   [ { Vendor_ID: 'ietf-teep-wg',
       Class_ID: '3cfa03b5-d4b1-453a-9104-4e4bef53b37e',
       Device_ID: 'teep-device' } ] }

TAM -> Device, TrustedAppInstall

status code: 200 OK
headers: HTTP/1.1 200 OK
Content-Type: application/teep+json
Content-Length: 120
Date: Wed, 19 Feb 2020 08:21:11 GMT
Connection: close
body: 
{"TYPE":3,"MANIFEST_LIST":["http://192.168.11.5:3000/TAs/8d82573a-926d-4754-9353-32dc29997f74.ta.sign.enc"],"TOKEN":"2"}

Device -> TAM, GET TA

method: GET
url: /TAs/8d82573a-926d-4754-9353-32dc29997f74.ta.sign.enc
httpVersion: 1.1
headers: {"pragma":"no-cache","cache-control":"no-cache","host":"example.com","origin":"http://192.168.11.3","connection":"close"}
body:
empy

TAM -> Device, TA binary

status code: 200 OK
headers: HTTP/1.1 200 OK
Date: Wed, 19 Feb 2020 08:21:11 GMT
Connection: close
Content-Length: 202025
body: {"protected":"eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2Iiwia2lkIjoiUDR3Z0tqXzZvQ3V6VkhtdlJ5NGpGbHZDSEVRWUZfb1F4THR0Xy1NWXV2YyJ9","encrypted_key":"kEpB8793QIt-TFUk-Jq_l
...
wUQFozDQtWPPXpZIcjlN2mym3FlIgDFymcde9CwdXMPCW8NrLTdWxYdhkleqW65y31O2KG5CTrqNjec7RZrQ6zLbadRZ407MycJs7MVCWb9G7tud80d9JE_yzdH606Bg","tag":"jJJ_quUxAdZwvzr0EsloZg"}

Device -> TAM, Success

method: POST
url: /api/tam
httpVersion: 1.1
headers: {"pragma":"no-cache","cache-control":"no-cache","host":"example.com","origin":"http://192.168.11.3","connection":"close","accept":"application/teep+json","content-length":"22","content-type":"application/teep+json"}
body: 
{ TYPE: 5, TOKEN: '2' }

TAM -> Device, Ack 204

status code: 204 No Content
headers: HTTP/1.1 204 No Content
Content-Length: 0
Date: Wed, 19 Feb 2020 08:21:12 GMT
Connection: close
body:
empy

CBOR type of manifest-list(SUIT_Envelope)

Draft-04 CDDL say:

   install = [
     type: TEEP-TYPE-install,
     token: uint,
     option: {
       ? manifest-list => [ + SUIT_Envelope ],
       * $$install-extensions,
       * $$teep-option-extensions
     }
   ]

Would like to use [ + bstr .cbor SUIT_Envelope ] for manifest-list.

   install = [
     type: TEEP-TYPE-install,
     token: uint,
     option: {
       ? manifest-list => [ + bstr .cbor SUIT_Envelope ],
       * $$install-extensions,
       * $$teep-option-extensions
     }
   ]

CBOR Diagnostic Notation example of manifest-list => [ + SUIT_Envelope ]:

/ install = /
[
   3,          / type : TEEP-TYPE-install = 3 (fixed int) /
   2004318072,  / token : 0x777777778 (uint), generated by TAM /
   / options :  /
   {
       10 :
       [        / manifest-list = 10 (mapkey) :
                      (array of SUIT_Envelope(any)) /
          {
              / authentication-wrapper = 2 (mapkey) : bstr .cbor SUIT_Authentication /
              2: h'82582482025820987EEC85FA99FD31D332381B9810F90B05C2E0D4F284A6F4211207ED00FFF750586FD28443A10126A0582482025820987EEC85FA99FD31D332381B9810F90B05C2E0D4F284A6F4211207ED00FFF7505840750141D65B4F20A88DC70C6785A67E0F4F085AEAD83BA2289D6E37271508CC91E0A0592F5C940C2257C9C0B26403C0BA4477F2CE37B60089FE02CDE7911D1C15',
              / manifest = 3 (mapkey) : bstr .cbor SUIT_Manifest /
              3: h'A50101020103585FA202818141000458568614A40150FA6B4A53D5AD5FDFBE9DE663E4D41FFE02501492AF1425695E48BF429B2D51F2AB450358248202582000112233445566778899AABBCCDDEEFF0123456789ABCDEFFEDCBA98765432100E1987D0010F020F0958258613A115781B687474703A2F2F6578616D706C652E636F6D2F66696C652E62696E1502030F0A4382030F'
          }
       ]
   }
]

CBOR Diagnostic Notation example of manifest-list => [ + bstr .cbor SUIT_Envelope ]:

/ install = /
[
   3,          / type : TEEP-TYPE-install = 3 (fixed int) /
   2004318072,  / token : 0x777777778 (uint), generated by TAM /
   / options :  /
   {
       10 :
       [        / manifest-list = 10 (mapkey) :
                      (array of bstr .cbor SUIT_Envelope(any)) /
          h'a202589882582482025820987eec85fa99fd31d332381b9810f90b05c2e0d4f284a6f4211207ed00fff750586fd28443a10126a0582482025820987eec85fa99fd31d332381b9810f90b05c2e0d4f284a6f4211207ed00fff7505840750141d65b4f20a88dc70c6785a67e0f4f085aead83ba2289d6e37271508cc91e0a0592f5c940c2257c9c0b26403c0ba4477f2ce37b60089fe02cde7911d1c15035894a50101020103585fa202818141000458568614a40150fa6b4a53d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab450358248202582000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d0010f020f0958258613a115781b687474703a2f2f6578616d706c652e636f6d2f66696c652e62696e1502030f0a4382030f'
       ]
   }
]

[ + bstr .cbor SUIT_Envelope ] is more better way to embed SUIT_Envelope in manifest-list of TEEP, I think.

when is tc-list mandatory to include in QueryResponse

tc-list is listed in the CDDL as optional:

   ? tc-list => [ + tc-info ],

and the text just says:

tc-list
The tc-list parameter enumerates the Trusted Components installed
on the device in the form of tc-info objects.

The QueryRequest has the following text:

data-item-requested
The data-item-requested parameter indicates what information the
TAM requests from the TEEP Agent in the form of a bitmap. Each
value in the bitmap corresponds to an IANA registered information
element. This specification defines the following initial set of
information elements:

  attestation (1)  With this value the TAM requests the TEEP Agent
     to return attestation evidence (e.g., an EAT) in the response.

  trusted-components (2)  With this value the TAM queries the TEEP
     Agent for all installed Trusted Components.

This text just mentions the information (evidence, tc-list) are "requested", but does not say whether they must be included in a QueryResponse or not. Thus, it's ambiguous whether the TAM needs to allow for the case where they are absent even though the flag was set in the QueryRequest.

In my view, the evidence should be mandatory when requested. The tc-list is less clear since many TEEs (like SGX) have no way to enumerate a tc-list and so at best could include an empty list, or perhaps a list that just includes the TEEP Agent itself, depending on the implementation. It's probably most consistent though to say it must be included, even if it's empty, when the requested bit is set in the QueryRequest.

Requested Components

Moved this issue from ietf-teep/architecture#107 to the teep-protocol document.

Hannes raised the issue:

Requested Components: A list of zero or more components (TAs or
other dependencies needed by a TEE) that are requested by some
depending app, but which are not currently installed in the TEE.

How does this information carried inside the attestation payload relate to the info conveyed in the TEEP protocol?

Dave responded:

As written, it implies that the list of components needed (but not already installed) are conveyed in the TEEP protocol inside claims. If we move them outside of claims then this bullet can be removed. We just need to pick one way.

Ming commented:

This is a quite generic statement, and vague.

1. What other components beyond TAs will it contain and how will they be interpreted?
2. What the word "app" means by "depending app"? It can be Untrusted App or TA.
3. "needed by a TEE" - this isn't dependency of manifest file for dependent TAs by a TA in WG discussion. So this list of "components" needed by a TEE should have some examples to illustrate if they are not TAs needed by a requestTA call in the doc.

For device attestation, the device and TEE identifying information look to be right. This can be out of the list, or optional at most.

Question here: how about list of current TAs that have been installed in the TEE? I think it is meaningful in architecture doc to say what kind of information to present. Protocol doc has the actual way to carry them.

SUIT manifest examples

Architecture Issue #7 was about implicit SD creation when installing a TA, rather than making it be explicit in the TEEP protocol. However now the installation of TA’s is done via a SUIT manifest so all the real work is delegated to SUIT. When a new SD is desired, how should one encode that in a SUIT manifest?

I think we need some examples in the TEEP protocol spec of SUIT commands to install a TA that is 1:1 with an SD (aka no notion of SD), and how to install a TA into an existing SD to enable sharing, etc.

The examples could also be in the SUIT manifest spec instead but that doc is closer to being done hence the suggestion to put in the TEEP protocol spec.

Add sample EAT to example section

PR #65 added examples but example is still missing SUIT manifest and EAT

Explanation of nested array of uneeded-tc-list

This is not an issue, just the explanation of #102

The type of unneeded-tc-list in query-response and update is following,

? unneeded-tc-list => [ + SUIT_Component_Identifier ],

so it could describe multiple TCs by using array.
At the same time, the type of SUIT_Component_Identifier is defined in https://tools.ietf.org/html/draft-moran-suit-manifest-05 as

SUIT_Component_Identifier =  [* bstr]

to contain description of one TC in array, in the way of https://github.com/suit-wg/manifest-spec/blob/master/draft-ietf-suit-manifest.md#SUIT_Component_Identifier-suit-component-identifier as

A Component Identifier can be trivial, such as the simple array [h'00']. It can also represent a filesystem path by encoding each segment of the path as an element in the list. For example, the path "/usr/bin/env" would encode to ['usr','bin','env'].

which require to be an array to specify one TC.

Therefore, [ + SUIT_Component_Identifier ] will be nested array in binary representation as following example.

    81                   # array(1)
      81                 # array(1)
        4F               # bytes(15)
          0102030405060708090A0B0C0D0E0F

https://github.com/hisanak Thanks for pointing this out.

Guidance of generating token

It would be good to have a recommendation of generating token in the draft at the section bellow.

  token: uint,

token : The value in the token parameter is used to match responses to requests. This is particularly useful when a TAM issues multiple concurrent requests to a TEEP Agent.

The way to generate the initial token in the TAM.
The estimate of length of token to make the implementation easier for resource constraint devices.

Having Control Operator .size for all entries

I had this in mind for a while but others were always higher priorities.
I would like to propose having Control Operator .size for all entries, or as much as possible, in the draft.
Currently we have .size definition on very a few entries and the size of other entries are unspecified, so it is legitimate for having very large size.
These are the lists which already have .size.

version = uint .size 4
data-item-requested = $data-item-requested .within uint .size 8
challenge => bstr .size (8..64),
suite = $TEEP-suite .within uint .size 4

For example, this is the CBOR Diagnostic Notation and Binary Representation of QueryRequest Message.

/ query-request = /
[
    1,          / type : TEEP-TYPE-query-request = 1 (fixed int) /
    / options : /
    {
        20 : 2004318071, / token : 0x77777777 (uint), generated by TAM /
        1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) : /
                   / TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA =
                     [ 1 ] (array of uint .size 8) /
        3 : [ 0 ], / version = 3 (mapkey) : 
                     [ 0 ] (array of uint .size 4) /
        4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) /
    },
    2           / data-item-requested : trusted-components = 2 (uint) /
]

83                        # array(3),
   01                     # unsigned(1)
   A4                     # map(4)
      14                  # unsigned(20)
      1A 77777777         # unsigned(2004318071, 0x77777777)
      01                  # unsigned(1)
      81                  # array(1)
         01               # unsigned(1) within .size 8
      03                  # unsigned(3)
      81                  # array(1)
         00               # unsigned(0) within .size 4
      04                  # unsigned(4)
      43                  # bytes(3)
         010203           # "\x01\x02\x03"
   02                     # unsigned(2)

Only supported-cipher-suites (.size 8) and version (.size 4) are specified.
If we could specify all the entries with .size, then it will make it possible to predict the total size the query-request message.

Having able to predict the size is important in the implementation especially for the resource constraint iot devices when allocating the buffer size for handling teep messages.
For example, in the line bellow,

char *message_buffer;
message_buffer = (char *)malloc(2048);

the number of 2048 would not be a just arbitrary number but it could a assure not to overflow from the spec.

Also, this will help preventing from cbor parser to crush by having a large entries in the message.

@hannestschofenig @dthaler if it is OK, I would like to prepare for ietf 110.

Change Teep to TEEP in the text

Minor editorial update to do.

RequestPolicyCheck API and multiple TAMs

Now that #87 is merged, ietf-teep/teep-over-http#32 now applies to the protocol doc as well.

As shown in Figure 1 of the TEEP architecture doc, a TEEP Agent may need to talk to multiple TAMs (e.g., one to get a TA, and a second one to get personalization data).

The TEEP protocol spec currently says:

When the RequestPolicyCheck API is invoked, the TEEP Agent decides
whether to initiate communication with any trusted TAMs (e.g., it might
choose to do so for a given TAM unless it detects that it has already
communicated with that TAM recently). If so, it passes back a TAM URI
to connect to.

The question is if the API can only pass back "a" TAM URI, then how does it conduct policy checks with multiple TAMs?

Deleting personalization data when deleting a TA

The arch spec allows for the TA binary and personalization data to be separate, and even come from different TAMs. For example, it states:

The TEEP protocol treats each TA, any dependencies the TA has, and
personalization data as separate components with separate
installation steps that are expressed in SUIT manifests, and a SUIT
manifest might contain or reference multiple binaries (see
[I-D.ietf-suit-manifest] for more details). The TEEP Agent is
responsible for handling any installation steps that need to be
performed inside the TEE, such as decryption of private TA binaries
or personalization data.

Question is, the TEEP protocol spec has a TrustedAppDelete message that does not use a SUIT manifest, and only has a list of TA's (not "components") to delete. So it can delete TAs, but how can associated personalization data be deleted, especially when they were installed by different TAMs?

Specify RATS claims

https://tools.ietf.org/html/draft-ietf-teep-architecture-12#section-7.1 lists claims that need to be specified in order for TEEP to use them. The proposal is that the TEEP protocol doc be the place to do so.

Example of Device has the TA binary and just needs the metadata

Feedback from the SECIoT hackathon in Berlin,

We would like to have both scenarios in TEEP protocol in QueryRequest.
(a) The device has the TA binary and just needs the metadata (as for install or delete)
(b) The device needs both the TA binary and the metadata

The current prototype only using (b) at the moment.

This discussion was raised on otrp
ietf-teep/OTrP#2

Construction of Ciphersuites

This is current draft.

# Ciphersuites {#ciphersuite}

A ciphersuite consists of an AEAD algorithm, an HMAC algorithm, and a signature
algorithm.
Each ciphersuite is identified with an integer value, which corresponds to
an IANA registered
ciphersuite (see {{ciphersuite-registry}}. This document specifies two ciphersuites.

; ciphersuites as bitmaps
suite = $TEEP-suite .within uint .size 8

Is there a reference how the bitmaps of Ciphersuites is constructed in other RFC?

Assign map key to supported-cipher-suites

The current draft says:

In QueryRequest and CDDL section

query-request = [
  type: TEEP-TYPE-query-request,
  token: uint,
  options: {
    ? supported-cipher-suites => suite,
    ? nonce => bstr .size (8..64),
    ? version => [ + version ],
    ? ocsp-data => bstr,
    * $$query-request-extensions
    * $$teep-option-extensions
  },
  data-item-requested  
]

But not defined map key value of supported-cipher-suites in CDDL and CBOR Labels.

So, how about assigning map key to supported-cipher-suites as 1 and assign cipher-suite as 13?
(cipher-suite is now using in teep-error.)

The current draft says:

                     +-----------------------+-------+
                     | Name                  | Label |
                     +-----------------------+-------+
                     | cipher-suites         | 1     |
                     | nonce                 | 2     |
                     | version               | 3     |
                     | ocsp-data             | 4     |
                     | selected-cipher-suite | 5     |
                     | selected-version      | 6     |
                     | eat                   | 7     |
                     | ta-list               | 8     |
                     | ext-list              | 9     |
                     | manifest-list         | 10    |
                     | msg                   | 11    |
                     | err-msg               | 12    |
                     +-----------------------+-------+

modified mapping:

                     +-------------------------+-------+
                     | Name                    | Label |
                     +-------------------------+-------+
                     | supported-cipher-suites | 1     |
                     | nonce                   | 2     |
                     | version                 | 3     |
                     | ocsp-data               | 4     |
                     | selected-cipher-suite   | 5     |
                     | selected-version        | 6     |
                     | eat                     | 7     |
                     | ta-list                 | 8     |
                     | ext-list                | 9     |
                     | manifest-list           | 10    |
                     | msg                     | 11    |
                     | err-msg                 | 12    |
                     | cipher-suites           | 13    |
                     +-------------------------+-------+

modified CDDL:

   supported-cipher-suites = 1
   nonce = 2
   versions = 3
   oscp-data = 4
   selected-cipher-suite = 5
   selected-version = 6
   eat = 7
   ta-list = 8
   ext-list = 9
   manifest-list = 10
   msg = 11
   err-msg = 12
   cipher-suites = 13

[hackathon] errors processing QueryRequest

A number of error codes in the document would be hit first upon processing the QueryRequest, much earlier than getting an Update, e.g., ERR_UNSUPPORTED_MSG_VERSION, ERR_UNSUPPORTED_CRYPTO_ALG, etc.

But the spec currently says an Error message can only be returned in response to an Update, and a QueryRequest must always result in a QueryResponse, which cannot contain an error code or error message. So the use of such error codes seems to be a contradiction.

A possible fix is to allow an Error to be sent in response to a QueryRequest in such cases.

Construction of SUIT_Envelope of URI outside the digest region

This is related #104, but more on how the SUIT_Envelope is constructed.

This is a question when we were thinking how to make the uri changeable.
By reading the section 5.5 of the suit-manifest, it may be possible to change the uri inside suit-install in the SUIT_Envelope with "Severed" feature.
https://tools.ietf.org/html/draft-ietf-suit-manifest-11#section-5.5

The following are the two examples of adding Severed suit-install by TAM.

This is the first idea that came up.

SUIT_Envelope = {
 suit-authentication-wrapper : {
   [
     / algorithm-id / 2 / "sha256" /,
     / digest-bytes / h'(digest-of-suit-manifest)'
   ]
 },
 suit-manifest : {
   suit-common : {
   },
   suit-install : {
     directive-set-parameters : {
       uri : 'http://example.com/original_tc_signed'
     }
   }
 },
 // TAM can add Severed suit-install, but the device cannot verify the 
TC binary whether the TC binary is authentic created by TC signer because 
there is no digest information of the TC binary.
 suit-install : {
   suit-directive-set-parameters : {
     uri : 'http://example.com/a_not_tc_signed'
   },
 }
}

Adding digest of the TC binary to be able to verify the authenticity of the TC binary.

SUIT_Envelope = {
 suit-authentication-wrapper : {
   [
     / algorithm-id / 2 / "sha256" /,
     / digest-bytes / h'(digest-of-suit-manifest)'
   ]
 },
 suit-manifest : {
   suit-common : {
   },
   suit-install : {
     directive-set-parameters : {
       uri : 'http://example.com/original_tc_signed',
       image-digest : [
         / algorithm-id / 2 / "sha256",
         / digest-bytes / h'(digest-of-image)'
       ]
     }
   }
 },
 // TAM adding Severed suit-install. The device can verify whether the 
TC binary image downloaded from the uri added by TAM  is an 
authentic binary created by TC signer with the image-digest in the 
signed area of the SUIT_Envelope.
 suit-install : {
   suit-directive-set-parameters : {
     uri : 'http://example.com/a_not_tc_signed'
   },
 }
}

I would like to propose the second example to be legimite for the TEEP usage.
Would be OK?

[Hackathon] How does Agent get unneeded-ta-list

Issue #16 originally raised the issue of passing a deletion wish from Agent to TAM, and PR #47 added support in the protocol.

However in trying to implement this, the question arises of where the Agent gets this information from. The installation wish comes from the RequestTA abstract API mentioned in the arch doc and transport spec when the wish comes from an untrusted app, or from the SUIT manifest dependency list of a trusted component (i.e., one that depends on another trusted component from a different TAM, such as for personalization data). However there is no "UnrequestTA" abstract API in any document.

Should we add "UnrequestTA" to the arch doc, transport spec, and protocol spec for symmetry?

Token Management consideration

Each TEEP message has token field. It has the role of binding TAM and TEEP device.
From some views(e.g. security, implementation),I think it would be preferable to describe how to handle token values.

• How to generate tokens
  It is necessary for tokens to have the resistance for avoiding collision and guessing from outsiders.
  It's considered in #71 and #40

• Unique token in each TEEP messaging
  How should TAM handle in this case?

     +------------+           +-------------+
     | TAM        |           |TEEP Agent   |
     +------------+           +-------------+
       QueryRequest ------->
                    <-------   QueryResponse
                    <-------   QueryResponse (contains the above QueryResponse's token)

In the current description, both QueryResponse are valid because these responses contain the same valid token.
So TEEP agent can look into TAM's behavior by sending multiple QueryResponse.
I think each TEEP messaging should use the unique token and token validness is once only.

Expanding this consideration for the procedure from QueryRequest/Response to TAInstall/Success, I suggest labeling reusing the same token as SHOULD NOT in the draft.

• Token using for the other purposes
  Token has the role of binding TAM and TEEP devices. TAM may use the tokens as the TEEP procedure's status value in TEEP devices.
  Is there any problem with using tokens for that purpose?
  Under the circumstances of keeping token uniqueness, I think it's no problem.
  But I also think the token's purpose should be limited for binding messaging and using tokens as if device ID SHOULD NOT be good from a security view to avoid unexpected side effects.

• Token expiring
  Simplicity, even too much time spent from sending QueryRequest/TAInstall, the token is still valid?
  TAM has to manage the TEEP messaging by tokens and generate (unique) tokens.
  If the token has an indefinite duration, TAM finally has to manage many tokens.
  #43 shows the case that waiting for a certain time to solve dependencies components.
  That needs the tokens enough time or indefinite validity.
  #71 is also related.

Error Code Registry allocation policy

The current draft uses Expert Review, but doesn't contain any rationale for that. Why do we need to allow vendors to extend error codes? By comparison HTTP status codes are IETF Review, and both HTTP and the TEEP protocol allow passing a text string along with the error code, which allows vendors to put details into the text string.

I would propose simplifying the TEEP protocol and either
(a) not using an IANA registry (I.e., require another RFC Updates the current doc), or
(b) using IETF Review like HTTP does

SUIT manifest processing errors

The TEEP protocol spec currently has error codes for events that would occur as part of parsing and executing a SUIT manifest, including:

ERR_TA_UNKNOWN_FORMAT (14)
The TEEP Agent returns this error when it does not recognize the
format of the TA binary.

ERR_TA_DECRYPTION_FAILED (15)
The TEEP Agent returns this error when it fails to decrypt the TA
binary.

ERR_TA_DECOMPRESSION_FAILED (16)
The TEEP Agent returns this error when it fails to decompress the
TA binary.

ERR_MANIFEST_PROCESSING_FAILED (17)
The TEEP Agent returns this error when manifest processing
failures occur that are less specific than ERR_TA_UNKNOWN_FORMAT,
ERR_TA_UNKNOWN_FORMAT, and ERR_TA_DECOMPRESSION_FAILED.

However, section 8.7.4 "Reporting Policy" of draft-ietf-suit-manifest-09 defines a much richer set of record information than can be expressed in such error codes. I would recommend that such error codes be removed and instead provide a way to report back SUIT_Record information if such info is needed.

Multi-Roundtrip TA Installation

If a TA installation that contains a SUIT manifest requires further interactions to perform a complete installation of dependencies then the TEEP Agent has to be given the ability to tell the TAM that further interactions are needed.

Hence, I should suggest to add the possibility to continue the TA installation after the TrustedAppInstall message.

Here is an example of what I have in mind:

+------------+           +-------------+
| TAM        |           |TEEP Agent   |
+------------+           +-------------+

  TrustedAppInstall ---->

                   <----   Continue

  TrustedAppInstall ---->

                           Success

                   <----    or

                           Error

TAM to have a way to choose uri for TC

It the current teep-protocol, probably it is assumed that the uri of TC is encapsulated inside SUIT_Envelope, so the uri portion is signed by the TC signer and TAM can not change the uri.

This concept is perfectly legitimate when TC signer knows the uri before creating the suit-manifest, and the business model of TAM and TC signer is tightly coupled.

If we could make uri independent from the TC signer, it will provide more wider range of use cases for the teep-protocol.
For example, considering a device manufacture who is a TC singer generates TCs and the suit-manifests and asking many different server vendors to host there TCs. It would be good if the manufacture do not have to generate many different suit-manifests each time for different server vendors with different uris.
Also, if the TAM vendor uses cdn or load balancer for hosting the TCs then the TAM vendors would like to select appropriate uri by TAM's decision.

Even the uri is not signed by TC signer, the rest of suit-manifest is signed by TC signer, and the device could validate the TC regardless of which uri the TC came from.
What the device would like to able to do in teep-protocol is even having the uri out of the scope of TC signer, the device could verify the TC binary by the digest of the binary and the TC's signature inside suit-manifest.

Would the current SUIT supports having another uri outside of TC signer area as following?

SUIT_Envelope = {
  suit-authentication-wrapper,
  suit-manifest : {
    suit-common : {
      suit-common-sequence : {
        suit-directive-override-parameters : {
          image-sigest : ["sha256", '0xF00'],
          uri : 'http://example.com/overridden_tc_signed'
        }
      }
    },
    suit-install : {
      directive-set-parameters : {
        uri : 'http://example.com/original_tc_signed'
      }
    }
  },
  //XXX: TAM want to modify URIs below even after tc-signer signed suit-manifest above.
  suit-install : {
    suit-directive-set-parameters : {
      uri : 'http://example.com/a_not_tc_signed'
    },
    suit-directive-try-each : [
      {
        directive-set-parameters : {
          uri : 'http://cdn.com/b_not_tc_signed'
        }
      },
      {
        directive-set-parameters : {
          uri : 'http://vendor.com/c_not_tc_signed'
        }
      }
    ]
  }
}

If the above is fine, then we may not have to change anything in teep.

TAM certificate caching

As noted in ietf-teep/teep-over-http#12 the discussion of caching of the TAM's certificate by the TEEP Agent is missing from the protocol spec.

Specifically, as in OTrP, if the OCSP_DATA is cached, then the TEEP Agent should be able to directly send a QueryResponse without waiting for the initial QueryRequest. This allows getting rid of an extra round trip, thus saving latency, bandwidth, and CPU cycles, all of which can be important for constrained nodes/networks.

I wonder if it is suitable for TEEP protocol to implement attestation using Remote Attestation of Intel SGX as below

There are three subjects;

1. Repeated QueryRequest - QueryResponse interactions in one attestation.
2. The EAT of QueryResponse has data for SGX Attestation.
3. The extensions of QueryRequest have data for SGX Attestation.

Each content is to be detailed in order. I hope you would read and may I have your opinion.

1. Repeated QueryRequest - QueryResponse interactions in one attestation.

For Remote Attestation of SGX to be put into practice, it is necessary to exchange messages between the TEEP Agent in a device and a TAM twice.
The following figure is from 'Intel_SGX_Developer_Reference_Linux_2.7.1_Open_Source'(https://download.01.org/intel-sgx/sgx-linux/2.7.1/docs/Intel_SGX_Developer_Reference_Linux_2.7.1_Open_Source.pdf, p.102).

(We can send msg0 with msg1 at step 10)

The connection is presented as ra_network_send_receive.
Corresponding to that, in terms of TEEP protocol it seems that exchanging QueryRequest and QueryResponse is to be done twice, doesn't it.

TAM                                         TEEP Agent
 Step1.QueryRequest ---------------------------->
 Step2.<----------------------------------------- QueryResponse(with EAT(msg0+msg1))
 Step3.QueryRequest(with Extention(msg2)) ------>
 Step4.<----------------------------------------- QueryResponse(with EAT(msg3))
GOOD or NG

(fig.1)

As summarized in fig.1, is it appropriate to implement the attestation of TEEP via repeated exchanges of QueryRequest and QueryResponse.

2. The EAT of QueryResponse has data for SGX Attestation.

At Step2 and Step4 in fig.1, the TEEP Agent ought to send to the TAM msg0, msg1, and msg3. Those are generated by the TEEP Agent and necessary for SGX Remote Attestation.

Is it correct to define custom claim identifier and send data packed in EAT of QueryResponse.

3. The extensions of QueryRequest has data for SGX Attestation.

At Step3 in fig.1, the TAM ought to send to the TEEP Agent msg2, which is generated by the TAM and necessary for SGX Remote Attestation.
Is it correct to define custom keys for the $$extensions part of QueryRequest and send data.

That is all.
With kind regards.

[hackathon] TA Signer or TC Signer

Should we change the TA Signer to TC Signer?

We have changed the name of unit which is handled in TEEP message from Trusted Application to Trustiest Component.
In the current draft, the contents of SUIT manifest which are TA Binaries and/or Personalization Data are written as they are signed by TA Signer.

Maybe easier to understand to rename TA Signer to TC Signer.

Enamuration of supported-cipher-suites in query-request

The current draft for the query-request could describe only one TAM's supported cipher-suites to devices.

query-request = [
  type: TEEP-TYPE-query-request,
  token: uint,
  options: {
    ? supported-cipher-suites => suite,
    ? challenge => bstr .size (8..64),
    ? versions => [ + version ],
    ? ocsp-data => bstr,
    * $$query-request-extensions
    * $$teep-option-extensions
  },
  data-item-requested
]

Would like to propose to be possible to enumerate many supported cipher-suites by changing:
from:

    ? supported-cipher-suites => suite,

to:

     ? supported-cipher-suites => [ + suite ],

Russ's comments on draft -05

TECHNICAL QUESTIONS AND SUGGESTIONS

In Section 4.2, the discussion of token says:

  The TAM MUST expire the token value after receiving the first
  responce from the device and ignore any subsequent messages that
  have the same token value.

Should this say the first response that has a valid signature? Otherwise, we are creating an opportunity for an attacker to quickly respond with a matching token but otherwise garbage. Then a legitimate responder will be ignored.

In Section 4.2, the discussion of ocsp-data says: "certificates up to the root certificate". I do not think we want an OCSP response for the trust anchor (a.k.a., root certificate). I suggest: "certificates up, but not including, to the root certificate".

In Section 7, I think that future ciphersuites should allow MAC algorithms other than HMAC, such as GMAC.

In Section 9, please say whether future registrations will allow integrity-without-confidentiality ciphersuites. Let's settle this now instead of dumping on the IANA Expert.

For the reference to OCSP, please use RFC 6960 (not RFC 2560).

The document talks about certificates, so it should reference RFC 5280.

EDITORIAL SUGGESTIONS

The document uses "trust anchor" and "root certificate". Please pick one. I greatly prefer trust anchor for alignment with RFC 5280.

In Section 3, the text says: "This specification defines five messages." For me, it would have been helpful for the five to be listed here before the description of the flows. I suggest: "This specification defines five messages: QueryRequest, QueryResponse, Update, Success, and Error."

In Section 4.2: s/Listing supporting SUIT commands/Listing supported SUIT commands/

In Section 4.2: s/by the TAM A value of 0/by the TAM. A value of 0/

In Section 4.3, it says:

tc-manifest-sequence-number
The minimum suit-manifest-sequence-number value from a SUIT
manifest for the Trusted Component. If not present, indicates
that any version will do.

Please reword to clarify the meaning of "version". Elsewhere in this document, version is talking about the TEEP protocol version, but that is not the meaning here.

Clarify how attestation information is kept confidential

The security considerations section says this about the attestation information:

This uniqueness may raise privacy concerns. To lower the
privacy implications the TEEP Agent MUST present its attestation
information only to an authenticated and authorized TAM.
But what it doesn’t say (and I think should point out) is the point that encryption can be provided by payload security, i.e., draft-ietf-rats-eat provides encryption via JOSE/COSE encryption, and the TEEP protocol just carries such encrypted JOSE/COSE objects without the TEEP protocol having to encrypt TEEP messages.

Currently the only mention of encryption in that doc is about TA binaries, which is in the opposite direction (TAM to Agent) than the one relevant here.

In contrast draft-ietf-teep-opentrustprotocol had text about encrypting device state information, which generates questions about why draft-ietf-teep-protocol does not. Need to elaborate in the text as to why, i.e., because it's part of the draft-ietf-rats-eat and just carried by the TEEP protocol.

[hackathon] generating suit manifest for delete

The unneeded-tc-list was delete in TEEP-TYPE-update from draft-05 since we decided to use the install, update and delete commands in suit manifest.

Honestly we just barely made deleting TC successfully working in this ietf110 hackathon with unneeded-tc-list and do not want to change it again, but would like to have support from the suit community for generating suit manifest for delete.

We looked into suit-manifest-generator and have been using generated manifest with install but could not find how to generate manifest with delete. We really appreciate help generating example manifest for deleting Trusted Components purposes.

[hackathon] token in teep message or using nonce in eat-claim-set

Section Entity Attestation Token was added from draft-05.

The token in the current teep message or using nonce in eat-claim-set for matching the request and reply between TAM and TEEP device.

Which should we use in the future?
Both seem to work.

Our current implementations use the token to keep track and binding the teep messages from the first QueryRequest to teep-success/teep-error.

Good to have examples of query-request-extensions and teep-option-extensions

For improving compatibility among different implementations, good to have examples of query-request-extensions and teep-option-extensions in messages.

The is definition of Install:

install = [
  type: TEEP-TYPE-install,
  token: uint,
  option: {
    ? manifest-list => [ + SUIT_Envelope ],
    * $$install-extensions,
    * $$teep-option-extensions
  }
]

Delete wish from Client App to TAM

This is from the ietf-teep/teep-over-http#8.

Would like to add member of informing insert or delete wish in the QueryResponse which is sent from Device to TAM.

For the situation that Client App is installed at the Device would like to have the TA associated it from the authorized TAM.

QueryResponse = {
// adding optional member
? request : uint
}

while the
requests = [ + (
install /
delete /
)]

and use the TA_LIST for specifying the TA which Client App would like to install or delete.