idnits 2.17.1 draft-moran-suit-manifest-01.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 (January 29, 2018) is 2272 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 681 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft M. Meriac 4 Intended status: Standards Track H. Tschofenig 5 Expires: August 2, 2018 Arm Limited 6 January 29, 2018 8 Firmware Manifest Format 9 draft-moran-suit-manifest-01 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 August 2, 2018. 35 Copyright Notice 37 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 9 70 3.4. Dependencies and Aliases . . . . . . . . . . . . . . . . 10 71 3.5. Device Identification . . . . . . . . . . . . . . . . . . 10 72 3.5.1. Vendor ID . . . . . . . . . . . . . . . . . . . . . . 11 73 3.5.2. Device Class ID . . . . . . . . . . . . . . . . . . . 11 74 3.5.3. Device ID . . . . . . . . . . . . . . . . . . . . . . 11 75 3.6. Authentication of Manifests . . . . . . . . . . . . . . . 12 76 3.7. Minimum Feature Set . . . . . . . . . . . . . . . . . . . 12 77 4. Manifest CDDL Specification . . . . . . . . . . . . . . . . . 12 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 7. Mailing List Information . . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . 15 85 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 A firmware update mechanism is an essential security feature for IoT 91 devices to deal with vulnerabilities. While the transport of 92 firmware images to the devices themselves is important there are 93 already various techniques available, such as the Lightweight 94 Machine-to-Machine (LwM2M) protocol offering device management of IoT 95 devices. Equally important is the inclusion of meta-data about the 96 conveyed firmware image (in the form of a manifest) and the use of 97 end-to-end security protection to detect modifications and 98 (optionally) to make reverse engineering more difficult. End-to-end 99 security allows the author, who builds the firmware image, to be sure 100 that no other party (including potential adversaries) installs 101 firmware updates on IoT devices without adequate privileges. This 102 authorization process is ensured by the use of dedicated symmetric or 103 asymmetric keys installed on the IoT device: for use cases where only 104 integrity protection is required it is sufficient to install a trust 105 anchor on the IoT device. For confidentiality protected firmware 106 images it is additionally required to install either one or multiple 107 symmetric or asymmetric keys on the IoT device. Starting security 108 protection at the author is a risk mitigation technique so that 109 firmware images and manifests can be stored on untrusted 110 respositories. 112 It is assumed that the reader is familiar with the high-level 113 firmware update architecture [Architecture]. 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 | digests | 156 | storageIdentifier | 157 | uris | 158 | size | 159 | COSE_Encrypt | 160 +--------------------+ 162 Figure 1: Components of a Manifest. 164 3.1. Manifest 166 The Manifest structure is the top-level construct that ties all other 167 structures together. In addition to the structures explained in 168 subsections below it contains 170 - a version number (in the 'manifestVersion' attribute) 172 - a textual description about the update, including the version / 173 vendor / model of the device (in the 'text' attribute). This 174 information is optional. 176 - a timestamp indicating when the manifest was created (in the 177 'timestamp' attribute). 179 The following CDDL fragment defines the manifest. 181 Manifest = [ 182 manifestVersion : uint, 183 text : {* int => tstr } / nil, 184 nonce : bstr, 185 timestamp : uint, 186 conditions: [ * condition ], 187 directives: [ * directive ] / nil, 188 aliases: [ * ResourceReference ] / nil, 189 dependencies: [ * ResourceReference ] / nil, 190 extensions: { * int => bstr } / nil, 191 payloadInfo: ? PayloadInfo 192 ] 194 In the text section, positive integers define standard text fields, 195 described in this draft. Negative integers define application- 196 specific text fields. 198 +----------+----------------------------------------------------------+ 199 | Field ID | Description | 200 +----------+----------------------------------------------------------+ 201 | 1 | A text description of this manifest | 202 | 2 | A text description of the payload | 203 | 3 | A text representation of the target vendor name / | 204 | | manufacturer name | 205 | 4 | A text representation of the target model number / | 206 | | model name | 207 +----------+----------------------------------------------------------+ 209 Text fields are never used by the target. They are for informational 210 purposes only. 212 3.2. PayloadInfo 214 The PayloadInfo structure contains information about the firmware 215 image: 217 - format: contains the firmware image type (such as rawBinary, 218 hexLocationLengthData, ELF). Format is an array of: an integer 219 (positive for standard types, negative for application-specific 220 types) and a bstr that encapsulates any information needed by the 221 format processor, that is not included in the firmware image 222 itself. 224 - size: offers information about the size of the firmware image in 225 bytes. If the size of the obtained firmware image differs from 226 the size stated in the manifest then the obtained image MUST be 227 consider corrupted. 229 - nonce: contains a (short) random value to ensure that a given 230 manifest is unique. This separates the function of the timestamp, 231 which is provided for rollback protection, from the function of 232 the nonce, which is for uniqueness. Keeping these functions 233 separate ensures that a number of edge cases are catered for, for 234 example: the creation of manifests quickly enough that they have 235 the same timestamp. 237 - storageIdentifier: indicates where the image should be placed on 238 the device. This value is useful, for example, when an IoT device 239 contains multiple microcontrollers (MCUs) and the decision needs 240 to be made to which MCU to send which firmware image. Another 241 example is when an IoT device contains both firmware and 242 configuration and the configuration must be updated while the 243 firmware remains the same. 245 - uris: a set of ranked references for where to find the payload. 246 By using a ranking, the device can select which the preferred URIs 247 are. If several URIs have the same preference, then devices 248 SHOULD select randomly from the available URIs of the same rank. 249 URIs need not be a URL, a URN is acceptable if the target 250 understands it. The uri can allow a device to use a ranked search 251 pattern to choose the best location to look for the payload in 252 complex distribution scenarios, such as attempting to find the 253 payload on a gateway device prior to looking on a fileserver. 255 - digestAlgorithm: This defines the type of digest used for all 256 entries in the digests list. The type must be a standard COSE MAC 257 algorithm or a message digest algorithm (these are not yet defined 258 in COSE). An optional 'parameters' bstr is provided in case one 259 of these algorithms requires additional configuration that would 260 normally be present in the 'protected' or 'unprotected' fields of 261 the COSE_Mac object. 263 - digests: This is a map of possible digests. It is indexed by 264 integer: positive for standardized digests and negative for 265 application-specific digests. 267 - payload: a COSE_Encrypt object, a bstr, or nil. Note that a 268 COSE_Mac could be used instead of a bstr / nil, but this would be 269 redundant since the whole structure is already authenticated. 271 NOTE: digests needs some form of key derivation to prevent the need 272 for multiple keys. It is expected that the same key be used, with a 273 KDF of some kind, to derive a key from the key used to sign the 274 manifest in the case of COSE_Mac manifests. Where manifests use 275 COSE_Sign at the top level, it is expected that digests will use 276 standard message digest algorithms instead of MAC algorithms. 278 The following CDDL fragment defines the payload info: 280 PayloadInfo = [ 281 format = [ 282 type: int, 283 ? parameters : bstr 284 ], 285 size: uint, 286 storageIdentifier: bstr, 287 uris: [*[ 288 rank: int, 289 uri: tstr 290 ]] / nil, 291 digestAlgorithm = [ 292 type : int, 293 ? parameters: bstr 294 ] / nil, 295 digests = {* int => bstr} / nil, 296 payload = COSE_Encrypt / bstr / nil 297 ] 299 Digests can contain several kinds of digest: 301 +-----------+---------------------------------------------------------+ 302 | Digest ID | Description | 303 +-----------+---------------------------------------------------------+ 304 | 1 | raw payload digest: the digest of the payload with no | 305 | | modification. This is the digest of the plaintext. | 306 | | This data is redundant when an AEAD algo is used. | 307 | 2 | installed payload digest: the digest of the payload, | 308 | | post-installation. This is most useful in differential | 309 | | updates. | 310 | 3 | ciphertext digest: The digest of the ciphertext of the | 311 | | payload. This is useful when compressed or differential | 312 | | updates are used, since it can be used to verify the | 313 | | downloaded package prior to decryption. | 314 | 4 | pre-image digest: The digest of the image that must | 315 | | already be present in the device in order to install | 316 | | the payload. | 317 +-----------+---------------------------------------------------------+ 319 There are several ways that this format can reference a payload: 321 1. The payload can be contained by the COSE_Encrypt object. In this 322 case, no URIs are expected, since the payload is contained in 323 COSE_Encrypt. 325 2. The COSE_Encrypt object is present, but its 'ciphertext' is nil. 326 This means that the ciphertext payload is delivered separately. 327 In this case, at least one URI is expected in uris. 329 3. The payload is a bstr. This encapsulates a plaintext payload. A 330 raw payload digest is redundant. No URIs are expected. 332 4. The payload is a nil. This means that the plaintext payload is 333 delivered separately. In this case, at least one URI is expected 334 in uris. At least one digest is expected in digests. 336 Most importantly, however, the PayloadInfo structure contains a 337 reference to the firmware image (in the 'reference' attribute) or the 338 image is embedded inside the PayloadInfo structure (within the 339 'integrated' attribute). A referenced image first needs to be 340 fetched by the device before the update can be applied. The 341 'reference' attribute contains a 'hash' and a 'uri' attribute: the 342 value in the 'hash' attribute allows the device to determine whether 343 it has already obtained this firmware image and, since it is included 344 in the digitally signed manifest, it protects the firmware image 345 against modifications. The 'uri' attribute references the image. 347 Encryption is handled by the COSE_Encrypt structure. Most encryption 348 modes are already supported via the COSE_Encrypt structure, only per- 349 device pre-shared keys (or per-device ECDH derivation of pre-shared 350 keys) needs to be described. When using an encrypted image key, 351 shared between many devices, the COSE_Encrypt recipients structure 352 should be filled out as follows: 354 / recipients / [ 355 [ 356 / protected / h'a1011820' / { 357 \ alg \ 1:32 \ AES-CCM-64-128-128 \ 358 } / , 359 / unprotected / { 360 / kid / 4:'' /, 361 / iv / 5:h'<7 bytes>' 362 }, 363 / ciphertext / nil 364 ] 365 ] 367 Figure 2: AES-CCM-64-128-128 COSE Example. 369 This allows a manifest to direct a device to fetch keys from a 370 particular location, identify them by name, or perform another fetch/ 371 lookup operation. The exact method for key distribution is out of 372 scope. (However, an array of COSE_Encrypt objects, each containing a 373 single key object, with a simple recipient object seems appropriate.) 375 This mode is tailored to use cases where a single encrypted firmware 376 image is transmitted to many IoT devices. 378 3.3. Condition and Directive 380 The Condition and the Directive structures together allow "If <...> 381 Then <...>" rules to be expressed. 383 It offers the following functionality: 385 - Apply an update immediately (Directive.applyImmediately) 387 - Apply an update only to devices that match the vendorId, classId, 388 deviceId attributes 390 - Apply an update only if the device system time is before the time 391 indicated in the Condition.lastApplicationTime. 393 - Wait to apply an update until the device system time is after an 394 indicated time. 396 The following CDDL fragment defines the structure of a condition: 398 condition = [ 399 type : int, 400 parameters : bstr 401 ] 402 directive = condition 404 Some condition types are predefined: 406 +--------------+------------------------------------------------------+ 407 | Condition ID | Description | 408 +--------------+------------------------------------------------------+ 409 | 1 | Vendor ID. parameters contains the 128-bit vendor ID | 410 | | to match. | 411 | 2 | Class ID. parameters contains the 128-bit device | 412 | | class ID to match. | 413 | 3 | Device ID. parameters contains the 128-bit device ID | 414 | | to match. | 415 | 4 | Best Before. Do not apply the update after time. | 416 | | parameters is serialized as an uint timestamp | 417 | | encoded in the bstr. | 418 +--------------+------------------------------------------------------+ 419 Some directive types are predefined: 421 +--------------+------------------------------------------------------+ 422 | Directive ID | Description | 423 +--------------+------------------------------------------------------+ 424 | 1 | Apply Immediately. Apply right away. Do not wait. | 425 | | parameters MUST contain a True or False, serialized | 426 | | in the bstr. Setting this value to False will cause | 427 | | the target to wait until a new manifest arrives with | 428 | | Apply Immediately set to true and a dependency on | 429 | | this manifest. | 430 | 2 | Apply After. Wait until time to apply update. | 431 | | parameters is serialized as a uint timestamp encoded | 432 | | in the bstr. | 433 +--------------+------------------------------------------------------+ 435 Application-specific conditions and directives MUST use negative 436 identifiers. 438 3.4. Dependencies and Aliases 440 In some situations an IoT device may require more than a single 441 firmware image. To express the requirement that more than one image 442 has to be installed on a device the dependencies structure is used, 443 which is of type ResourceReference. 445 The following CDDL fragment defines the ResourceReference: 447 ResourceReference = [ 448 uri : tstr, 449 digest : bstr 450 ] 452 Aliases are used to refer to alternative locations of firmware 453 images. This is useful in environments where organizations cache 454 firmware images (and their corresponding manifests) on premise to 455 avoid the need to fetch images from repositories maintained by the 456 developer's organizations (such a device manufacturer or an OEM). 458 3.5. Device Identification 460 A device is identified by a combination of three identifiers: 462 - A vendor identifier 464 - A device class identifier 466 - A device identifier 468 3.5.1. Vendor ID 470 The vendor ID is a 128-bit number that conforms to RFC 4122, type 5. 471 This number is used by the device to verify manifests. 473 The Vendor ID should be derived from the manufacturer's domain name 474 using the algorithm defined in Section 4.3 of RFC 4122. 476 A vendor ID is typically compiled into a firmware image since it is 477 static for the lifetime of the firmware. 479 3.5.2. Device Class ID 481 The device class is a 128-bit number that conforms to RFC 4122, type 482 5. This number is used by the client to verify manifests. The 483 Device Class ID SHOULD use the Vendor ID as the namespace, but the ID 484 within the namespace can be arbitrary. 486 A class ID is also typically compiled into a firmware image since it 487 is static for the lifetime of the firmware. 489 3.5.3. Device ID 491 The device ID is also a 128-bit number that conforms to RFC 4122. 492 The device ID can come from a variety of sources. For example, a 493 device may obtain this identifier during the manufacturing phase 494 (together with other configuration information and manufacturer- 495 provided credentials). In this case, we recommend using RFC 4122, 496 type 1, where the node ID is the factory tool ID, which provides 497 traceability of a device back to the origin of manufacture. A device 498 ID can also come from on-device resources, such as device unique-ID 499 registers or device identifiers in CPUs. Our recommendation is to 500 provide unique CPU resources to a generator function similar to the 501 one used for the class_id. In this example, the device_info may be a 502 combination of several components, such as: 504 - MAC address 506 - Device unique identifier 508 Where multiple sources of unique identity are available, they should 509 all be provided to the UUID function, since it combines them to 510 create a single, unique identifier. 512 3.6. Authentication of Manifests 514 At the top level, manifests are authenticated using either the 515 COSE_Mac or COSE_Sign structures, depending on application. The 516 considerations that apply to encryption keys in PayloadInfo apply 517 equally to the use of Mac keys in COSE_Mac. 519 3.7. Minimum Feature Set 521 Not all devices will support the full feature set described in this 522 specification. If features become complex enough, it may be 523 necessary to report the features used by a manifest. Since this is 524 redundant information, it is excluded from this draft. 526 At minimum, targets MUST support the following manifest fields: 528 1. manifestVersion, so that the target can tell which version of 529 manifest is in use. 531 2. text (this is ignored by the target) 533 3. nonce (this is ignored by the target) 535 4. timestamp 537 5. conditions 539 6. payloadInfo 541 A target attempting to parse a manifest that contains non-nil fields 542 that it does not support SHALL report an error in validation. 544 At minimum, targets MUST support the ONE of the following payload 545 modes: 547 1. digestAlgorithm, digests, bstr 549 2. digestAlgorithm, digests, uris, nil payload 551 3. COSE_Encrypt, inline ciphertext 553 4. COSE_Encrypt, nil ciphertext 555 4. Manifest CDDL Specification 557 The following CDDL code describes the entire manifest format. 559 condition = [ 560 type : int, 561 parameters : bstr 562 ] 563 directive = condition 565 ResourceReference = [ 566 uri : tstr, 567 digest : bstr 568 ] 570 PayloadInfo = [ 571 format = [ 572 type: int, 573 ? parameters : bstr 574 ], 575 size: uint, 576 storageIdentifier: bstr, 577 uris: [*[ 578 rank: int, 579 uri: tstr 580 ]] / nil, 581 digestAlgorithm = [ 582 type : int, 583 ? parameters: bstr 584 ] / nil, 585 digests = {* int => bstr} / nil, 586 payload = COSE_Encrypt / bstr / nil 587 ] 589 Manifest = [ 590 manifestVersion : uint, 591 text : {* int => tstr } / nil, 592 nonce : bstr, 593 timestamp : uint, 594 conditions: [ * condition ], 595 directives: [ * directive ] / nil, 596 aliases: [ * ResourceReference ] / nil, 597 dependencies: [ * ResourceReference ] / nil, 598 extensions: { * int => bstr } / nil, 599 payloadInfo: ? payloadInfo 600 ] 602 The manifest itself is encapsulated in either a COSE_Mac or a 603 COSE_Sign block. 605 5. IANA Considerations 607 Editor's Note: A few registries would be good to allow easier 608 allocation of new features. 610 6. Security Considerations 612 This document is about a manifest format describing and protecting 613 firmware images and as such it is part of a larger solution for 614 offering a standardized way of delivering firmware updates to IoT 615 devices. A more detailed discussion about security can be found in 616 the architecture document [Architecture]. 618 7. Mailing List Information 620 The discussion list for this document is located at the e-mail 621 address suit@ietf.org [1]. Information on the group and information 622 on how to subscribe to the list is at 623 https://www1.ietf.org/mailman/listinfo/suit 625 Archives of the list can be found at: https://www.ietf.org/mail- 626 archive/web/suit/current/index.html 628 8. Acknowledgements 630 We would like the following persons for their support in designing 631 this mechanism 633 - Geraint Luff 635 - Amyas Phillips 637 - Dan Ros 639 - Thomas Eichinger 641 - Michael Richardson 643 - Emmanuel Baccelli 645 - Ned Smith 647 - David Brown 649 - Jim Schaad 651 - Carsten Bormann 652 - Cullen Jennings 654 - Olaf Bergmann 656 - Suhas Nandakumar 658 - Phillip Hallam-Baker 660 We would also like to thank the WG chairs, Russ Housley, David 661 Waltermire, Dave Thaler and the responsible security area director, 662 Kathleen Moriarty, for their support. 664 9. References 666 9.1. Normative References 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, 670 DOI 10.17487/RFC2119, March 1997, . 673 9.2. Informative References 675 [Architecture] 676 Tschofenig, H., "A Firmware Update Architecture for 677 Internet of Things Devices", January 2018. 679 9.3. URIs 681 [1] mailto:suit@ietf.org 683 Authors' Addresses 685 Brendan Moran 686 Arm Limited 688 EMail: Brendan.Moran@arm.com 690 Milosch Meriac 691 Arm Limited 693 EMail: Milosch.Meriac@arm.com 694 Hannes Tschofenig 695 Arm Limited 697 EMail: hannes.tschofenig@gmx.net