Draft: draft-ietf-suit-information-model

Commentary: Change from MANDATORY to REQUIRED in line with RFC2119 . Introduce a white - labelling example for Vendor ID + Class ID Change to Manifest Element : Signature ; allowing a manifest sent via an authenticated channel opens a secondary threat . Disallow this use - case explicitly , with justification . Define size limitation for integrated payloads . 
 Does it make sense to mention that any data obtained by decoding the manifest must also be protected from tampering ? 
 I think that makes perfect sense .
Paragraph (version A):
Because the information model covers a wide range of user stories and
a wide range of threats, not all information elements apply to all
scenarios.  As a result, various information elements could be
considered optional to implement and optional to use, depending on
which threats exist in a particular domain of application and which
user stories are required.  Elements marked as mandatory provide
baseline security and usability properties that are expected to be
required for most applications.  Those elements are mandatory to
implement and mandatory to use.  Elements marked as recommended
provide important security or usability properties that are needed on
most devices.  Elements marked as optional enable security or
usability properties that are useful in some applications.
Paragraph (version B):
Because the information model covers a wide range of user stories and
a wide range of threats, not all information elements apply to all
scenarios.  As a result, various information elements could be
considered optional to implement and optional to use, depending on
which threats exist in a particular domain of application and which
user stories are required.  Elements marked as REQUIRED provide
baseline security and usability properties that are expected to be
required for most applications.  Those elements are REQUIRED to
implement and REQUIRED to use.  Elements marked as recommended
provide important security or usability properties that are needed on
most devices.  Elements marked as optional enable security or
usability properties that are useful in some applications.
Paragraph (version A):
This element is MANDATORY and MUST be present in order to allow
devices to identify the version of the manifest data model that is in
use.
Paragraph (version B):
This element is REQUIRED and MUST be present in order to allow
devices to identify the version of the manifest data model that is in
use.
Paragraph (version A):
This element is MANDATORY and is necessary to prevent malicious
actors from reverting a firmware update against the policies of the
relevant authority.
Paragraph (version B):
This element is REQUIRED and is necessary to prevent malicious actors
from reverting a firmware update against the policies of the relevant
authority.
Paragraph (version B):
The product will match against each of these class IDs.  If Vendor A
and Vendor B provide different components for the device, the
implementor MAY choose to make ID matching scoped to each component.
Then, the vendorIdA, classIdA match the component ID supplied by
Vendor A, and the vendorIdB, classIdB match the component ID supplied
by Vendor B.
Paragraph (version A):
This element is MANDATORY and MUST be present to enable devices to
decode payloads correctly.
Paragraph (version B):
This element is REQUIRED and MUST be present to enable devices to
decode payloads correctly.
Paragraph (version A):
This element is MANDATORY and MUST be present to enable devices to
store payloads to the correct location.
Paragraph (version B):
This element is REQUIRED and MUST be present to enable devices to
store payloads to the correct location.
Paragraph (version A):
This element is MANDATORY to implement and fundamentally necessary to
ensure the authenticity and integrity of the payload.  Support for
more than one digest is OPTIONAL to implement in a recipient device.
Paragraph (version B):
This element is REQUIRED to implement and fundamentally necessary to
ensure the authenticity and integrity of the payload.  Support for
more than one digest is OPTIONAL to implement in a recipient device.
Paragraph (version A):
This element is MANDATORY and informs the target device how big of a
payload to expect.  Without it, devices are exposed to some classes
of denial of service attack.
Paragraph (version B):
This element is REQUIRED and informs the target device how big of a
payload to expect.  Without it, devices are exposed to some classes
of denial of service attack.
Paragraph (version A):
This element is MANDATORY and represents the foundation of all
security properties of the manifest.  There are two exceptions to
this requirement: 1) if the manifest is authenticated by a second
manifest as a dependency and 2) if the manifest is authenticated by
channel security and contains only channel information (such as
URIs).
Paragraph (version B):
This element is REQUIRED in non-dependency manifests and represents
the foundation of all security properties of the manifest.  Manifests
which are included as dependencies by another manifest SHOULD include
a signature so that the recipient can distinguish between different
actors with different permissions.
Paragraph (version B):
A manifest MUST NOT be considered authenticated by channel security
even if it contains only channel information (such as URIs).  If the
authenticated remote or channel were compromised, the threat actor
could induce recipients to queries traffic over any accessible
network.  Lightweight authentication with pre-existing relationships
SHOULD be done with MAC.
Paragraph (version A):
This element is MANDATORY to use in deployments that include both
multiple authorities and multiple payloads.
Paragraph (version B):
This element is REQUIRED to use in deployments that include both
multiple authorities and multiple payloads.
Paragraph (version A):
This element is MANDATORY to use for encrypted payloads,
Paragraph (version B):
This element is REQUIRED to use for encrypted payloads,
Paragraph (version B):
If an attacker can modify a manifest after it is authenticated (Time
Of Check) but before it is used (Time Of Use), then the attacker can
place any content whatsoever in the manifest.
Paragraph (version A):
Cryptographic keys for signing manifests SHOULD be stored in a manner
that is inaccessible to networked devices, for example in an HSM, or
an air-gapped computer.  This protects against an attacker obtaining
the keys.
Paragraph (version B):
Cryptographic keys for signing/authenticating manifests SHOULD be
stored in a manner that is inaccessible to networked devices, for
example in an HSM, or an air-gapped computer.  This protects against
an attacker obtaining the keys.
Paragraph (version B):
Both the manifest and any data extracted from it MUST be held
immutable between its authenticity verification (time of check) and
its use (time of use).  To make this guarantee, the manifest MUST fit
within an internal memory or a secure memory, such as encrypted
memory.  The recipient SHOULD defend the manifest from tampering by
code or hardware resident in the recipient, for example other
processes or debuggers.
Paragraph (version B):
If an application requires that the manifest is verified before
storing it, then this means the manifest MUST fit in RAM.
Paragraph (version B):
Small payloads may include, for example, wrapped encryption keys,
encoded configuration, public keys, RFC8392 CBOR Web Tokens, or X.509
certificates.
Paragraph (version A):
N.B.  If a manifest is delivered over an authenticated channel and
that manifest contains only override information for which the remote
is authorised, then it can be considered authenticated by the channel
authentication.
Paragraph (version B):
Integrated payloads may include, for example, wrapped encryption
keys, encoded configuration, public keys, RFC8392 CBOR Web Tokens, or
X.509 certificates.
Paragraph (version B):
When an integrated payload is provided, this increases the size of
the manifest.  Manifest size can cause several processing and storage
concerns that require careful consideration.  The payload can prevent
the whole manifest from being contained in a single network packet,
which can cause fragmentation and the loss of portions of the
manifest in lossy networks.  This causes the need for reassembly and
retransmission logic.  The manifest must be held immutable between
verification and processing (see req-sec-mfst-const), so a larger
manifest will consume more memory with immutability guarantees, for
example internal RAM or NVRAM, or external secure memory.  If the
manifest exceeds the available immutable memory, then it must be
processed modularly, evaluating each of: delegation chains, the
security container, and the actual manifest, which includes verifying
the integrated payload.  If the security model calls for downloading
the manifest and validating it before storing to NVRAM in order to
prevent wear to NVRAM and energy expenditure in NVRAM, then either
increasing memory allocated to manifest storage or modular processing
of the received manifest may be required.  While the manifest has
been organised to enable this type of processing, it creates
additional complexity in the parser.  If the manifest is stored in
NVRAM prior to processing, the integrated payload may cause the
manifest to exceed the available storage.  Because the manifest is
received prior to validation of applicability, authority, or
correctness, integrated payloads cause the recipient to expend
network bandwidth and energy that may not be required if the manifest
is discarded and these costs vary with the size of the integrated
payload.
Paragraph (version B):
See also: req-sec-mfst-const.