< draft-ietf-suit-manifest-16.txt   draft-ietf-suit-manifest-17.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Arm Limited Intended status: Standards Track Arm Limited
Expires: 29 April 2022 H. Birkholz Expires: 30 October 2022 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
K. Zandberg K. Zandberg
Inria Inria
26 October 2021 28 April 2022
A Concise Binary Object Representation (CBOR)-based Serialization Format A Concise Binary Object Representation (CBOR)-based Serialization Format
for the Software Updates for Internet of Things (SUIT) Manifest for the Software Updates for Internet of Things (SUIT) Manifest
draft-ietf-suit-manifest-16 draft-ietf-suit-manifest-17
Abstract Abstract
This specification describes the format of a manifest. A manifest is This specification describes the format of a manifest. A manifest is
a bundle of metadata about code/data obtained by a recipient (chiefly a bundle of metadata about code/data obtained by a recipient (chiefly
the firmware for an IoT device), where to find the that code/data, the firmware for an IoT device), where to find the that code/data,
the devices to which it applies, and cryptographic information the devices to which it applies, and cryptographic information
protecting the manifest. Software updates and Trusted Invocation protecting the manifest. Software updates and Trusted Invocation
both tend to use sequences of common operations, so the manifest both tend to use sequences of common operations, so the manifest
encodes those sequences of operations, rather than declaring the encodes those sequences of operations, rather than declaring the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 April 2022. This Internet-Draft will expire on 30 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. How to use this Document . . . . . . . . . . . . . . . . . . 8 3. How to use this Document . . . . . . . . . . . . . . . . . . 8
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. IoT Firmware Update Constraints . . . . . . . . . . . . . 9 4.1. IoT Firmware Update Constraints . . . . . . . . . . . . . 9
4.2. SUIT Workflow Model . . . . . . . . . . . . . . . . . . . 10 4.2. SUIT Workflow Model . . . . . . . . . . . . . . . . . . . 10
5. Metadata Structure Overview . . . . . . . . . . . . . . . . . 11 5. Metadata Structure Overview . . . . . . . . . . . . . . . . . 11
5.1. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Authentication Block . . . . . . . . . . . . . . . . . . 12 5.2. Authentication Block . . . . . . . . . . . . . . . . . . 13
5.3. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Critical Metadata . . . . . . . . . . . . . . . . . . 13 5.3.1. Critical Metadata . . . . . . . . . . . . . . . . . . 13
5.3.2. Common . . . . . . . . . . . . . . . . . . . . . . . 13 5.3.2. Common . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.3. Command Sequences . . . . . . . . . . . . . . . . . . 14 5.3.3. Command Sequences . . . . . . . . . . . . . . . . . . 14
5.3.4. Integrity Check Values . . . . . . . . . . . . . . . 14 5.3.4. Integrity Check Values . . . . . . . . . . . . . . . 14
5.3.5. Human-Readable Text . . . . . . . . . . . . . . . . . 14 5.3.5. Human-Readable Text . . . . . . . . . . . . . . . . . 14
5.4. Severable Elements . . . . . . . . . . . . . . . . . . . 15 5.4. Severable Elements . . . . . . . . . . . . . . . . . . . 15
5.5. Integrated Payloads . . . . . . . . . . . . . . . . . . . 15 5.5. Integrated Payloads . . . . . . . . . . . . . . . . . . . 15
6. Manifest Processor Behavior . . . . . . . . . . . . . . . . . 15 6. Manifest Processor Behavior . . . . . . . . . . . . . . . . . 15
6.1. Manifest Processor Setup . . . . . . . . . . . . . . . . 16 6.1. Manifest Processor Setup . . . . . . . . . . . . . . . . 16
skipping to change at page 3, line 9 skipping to change at page 3, line 9
7.6. Load from Nonvolatile Storage Template . . . . . . . . . 26 7.6. Load from Nonvolatile Storage Template . . . . . . . . . 26
7.7. A/B Image Template . . . . . . . . . . . . . . . . . . . 26 7.7. A/B Image Template . . . . . . . . . . . . . . . . . . . 26
8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 28 8. Metadata Structure . . . . . . . . . . . . . . . . . . . . . 28
8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 28 8.1. Encoding Considerations . . . . . . . . . . . . . . . . . 28
8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 28
8.3. Authenticated Manifests . . . . . . . . . . . . . . . . . 29 8.3. Authenticated Manifests . . . . . . . . . . . . . . . . . 29
8.4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 29 8.4. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4.1. suit-manifest-version . . . . . . . . . . . . . . . . 30 8.4.1. suit-manifest-version . . . . . . . . . . . . . . . . 30
8.4.2. suit-manifest-sequence-number . . . . . . . . . . . . 30 8.4.2. suit-manifest-sequence-number . . . . . . . . . . . . 30
8.4.3. suit-reference-uri . . . . . . . . . . . . . . . . . 30 8.4.3. suit-reference-uri . . . . . . . . . . . . . . . . . 30
8.4.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 30 8.4.4. suit-text . . . . . . . . . . . . . . . . . . . . . . 31
8.4.5. suit-common . . . . . . . . . . . . . . . . . . . . . 32 8.4.5. suit-common . . . . . . . . . . . . . . . . . . . . . 32
8.4.6. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 33 8.4.6. SUIT_Command_Sequence . . . . . . . . . . . . . . . . 33
8.4.7. Reporting Policy . . . . . . . . . . . . . . . . . . 35 8.4.7. Reporting Policy . . . . . . . . . . . . . . . . . . 35
8.4.8. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 36 8.4.8. SUIT_Parameters . . . . . . . . . . . . . . . . . . . 36
8.4.9. SUIT_Condition . . . . . . . . . . . . . . . . . . . 42 8.4.9. SUIT_Condition . . . . . . . . . . . . . . . . . . . 42
8.4.10. SUIT_Directive . . . . . . . . . . . . . . . . . . . 45 8.4.10. SUIT_Directive . . . . . . . . . . . . . . . . . . . 45
8.4.11. Integrity Check Values . . . . . . . . . . . . . . . 50 8.4.11. Integrity Check Values . . . . . . . . . . . . . . . 50
8.5. Severable Elements . . . . . . . . . . . . . . . . . . . 50 8.5. Severable Elements . . . . . . . . . . . . . . . . . . . 50
9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 50 9. Access Control Lists . . . . . . . . . . . . . . . . . . . . 50
10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 51 10. SUIT Digest Container . . . . . . . . . . . . . . . . . . . . 51
skipping to change at page 3, line 43 skipping to change at page 3, line 43
B.2. Example 1: Simultaneous Download and Installation of B.2. Example 1: Simultaneous Download and Installation of
Payload . . . . . . . . . . . . . . . . . . . . . . . . . 67 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.3. Example 2: Simultaneous Download, Installation, Secure B.3. Example 2: Simultaneous Download, Installation, Secure
Boot, Severed Fields . . . . . . . . . . . . . . . . . . 69 Boot, Severed Fields . . . . . . . . . . . . . . . . . . 69
B.4. Example 3: A/B images . . . . . . . . . . . . . . . . . . 73 B.4. Example 3: A/B images . . . . . . . . . . . . . . . . . . 73
B.5. Example 4: Load from External Storage . . . . . . . . . . 76 B.5. Example 4: Load from External Storage . . . . . . . . . . 76
B.6. Example 5: Two Images . . . . . . . . . . . . . . . . . . 79 B.6. Example 5: Two Images . . . . . . . . . . . . . . . . . . 79
Appendix C. C. Design Rational . . . . . . . . . . . . . . . . 82 Appendix C. C. Design Rational . . . . . . . . . . . . . . . . 82
C.1. C.1 Design Rationale: Envelope . . . . . . . . . . . . . 83 C.1. C.1 Design Rationale: Envelope . . . . . . . . . . . . . 83
C.2. C.2 Byte String Wrappers . . . . . . . . . . . . . . . . 84 C.2. C.2 Byte String Wrappers . . . . . . . . . . . . . . . . 84
Appendix D. D. Implementation Conformance Matrix . . . . . . . 84 Appendix D. D. Implementation Conformance Matrix . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
A firmware update mechanism is an essential security feature for IoT A firmware update mechanism is an essential security feature for IoT
devices to deal with vulnerabilities. While the transport of devices to deal with vulnerabilities. While the transport of
firmware images to the devices themselves is important there are firmware images to the devices themselves is important there are
already various techniques available. Equally important is the already various techniques available. Equally important is the
inclusion of metadata about the conveyed firmware image (in the form inclusion of metadata about the conveyed firmware image (in the form
of a manifest) and the use of a security wrapper to provide end-to- of a manifest) and the use of a security wrapper to provide end-to-
end security protection to detect modifications and (optionally) to end security protection to detect modifications and (optionally) to
skipping to change at page 4, line 43 skipping to change at page 4, line 43
* Verify them * Verify them
* Load them into memory * Load them into memory
* Invoke them * Invoke them
This specification defines the SUIT manifest format and it is This specification defines the SUIT manifest format and it is
intended to meet several goals: intended to meet several goals:
* Meet the requirements defined in * Meet the requirements defined in [RFC9124].
[I-D.ietf-suit-information-model].
* Simple to parse on a constrained node * Simple to parse on a constrained node
* Simple to process on a constrained node * Simple to process on a constrained node
* Compact encoding * Compact encoding
* Comprehensible by an intermediate system * Comprehensible by an intermediate system
* Expressive enough to enable advanced use cases on advanced nodes * Expressive enough to enable advanced use cases on advanced nodes
skipping to change at page 5, line 37 skipping to change at page 5, line 37
* a device to reason about the installation of a firmware. * a device to reason about the installation of a firmware.
* a device to reason about the authenticity & encoding of a firmware * a device to reason about the authenticity & encoding of a firmware
at boot. at boot.
Each of these uses happens at a different stage of the manifest Each of these uses happens at a different stage of the manifest
lifecycle, so each has different requirements. lifecycle, so each has different requirements.
It is assumed that the reader is familiar with the high-level It is assumed that the reader is familiar with the high-level
firmware update architecture [RFC9019] and the threats, requirements, firmware update architecture [RFC9019] and the threats, requirements,
and user stories in [I-D.ietf-suit-information-model]. and user stories in [RFC9124].
The design of this specification is based on an observation that the The design of this specification is based on an observation that the
vast majority of operations that a device can perform during an vast majority of operations that a device can perform during an
update or Trusted Invocation are composed of a small group of update or Trusted Invocation are composed of a small group of
operations: operations:
* Copy some data from one place to another * Copy some data from one place to another
* Transform some data * Transform some data
skipping to change at page 6, line 23 skipping to change at page 6, line 23
firmware image from one place to another, checking that a firmware firmware image from one place to another, checking that a firmware
image is correct, verifying that the specified firmware is the image is correct, verifying that the specified firmware is the
correct firmware for the device, or unpacking a firmware. By using correct firmware for the device, or unpacking a firmware. By using
these steps in different orders and changing the parameters they use, these steps in different orders and changing the parameters they use,
a broad range of use cases can be supported. The SUIT manifest uses a broad range of use cases can be supported. The SUIT manifest uses
this observation to optimize metadata for consumption by constrained this observation to optimize metadata for consumption by constrained
devices. devices.
While the SUIT manifest is informed by and optimized for firmware While the SUIT manifest is informed by and optimized for firmware
update and Trusted Invocation use cases, there is nothing in the SUIT update and Trusted Invocation use cases, there is nothing in the SUIT
Information Model ([I-D.ietf-suit-information-model]) that restricts Information Model ([RFC9124]) that restricts its use to only those
its use to only those use cases. Other use cases include the use cases. Other use cases include the management of trusted
management of trusted applications (TAs) in a Trusted Execution applications (TAs) in a Trusted Execution Environment (TEE), as
Environment (TEE), as discussed in [I-D.ietf-teep-architecture]. discussed in [I-D.ietf-teep-architecture].
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Additionally, the following terminology is used throughout this Additionally, the following terminology is used throughout this
skipping to change at page 7, line 7 skipping to change at page 7, line 7
* Resource: A piece of information that is used to construct a * Resource: A piece of information that is used to construct a
payload. payload.
* Manifest: A manifest is a bundle of metadata about the firmware * Manifest: A manifest is a bundle of metadata about the firmware
for an IoT device, where to find the firmware, and the devices to for an IoT device, where to find the firmware, and the devices to
which it applies. which it applies.
* Envelope: A container with the manifest, an authentication wrapper * Envelope: A container with the manifest, an authentication wrapper
with cryptographic information protecting the manifest, with cryptographic information protecting the manifest,
authorization information, and severable elements (see: TBD). authorization information, and severable elements.
* Update: One or more manifests that describe one or more payloads. * Update: One or more manifests that describe one or more payloads.
* Update Authority: The owner of a cryptographic key used to sign * Update Authority: The owner of a cryptographic key used to sign
updates, trusted by Recipients. updates, trusted by Recipients.
* Recipient: The system, typically an IoT device, that receives and * Recipient: The system, typically an IoT device, that receives and
processes a manifest. processes a manifest.
* Manifest Processor: A component of the Recipient that consumes * Manifest Processor: A component of the Recipient that consumes
skipping to change at page 9, line 11 skipping to change at page 9, line 11
The IANA consideration section, see Section 11, provides instructions The IANA consideration section, see Section 11, provides instructions
to IANA to create several registries. This section also provides the to IANA to create several registries. This section also provides the
CBOR labels for the structures defined in this document. CBOR labels for the structures defined in this document.
The complete CDDL description is provided in Appendix A, examples are The complete CDDL description is provided in Appendix A, examples are
given in Appendix B and a design rational is offered in Appendix C. given in Appendix B and a design rational is offered in Appendix C.
Finally, Appendix D gives a summarize of the mandatory-to-implement Finally, Appendix D gives a summarize of the mandatory-to-implement
features of this specification. features of this specification.
This specification covers the core features of SUIT. Additional This specification covers the core features of SUIT. Additional
specifications will cover advanced use cases and update management specifications describe functionality of advanced use cases, such as:
needs:
* Firmware Encryption is covered in * Firmware Encryption is covered in
[I-D.ietf-suit-firmware-encryption] [I-D.ietf-suit-firmware-encryption]
* Update Management is covered in (TBD) * Update Management is covered in [I-D.ietf-suit-update-management]
* Multiple Trust Domains (dependencies, key delegation, multiple * Features, such as dependencies, key delegation, multiple
processors, TEEs, etc.) are covered in (TBD) processors, required by the use of multiple trust domains are
covered in [I-D.ietf-suit-trust-domains]
* Update Compression is covered in (TBD) * Secure reporting of the update status is covered in
[I-D.ietf-suit-report]
* Compression of firmware images
4. Background 4. Background
Distributing software updates to diverse devices with diverse trust Distributing software updates to diverse devices with diverse trust
anchors in a coordinated system presents unique challenges. Devices anchors in a coordinated system presents unique challenges. Devices
have a broad set of constraints, requiring different metadata to make have a broad set of constraints, requiring different metadata to make
appropriate decisions. There may be many actors in production IoT appropriate decisions. There may be many actors in production IoT
systems, each of whom has some authority. Distributing firmware in systems, each of whom has some authority. Distributing firmware in
such a multi-party environment presents additional challenges. Each such a multi-party environment presents additional challenges. Each
party requires a different subset of data. Some data may not be party requires a different subset of data. Some data may not be
accessible to all parties. Multiple signatures may be required from accessible to all parties. Multiple signatures may be required from
parties with different authorities. This topic is covered in more parties with different authorities. This topic is covered in more
depth in [RFC9019]. The security aspects are described in depth in [RFC9019]. The security aspects are described in [RFC9124].
[I-D.ietf-suit-information-model].
4.1. IoT Firmware Update Constraints 4.1. IoT Firmware Update Constraints
The various constraints of IoT devices and the range of use cases The various constraints of IoT devices and the range of use cases
that need to be supported create a broad set of requirements. For that need to be supported create a broad set of requirements. For
example, devices with: example, devices with:
* limited processing power and storage may require a simple * limited processing power and storage may require a simple
representation of metadata. representation of metadata.
skipping to change at page 17, line 6 skipping to change at page 17, line 6
* Required parameter not supplied. * Required parameter not supplied.
These failure reasons MAY be combined with retry mechanisms prior to These failure reasons MAY be combined with retry mechanisms prior to
marking a manifest as invalid. marking a manifest as invalid.
Selecting an older manifest in the event of failure of the latest Selecting an older manifest in the event of failure of the latest
valid manifest is a robustness mechanism that is necessary for valid manifest is a robustness mechanism that is necessary for
supporting the requirements in [RFC9019], section 3.5. It may not be supporting the requirements in [RFC9019], section 3.5. It may not be
appropriate for all applications. In particular Trusted Execution appropriate for all applications. In particular Trusted Execution
Environments MAY require a failure to invoke a new installation, Environments MAY require a failure to invoke a new installation,
rather than a rollback approach. See rather than a rollback approach. See [RFC9124], Section 4.2.1 for
[I-D.ietf-suit-information-model], Section 4.2.1 for more discussion more discussion on the security considerations that apply to
on the security considerations that apply to rollback. rollback.
Following these initial tests, the manifest processor clears all Following these initial tests, the manifest processor clears all
parameter storage. This ensures that the manifest processor begins parameter storage. This ensures that the manifest processor begins
without any leaked data. without any leaked data.
6.2. Required Checks 6.2. Required Checks
The RECOMMENDED process is to verify the signature of the manifest The RECOMMENDED process is to verify the signature of the manifest
prior to parsing/executing any section of the manifest. This guards prior to parsing/executing any section of the manifest. This guards
the parser against arbitrary input by unauthenticated third parties, the parser against arbitrary input by unauthenticated third parties,
skipping to change at page 29, line 11 skipping to change at page 29, line 11
The Envelope contains each of the other primary constituent parts of The Envelope contains each of the other primary constituent parts of
the SUIT metadata. It allows for modular processing of the manifest the SUIT metadata. It allows for modular processing of the manifest
by ordering components in the expected order of processing. by ordering components in the expected order of processing.
The Envelope is encoded as a CBOR Map. Each element of the Envelope The Envelope is encoded as a CBOR Map. Each element of the Envelope
is enclosed in a bstr, which allows computation of a message digest is enclosed in a bstr, which allows computation of a message digest
against known bounds. against known bounds.
8.3. Authenticated Manifests 8.3. Authenticated Manifests
The suit-authentication-wrapper contains a list containing a SUIT The suit-authentication-wrapper contains a SUIT Digest Container (see
Digest Container (see Section 10) and one or more cryptographic Section 10) and one or more SUIT Authentication Blocks. The
authentication wrappers for the Manifest. These blocks are SUIT_Digest carries the result of computing the indicated hash
implemented as COSE_Mac_Tagged or COSE_Sign_Tagged structures with algorithm over the suit-manifest element. A signing application MUST
null payloads, indicating that the payload to be used is the SUIT verify the suit-manifest element against the SUIT_Digest prior to
Digest Container. This enables modular processing of the manifest. signing. A SUIT Authentication Block is implemented as
The COSE_Mac_Tagged and COSE_Sign_Tagged blocks are described in RFC COSE_Mac_Tagged, COSE_Mac0_Tagged, COSE_Sign_Tagged or
8152 [RFC8152]. The suit-authentication-wrapper MUST come before any COSE_Sign1_Tagged structures with detached payloads, as described in
element in the SUIT_Envelope, regardless of canonical encoding of RFC 8152 [RFC8152].
CBOR. All validators MUST reject any SUIT_Envelope that begins with
any element other than a suit-authentication-wrapper (NOTE: key For COSE_Sign and COSE_Sign1 a special signature structure (called
delegation MAY relax this requirement to include a delegation Sig_structure) has to be created onto which the selected digital
structure as well). signature algorithm is applied to, see Section 4.4 of [RFC8152] for
details. This specification requires Sig_structure to be populated
as follows: * The external_aad field MUST be set to a zero-length
binary string (i.e. there is no external additional authenticated
data). * The payload field contains the SUIT_Digest wrapped in a
bstr, as per the requirements in Section 4.4 of RFC 8152. All other
fields in the Sig_structure are populated as described in Section 4.4
of [RFC8152].
Likewise, Section 6.3 of [RFC8152] describes the details for
computing a MAC and the fields of the MAC_structure need to be
populated. The rules for external_aad and the payload fields
described in the paragraph above also apply to this structure.
The suit-authentication-wrapper MUST come before the suit-manifest
element, regardless of canonical encoding of CBOR.
A SUIT_Envelope that has not had authentication information added A SUIT_Envelope that has not had authentication information added
MUST still contain the suit-authentication-wrapper element, but the MUST still contain the suit-authentication-wrapper element, but the
content MUST be a list containing only the SUIT_Digest. content MUST be a list containing only the SUIT_Digest.
A signing application MUST verify the suit-manifest element against
the SUIT_Digest prior to signing.
8.4. Manifest 8.4. Manifest
The manifest contains: The manifest contains:
* a version number (see Section 8.4.1) * a version number (see Section 8.4.1)
* a sequence number (see Section 8.4.2) * a sequence number (see Section 8.4.2)
* a reference URI (see Section 8.4.3) * a reference URI (see Section 8.4.3)
* a common structure with information that is shared between command * a common structure with information that is shared between command
sequences (see Section 8.4.5) sequences (see Section 8.4.5)
* one or more lists of commands that the Recipient should perform * one or more lists of commands that the Recipient should perform
(see Section 8.4.6) (see Section 8.4.6)
* a reference to the full manifest (see Section 8.4.3) * a reference to the full manifest (see Section 8.4.3)
* human-readable text describing the manifest found in the * human-readable text describing the manifest found in the
SUIT_Envelope (see Section 8.4.4) SUIT_Envelope (see Section 8.4.4)
skipping to change at page 38, line 9 skipping to change at page 38, line 9
reference the object with a single pointer and traverse it without reference the object with a single pointer and traverse it without
understanding the contents. This is important for modularization and understanding the contents. This is important for modularization and
division of responsibility within a pull parser. The same division of responsibility within a pull parser. The same
consideration does not apply to Directives because those elements are consideration does not apply to Directives because those elements are
invoked with their arguments immediately. invoked with their arguments immediately.
8.4.8.1. CBOR PEN UUID Namespace Identifier 8.4.8.1. CBOR PEN UUID Namespace Identifier
The CBOR PEN UUID Namespace Identifier is constructed as follows: The CBOR PEN UUID Namespace Identifier is constructed as follows:
It uses the OID Namespace as a starting point, then uses the CBOR OID It uses the OID Namespace as a starting point, then uses the CBOR
encoding for the IANA PEN OID (1.3.6.1.4.1): absolute OID encoding for the IANA PEN OID (1.3.6.1.4.1):
D8 6F # tag(111) D8 6F # tag(111)
45 # bytes(5) 45 # bytes(5)
# Absolute OID encoding of IANA Private Enterprise Number: # Absolute OID encoding of IANA Private Enterprise Number:
# 1.3. 6. 1. 4. 1 # 1.3. 6. 1. 4. 1
2B 06 01 04 01 # X.690 Clause 8.19 2B 06 01 04 01 # X.690 Clause 8.19
Computing a type 5 UUID from these produces: Computing a type 5 UUID from these produces:
NAMESPACE_CBOR_PEN = UUID5(NAMESPACE_OID, h'D86F452B06010401') NAMESPACE_CBOR_PEN = UUID5(NAMESPACE_OID, h'D86F452B06010401')
skipping to change at page 55, line 43 skipping to change at page 55, line 43
+-------+----------------------------+---------------+ +-------+----------------------------+---------------+
Table 11 Table 11
12. Security Considerations 12. Security Considerations
This document is about a manifest format protecting and describing This document is about a manifest format protecting and describing
how to retrieve, install, and invoke firmware images and as such it how to retrieve, install, and invoke firmware images and as such it
is part of a larger solution for delivering firmware updates to IoT is part of a larger solution for delivering firmware updates to IoT
devices. A detailed security treatment can be found in the devices. A detailed security treatment can be found in the
architecture [RFC9019] and in the information model architecture [RFC9019] and in the information model [RFC9124]
[I-D.ietf-suit-information-model] documents. documents.
13. Acknowledgements 13. Acknowledgements
We would like to thank the following persons for their support in We would like to thank the following persons for their support in
designing this mechanism: designing this mechanism:
* Milosch Meriac * Milosch Meriac
* Geraint Luff * Geraint Luff
* Dan Ros * Dan Ros
skipping to change at page 56, line 32 skipping to change at page 56, line 32
* Michael Richardson * Michael Richardson
* David Brown * David Brown
* Emmanuel Baccelli * Emmanuel Baccelli
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-suit-information-model]
Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest
Information Model for Firmware Updates in IoT Devices",
Work in Progress, Internet-Draft, draft-ietf-suit-
information-model-13, 8 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-suit-
information-model-13.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 57, line 23 skipping to change at page 57, line 14
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things", Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021, RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/info/rfc9019>. <https://www.rfc-editor.org/info/rfc9019>.
[RFC9124] Moran, B., Tschofenig, H., and H. Birkholz, "A Manifest
Information Model for Firmware Updates in Internet of
Things (IoT) Devices", RFC 9124, DOI 10.17487/RFC9124,
January 2022, <https://www.rfc-editor.org/info/rfc9124>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-cbor-tags-oid] [I-D.ietf-cbor-tags-oid]
Bormann, C., "Concise Binary Object Representation (CBOR) Bormann, C., "Concise Binary Object Representation (CBOR)
Tags for Object Identifiers", Work in Progress, Internet- Tags for Object Identifiers", Work in Progress, Internet-
Draft, draft-ietf-cbor-tags-oid-08, 21 May 2021, Draft, draft-ietf-cbor-tags-oid-08, 21 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid- <https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-
08.txt>. 08.txt>.
[I-D.ietf-cose-hash-algs] [I-D.ietf-cose-hash-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", Work in Progress, Internet-Draft, draft- Hash Algorithms", Work in Progress, Internet-Draft, draft-
ietf-cose-hash-algs-09, 14 September 2020, ietf-cose-hash-algs-09, 14 September 2020,
<https://www.ietf.org/archive/id/draft-ietf-cose-hash- <https://www.ietf.org/archive/id/draft-ietf-cose-hash-
algs-09.txt>. algs-09.txt>.
[I-D.ietf-suit-firmware-encryption] [I-D.ietf-suit-firmware-encryption]
Tschofenig, H., Housley, R., and B. Moran, "Firmware Tschofenig, H., Housley, R., and B. Moran, "Firmware
Encryption with SUIT Manifests", Work in Progress, Encryption with SUIT Manifests", Work in Progress,
Internet-Draft, draft-ietf-suit-firmware-encryption-02, 25 Internet-Draft, draft-ietf-suit-firmware-encryption-04, 20
October 2021, <https://www.ietf.org/archive/id/draft-ietf- April 2022, <https://www.ietf.org/archive/id/draft-ietf-
suit-firmware-encryption-02.txt>. suit-firmware-encryption-04.txt>.
[I-D.ietf-suit-report]
Moran, B. and H. Birkholz, "Secure Reporting of Update
Status", Work in Progress, Internet-Draft, draft-ietf-
suit-report-01, 12 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-suit-report-
01.txt>.
[I-D.ietf-suit-trust-domains]
Moran, B., "SUIT Manifest Extensions for Multiple Trust
Domains", Work in Progress, Internet-Draft, draft-ietf-
suit-trust-domains-00, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-suit-trust-
domains-00.txt>.
[I-D.ietf-suit-update-management]
Moran, B., "Update Management Extensions for Software
Updates for Internet of Things (SUIT) Manifests", Work in
Progress, Internet-Draft, draft-ietf-suit-update-
management-00, 7 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-suit-update-
management-00.txt>.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-15, 12 July 2021, ietf-teep-architecture-17, 19 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-teep- <https://www.ietf.org/archive/id/draft-ietf-teep-
architecture-15.txt>. architecture-17.txt>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[YAML] "YAML Ain't Markup Language", 2020, <https://yaml.org/>. [YAML] "YAML Ain't Markup Language", 2020, <https://yaml.org/>.
Appendix A. A. Full CDDL Appendix A. A. Full CDDL
In order to create a valid SUIT Manifest document the structure of In order to create a valid SUIT Manifest document the structure of
the corresponding CBOR message MUST adhere to the following CDDL data the corresponding CBOR message MUST adhere to the following CDDL data
definition. definition.
To be valid, the following CDDL MUST have the COSE CDDL appended to To be valid, the following CDDL MUST have the COSE CDDL appended to
it. The COSE CDDL can be obtained by following the directions in it. The COSE CDDL can be obtained by following the directions in
[RFC8152], section 1.4. [RFC8152], Section 1.3.
SUIT_Envelope_Tagged = #6.107(SUIT_Envelope) SUIT_Envelope_Tagged = #6.107(SUIT_Envelope)
SUIT_Envelope = { SUIT_Envelope = {
? suit-delegation => bstr .cbor SUIT_Delegation,
suit-authentication-wrapper => bstr .cbor SUIT_Authentication, suit-authentication-wrapper => bstr .cbor SUIT_Authentication,
suit-manifest => bstr .cbor SUIT_Manifest, suit-manifest => bstr .cbor SUIT_Manifest,
SUIT_Severable_Manifest_Members, SUIT_Severable_Manifest_Members,
* SUIT_Integrated_Payload, * SUIT_Integrated_Payload,
* $$SUIT_Envelope_Extensions, * $$SUIT_Envelope_Extensions,
* (int => bstr) * (int => bstr)
} }
SUIT_Authentication = [ SUIT_Authentication = [
bstr .cbor SUIT_Digest, bstr .cbor SUIT_Digest,
* bstr .cbor SUIT_Authentication_Block * bstr .cbor SUIT_Authentication_Block
] ]
SUIT_Digest = [ SUIT_Digest = [
suit-digest-algorithm-id : suit-cose-hash-algs, suit-digest-algorithm-id : suit-cose-hash-algs,
suit-digest-bytes : bstr, suit-digest-bytes : bstr,
skipping to change at page 59, line 30 skipping to change at page 60, line 4
} }
SUIT_Unseverable_Members = ( SUIT_Unseverable_Members = (
? suit-validate => bstr .cbor SUIT_Command_Sequence, ? suit-validate => bstr .cbor SUIT_Command_Sequence,
? suit-load => bstr .cbor SUIT_Command_Sequence, ? suit-load => bstr .cbor SUIT_Command_Sequence,
? suit-run => bstr .cbor SUIT_Command_Sequence, ? suit-run => bstr .cbor SUIT_Command_Sequence,
* $$unseverable-manifest-member-extensions, * $$unseverable-manifest-member-extensions,
) )
SUIT_Severable_Members_Choice = ( SUIT_Severable_Members_Choice = (
? suit-payload-fetch => \ ? suit-payload-fetch =>
bstr .cbor SUIT_Command_Sequence / SUIT_Digest, bstr .cbor SUIT_Command_Sequence / SUIT_Digest,
? suit-install => bstr .cbor SUIT_Command_Sequence / SUIT_Digest, ? suit-install => bstr .cbor SUIT_Command_Sequence / SUIT_Digest,
? suit-text => bstr .cbor SUIT_Command_Sequence / SUIT_Digest, ? suit-text => bstr .cbor SUIT_Command_Sequence / SUIT_Digest,
* $$severable-manifest-members-choice-extensions * $$severable-manifest-members-choice-extensions
) )
SUIT_Common = { SUIT_Common = {
? suit-components => SUIT_Components, ? suit-components => SUIT_Components,
? suit-common-sequence => bstr .cbor SUIT_Common_Sequence, ? suit-common-sequence => bstr .cbor SUIT_Common_Sequence,
* $$SUIT_Common-extensions, * $$SUIT_Common-extensions,
 End of changes. 33 change blocks. 
68 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/