jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-suit-information-model

Commentary: Minor clarification on the point of manifest validation
Paragraph (version A):
A monotonically increasing sequence number to prevent malicious
actors from reverting a firmware update against the policies of the
relevant authority.
Paragraph (version B):
A monotonically increasing (unsigned) sequence number to prevent
malicious actors from reverting a firmware update against the
policies of the relevant authority.  This number must not wrap
around.
Paragraph (version A):
The Class ID UUID should use the Vendor ID as the name space
identifier.  Other options include version 1 and 4 UUIDs.  Classes
may be more fine-grained granular than is required to identify
firmware compatibility.  Classes must not be less granular than is
required to identify firmware compatibility.  Devices may have
multiple Class IDs.
Paragraph (version B):
The Class ID UUID should use the Vendor ID as the name space
identifier.  Classes may be more fine-grained granular than is
required to identify firmware compatibility.  Classes must not be
less granular than is required to identify firmware compatibility.
Devices may have multiple Class IDs.
Paragraph (version B):
Implemented by: Hardware-assisted isolation technologies, which are
outside the scope of the manifest format.
Paragraph (version B):
Implemented by: Secure storage technology, which is a system design/
implementation aspect outside the scope of the manifest format.
Paragraph (version B):
Implemented by: Testing infrastructure.  While outside the scope of
the manifest format, proper testing of low-level software is
essential for avoiding unnecessary down-time or worse situations.
Paragraph (version B):
Implemented by: Physical and network security for protecting the
environment where firmware updates are prepared to avoid unauthorized
access to this infrastructure.
Paragraph (version B):
Implemented by: Proper system design with sufficient resources and
implementation avoiding TOCTOU attacks.
Draft: draft-ietf-suit-information-model

Commentary: Clarify that delegation chains are lists of authentication tokens where each token provides credentials for the next until the final token which provides the credentials for the manifest . 
   wrote :
Paragraph (version A):
The delegation chain offers enhanced authorization functionality via
authorization tokens.  Each token itself is protected and does not
require another layer of protection.  Because the delegation chain is
needed to verify the signature, it must be placed in the Manifest
Envelope, rather than the Manifest.
Paragraph (version B):
The delegation chain offers enhanced authorization functionality via
authorization tokens, such as CBOR Web Tokens RFC8392 with Proof of
Possession Key Semantics RFC8747.  Each token itself is protected and
does not require another layer of protection.  Each authorization
token typically includes a public key or a public key fingerprint,
however this is dependent on the tokens used.  Each token MAY include
additional metadata, such as key usage information.  Because the
delegation chain is needed to verify the signature, it must be placed
in the Manifest Envelope, rather than the Manifest.
Paragraph (version B):
The first token in any delegation chain MUST be autheticated by the
recipient's Trust Anchor.  Each subsequent token MUST be
authenticated using the previous token.  This allows a recipient to
discard each antecedent token after it has authenticated the
subsequent token.  The final token MUST enable authentication of the
manifest.  More than one delegation chain MAY be used if more than
one signature is used.  Note that no restriction is placed on the
encoding order of these tokens, the order of elements is logical
only.
Draft: draft-ietf-suit-information-model

Commentary: Explain why a UUID or PEN is preferred for vendor ID Explain why a UUID is preferred over free text for firmware compatibility matching 
   wrote : 
   wrote : 
 Fixed in
Paragraph (version B):
Fixed-size binary identifiers are preferred because they are simple
to match, unambiguous in length, explicitly non-parsable, and require
no issuing authority.  Guaranteed unique integers are preferred
because they are small and simple to match, however they may not be
fixed length and they may require an issuing authority to ensure
uniqueness.  Free-form text is avoided because it is variable-length,
prone to error, and often requires parsing outside the scope of the
manifest serialization.
Paragraph (version A):
Class ID is not intended to be a human-readable element.  It is
intended for binary match/mismatch comparison only.
Paragraph (version B):
Class ID is not intended to be a human-readable element.  It is
intended for binary match/mismatch comparison only.  A manifest
serialization SHOULD NOT permit free-form text content to be used for
Class ID.  A fixed-size binary identifier SHOULD be used.
Paragraph (version B):
Some organizations desire to keep the same product naming across
multiple, incompatible hardware revisions for ease of user
experience.  If this naming is propagated into the firmware, then
matching a specific hardware version becomes a challenge.  An opaque,
non-readable binary identifier has no naming implications and so is
more likely to be usable for distinguishing among incompatible device
groupings, regardless of naming.
Paragraph (version B):
Fixed-size binary identifiers are preferred because they are simple
to match, unambiguous in length, opaque and free from naming
implications, and explicitly non-parsable.  Free-form text is avoided
because it is variable-length, prone to error, often requires parsing
outside the scope of the manifest serialization, and may be
homogenized across incompatible device groupings.
Paragraph (version B):
Textual information pertaining to the update described by the
manifest.  This information is for human consumption only.  It MUST
NOT be the basis of any decision made by the recipient.
Paragraph (version B):
As a Device Operator, I want to understand what an update will do and
to which devices it applies so that I can make informed choices about
which updates to apply, when to apply them, and which devices should
be updated.
Paragraph (version B):
It MUST be possible for a Device Operator to determine what a
manifest will do and which devices will accept it prior to
distribution.
Draft: draft-ietf-suit-information-model

