Re: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse

Mingliang Pei <> Wed, 13 May 2020 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35A703A0DCA for <>; Tue, 12 May 2020 23:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.772
X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hxEaznLWNsRE for <>; Tue, 12 May 2020 23:00:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C89963A0DC8 for <>; Tue, 12 May 2020 23:00:43 -0700 (PDT)
Received: by with SMTP id b26so12561226lfa.5 for <>; Tue, 12 May 2020 23:00:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=khQlIe1bsbc/hJhja0mt+CWZ6wOLrvNi/f6bUJHrnjY=; b=ZP2ZbwX5qrVPi+ucr4SpEPh5ygMhgtMUWARsH/7y3/IYbORNmKDvC6EaRo/hOJf9+Z Dr74I2potd5UHm4EjsFAmPScXR5z2uFCtDDASdlpKd03YsgGxQEd2rZ1ntXxR/eOe9A3 F9xGHH17JQa2JDhXeBqbuWyC+HkfoLFl/SaBU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=khQlIe1bsbc/hJhja0mt+CWZ6wOLrvNi/f6bUJHrnjY=; b=Z+yqsGq9LiVTtu7fQJxyFHMcXp5eKQ+cTfqJURpJZ1m6PzaS/KPpQsWXuaNkVp0PPd jPbudppqKqCCnO96ZVE+AccWJ0xuzJM0IAWpkI/Z/CverzRYtVyRIjg741KZ1W/wwTf1 vHmntlkAgIJJelcWxqs5jOXlZa+kJ3mM0lew6dGxEw17WvkkAGnGj2iwz0HektqqZRKQ kbn7kHsojv11MVgAeWijwbL4n30ULXYrAXNVpsS0QBqeZ8jpyy1RK5zBeeWNJI2CLYzC BcuFAuh9Mqwd0Aj84u9W+WOycgF74Du0wKy9j+rxY4hHIZqQiW9Glhzn8ogm9Fnx2GbE vciA==
X-Gm-Message-State: AOAM5333ANqm4PHzXJSwcHqYMxchcGFO9rE8CGonqBsqzSn/+lq/c2CX DoBEUATAzsLzgsYHy8d4xwxWGuI20sMmKF3XMt6QJg==
X-Google-Smtp-Source: ABdhPJzAHaKGfPG4z5HEDUCmHqJU2datHoRp6rNGNB0vPdF+Xe45Lr/JHngE/9Tbrb97Wt1DSW5G4VV99+5A4AX20BA=
X-Received: by 2002:a19:7004:: with SMTP id h4mr15815781lfc.148.1589349641682; Tue, 12 May 2020 23:00:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mingliang Pei <>
Date: Tue, 12 May 2020 23:00:30 -0700
Message-ID: <>
To: Hannes Tschofenig <>
Cc: Akira Tsukamoto <>, teep <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d7d51305a5814cc3"
Archived-At: <>
Subject: Re: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 May 2020 06:00:46 -0000

One of the questions is: who creates or assigns an ID as the TA_ID to a TA?

A TAM is responsible to install, upgrade, or delete a TA. It may give it an
identifier to track it. Different versions of TAs may use the same TA ID
but add a version convention. This allows a TAM to identify a TA for

To ensure uniqueness, a UUID is a good choice for a TA ID where a TAM may
create to be unique.

Should the TA developer create and provide TA ID to the downstream systems?
It can but I think a TAM may override it if it needs to do so. The TA
developer should define a friendly display name for the TA. When a TAM
manages many TAs, a TAM operator will like to see friendly display names
rather than the opaque TA IDs that are created for machine consumption. A
TAM may locally maintain a mapping between TA names and TA IDs.

With SUIT compatibility, a UUID Component ID for TA ID can work. Is there a
place holder in SUIT for a TA friendly name? A TA name doesn't need to be
passed to the TEEs for management; it may help debugging logging but may
not be worthy of the bandwidth and size cost.



On Tue, May 12, 2020 at 2:14 AM Hannes Tschofenig <>

> Hi Akira,
> I had a chat with Brendan about this topic.
> In the SUIT model there is a manifest somewhere and it provides a pointer
> to where the binary, and other data is.
> That pointer is a URI. This is used to fetch the information from some
> repository.
> The vendor id and class id are identifiers used by the device to determine
> whether it is looking at a manifest that can be applied to itself. A device
> must not install software/firmware it is not supposed to because otherwise
> you can quickly DoS the device.
> For me, the question is what information should the device report when it
> is asked what software it runs. Brendan suggested to use the Component ID
> and we would make recommendations regarding the construction and the
> uniqueness we would like to have. For example, we could say that the
> component id for a TA should be a UUID and the same TA binary would have
> the same UUID. Note that this component ID could subsequently also be used
> as a filename but we could also keep it separate.
> What do you think?
> Ciao
> Hannes
> -----Original Message-----
> From: TEEP <> On Behalf Of Akira Tsukamoto
> Sent: Monday, April 13, 2020 7:46 AM
> To: teep <>rg>;
> Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for
> TEEP_QueryResponse
> Hi all,
> I would like to restart the discussion of Unique Identifier of TA_ID in
> TEEP's QueryResponse which was one of the item came up at TEEP interim
> meeting last week.
> The discussion started between the Hackathon in Singapore and Berlin.
> This is the link to the github.
> After going though again, I started to have my preference.
> The usage of TA_ID in TEEP message is to distinguish the required TA in
> the device by parsing of identification id.
> The it will be good to be able to match the TA with one bstr for one TA.
> I started to think hash value might work.
> Using the hash value from the properties of Parameters in Section 5.4.1 in
> SUIT CBOR Manifest for each TA.
> The generating hash from adding all the properties.
> These are the requited parameters.
>     -  Vendor ID.
>     -  Class ID. # Could be file name for SGX, uuid for op-tee. uuid is
> used
>                    as file name in op-tee anyway
>     -  Image Digest. # This is version of TA It is up to the user who
> would like to add optional parameters for the seed.
> We have to consider which hash function to use too, and easiest to come up
> is probably sha256.
> The hash value of sha256 is 32 bytes which is still going to be second
> largest member than NONCE in TEEP message.
> I prefer smaller bytes to reduce the teep message size but raw parameters
> of all three above would be larger than 32bytes, so it may be acceptable.
> The purpose of the hash value here is mainly for prevent colliding between
> different TAs or different version in the TAM server.
> -Akira
> _______________________________________________
> TEEP mailing list
> 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