idnits 2.17.1 draft-moran-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (26 October 2021) is 905 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 275 -- Looks like a reference, but probably isn't: '2' on line 275 -- Looks like a reference, but probably isn't: '3' on line 246 == Missing Reference: '-1' is mentioned on line 275, but not defined == Missing Reference: '-2' is mentioned on line 248, but not defined == Missing Reference: '-3' is mentioned on line 252, but not defined -- Looks like a reference, but probably isn't: '4' on line 252 -- Looks like a reference, but probably isn't: '0' on line 275 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-19 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-14 ** Downref: Normative reference to an Informational RFC: RFC 9019 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 26 October 2021 5 Expires: 29 April 2022 7 Update Management Extensions for Software Updates for Internet of Things 8 (SUIT) Manifests 9 draft-moran-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 29 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . 5 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: a 115 CoSWID can enable a 117 3.1. suit-coswid 119 suit-coswid is a member of the suit-manifest. It contains a Concise 120 Software Identifier (CoSWID) as defined in [I-D.ietf-sacm-coswid]. 121 This element SHOULD be made severable so that it can be discarded by 122 the Recipient or an intermediary if it is not required by the 123 Recipient. 125 suit-coswid typically requires no processing by the Recipient. 126 However all Recipients MUST NOT fail if a suit-coswid is present. 128 suit-coswid is RECOMMENDED to implement and RECOMMENDED to include in 129 manifests. 131 TODO: CoRIM might be a preferable alternative to CoSWID. TODO: 132 Should CoMID be offered as an alternative to Vendor ID/Class ID? 133 TODO: Should there be a CoMID namespace identifier for UUIDs? 135 3.2. text-version-required 137 suit-text-version-required is used to represent a version-based 138 dependency on suit-parameter-version as described in Section 4.4 and 139 Section 5.5. To describe a version dependency, a Manifest Author 140 SHOULD populate the suit-text map with a SUIT_Component_Identifier 141 key for the dependency component, and place in the corresponding map 142 a suit-text-version-required key with a free text expression that is 143 representative of the version constraints placed on the dependency. 144 This text SHOULD be expressive enough that a device operator can be 145 expected to understand the dependency. This is a free text field and 146 there are no specific formatting rules. 148 By way of example only, to express a dependency on a component "['x', 149 'y']", where the version should be any v1.x later than v1.2.5, but 150 not v2.0 or above, the author would add the following structure to 151 the suit-text element. Note that this text is in cbor-diag notation. 153 [h'78',h'79'] : { 154 7 : ">=1.2.5,<2" 155 } 157 4. Extension Parameters 159 Several parameters are needed to define the behaviour of the commands 160 specified in Section 5. These parameters follow the same 161 considerations as defined in SUIT_Parameters of 162 [I-D.ietf-suit-manifest] 164 +=================+================================+=============+ 165 | Name | CDDL Structure | Reference | 166 +=================+================================+=============+ 167 | Use Before | suit-parameter-use-before | Section 4.1 | 168 +-----------------+--------------------------------+-------------+ 169 | Minimum Battery | suit-parameter-minimum-battery | Section 4.2 | 170 +-----------------+--------------------------------+-------------+ 171 | Update Priority | suit-parameter-update-priority | Section 4.3 | 172 +-----------------+--------------------------------+-------------+ 173 | Version | suit-parameter-version | Section 4.4 | 174 +-----------------+--------------------------------+-------------+ 175 | Wait Info | suit-parameter-wait-info | Section 4.5 | 176 +-----------------+--------------------------------+-------------+ 178 Table 1 180 4.1. suit-parameter-use-before 182 An expiry date for the use of the manifest encoded as the positive 183 integer number of seconds since 1970-01-01. Implementations that use 184 this parameter MUST use a 64-bit internal representation of the 185 integer. Used with Section 5.1 187 4.2. suit-parameter-minimum-battery 189 This parameter sets the minimum battery level in mWh. This parameter 190 is encoded as a positive integer. Used with suit-condition-minimum- 191 battery (Section 5.3). 193 4.3. suit-parameter-update-priority 195 This parameter sets the priority of the update. This parameter is 196 encoded as an integer. It is used along with suit-condition-update- 197 authorized (Section 5.4) to ask an application for permission to 198 initiate an update. This does not constitute a privilege inversion 199 because an explicit request for authorization has been provided by 200 the Update Authority in the form of the suit-condition-update- 201 authorized command. 203 Applications MAY define their own meanings for the update priority. 204 For example, critical reliability & vulnerability fixes MAY be given 205 negative numbers, while bug fixes MAY be given small positive 206 numbers, and feature additions MAY be given larger positive numbers, 207 which allows an application to make an informed decision about 208 whether and when to allow an update to proceed. 210 4.4. suit-parameter-version 212 Indicates allowable versions for the specified component. Allowable 213 versions can be specified, either with a list or with range matching. 214 This parameter is compared with version asserted by the current 215 component when suit-condition-version (Section 5.5) is invoked. The 216 current component may assert the current version in many ways, 217 including storage in a parameter storage database, in a metadata 218 object, or in a known location within the component itself. 220 The component version can be compared as: 222 * Greater. 224 * Greater or Equal. 226 * Equal. 228 * Lesser or Equal. 230 * Lesser. 232 Versions are encoded as a CBOR list of integers. Comparisons are 233 done on each integer in sequence. Comparison stops after all 234 integers in the list defined by the manifest have been consumed OR 235 after a non-equal match has occurred. For example, if the manifest 236 defines a comparison, "Equal [1]", then this will match all version 237 sequences starting with 1. If a manifest defines both "Greater or 238 Equal [1,0]" and "Lesser [1,10]", then it will match versions 1.0.x 239 up to, but not including 1.10. 241 While the exact encoding of versions is application-defined, semantic 242 versions map conveniently. For example, 244 * 1.2.3 = [1,2,3]. 246 * 1.2-rc3 = [1,2,-1,3]. 248 * 1.2-beta = [1,2,-2]. 250 * 1.2-alpha = [1,2,-3]. 252 * 1.2-alpha4 = [1,2,-3,4]. 254 suit-condition-version is OPTIONAL to implement. 256 Versions SHOULD be provided as follows: 258 1. The first integer represents the major number. This indicates 259 breaking changes to the component. 261 2. The second integer represents the minor number. This is 262 typically reserved for new features or large, non-breaking 263 changes. 265 3. The third integer is the patch version. This is typically 266 reserved for bug fixes. 268 4. The fourth integer is the build number. 270 Where Alpha (-3), Beta (-2), and Release Candidate (-1) are used, 271 they are inserted as a negative number between Minor and Patch 272 numbers. This allows these releases to compare correctly with final 273 releases. For example, Version 2.0, RC1 should be lower than Version 274 2.0.0 and higher than any Version 1.x. By encoding RC as -1, this 275 works correctly: [2,0,-1,1] compares as lower than [2,0,0]. 276 Similarly, beta (-2) is lower than RC and alpha (-3) is lower than 277 RC. 279 4.5. suit-parameter-wait-info 281 suit-directive-wait (Section 5.6) directs the manifest processor to 282 pause until a specified event occurs. The suit-parameter-wait-info 283 encodes the parameters needed for the directive. 285 The exact implementation of the pause is implementation-defined. For 286 example, this could be done by blocking on a semaphore, registering 287 an event handler and suspending the manifest processor, polling for a 288 notification, or aborting the update entirely, then restarting when a 289 notification is received. 291 suit-parameter-wait-info is encoded as a map of wait events. When 292 ALL wait events are satisfied, the Manifest Processor continues. The 293 wait events currently defined are described in the following table. 295 +======================+==========+==========================+ 296 | Name | Encoding | Description | 297 +======================+==========+==========================+ 298 | suit-wait-event- | int | Same as suit-parameter- | 299 | authorization | | update-priority | 300 +----------------------+----------+--------------------------+ 301 | suit-wait-event- | int | Wait until power state | 302 | power | | | 303 +----------------------+----------+--------------------------+ 304 | suit-wait-event- | int | Wait until network state | 305 | network | | | 306 +----------------------+----------+--------------------------+ 307 | suit-wait-event- | See | Wait for other device to | 308 | other-device-version | below | match version | 309 +----------------------+----------+--------------------------+ 310 | suit-wait-event-time | uint | Wait until time (seconds | 311 | | | since 1970-01-01) | 312 +----------------------+----------+--------------------------+ 313 | suit-wait-event- | uint | Wait until seconds since | 314 | time-of-day | | 00:00:00 | 315 +----------------------+----------+--------------------------+ 316 | suit-wait-event- | uint | Wait until seconds since | 317 | time-of-day-utc | | 00:00:00 UTC | 318 +----------------------+----------+--------------------------+ 319 | suit-wait-event-day- | uint | Wait until days since | 320 | of-week | | Sunday | 321 +----------------------+----------+--------------------------+ 322 | suit-wait-event-day- | uint | Wait until days since | 323 | of-week-utc | | Sunday UTC | 324 +----------------------+----------+--------------------------+ 326 Table 2 328 suit-wait-event-other-device-version reuses the encoding of suit- 329 parameter-version-match. It is encoded as a sequence that contains 330 an implementation-defined bstr identifier for the other device, and a 331 list of one or more SUIT_Parameter_Version_Match. 333 5. Extension Commands 335 The following table defines the semantics of the commands defined in 336 this specification in the same way as in the Abstract Machine 337 Description, Section 6.4, of [I-D.ietf-suit-manifest]. 339 +=============+=================+===============================+ 340 | Command | CDDL Identifier | Semantic of the Operation | 341 | Name | | | 342 +=============+=================+===============================+ 343 | Use Before | suit-condition- | assert(now() < | 344 | | use-before | current.params[use-before]) | 345 +-------------+-----------------+-------------------------------+ 346 | Check Image | suit-condition- | assert(not binary- | 347 | Not Match | image-not-match | match(digest(current), | 348 | | | current.params[digest])) | 349 +-------------+-----------------+-------------------------------+ 350 | Check | suit-condition- | assert(battery >= | 351 | Minimum | minimum-battery | current.params[minimum- | 352 | Battery | | battery]) | 353 +-------------+-----------------+-------------------------------+ 354 | Check | suit-condition- | assert( isAuthorized( | 355 | Update | update- | current.params[priority])) | 356 | Authorized | authorized | | 357 +-------------+-----------------+-------------------------------+ 358 | Check | suit-condition- | assert(version_check(current, | 359 | Version | version | current.params[version])) | 360 +-------------+-----------------+-------------------------------+ 361 | Wait For | suit-directive- | until event(arg), wait | 362 | Event | wait | | 363 +-------------+-----------------+-------------------------------+ 365 Table 3 367 5.1. suit-condition-use-before 369 Verify that the current time is BEFORE the specified time. suit- 370 condition-use-before is used to specify the last time at which an 371 update should be installed. The recipient evaluates the current time 372 against the suit-parameter-use-before parameter (Section 4.1), which 373 must have already been set as a parameter, encoded as seconds after 374 1970-01-01 00:00:00 UTC. Timestamp conditions MUST be evaluated in 375 64 bits, regardless of encoded CBOR size. suit-condition-use-before 376 is OPTIONAL to implement. 378 5.2. suit-condition-image-not-match 380 Verify that the current component does not match the suit-parameter- 381 image-digest (Section 8.4.8.6 of [I-D.ietf-suit-manifest]). If no 382 digest is specified, the condition fails. suit-condition-image-not- 383 match is OPTIONAL to implement. 385 5.3. suit-condition-minimum-battery 387 suit-condition-minimum-battery provides a mechanism to test a 388 Recipient's battery level before installing an update. This 389 condition is primarily for use in primary-cell applications, where 390 the battery is only ever discharged. For batteries that are charged, 391 suit-directive-wait is more appropriate, since it defines a "wait" 392 until the battery level is sufficient to install the update. suit- 393 condition-minimum-battery is specified in mWh. suit-condition- 394 minimum-battery is OPTIONAL to implement. suit-condition-minimum- 395 battery consumes suit-parameter-minimum-battery (Section 4.2). 397 5.4. suit-condition-update-authorized 399 Request Authorization from the application and fail if not 400 authorized. This can allow a user to decline an update. suit- 401 parameter-update-priority (Section 4.3) provides an integer priority 402 level that the application can use to determine whether or not to 403 authorize the update. Priorities are application defined. suit- 404 condition-update-authorized is OPTIONAL to implement. 406 5.5. suit-condition-version 408 suit-condition-version allows comparing versions of firmware. 409 Verifying image digests is preferred to version checks because 410 digests are more precise. suit-condition-version examines a 411 component's version against the version info specified in suit- 412 parameter-version (Section 4.4) 414 5.6. suit-directive-wait 416 suit-directive-wait directs the manifest processor to pause until a 417 specified event occurs. Some possible events include: 419 1. Authorization 421 2. External Power 423 3. Network availability 425 4. Other Device Firmware Version 427 5. Time 429 6. Time of Day 431 7. Day of Week 433 6. IANA Considerations 435 IANA is requested to: 437 * allocate key 14 in the SUIT Envelope registry for suit-coswid 439 * allocate key 14 in the SUIT Manifest registry for suit-coswid 441 * allocate key 7 in the SUIT Component Text registry for suit-text- 442 version-required 444 * allocate the commands and parameters as shown in the following 445 tables 447 6.1. SUIT Commands 449 +=======+===================+=============+ 450 | Label | Name | Reference | 451 +=======+===================+=============+ 452 | 4 | Use Before | Section 5.1 | 453 +-------+-------------------+-------------+ 454 | 25 | Image Not Match | Section 5.2 | 455 +-------+-------------------+-------------+ 456 | 26 | Minimum Battery | Section 5.3 | 457 +-------+-------------------+-------------+ 458 | 27 | Update Authorized | Section 5.4 | 459 +-------+-------------------+-------------+ 460 | 28 | Version | Section 5.5 | 461 +-------+-------------------+-------------+ 462 | 29 | Wait For Event | Section 5.6 | 463 +-------+-------------------+-------------+ 465 Table 4 467 6.2. SUIT Parameters 469 +=======+=================+=============+ 470 | Label | Name | Reference | 471 +=======+=================+=============+ 472 | 4 | Use Before | Section 4.1 | 473 +-------+-----------------+-------------+ 474 | 26 | Minimum Battery | Section 4.2 | 475 +-------+-----------------+-------------+ 476 | 27 | Update Priority | Section 4.3 | 477 +-------+-----------------+-------------+ 478 | 28 | Version | Section 4.4 | 479 +-------+-----------------+-------------+ 480 | 29 | Wait Info | Section 4.5 | 481 +-------+-----------------+-------------+ 483 Table 5 485 7. Security Considerations 487 This document extends the SUIT manifest specification. A detailed 488 security treatment can be found in the architecture [RFC9019] and in 489 the information model [I-D.ietf-suit-information-model] documents. 491 8. References 493 8.1. Normative References 495 [I-D.ietf-sacm-coswid] 496 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 497 Waltermire, "Concise Software Identification Tags", Work 498 in Progress, Internet-Draft, draft-ietf-sacm-coswid-19, 20 499 October 2021, . 502 [I-D.ietf-suit-manifest] 503 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 504 "A Concise Binary Object Representation (CBOR)-based 505 Serialization Format for the Software Updates for Internet 506 of Things (SUIT) Manifest", Work in Progress, Internet- 507 Draft, draft-ietf-suit-manifest-14, 12 July 2021, 508 . 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 517 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 518 May 2017, . 520 [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 521 Firmware Update Architecture for Internet of Things", 522 RFC 9019, DOI 10.17487/RFC9019, April 2021, 523 . 525 8.2. Informative References 527 [I-D.ietf-suit-information-model] 528 Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest 529 Information Model for Firmware Updates in IoT Devices", 530 Work in Progress, Internet-Draft, draft-ietf-suit- 531 information-model-13, 8 July 2021, 532 . 535 Appendix A. A. Full CDDL 537 To be valid, the following CDDL MUST be appended to the SUIT Manifest 538 CDDL. The SUIT CDDL is defined in Appendix A of 539 [I-D.ietf-suit-manifest] 541 $$SUIT_severable-members-extensions //= ( 542 suit-coswid => bstr .cbor concise-software-identity) 544 $$severable-manifest-members-choice-extensions //= ( 545 suit-coswid => bstr .cbor SUIT_Command_Sequence / SUIT_Digest 546 ) 548 SUIT_Condition //= ( 549 suit-condition-image-not-match, SUIT_Rep_Policy) 550 SUIT_Condition //= ( 551 suit-condition-use-before, SUIT_Rep_Policy) 552 SUIT_Condition //= ( 553 suit-condition-minimum-battery, SUIT_Rep_Policy) 554 SUIT_Condition //= ( 555 suit-condition-update-authorized, SUIT_Rep_Policy) 556 SUIT_Condition //= ( 557 suit-condition-version, SUIT_Rep_Policy) 559 SUIT_Directive //= ( 560 suit-directive-wait, SUIT_Rep_Policy) 562 SUIT_Wait_Event = { + SUIT_Wait_Events } 564 SUIT_Wait_Events //= (suit-wait-event-authorization => int) 565 SUIT_Wait_Events //= (suit-wait-event-power => int) 566 SUIT_Wait_Events //= (suit-wait-event-network => int) 567 SUIT_Wait_Events //= (suit-wait-event-other-device-version 568 => SUIT_Wait_Event_Argument_Other_Device_Version) 569 SUIT_Wait_Events //= (suit-wait-event-time => uint); Timestamp 570 SUIT_Wait_Events //= (suit-wait-event-time-of-day 571 => uint); Time of Day (seconds since 00:00:00) 572 SUIT_Wait_Events //= (suit-wait-event-day-of-week 573 => uint); Days since Sunday 575 SUIT_Wait_Event_Argument_Other_Device_Version = [ 576 other-device: bstr, 577 other-device-version: [ + SUIT_Parameter_Version_Match ] 578 ] 580 SUIT_Parameters //= (suit-parameter-use-before => uint) 581 SUIT_Parameters //= (suit-parameter-minimum-battery => uint) 582 SUIT_Parameters //= (suit-parameter-update-priority => uint) 583 SUIT_Parameters //= (suit-parameter-version => 584 SUIT_Parameter_Version_Match) 585 SUIT_Parameters //= (suit-parameter-wait-info => 586 bstr .cbor SUIT_Wait_Event) 588 SUIT_Parameter_Version_Match = [ 589 suit-condition-version-comparison-type: 590 SUIT_Condition_Version_Comparison_Types, 591 suit-condition-version-comparison-value: 592 SUIT_Condition_Version_Comparison_Value 593 ] 594 SUIT_Condition_Version_Comparison_Types /= 595 suit-condition-version-comparison-greater 596 SUIT_Condition_Version_Comparison_Types /= 597 suit-condition-version-comparison-greater-equal 598 SUIT_Condition_Version_Comparison_Types /= 599 suit-condition-version-comparison-equal 600 SUIT_Condition_Version_Comparison_Types /= 601 suit-condition-version-comparison-lesser-equal 602 SUIT_Condition_Version_Comparison_Types /= 603 suit-condition-version-comparison-lesser 605 suit-condition-version-comparison-greater = 1 606 suit-condition-version-comparison-greater-equal = 2 607 suit-condition-version-comparison-equal = 3 608 suit-condition-version-comparison-lesser-equal = 4 609 suit-condition-version-comparison-lesser = 5 611 SUIT_Condition_Version_Comparison_Value = [+int] 613 $$suit-text-component-key-extensions //= ( 614 suit-text-version-required => tstr) 616 suit-coswid = 14 617 suit-condition-use-before = 4 618 suit-condition-image-not-match = 25 619 suit-condition-minimum-battery = 26 620 suit-condition-update-authorized = 27 621 suit-condition-version = 28 622 suit-directive-wait = 29 624 suit-wait-event-authorization = 1 625 suit-wait-event-power = 2 626 suit-wait-event-network = 3 627 suit-wait-event-other-device-version = 4 628 suit-wait-event-time = 5 629 suit-wait-event-time-of-day = 6 630 suit-wait-event-day-of-week = 7 632 suit-parameter-use-before = 4 633 suit-parameter-minimum-battery = 26 634 suit-parameter-update-priority = 27 635 suit-parameter-version = 28 636 suit-parameter-wait-info = 29 638 suit-text-version-required = 7 640 Author's Address 642 Brendan Moran 643 Arm Limited 645 Email: Brendan.Moran@arm.com