idnits 2.17.00 (12 Aug 2021) /tmp/idnits7534/draft-ietf-suit-update-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-suit-manifest]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 289 -- Looks like a reference, but probably isn't: '2' on line 289 -- Looks like a reference, but probably isn't: '3' on line 260 == Missing Reference: '-1' is mentioned on line 289, but not defined == Missing Reference: '-2' is mentioned on line 262, but not defined == Missing Reference: '-3' is mentioned on line 266, but not defined -- Looks like a reference, but probably isn't: '4' on line 266 -- Looks like a reference, but probably isn't: '0' on line 289 == Outdated reference: A later version (-21) exists of draft-ietf-sacm-coswid-20 == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-16 ** Downref: Normative reference to an Informational RFC: RFC 9019 == Outdated reference: draft-ietf-suit-information-model has been published as RFC 9124 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft Arm Limited 4 Intended status: Standards Track 7 March 2022 5 Expires: 8 September 2022 7 Update Management Extensions for Software Updates for Internet of Things 8 (SUIT) Manifests 9 draft-ietf-suit-update-management-00 11 Abstract 13 This specification describes extensions to the SUIT manifest format 14 defined in [I-D.ietf-suit-manifest]. These extensions allow an 15 update author, update distributor or device operator to more 16 precisely control the distribution and installation of updates to IoT 17 devices. These extensions also provide a mechanism to inform a 18 management system of Software Identifier and Software Bill Of 19 Materials information about an updated device. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 8 September 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 56 3. Extension Metadata . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. suit-coswid . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. text-version-required . . . . . . . . . . . . . . . . . . 4 59 4. Extension Parameters . . . . . . . . . . . . . . . . . . . . 4 60 4.1. suit-parameter-use-before . . . . . . . . . . . . . . . . 5 61 4.2. suit-parameter-minimum-battery . . . . . . . . . . . . . 5 62 4.3. suit-parameter-update-priority . . . . . . . . . . . . . 5 63 4.4. suit-parameter-version . . . . . . . . . . . . . . . . . 6 64 4.5. suit-parameter-wait-info . . . . . . . . . . . . . . . . 7 65 5. Extension Commands . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. suit-condition-use-before . . . . . . . . . . . . . . . . 9 67 5.2. suit-condition-image-not-match . . . . . . . . . . . . . 9 68 5.3. suit-condition-minimum-battery . . . . . . . . . . . . . 10 69 5.4. suit-condition-update-authorized . . . . . . . . . . . . 10 70 5.5. suit-condition-version . . . . . . . . . . . . . . . . . 10 71 5.6. suit-directive-wait . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. SUIT Commands . . . . . . . . . . . . . . . . . . . . . . 11 74 6.2. SUIT Parameters . . . . . . . . . . . . . . . . . . . . . 11 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Appendix A. A. Full CDDL . . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Full management of software updates for unattended, connected 85 devices, such as Internet of Things devices requires a cooperation 86 between the update author(s) and management, distribution, policy 87 enforcement, and auditing systems. This specification provides the 88 extensions to the SUIT manifest ([I-D.ietf-suit-manifest]) that 89 enable an author to coordinate with these other systems. These 90 extensions enable authors to instruct devices to examine update 91 priority, local update authorisation, update lifetime, and system 92 properties. They also enable devices to report and distributors to 93 collect Software Bill of Materials information. 95 Extensions in this specification are OPTIONAL to implment and 96 OPTIONAL to include in manifests unless otherwise designated. 98 2. Conventions and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 Additionally, the following terminology is used throughout this 107 document: 109 * SUIT: Software Update for the Internet of Things, also the IETF 110 working group for this standard. 112 3. Extension Metadata 114 Some additional metadata makes management of SUIT updates easier: 116 * CoSWID, CoMID, CoRIM 118 * Text descriptions of requirements 120 3.1. suit-coswid 122 a CoSWID can enable Software Bill-of-Materials use-cases. A CoMID 123 can enable monitoring of expected hardware. A CoRIM (which may 124 contain both CoSWID and CoMID) can enable both of these use-cases, 125 but can also act as the transport for expected values to an 126 attestation Verifier. Tightly coupling update and attestation 127 ensures that verification infrastructure always knows what software 128 to expect on each device. 130 suit-coswid is a member of the suit-manifest. It contains a Concise 131 Software Identifier (CoSWID) as defined in [I-D.ietf-sacm-coswid]. 132 This element SHOULD be made severable so that it can be discarded by 133 the Recipient or an intermediary if it is not required by the 134 Recipient. 136 suit-coswid typically requires no processing by the Recipient. 137 However all Recipients MUST NOT fail if a suit-coswid is present. 139 suit-coswid is RECOMMENDED to implement and RECOMMENDED to include in 140 manifests. 142 NOTE: CoRIM comprises a list of CoSWID and a list of CoMID, so it may 143 be preferable to a CoSWID. 145 NOTE: CoMID may be a preferable alternative to Vendor ID/Class ID, 146 however it consumes more bandwidth, so a UUID based on CoMID may be 147 appropriate. 149 3.2. text-version-required 151 suit-text-version-required is used to represent a version-based 152 dependency on suit-parameter-version as described in Section 4.4 and 153 Section 5.5. To describe a version dependency, a Manifest Author 154 SHOULD populate the suit-text map with a SUIT_Component_Identifier 155 key for the dependency component, and place in the corresponding map 156 a suit-text-version-required key with a free text expression that is 157 representative of the version constraints placed on the dependency. 158 This text SHOULD be expressive enough that a device operator can be 159 expected to understand the dependency. This is a free text field and 160 there are no specific formatting rules. 162 By way of example only, to express a dependency on a component "['x', 163 'y']", where the version should be any v1.x later than v1.2.5, but 164 not v2.0 or above, the author would add the following structure to 165 the suit-text element. Note that this text is in cbor-diag notation. 167 [h'78',h'79'] : { 168 7 : ">=1.2.5,<2" 169 } 171 4. Extension Parameters 173 Several parameters are needed to define the behaviour of the commands 174 specified in Section 5. These parameters follow the same 175 considerations as defined in Section 8.4.8 of 176 [I-D.ietf-suit-manifest]. 178 +=================+================================+=============+ 179 | Name | CDDL Structure | Reference | 180 +=================+================================+=============+ 181 | Use Before | suit-parameter-use-before | Section 4.1 | 182 +-----------------+--------------------------------+-------------+ 183 | Minimum Battery | suit-parameter-minimum-battery | Section 4.2 | 184 +-----------------+--------------------------------+-------------+ 185 | Update Priority | suit-parameter-update-priority | Section 4.3 | 186 +-----------------+--------------------------------+-------------+ 187 | Version | suit-parameter-version | Section 4.4 | 188 +-----------------+--------------------------------+-------------+ 189 | Wait Info | suit-parameter-wait-info | Section 4.5 | 190 +-----------------+--------------------------------+-------------+ 192 Table 1 194 4.1. suit-parameter-use-before 196 An expiry date for the use of the manifest encoded as the positive 197 integer number of seconds since 1970-01-01. Implementations that use 198 this parameter MUST use a 64-bit internal representation of the 199 integer. Used with Section 5.1 201 4.2. suit-parameter-minimum-battery 203 This parameter sets the minimum battery level in mWh. This parameter 204 is encoded as a positive integer. Used with suit-condition-minimum- 205 battery (Section 5.3). 207 4.3. suit-parameter-update-priority 209 This parameter sets the priority of the update. This parameter is 210 encoded as an integer. It is used along with suit-condition-update- 211 authorized (Section 5.4) to ask an application for permission to 212 initiate an update. This does not constitute a privilege inversion 213 because an explicit request for authorization has been provided by 214 the Update Authority in the form of the suit-condition-update- 215 authorized command. 217 Applications MAY define their own meanings for the update priority. 218 For example, critical reliability & vulnerability fixes MAY be given 219 negative numbers, while bug fixes MAY be given small positive 220 numbers, and feature additions MAY be given larger positive numbers, 221 which allows an application to make an informed decision about 222 whether and when to allow an update to proceed. 224 4.4. suit-parameter-version 226 Indicates allowable versions for the specified component. Allowable 227 versions can be specified, either with a list or with range matching. 228 This parameter is compared with version asserted by the current 229 component when suit-condition-version (Section 5.5) is invoked. The 230 current component may assert the current version in many ways, 231 including storage in a parameter storage database, in a metadata 232 object, or in a known location within the component itself. 234 The component version can be compared as: 236 * Greater. 238 * Greater or Equal. 240 * Equal. 242 * Lesser or Equal. 244 * Lesser. 246 Versions are encoded as a CBOR list of integers. Comparisons are 247 done on each integer in sequence. Comparison stops after all 248 integers in the list defined by the manifest have been consumed OR 249 after a non-equal match has occurred. For example, if the manifest 250 defines a comparison, "Equal [1]", then this will match all version 251 sequences starting with 1. If a manifest defines both "Greater or 252 Equal [1,0]" and "Lesser [1,10]", then it will match versions 1.0.x 253 up to, but not including 1.10. 255 While the exact encoding of versions is application-defined, semantic 256 versions map conveniently. For example, 258 * 1.2.3 = [1,2,3]. 260 * 1.2-rc3 = [1,2,-1,3]. 262 * 1.2-beta = [1,2,-2]. 264 * 1.2-alpha = [1,2,-3]. 266 * 1.2-alpha4 = [1,2,-3,4]. 268 suit-condition-version is OPTIONAL to implement. 270 Versions SHOULD be provided as follows: 272 1. The first integer represents the major number. This indicates 273 breaking changes to the component. 275 2. The second integer represents the minor number. This is 276 typically reserved for new features or large, non-breaking 277 changes. 279 3. The third integer is the patch version. This is typically 280 reserved for bug fixes. 282 4. The fourth integer is the build number. 284 Where Alpha (-3), Beta (-2), and Release Candidate (-1) are used, 285 they are inserted as a negative number between Minor and Patch 286 numbers. This allows these releases to compare correctly with final 287 releases. For example, Version 2.0, RC1 should be lower than Version 288 2.0.0 and higher than any Version 1.x. By encoding RC as -1, this 289 works correctly: [2,0,-1,1] compares as lower than [2,0,0]. 290 Similarly, beta (-2) is lower than RC and alpha (-3) is lower than 291 RC. 293 4.5. suit-parameter-wait-info 295 suit-directive-wait (Section 5.6) directs the manifest processor to 296 pause until a specified event occurs. The suit-parameter-wait-info 297 encodes the parameters needed for the directive. 299 The exact implementation of the pause is implementation-defined. For 300 example, this could be done by blocking on a semaphore, registering 301 an event handler and suspending the manifest processor, polling for a 302 notification, or aborting the update entirely, then restarting when a 303 notification is received. 305 suit-parameter-wait-info is encoded as a map of wait events. When 306 ALL wait events are satisfied, the Manifest Processor continues. The 307 wait events currently defined are described in the following table. 309 +======================+==========+==========================+ 310 | Name | Encoding | Description | 311 +======================+==========+==========================+ 312 | suit-wait-event- | int | Same as suit-parameter- | 313 | authorization | | update-priority | 314 +----------------------+----------+--------------------------+ 315 | suit-wait-event- | int | Wait until power state | 316 | power | | | 317 +----------------------+----------+--------------------------+ 318 | suit-wait-event- | int | Wait until network state | 319 | network | | | 320 +----------------------+----------+--------------------------+ 321 | suit-wait-event- | See | Wait for other device to | 322 | other-device-version | below | match version | 323 +----------------------+----------+--------------------------+ 324 | suit-wait-event-time | uint | Wait until time (seconds | 325 | | | since 1970-01-01) | 326 +----------------------+----------+--------------------------+ 327 | suit-wait-event- | uint | Wait until seconds since | 328 | time-of-day | | 00:00:00 | 329 +----------------------+----------+--------------------------+ 330 | suit-wait-event- | uint | Wait until seconds since | 331 | time-of-day-utc | | 00:00:00 UTC | 332 +----------------------+----------+--------------------------+ 333 | suit-wait-event-day- | uint | Wait until days since | 334 | of-week | | Sunday | 335 +----------------------+----------+--------------------------+ 336 | suit-wait-event-day- | uint | Wait until days since | 337 | of-week-utc | | Sunday UTC | 338 +----------------------+----------+--------------------------+ 340 Table 2 342 suit-wait-event-other-device-version reuses the encoding of suit- 343 parameter-version-match. It is encoded as a sequence that contains 344 an implementation-defined bstr identifier for the other device, and a 345 list of one or more SUIT_Parameter_Version_Match. 347 5. Extension Commands 349 The following table defines the semantics of the commands defined in 350 this specification in the same way as in the Abstract Machine 351 Description, Section 6.4, of [I-D.ietf-suit-manifest]. 353 +=============+=================+===============================+ 354 | Command | CDDL Identifier | Semantic of the Operation | 355 | Name | | | 356 +=============+=================+===============================+ 357 | Use Before | suit-condition- | assert(now() < | 358 | | use-before | current.params[use-before]) | 359 +-------------+-----------------+-------------------------------+ 360 | Check Image | suit-condition- | assert(not binary- | 361 | Not Match | image-not-match | match(digest(current), | 362 | | | current.params[digest])) | 363 +-------------+-----------------+-------------------------------+ 364 | Check | suit-condition- | assert(battery >= | 365 | Minimum | minimum-battery | current.params[minimum- | 366 | Battery | | battery]) | 367 +-------------+-----------------+-------------------------------+ 368 | Check | suit-condition- | assert( isAuthorized( | 369 | Update | update- | current.params[priority])) | 370 | Authorized | authorized | | 371 +-------------+-----------------+-------------------------------+ 372 | Check | suit-condition- | assert(version_check(current, | 373 | Version | version | current.params[version])) | 374 +-------------+-----------------+-------------------------------+ 375 | Wait For | suit-directive- | until event(arg), wait | 376 | Event | wait | | 377 +-------------+-----------------+-------------------------------+ 379 Table 3 381 5.1. suit-condition-use-before 383 Verify that the current time is BEFORE the specified time. suit- 384 condition-use-before is used to specify the last time at which an 385 update should be installed. The recipient evaluates the current time 386 against the suit-parameter-use-before parameter (Section 4.1), which 387 must have already been set as a parameter, encoded as seconds after 388 1970-01-01 00:00:00 UTC. Timestamp conditions MUST be evaluated in 389 64 bits, regardless of encoded CBOR size. suit-condition-use-before 390 is OPTIONAL to implement. 392 5.2. suit-condition-image-not-match 394 Verify that the current component does not match the suit-parameter- 395 image-digest (Section 8.4.8.6 of [I-D.ietf-suit-manifest]). If no 396 digest is specified, the condition fails. suit-condition-image-not- 397 match is OPTIONAL to implement. 399 5.3. suit-condition-minimum-battery 401 suit-condition-minimum-battery provides a mechanism to test a 402 Recipient's battery level before installing an update. This 403 condition is primarily for use in primary-cell applications, where 404 the battery is only ever discharged. For batteries that are charged, 405 suit-directive-wait is more appropriate, since it defines a "wait" 406 until the battery level is sufficient to install the update. suit- 407 condition-minimum-battery is specified in mWh. suit-condition- 408 minimum-battery is OPTIONAL to implement. suit-condition-minimum- 409 battery consumes suit-parameter-minimum-battery (Section 4.2). 411 5.4. suit-condition-update-authorized 413 Request Authorization from the application and fail if not 414 authorized. This can allow a user to decline an update. suit- 415 parameter-update-priority (Section 4.3) provides an integer priority 416 level that the application can use to determine whether or not to 417 authorize the update. Priorities are application defined. suit- 418 condition-update-authorized is OPTIONAL to implement. 420 5.5. suit-condition-version 422 suit-condition-version allows comparing versions of firmware. 423 Verifying image digests is preferred to version checks because 424 digests are more precise. suit-condition-version examines a 425 component's version against the version info specified in suit- 426 parameter-version (Section 4.4) 428 5.6. suit-directive-wait 430 suit-directive-wait directs the manifest processor to pause until a 431 specified event occurs. Some possible events include: 433 1. Authorization 435 2. External Power 437 3. Network availability 439 4. Other Device Firmware Version 441 5. Time 443 6. Time of Day 445 7. Day of Week 447 6. IANA Considerations 449 IANA is requested to: 451 * allocate key 14 in the SUIT Envelope registry for suit-coswid 453 * allocate key 14 in the SUIT Manifest registry for suit-coswid 455 * allocate key 7 in the SUIT Component Text registry for suit-text- 456 version-required 458 * allocate the commands and parameters as shown in the following 459 tables 461 6.1. SUIT Commands 463 +=======+===================+=============+ 464 | Label | Name | Reference | 465 +=======+===================+=============+ 466 | 4 | Use Before | Section 5.1 | 467 +-------+-------------------+-------------+ 468 | 25 | Image Not Match | Section 5.2 | 469 +-------+-------------------+-------------+ 470 | 26 | Minimum Battery | Section 5.3 | 471 +-------+-------------------+-------------+ 472 | 27 | Update Authorized | Section 5.4 | 473 +-------+-------------------+-------------+ 474 | 28 | Version | Section 5.5 | 475 +-------+-------------------+-------------+ 476 | 29 | Wait For Event | Section 5.6 | 477 +-------+-------------------+-------------+ 479 Table 4 481 6.2. SUIT Parameters 483 +=======+=================+=============+ 484 | Label | Name | Reference | 485 +=======+=================+=============+ 486 | 4 | Use Before | Section 4.1 | 487 +-------+-----------------+-------------+ 488 | 26 | Minimum Battery | Section 4.2 | 489 +-------+-----------------+-------------+ 490 | 27 | Update Priority | Section 4.3 | 491 +-------+-----------------+-------------+ 492 | 28 | Version | Section 4.4 | 493 +-------+-----------------+-------------+ 494 | 29 | Wait Info | Section 4.5 | 495 +-------+-----------------+-------------+ 497 Table 5 499 7. Security Considerations 501 This document extends the SUIT manifest specification. A detailed 502 security treatment can be found in the architecture [RFC9019] and in 503 the information model [I-D.ietf-suit-information-model] documents. 505 8. References 507 8.1. Normative References 509 [I-D.ietf-sacm-coswid] 510 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 511 Waltermire, "Concise Software Identification Tags", Work 512 in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26 513 January 2022, . 516 [I-D.ietf-suit-manifest] 517 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 518 "A Concise Binary Object Representation (CBOR)-based 519 Serialization Format for the Software Updates for Internet 520 of Things (SUIT) Manifest", Work in Progress, Internet- 521 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 522 . 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 531 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 532 May 2017, . 534 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 535 Firmware Update Architecture for Internet of Things", 536 RFC 9019, DOI 10.17487/RFC9019, April 2021, 537 . 539 8.2. Informative References 541 [I-D.ietf-suit-information-model] 542 Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest 543 Information Model for Firmware Updates in Internet of 544 Things (IoT) Devices", Work in Progress, Internet-Draft, 545 draft-ietf-suit-information-model-13, 8 July 2021, 546 . 549 Appendix A. A. Full CDDL 551 To be valid, the following CDDL MUST be appended to the SUIT Manifest 552 CDDL. The SUIT CDDL is defined in Appendix A of 553 [I-D.ietf-suit-manifest] 555 $$SUIT_severable-members-extensions //= ( 556 suit-coswid => bstr .cbor concise-software-identity) 558 $$severable-manifest-members-choice-extensions //= ( 559 suit-coswid => bstr .cbor SUIT_Command_Sequence / SUIT_Digest 560 ) 562 SUIT_Condition //= ( 563 suit-condition-image-not-match, SUIT_Rep_Policy) 564 SUIT_Condition //= ( 565 suit-condition-use-before, SUIT_Rep_Policy) 566 SUIT_Condition //= ( 567 suit-condition-minimum-battery, SUIT_Rep_Policy) 568 SUIT_Condition //= ( 569 suit-condition-update-authorized, SUIT_Rep_Policy) 570 SUIT_Condition //= ( 571 suit-condition-version, SUIT_Rep_Policy) 573 SUIT_Directive //= ( 574 suit-directive-wait, SUIT_Rep_Policy) 576 SUIT_Wait_Event = { + SUIT_Wait_Events } 578 SUIT_Wait_Events //= (suit-wait-event-authorization => int) 579 SUIT_Wait_Events //= (suit-wait-event-power => int) 580 SUIT_Wait_Events //= (suit-wait-event-network => int) 581 SUIT_Wait_Events //= (suit-wait-event-other-device-version 582 => SUIT_Wait_Event_Argument_Other_Device_Version) 583 SUIT_Wait_Events //= (suit-wait-event-time => uint); Timestamp 584 SUIT_Wait_Events //= (suit-wait-event-time-of-day 585 => uint); Time of Day (seconds since 00:00:00) 586 SUIT_Wait_Events //= (suit-wait-event-day-of-week 587 => uint); Days since Sunday 589 SUIT_Wait_Event_Argument_Other_Device_Version = [ 590 other-device: bstr, 591 other-device-version: [ + SUIT_Parameter_Version_Match ] 592 ] 594 SUIT_Parameters //= (suit-parameter-use-before => uint) 595 SUIT_Parameters //= (suit-parameter-minimum-battery => uint) 596 SUIT_Parameters //= (suit-parameter-update-priority => uint) 597 SUIT_Parameters //= (suit-parameter-version => 598 SUIT_Parameter_Version_Match) 599 SUIT_Parameters //= (suit-parameter-wait-info => 600 bstr .cbor SUIT_Wait_Event) 602 SUIT_Parameter_Version_Match = [ 603 suit-condition-version-comparison-type: 604 SUIT_Condition_Version_Comparison_Types, 605 suit-condition-version-comparison-value: 606 SUIT_Condition_Version_Comparison_Value 607 ] 608 SUIT_Condition_Version_Comparison_Types /= 609 suit-condition-version-comparison-greater 610 SUIT_Condition_Version_Comparison_Types /= 611 suit-condition-version-comparison-greater-equal 612 SUIT_Condition_Version_Comparison_Types /= 613 suit-condition-version-comparison-equal 614 SUIT_Condition_Version_Comparison_Types /= 615 suit-condition-version-comparison-lesser-equal 616 SUIT_Condition_Version_Comparison_Types /= 617 suit-condition-version-comparison-lesser 619 suit-condition-version-comparison-greater = 1 620 suit-condition-version-comparison-greater-equal = 2 621 suit-condition-version-comparison-equal = 3 622 suit-condition-version-comparison-lesser-equal = 4 623 suit-condition-version-comparison-lesser = 5 625 SUIT_Condition_Version_Comparison_Value = [+int] 627 $$suit-text-component-key-extensions //= ( 628 suit-text-version-required => tstr) 630 suit-coswid = 14 631 suit-condition-use-before = 4 632 suit-condition-image-not-match = 25 633 suit-condition-minimum-battery = 26 634 suit-condition-update-authorized = 27 635 suit-condition-version = 28 636 suit-directive-wait = 29 638 suit-wait-event-authorization = 1 639 suit-wait-event-power = 2 640 suit-wait-event-network = 3 641 suit-wait-event-other-device-version = 4 642 suit-wait-event-time = 5 643 suit-wait-event-time-of-day = 6 644 suit-wait-event-day-of-week = 7 646 suit-parameter-use-before = 4 647 suit-parameter-minimum-battery = 26 648 suit-parameter-update-priority = 27 649 suit-parameter-version = 28 650 suit-parameter-wait-info = 29 652 suit-text-version-required = 7 654 Author's Address 656 Brendan Moran 657 Arm Limited 658 Email: Brendan.Moran@arm.com