Commentary: Clarified several points : Remote secure clocks require authentication . This was assumed when using the " correctness guarantees " however that was not sufficiently clear . Risks associated with using a flawed clock for manifest expiry . Secure clock can be used for key expiry . Risk of flawed clock for key expiry is identical to not having key rotation . 
   wrote : 
 We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed .
Paragraph (version A):
Secure time and secure clock refer to a set of requirements on time
sources.  For local time sources, this primarily means that the clock
must be monotonically increasing, including across power cycles,
firmware updates, etc.  For remote time sources, the provided time
must be guaranteed to be correct to within some predetermined bounds,
whenever the time source is accessible.
Paragraph (version B):
Secure time and secure clock refer to a set of requirements on time
sources.  For local time sources, this primarily means that the clock
must be monotonically increasing, including across power cycles,
firmware updates, etc.  For remote time sources, the provided time
must be both authenticated and guaranteed to be correct to within
some predetermined bounds, whenever the time source is accessible.
Paragraph (version B):
Implements: req-use-delegation,
Paragraph (version B):
Mitigated by: req-sec-key-protection,
Paragraph (version B):
If a device has a flawed time source (either local or remote), an old
update can be deployed as new.
Paragraph (version B):
Cryptographic keys for signing/authenticating manifests SHOULD be
replaced from time to time.  Because it is difficult and risky to
replace a Trust Anchor, keys used for signing updates SHOULD be
delegates of that Trust Anchor.
Paragraph (version B):
If key expiration is performed based on time, then a secure clock is
needed.  If the time source used by a recipient to check for
expiration is flawed, an old signing key can be used as current,
which compounds threat-key-exposure.
Draft: draft-ietf-suit-information-model

Commentary: Section 4 We should probably mention the URI security considerations ( RFC 3986 ) somewhere , as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself , when dereferencing URIs . 
 Addressed in 
 Addressed in draft - ietf - suit - information - model-11 
 It might also be worth reiterating the topic that came up during one of the other review threads : firmware update is by definition remote code execution , so if you trust an entity to provide your firmware , you are trusting them to do the right thing . Many classes of attack involving malicious or modified payloads then become irrelevant , so we are left with just needing to verify that it did come from a trusted party and is not going backwards , topics that are covered quite well already ( including TOCTOU ) . 
 Addressed in 
 Addressed in draft - ietf - suit - information - model-11
Paragraph (version B):
Note that it is worthwhile to recall that a firmware update is, by
definition, remote code execution.  Hence, if a device is configured
to trust an entity to provide firmware, it trusts this entity to do
the "right thing".  Many classes of attacks can be mitigated by
verifying that a firmware update came from a trusted party and that
no rollback is taking place.  However, if the trusted entity has been
compromised and distributes attacker-provided firmware to devices
then the possibilities for deference are limited.
Paragraph (version A):
The location where a target should find a payload MUST be
authenticated.
Paragraph (version B):
The location where a target should find a payload MUST be
authenticated.  Remote resources need to receive an equal amount of
cryptographic protection as the manifest itself, when dereferencing
URIs.  The security considerations of Uniform Resource Identifiers
(URIs) are applicable RFC3986.
Draft: draft-ietf-suit-information-model

Commentary: This pull request merges the submitted v01 version into the master branch .
Paragraph (version A):
As a Device Operator, I want to ensure the quality of a firmware
update before installing it, so that I can ensure interoperability of
all devices in my product family.  I want to restrict the ability to
make changes to my firmware to certain operations only.
Paragraph (version B):
As a Device Operator, I want to ensure the quality of a firmware
update before installing it, so that I can ensure interoperability of
all devices in my product family.  I want to restrict the ability to
make changes to my devices to require my express approval.