Draft: draft-ietf-suit-architecture

Commentary: Well , hopefully , at least . Trying to keep the easy stuff out of my ballot .
Trust Anchor: A trust anchor, as defined in RFC6024, represents an
authoritative entity via a public key and associated data.  The
public key is used to verify digital signatures, and the
associated data is used to constrain the types of information for
which the trust anchor is authoritative.
Device Operator: The device operator is responsible for the day-
to-day operation of a fleet of IoT devices.  Customers of IoT
devices, as the owners of IoT devices - such as enterprise
customers or end users, interact with their IoT devices indirectly
through the device operator via web or smart phone apps.
Device Operator: The device operator is responsible for the day-
to-day operation of a fleet of IoT devices.  Customers of IoT
devices, as the owners of IoT devices - such as enterprise
customers or end users - interact with their IoT devices
indirectly through the device operator via web or smart phone
apps.
Firmware Consumer: The firmware consumer is the recipient of the
firmware image and the manifest.  It is responsible for parsing
and verifying the received manifest and for storing the obtained
firmware image.  The firmware consumer plays the role of the
update component on the IoT device typically running in the
application firmware.  It interacts with the firmware server and
with the status tracker client (locally).
Firmware Consumer: The firmware consumer is the recipient of the
firmware image and the manifest.  It is responsible for parsing
and verifying the received manifest and for storing the obtained
firmware image.  The firmware consumer plays the role of the
update component on the IoT device, typically running in the
application firmware.  It interacts with the firmware server and
with the status tracker client (locally).
the Internet protocol stack for firmware downloads.  Because
firmware images are often multiple kilobytes, sometimes exceeding
one hundred kilobytes, in size for low end IoT devices and even
several megabytes large for IoT devices running full-fledged
operating systems like Linux, the protocol mechanism for
retrieving these images needs to offer features like congestion
control, flow control, fragmentation and reassembly, and
mechanisms to resume interrupted or corrupted transfers.
the Internet protocol stack for firmware downloads.  Because
firmware images are often multiple kilobytes, sometimes exceeding
one hundred kilobytes, for low-end IoT devices and even several
megabytes for IoT devices running full-fledged operating systems
like Linux, the protocol mechanism for retrieving these images
needs to offer features like congestion control, flow control,
fragmentation and reassembly, and mechanisms to resume interrupted
or corrupted transfers.
With Server-initiated updates the server-side component of the
status tracker learns about a new firmware version and determines
which devices qualify for a firmware update.  Once the relevant
devices have been selected, the status tracker pushes images and
manifests to the firmware consumer.  Server-initiated updates are
important because they allow a quick response time.  Note that the
client-side status tracker needs to be reachable by the server-
side component.  This may require devices to keep reachability
information on the server-side up-to-date and state at NATs and
stateful packet filtering firewalls alive.
With Server-initiated updates the server-side component of the
status tracker learns about a new firmware version and determines
which devices qualify for a firmware update.  Once the relevant
devices have been selected, the status tracker informs these
devices and the firmware consumers obtain those images and
manifests.  Server-initiated updates are important because they
allow a quick response time.  Note that in this mode the client-
side status tracker needs to be reachable by the server-side
component.  This may require devices to keep reachability
information on the server-side up-to-date and state at NATs and
stateful packet filtering firewalls alive.
Once the device operator triggers update via the status tracker, it
will keep track of the update process on the device.  This allows the
device operator to know what devices have received an update and
which of them are still pending an update.
Once the device operator triggers an update via the status tracker,
it will keep track of the update process on the device.  This allows
the device operator to know what devices have received an update and
which of them are still pending an update.
Firmware images and manifests may be conveyed as a bundle or
detached.  The manifest must support both approaches.
Firmware images and manifests may be conveyed as a bundle or
detached.  The manifest format must support both approaches.
architecture describes the steps for getting the firmware image and
the manifest from the author to the firmware consumer on the IoT
device.  Once the firmware consumer has retrieved and successfully
processed the manifest and the firmware image it needs to invoke the
new firmware image.  This is managed in many different ways,
depending on the type of device, but it typically involves halting
the current version of the firmware, handing control over to a
firmware with a higher privilege/trust level (the firmware verifier)
verifying the new firmware's authenticity & integrity, and then
invoking it.
architecture describes the steps for getting the firmware image and
the manifest from the author to the firmware consumer on the IoT
device.  Once the firmware consumer has retrieved and successfully
processed the manifest and the firmware image it needs to invoke the
new firmware image.  This is managed in many different ways,
depending on the type of device, but it typically involves halting
the current version of the firmware, handing control over to a
firmware with a higher privilege/trust level (the firmware verifier),
verifying the new firmware's authenticity & integrity, and then
invoking it.
Ability to expose boot process-related data to the application
firmware (such as to the status tracker).  This allows sharing
information about the current firmware version, and the status of
the firmware update process and whether errors have occurred.
There must be an ability to expose boot process-related data to
the application firmware (such as to the status tracker).  This
allows sharing information about the current firmware version, and
the status of the firmware update process and whether errors have
occurred.
In order for a firmware consumer to apply an update, it has to make
several decisions using manifest-provided information and data
available on the device itself.  For more detailed information and a
longer list of information elements in the manifest consult the
information model specification I-D.ietf-suit-information-model,
which offers justifications for each element, and the manifest, see
I-D.ietf-suit-manifest, for details about how this information is
included in the manifest.
In order for a firmware consumer to apply an update, it has to make
several decisions using manifest-provided information and data
available on the device itself.  For more detailed information and a
longer list of information elements in the manifest consult the
information model specification I-D.ietf-suit-information-model,
which offers justifications for each element, and the manifest
specification I-D.ietf-suit-manifest for details about how this
information is included in the manifest.
Keeping the code size and complexity of a manifest parsers small is
important for constrained IoT devices.  Since the manifest parsing
code may also be used by the bootloader it is part of the trusted
computing base.
Keeping the code size and complexity of a manifest parsers small is
important for constrained IoT devices.  Since the manifest parsing
code may also be used by the bootloader it can be part of the trusted
computing base.
Authentication ensures that the device can cryptographically
identify the author(s) creating firmware images and manifests.
Authenticated identities may be used as input to the authorization
process.  Not all entities creating and signing manifests have the
same permissions.  A device needs to determine whether the
requested action is indeed covered by the permission of the party
that signed the manifest.  Informing the device about the
permissions of the different parties also happens in an out-of-
band fashion and is also a duty of the Trust Provisioning
Authority.
Authentication ensures that the device can cryptographically
identify the author(s) creating firmware images and manifests.
Authenticated identities may be used as input to the authorization
process.  Not all entities creating and signing manifests have the
same permissions.  A device needs to determine whether the
requested action is indeed covered by the permission of the party
that signed the manifest.  Informing the device about the
permissions of the different parties also happens in an out-of-
band fashion and is a duty of the Trust Provisioning Authority.
When a device obtains a monolithic firmware image from a single
author without any additional approval steps then the authorization
flow is relatively simple.  There are, however, other cases where
more complex policy decisions need to be made before updating a
device.
When a device obtains a monolithic firmware image from a single
author without any additional approval steps, the authorization flow
is relatively simple.  There are, however, other cases where more
complex policy decisions need to be made before updating a device.