Re: [Suit] Parameters and Commands

<> Fri, 28 February 2020 01:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCA913A0BA5 for <>; Thu, 27 Feb 2020 17:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eI5pkrUio2a6 for <>; Thu, 27 Feb 2020 17:40:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A28F83A0B9D for <>; Thu, 27 Feb 2020 17:40:33 -0800 (PST)
Received: by (mx-mo-csw1115) id 01S1eGcK006850; Fri, 28 Feb 2020 10:40:17 +0900
X-Iguazu-Qid: 2wGr5CsUeWezOmx0uC
X-Iguazu-QSIG: v=2; s=0; t=1582854016; q=2wGr5CsUeWezOmx0uC; m=tXwgJpKJoXwVUopiF1sLTwbs04crATA1e0S7k1SpCWE=
Received: from ( []) by (mx-mr1112) id 01S1eEwd011243; Fri, 28 Feb 2020 10:40:15 +0900
Received: from ([]) by with ESMTP id 01S1eEnx024302; Fri, 28 Feb 2020 10:40:14 +0900 (JST)
Received: from ([]) by with ESMTP id 01S1eEvN014923; Fri, 28 Feb 2020 10:40:14 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=H7o4cmOcAsmAeCxcVkOqQOS7XiYjrOkW7vjPOlPB+6I2UPRZm0wyximq2l07mfXi+MZBvzViRLRwe3GYUXU+7HeHNaizY/5IE3OzX5eIB8YADzi7NgVIeUp4MUT7mljRG2+/JdK9pwb8/opVTFtxLqhOcJ0/FF+uFwk7FWBgMSzFj2FNbh043zxU+f1L5lgZJejgskT5TxkUKtNKk61StGRlY2+rtMbtV/nRL02thJZnp+pi9xFyXgEbpRWt0URIJnfwghkEx0+pjpr8RwkupInLdt861NOt4TURUL82Txcl0IHMWZyjOnUq2kfK0wQeXTfVa6MSDQUcVmxjG3ex0A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zUC07CPfAe8JO3HfOBUmm6T1FH61kTNcbT+EMj1YGBE=; b=GU4BuelywR6lNGEosEZmThnhk7F25XQkpy25uDgegoobhInZ2kryfN9zR1GLCyNG4IKi+SsukRG2+vYnQ5Blu09OtKK8YCMjtUYoJf1cFoXiyqsJb68Pfhe/geCE0U/vf0cvDSh6oR6FrFhMmQ5oTFjMjZSW8fE/+0vhhFKbDBgb6tp8+ztOVAPex2rFARb/+qGia6iBmHI+5arB7C1U+P3f554AprOnZQMzveM8bYGRhgwppdwfN4Q42ufYogn9hSwkg6XQhDQrhWNv+5D2n3Gfg4Nw/UuLNvumS8T9Kai3rYaSZ5cDJmXFoM6GFRyf9ZoftLCwyBzni2LuHEkzxg==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
From: <>
To: <>, <>
CC: <>, <>
Thread-Topic: Parameters and Commands
Thread-Index: AQHV7XQQQA0i3AEJykizdfj2dpCACagv1DJA
Date: Fri, 28 Feb 2020 01:39:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-PH, en-US
Content-Language: ja-JP
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e803c64c-01aa-4ee3-eaf2-08d7bbef1fcd
x-ms-traffictypediagnostic: TYAPR01MB4623:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0327618309
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(189003)(199004)(316002)(966005)(33656002)(66946007)(5660300002)(6506007)(66476007)(64756008)(66556008)(76116006)(71200400001)(54906003)(110136005)(7116003)(52536014)(66446008)(478600001)(2906002)(186003)(26005)(9686003)(3480700007)(55016002)(55236004)(7696005)(8676002)(8936002)(53546011)(86362001)(81156014)(4326008)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:TYAPR01MB4623;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1ShLWdY4e8Q7i+GBGWxY800Oj+YAa0kQsyyL+I2kNk1WhDV8wCdQo9aMSA6NxF/LsC9/I9nObmOpjy6VH0sarfMdD+B4SkGHE6H4JUkyRMs16ksg1tscZydmfwJuX9Nuffy2Soc0ajmXllWBZAp1cIXREkQbkdln9+nMKUhqN5Tby1k6wtMlL73BByudaMxVRoRrBQTNG5vdREInhf7XLRHkTXhH8e7ty32GnBbu+HA0zwd4Iix9Vbj+bb5EgJBcOQV2yNPXGfOEA67LecFtjqvGuZrZuErTwnYQapW2zbGKexSdwq+o4lMFrSDFB+eS5uVtqbXkqU1FiSZnlehX4lhMAGGNGL7kAn2C7D1rmz1KBP7yXfqbclTZAoPP5VSAfXUkIwK1pZexnrvHMinegQy2BUf22bk03Tfyv9zWOv4z0eZ2uu9Xd5e1zWTKo59+P4zWj1a6vCNMUlqQvXEtQ/I2YlaHTmhKFU9BJspEfgwqIxy4pNYD0qLcKrT0XMmwnbnZM0rx1xDLbw2r3dNsKw==
x-ms-exchange-antispam-messagedata: D5Fr5gEh7/2GMoMtCYf8F/IedicsClTMr/zAB7HVu4Jq3XM4EEYxsP+zJ4YHkr1qq+nRazC/JOkFzoBLVRja0ThMCqL2DpE2VckMT3BOSpzO4+X0vMp9XahIdpfNJlP9yzaJNnD9T3Hlc+S1UB1dLw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_TYAPR01MB233510E6D1C2AC5F017457A798E80TYAPR01MB2335jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e803c64c-01aa-4ee3-eaf2-08d7bbef1fcd
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 01:39:59.7323 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EjWR1DBljyKrtjnK6EHHQEEdU9MumtDsUeJSpZMC8OxzqYcqsjMBHZRD9q2ITnDi05ygX0jO1KHZ6YL+EWB0mfrouI/lv1uiJlnd2piWFUuMCwhNz0A2S6gkgFnuTVbf
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4623
MSSCP.TransferMailToMossAgent: 103
Archived-At: <>
Subject: Re: [Suit] Parameters and Commands
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: Fri, 28 Feb 2020 01:40:36 -0000

