idnits 2.17.1 draft-moran-fud-manifest-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 18, 2017) is 2466 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 680 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FUD B. Moran 3 Internet-Draft M. Meriac 4 Intended status: Informational H. Tschofenig 5 Expires: January 19, 2018 ARM Limited 6 July 18, 2017 8 Firmware Manifest Format 9 draft-moran-fud-manifest-00 11 Abstract 13 This specification describes the format of a manifest. A manifest is 14 a bundle of metadata about the firmware for an IoT device, where to 15 find the firmware, the devices to which it applies, and cryptographic 16 information protecting the manifest. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 19, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 66 3. Components . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. PayloadInfo . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Condition and Directive . . . . . . . . . . . . . . . . . 6 70 3.4. Aliases and Dependencies . . . . . . . . . . . . . . . . 7 71 3.5. Device Identification . . . . . . . . . . . . . . . . . . 7 72 3.5.1. Vendor ID . . . . . . . . . . . . . . . . . . . . . . 7 73 3.5.2. Device class ID . . . . . . . . . . . . . . . . . . . 8 74 3.5.3. Device ID . . . . . . . . . . . . . . . . . . . . . . 8 75 4. Manifest ASN.1 Format . . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. Mailing List Information . . . . . . . . . . . . . . . . . . 14 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 9.2. Informative References . . . . . . . . . . . . . . . . . 15 83 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 A firmware update mechanism is an essential security feature for IoT 89 devices to deal with vulnerabilities. While the transport of 90 firmware images to the devices themselves is important there are 91 already various techniques available, such as the Lightweight 92 Machine-to-Machine (LwM2M) protocol offering device management of IoT 93 devices. Equally important is the inclusion of meta-data about the 94 conveyed firmware image (in the form of a manifest) and the use of 95 end-to-end security protection to detect modifications and 96 (optionally) to make reverse engineering more difficult. End-to-end 97 security allows the author, who builds the firmware image, to be sure 98 that no other party (including potential adversaries) to install 99 firmware updates on IoT devices with adequate privileges. This 100 authorization process is ensured by the use of dedicated asymmetric 101 keys installed on the IoT device: for use cases where only integrity 102 protection is required it is sufficient to install a trust anchor on 103 the IoT device. For confidentiality protected firmware images it is 104 additionally required to install either one or multiple symmetric or 105 asymmetric keys on the IoT device. Starting security protection by 106 the author is a risk mitigation technique so firmware images and 107 manifests can be stored on untrusted respositories. 109 It is assumed that the reader is familiar with the high-level 110 firmware update architecture [Architecture]. This document is 111 structured as follows: In Section 3 we describe the main building 112 blocks of the manifest and Section 4 contains the description of the 113 ASN.1 of the manifest. 115 2. Conventions and Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in RFC 120 2119 [RFC2119]. 122 To describe the components of the manifest we use the terms 123 structures and attributes. The manifest has a hierarchical structure 124 and top level components are called structures and the attributes are 125 the components within them. 127 3. Components 129 The key components of a manifest are shown in Figure 1 and are 130 explained in the sub-sections below. 132 +-------------------+ +-----------+ 133 | Manifest | | Condition | 134 +-------------------+ +-----------+ 135 | manifestVersion | | type | 136 | text | | value | +-----------+ 137 | nonce | +-----+-----+ | Directive | 138 | timestamp | | +-----------+ 139 | conditions ------+----------+ | type | 140 | directives ------+----------------------+ value | 141 | aliases ---------+-----------------+ +-----------+ 142 | dependencies ----+--------------+ | 143 | payloadInfo-+ | | | 144 +--------------|----+ +-----+--+-----------+ 145 | | ResourceReference | 146 | +--------------------+ 147 | | hash | 148 | | uri | 149 | +---------+----------+ 150 | | 151 +--------------+-----+ | 152 | PayloadInfo | | 153 +--------------------+ | 154 | format | | 155 | encryptionInfo | | 156 | storageIdentifier | | 157 | size | | +------------+ 158 | payload ----------+-----------------+-----+ integrated | 159 +--------------------+ +------------+ 161 Figure 1: Components of a Manifest. 163 3.1. Manifest 165 The Manifest structure is the top-level construct that ties all other 166 structures together. In addition to the structures explained in 167 subsections below it contains: 169 - a version number (in the 'manifestVersion' attribute) 171 - a textual description about the update, including the version / 172 vendor / model of the device (in the 'text' attribute). This 173 information is optional. 175 - a timestamp indicating when the manifest was created (in the 176 'timestamp' attribute). 178 3.2. PayloadInfo 180 The PayloadInfo structure contains information about the firmware 181 image. The 'format' attribute contains the firmware image type (such 182 as rawBinary, hexLocationLengthData, ELF). The 'size' attribute 183 offers information about the size of the firmware image in bytes. If 184 the size of the obtained firmware image differs from the size stated 185 in the manifest then the obtained image MUST be consider corrupted. 186 The 'nonce' attribute contains a (short) random value to ensure that 187 a given manifest is unique. This separates the function of the 188 timestamp, which is provided for rollback protection, from the 189 function of the nonce, which is for uniqueness. Keeping these 190 functions separate ensures that a number of edge cases are catered 191 for, for example: the creation of manifests quickly enough that they 192 have the same timestamp. The 'storageIdentifier' attribute indicates 193 where the image should be placed on the device. This value useful, 194 for example, when an IoT device contains multiple microcontrollers 195 (MCUs) and the decision needs to be made to which MCU to send which 196 firmware image. 198 Most importantly, however, the PayloadInfo structure contains a 199 reference to the firmware image (in the 'reference' attribute) or the 200 image is embedded inside the PayloadInfo structure (within the 201 'integrated' attribute). A referenced image first needs to be 202 fetched by the device before the update can be applied. The 203 'reference' attribute contains a 'hash' and a 'uri' attribute: the 204 value in the 'hash' attribute allows the device to determine whether 205 it has already obtained this firmware image and, since it is included 206 in the digitally signed manifest, it protects the firmware image 207 against modifications. The 'uri' attribute references the image. 209 Finally, a firmware image may be encrypted and information about how 210 to decrypt is provided in this payload in the 'encryptionInfo' 211 attribute. The following options are provided: 213 - No encryption (mode="none"). In this case the firmware image is 214 not encrypted and only integrity protected. 216 - Encryption using a symmetric key (mode="preSharedKey"). The 217 assumption is that the symmetric key is pre-provisioned (in an 218 out-of-band fashion) on the IoT device and also available to the 219 developer. 221 - Encryption using a symmetric key derived via a key derivation 222 function (mode="preSharedKeyKdf"). This option is a variation of 223 the symmetric key encryption mode whereby a key derivation 224 function is applied to the pre-provisioned key before it is used 225 for encrypting the firmware image. 227 - Encryption using a symmetric key found in the 'KeyTable' attribute 228 (mode="keyTable"). This mode is tailored to use cases where a 229 single encrypted firmware image is transmitted to many IoT 230 devices. 232 Depending on the selected mode different information has to be 233 conveyed in the manifest. 235 - When encryption using a symmetric key is selected then the 'KeyId' 236 attributes provides information for identifying the appropriate 237 symmetric key. 239 - When encryption using a symmetric key derived via a key derivation 240 function is selected then the following three parameters are 241 provided by the 'KdfParameters' attribute: KDF algorithm, nonce, 242 and a key id. The computed function KDF(key, nonce). 244 - When encryption using the key table is selected then the 245 'KeyTable' attribute is used. Figure 2 shows the concept 246 graphically where the firmware image is encrypted by a symmetric 247 key and this symmetric key is encrypted with the public key of 248 each of the devices. 250 +.............................+ 251 . . 252 . Manifest . 253 . 254 . +----------------------+ . 255 . | Key Table | . ***************** 256 . +----------------------+ . * * 257 . | +----------------+ | . * Firmware * 258 . | |{K}Pub(Device A)| | . * Image * 259 . | +----------------+ |<-------> * (encrypted * 260 . | | . * with key K) * 261 . | +----------------+ | . * * 262 . | |{K}Pub(Device B)| | . ***************** 263 . | +----------------+ | . 264 . +----------------------+ . 265 . . 266 +.............................+ 268 Figure 2: Key Table. 270 3.3. Condition and Directive 272 The Condition and the Directive structures together allow "If <...> 273 Then <...>" rules to be expressed. 275 It offers the following functionality: 277 - Apply an update before a given date only (Directive.applyAfter) 279 - Apply an update immediately (Directive.applyImmediately) 281 - Apply an update only to devices that match the vendorId, classId, 282 deviceId attributes 284 - Apply an update only if the device system time is before the time 285 indicated in the Condition.lastApplicationTime. 287 3.4. Aliases and Dependencies 289 In some situations an IoT device may require more than a single 290 firmware update image. To express the requirement that more than a 291 single image has to be installed on a device the dependencies 292 structure is used, which is of type ResourceReference (as used by the 293 PayloadInfo structure). 295 Aliases are used to refer to alternative locations of firmware 296 images. This is useful in environments where organizations cache 297 firmware images (and their corresponding manifests) on premise to 298 avoid the need to fetch imagines from repositories maintained by the 299 developer's organizations (such a device manufacturer or an OEM). 301 3.5. Device Identification 303 A device is identified by at least three identifiers: 305 - A vendor identifier 307 - A device class identifier 309 - A device identifier 311 3.5.1. Vendor ID 313 The vendor ID is a 128-bit number that conforms to RFC-4122, type 5. 314 This number is used by the device to verify manifests. 316 The Vendor ID should be derived from the manufacturer's domain name 317 using the algorithm defined in Section 4.3 of RFC-4122. 319 A vendor ID is typically compiled into a firmware image since it is 320 static for the lifetime of the firmware. 322 3.5.2. Device class ID 324 The device class is a 128-bit number that conforms to RFC-4122, type 325 5. This number is used by the client to verify manifests. The 326 Device Class ID SHOULD use the Vendor ID as the namespace, but the ID 327 within the namespace can be arbitrary. 329 A class ID is also typically compiled into a firmware image since it 330 is static for the lifetime of the firmware. 332 3.5.3. Device ID 334 The device ID is also a 128-bit number that conforms to RFC-4122. 335 The device ID can come from a variety of sources. For example, a 336 device may obtain this identifier during the manufacturing phase 337 (together with other configuration information and manufacturer- 338 provided credentials). In this case, we recommend using RFC-4122, 339 type 1, where the node ID is the factory tool ID, which provides 340 traceability of a device back to the origin of manufacture. A device 341 ID can also come from on-device resources, such as device unique-ID 342 registers or device identifiers in CPUs. Our recommendation is to 343 provide unique CPU resources to a generator function similar to the 344 one used for the class_id. In this example, the device_info may be a 345 combination of several components, such as: 347 - MAC address 349 - Device unique identifier 351 Where multiple sources of unique identity are available, they should 352 all be provided to the UUID function, since it combines them to 353 create a single, unique identifier. 355 4. Manifest ASN.1 Format 357 -- Manifest definition file in ASN.1 (v. 1.0.0-alpha) 358 ManifestSchema DEFINITIONS IMPLICIT TAGS ::= BEGIN 360 Uri ::= UTF8String 361 Bytes ::= OCTET STRING 362 UUID ::= OCTET STRING 363 Payload ::= OCTET STRING 365 AlgorithmIdentifier ::= SEQUENCE { 366 algorithm OBJECT IDENTIFIER, 367 parameters ANY DEFINED BY algorithm OPTIONAL } 369 KeyId ::= OCTET STRING 370 KdfParameters ::= SEQUENCE { 371 kdfAlgorithm AlgorithmIdentifier, 372 kdfNonce OCTET STRING, 373 keyId KeyId 374 } 376 WrappedKey ::= SEQUENCE { 377 deviceSubjectKeyIdentifier OCTET STRING, 378 key OCTET STRING 379 } 381 KeyTable ::= SEQUENCE { 382 keyWrapAlgorithm AlgorithmIdentifier, 383 keySize INTEGER, 384 payloadKeyDigest OCTET STRING, 385 subjectKeyIdentifier OCTET STRING, 386 table CHOICE { 387 uri UTF8String, 388 integrated SEQUENCE OF WrappedKey 389 } 390 } 392 EncryptionInfo ::= SEQUENCE { 393 mode ENUMERATED { 394 none(0), preSharedKey(1), preSharedKeyKdf(2), keyTable(3) 395 }, 396 config ANY DEFINED BY mode, 397 encryptedPayloadHash OCTET STRING 398 } 400 PayloadInfo ::= SEQUENCE { 401 format CHOICE { 402 enum ENUMERATED { 403 rawBinary(1), hexLocationLengthData(2), elf(3), bsdiff(4) 404 }, 405 objectId OBJECT IDENTIFIER 406 }, 407 encryptionInfo EncryptionInfo OPTIONAL, 408 storageIdentifier OCTET STRING, 409 size INTEGER, 410 payload CHOICE { 411 reference ResourceReference, 412 integrated OCTET STRING 413 } 414 } 416 ResourceReference ::= SEQUENCE { 417 hash OCTET STRING, 418 uri Uri 419 } 421 ConditionValue ::= CHOICE { 422 int INTEGER, 423 raw OCTET STRING 424 } 425 Condition ::= SEQUENCE { 426 type ENUMERATED { 427 vendorId(1), 428 classId(2), 429 deviceId(3), 430 lastApplicationTime(4), 432 vendorSpecificMinimum(2147483648) 433 }, 434 value ConditionValue 435 } 436 DirectiveRule ::= CHOICE { 437 int INTEGER, 438 bool BOOLEAN, 439 raw OCTET STRING 440 } 441 Directive ::= SEQUENCE { 442 type ENUMERATED { 443 applyImmediately(1), 444 applyAfter(2), 445 restartComponent(3), 446 restartSystem(4), 447 installationHandler(5), 449 vendorSpecificMinimum(2147483648) 450 }, 451 rule DirectiveRule 452 } 454 TextField ::= SEQUENCE { 455 type ENUMERATED { 456 description(0), version(1), vendor(2), model(3) 457 }, 458 value UTF8String 459 } 461 Manifest ::= SEQUENCE { 462 manifestVersion ENUMERATED { 463 v1(1) 464 }, 465 text SEQUENCE OF TextField OPTIONAL, 466 nonce OCTET STRING, 467 digestAlgorithm AlgorithmIdentifier, 468 timestamp INTEGER, 469 conditions SEQUENCE OF Condition, 470 directives SEQUENCE OF Directive, 471 aliases SEQUENCE OF ResourceReference, 472 dependencies SEQUENCE OF ResourceReference, 473 payloadInfo PayloadInfo OPTIONAL 474 } 476 END 478 Below is the manifest format in the ASN.1 2015 format. 480 -- Manifest definition file in ASN.1:2015 (v. 1.0.0-alpha) 481 ManifestSchema DEFINITIONS IMPLICIT TAGS ::= BEGIN 483 Uri ::= UTF8String 484 Bytes ::= OCTET STRING 485 UUID ::= OCTET STRING 486 Payload ::= OCTET STRING 488 KeyId ::= OCTET STRING 490 KdfParameters ::= SEQUENCE { 491 kdfAlgorithm AlgorithmIdentifier, 492 kdfNonce OCTET STRING, 493 keyId KeyId 494 } 496 WrappedKey ::= SEQUENCE { 497 deviceSubjectKeyIdentifier OCTET STRING, 498 key OCTET STRING 499 } 501 KeyTable ::= SEQUENCE { 502 keyWrapAlgorithm AlgorithmIdentifier, 503 keySize INTEGER, 504 payloadKeyDigest OCTET STRING, 505 subjectKeyIdentifier OCTET STRING, 506 table CHOICE { 507 uri UTF8String, 508 integrated SEQUENCE OF WrappedKey 509 } 510 } 512 PAYLOADENCRYPTION ::= CLASS { 513 &mode ENUMERATED { 514 none(0), pre-shared-key(1), pre-shared-key-kdf(2), key-table(3) 515 } UNIQUE, 516 --OpenType-- &Config 517 } WITH SYNTAX { MODE &mode, CONFIG &Config} 519 EncryptionOptions PAYLOADENCRYPTION ::= { 520 {MODE none, CONFIG NULL} | 521 {MODE pre-shared-key, CONFIG KeyId} | 522 {MODE pre-shared-key-kdf, CONFIG KdfParameters} | 523 {MODE key-table, CONFIG KeyTable} 524 } 526 EncryptionInfo ::= SEQUENCE { 527 mode PAYLOADENCRYPTION.&mode ({EncryptionOptions}), 528 config PAYLOADENCRYPTION.&Config ({EncryptionOptions}{@mode}), 529 encryptedPayloadHash OCTET STRING 530 } 532 PayloadInfo ::= SEQUENCE { 533 format CHOICE { 534 enum ENUMERATED { 535 undefined(0), raw-binary(1) 536 }, 537 objectId OBJECT IDENTIFIER 538 }, 539 encryptionInfo EncryptionInfo OPTIONAL, 540 storageIdentifier OCTET STRING, 541 size INTEGER, 542 payload CHOICE { 543 reference ResourceReference, 544 integrated OCTET STRING 545 } 546 } 548 ResourceReference ::= SEQUENCE { 549 hash OCTET STRING, 550 uri UTF8String 551 } 553 CONDITION ::= CLASS { 554 &type ENUMERATED { 555 vendorId(1), 556 classId(2), 557 deviceId(3), 558 lastApplicationTime(4), 560 vendorSpecificMinimum(2147483648) 561 }, 562 &Value 563 } WITH SYNTAX {TYPE &type, VALUE &Value} 565 ConditionTable CONDITION ::= { 566 {TYPE vendorId, VALUE OCTET STRING} | 567 {TYPE classId, VALUE OCTET STRING} | 568 {TYPE deviceId, VALUE OCTET STRING} | 569 {TYPE applyBefore, VALUE INTEGER} | 570 {TYPE vendorSpecific, VALUE OCTET STRING} 571 } 573 Condition ::= SEQUENCE { 574 type CONDITION.&type ({ConditionTable}), 575 value CONDITION.&Value ({ConditionTable} {@type}) 576 } 578 DIRECTIVE ::= CLASS { 579 &type ENUMERATED { 580 applyImmediately(1), 581 applyAfter(2), 582 restartComponent(3), 583 restartSystem(4), 584 installationHandler(5), 586 vendorSpecificMinimum(2147483648) 587 }, 588 &Rule 589 } WITH SYNTAX {TYPE &type, RULE &Rule} 591 DirectiveTable DIRECTIVE ::= { 592 {TYPE applyImmediately, RULE BOOLEAN} | 593 {TYPE applyAfter, RULE INTEGER} | 594 {TYPE restartComponent, RULE BOOLEAN} | 595 {TYPE restartSystem, RULE BOOLEAN} | 596 {TYPE installationHandler, RULE OCTET STRING} | 597 {TYPE vendorSpecific, RULE OCTET STRING} 598 } 600 Directive ::= SEQUENCE { 601 type DIRECTIVE.&type ({DirectiveTable}), 602 rule DIRECTIVE.&Rule ({DirectiveTable} {@type}) 603 } 605 TextField ::= SEQUENCE { 606 type ENUMERATED { 607 description(0), version(1), vendor(2), model(3) 608 }, 609 value UTF8String 611 } 613 Manifest ::= SEQUENCE { 614 manifestVersion ENUMERATED { 615 v1(1) 616 }, 617 text SEQUENCE OF TextField OPTIONAL, 618 nonce OCTET STRING, 619 digestAlgorithm AlgorithmIdentifier, 620 timestamp INTEGER, 621 conditions SEQUENCE OF Condition, 622 directives SEQUENCE OF Directive, 623 aliases SEQUENCE OF ResourceReference, 624 dependencies SEQUENCE OF ResourceReference, 625 payload PayloadInfo OPTIONAL 626 } 628 END 630 5. IANA Considerations 632 Editor's Note: A few registries would be good to allow easier 633 allocation of new features. 635 6. Security Considerations 637 This document is about a manifest format describing and protecting 638 firmware images and as such it is part of a larger solution for 639 offering a standardized way of delivering firmware updates to IoT 640 devices. A more detailed discussion about security can be found in 641 the architecture document [Architecture]. 643 7. Mailing List Information 645 The discussion list for this document is located at the e-mail 646 address fud@ietf.org [1]. Information on the group and information 647 on how to subscribe to the list is at 648 https://www1.ietf.org/mailman/listinfo/fud 650 Archives of the list can be found at: https://www.ietf.org/mail- 651 archive/web/fud/current/index.html 653 8. Acknowledgements 655 We would like the following persons for their support in designing 656 this mechanism 658 - Geraint Luff 659 - Amyas Phillips 661 - Dan Ros 663 9. References 665 9.1. Normative References 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, 669 DOI 10.17487/RFC2119, March 1997, 670 . 672 9.2. Informative References 674 [Architecture] 675 Moran, B., "A Firmware Update Architecture for Internet of 676 Things Devices", July 2017. 678 9.3. URIs 680 [1] mailto:fud@ietf.org 682 Authors' Addresses 684 Brendan Moran 685 ARM Limited 687 EMail: Brendan.Moran@arm.com 689 Milosch Meriac 690 ARM Limited 692 EMail: Milosch.Meriac@arm.com 694 Hannes Tschofenig 695 ARM Limited 697 EMail: hannes.tschofenig@gmx.net