Hi Brendan,

Do we need to make a new issue here?

I can make an issue if it’s necessary.


From: Suit <> On Behalf Of Brendan Moran
Sent: Thursday, February 27, 2020 10:45 PM
To: suit <>
Cc: Koen Zandberg <>et>; Emmanuel Baccelli <>
Subject: [Suit] Parameters and Commands

During the hackathon, I discovered that my examples and my manifest generator tool are generating incorrect sequences for testing vendor ID and class ID.

There are currently two ways to handle commands (conditions or directives):

  1.  The command consumes an argument (that is the value that follows the command's key)
  2.  The command consumes a parameter (that is a value set by the “set-parameters” or “override-parameters” commands)

This duality led to my error in setting up the Vendor and Class ID tests in the demo code.

The reasons for each mode are:

  1.  Command consumes an argument

     *   Encoding is more compact (encoding via parameters takes 2-3 more bytes, depending on the situation).
     *   Less storage needed (the argument is consumed immediately)
     *   Does not require matching parameter key
     *   More explicit association between command and argument

  1.  Command consumes a parameter

     *   More compact when the parameter is used more than once (e.g. image digest)
     *   Allows override by dependencies, when set-parameters is used

We’ve talked before about “only one way to do things” and I think I can see a path to making that the case here. Here is my proposal:

Commands consuming a parameter are absolutely necessary due to override and deduplication concerns. Conditions testing against an argument are convenient and more explicit. Therefore, harmonising around a single option probably means that we have to select parameters instead of arguments:

  1.  Eliminate arguments from most commands (see below)
  2.  Match most parameter keys with command keys to simplify the association, make “arguments” more explicit

Only these commands require arguments, since they either deal with setting parameters, setting parameter scope, or with flow control, which requires nested command sequences.

  *   Set Component Index
  *   Set Dependency Index
  *   Set Parameters
  *   Override Parameters
  *   Try-each
  *   Run Sequence
  *   For Each Component

This leaves the majority of commands with NUL arguments. This is actually quite useful for another feature.

We have also discussed the possibility of defining attestation policy within SUIT. This would mean that we need flags to indicate to the parser which measurements should be reported. For example, a Vendor ID, an image digest, or a component offset might need to be reported in the attestation report. Each of these is checked by a condition. Each of those conditions will consume a parameter under this model. Then, the argument can indicate: report a measurement, do not report a measurement, report a measurement only if comparison is successful, or perhaps other attestation-related policies. Bear in mind that attesting a failed condition may be helpful for attesting why a manifest has failed, as we discussed in the hackathon and virtual interim meeting.

If we are making the majority of commands are using parameters instead of arguments, this becomes trivial: the arguments are replaced with attestation policy arguments. This allows us to tell the attestation engine explicitly what to report from the manifest, which allows secure, dynamically updatable attestation policy.

This doesn’t introduce a substantial change to either the parser or the format. If there is some appetite for simplifying the correlation between commands and parameters, I think it might make sense to spend some effort aligning parameter keys with command keys. This could simplify the parser by allowing a generic parameter lookup to be done in one place, rather than by each handler.

Best Regards,
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.