jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rats-architecture

Commentary: * * Section 12.1.2.1 . Would it be more precise to say : OLD The degree of protection afforded to this key material can vary by device , based upon considerations as to a cost / benefit evaluation of the intended function of the device . NEW The degree of protection afforded to this key material can vary by the intended function of the device and the specific practices of the device manufacturer or integrator .
Paragraph (version A):
The degree of protection afforded to this key material can vary by
device, based upon considerations as to a cost/benefit evaluation of
the intended function of the device.  The confidentiality protection
is fundamentally based upon some amount of physical protection: while
encryption is often used to provide confidentiality when a key is
conveyed across a factory, where the attestation key is created or
applied, it must be available in an unencrypted form.  The physical
protection can therefore vary from situations where the key is
unencrypted only within carefully controlled secure enclaves within
silicon, to situations where an entire facility is considered secure,
by the simple means of locked doors and limited access.
Paragraph (version B):
The degree of protection afforded to this key material can vary by
the intended function of the device and the specific practices of the
device manufacturer or integrator.  The confidentiality protection is
fundamentally based upon some amount of physical protection: while
encryption is often used to provide confidentiality when a key is
conveyed across a factory, where the attestation key is created or
applied, it must be available in an unencrypted form.  The physical
protection can therefore vary from situations where the key is
unencrypted only within carefully controlled secure enclaves within
silicon, to situations where an entire facility is considered secure,
by the simple means of locked doors and limited access.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 In we now explicitly say that " confidentiality protection of Evidence and Attestation Results " is required in some form . In we now explicitly say that " Many Claims in Evidence , many Claims in Attestation Results , and   potentially contain Personally Identifying Information ( PII ) " . See my point already ? Maybe protection of   is " technically out - of - scope " , but expressing this side by side makes a curious impression to me .
Paragraph (version A):
Evidence and Attestation Results are expected to be integrity
protected (i.e., either via signing or a secure channel) and
optionally might be confidentiality protected via encryption.  If
there isn't confidentiality protection of Evidence and Attestation
Results, the underlying conveyance protocol should provide these
protections.
Paragraph (version B):
Conceptual messages carrying sensitive or confidential information
are expected to be integrity protected (i.e., either via signing or a
secure channel) and optionally might be confidentiality protected via
encryption.  If there isn't confidentiality protection of conceptual
messages themselves, the underlying conveyance protocol should
provide these protections.
Draft: draft-ietf-rats-architecture

Commentary: Reworded paragraph following the word ' vouch ' to better explain the how Endorsements affect Verifier 's trust in the Attester . 
 ` 
 " ... vouch for the Attester 's ability to securely generate Evidence by asserting endorsement claims regarding the ways in which attestation keys are protected . Consequently , the  's key material is stored in the Verifier 's trust anchor store so that Endorsements can be included in the Verifier 's appraisal . " 
 This proposal is definitely a step into the right direction . We should not overload this , but I think this is appropriately improved . 
 " attestation keys are protected " is too narrow 
 See PR
Paragraph (version A):
In a typical solution, a Verifier comes to trust an Attester
indirectly by having an Endorser (such as a manufacturer) vouch for
the Attester's ability to securely generate Evidence, in which case
the Endorser's key material is stored in the Verifier's trust anchor
store.
Paragraph (version B):
In a typical solution, a Verifier comes to trust an Attester
indirectly by having an Endorser (such as a manufacturer) vouch for
the Attester's ability to securely generate Evidence through
Endorsements (see endorsements).  Endorsements might describe the
ways in which the Attester resists attack, protects secrets and
measures Target Environments.  Consequently, the Endorser's key
material is stored in the Verifier's trust anchor store so that
Endorsements can be authenticated and used in the Verifier's
appraisal process.
Draft: draft-ietf-rats-architecture

Commentary: maybe unclear if this was what was intended 
 massaged the change a bit to retain the previous statement better 
 ` I 'm not convinced this analogy is helpful . Yes , it conveys the need for detailed information but it also immediately suggests   might include PII or privacy sensitive identifiers . 
 I agree that the analogy to physical passports is misleading . The paragraph tries to justify AR as being detailed and privacy sensitive then in the next paragraph tries to describe them as not needing to be too specific ; " Unlike Evidence , which is often very device- and vendor - specific ,   can be vendor - neutral , if the Verifier has a way to generate vendor - agnostic information based on the appraisal of vendor - specific information in Evidence . " It is sufficient to say that both Evidence and   can contain privacy sensitive content . The Attester may rely on the Verifier to obfuscate privacy sensitive Claims that were shared as part of Evidence . 
 It should be clear that appraising Evidence involves various procedures that are part of the appraisal and that these can be quite resource intensive ( like creating a passport ) , in contrast to   that are intended to be easily digestible and universal understood ( like using a passport ) ! 
 add , " contain privacy sensitive information as discussed in section { Privacy } "
Paragraph (version A):
Thus, Attestation Results often need to include detailed information
about the Attester, for use by Relying Parties, much like physical
passports and drivers licenses include personal information such as
name and date of birth.  Unlike Evidence, which is often very device-
and vendor-specific, Attestation Results can be vendor-neutral, if
the Verifier has a way to generate vendor-agnostic information based
on the appraisal of vendor-specific information in Evidence.  This
allows a Relying Party's appraisal policy to be simpler, potentially
based on standard ways of expressing the information, while still
allowing interoperability with heterogeneous devices.
Paragraph (version B):
Thus, Attestation Results can contain detailed information about an
Attester, which can include privacy sensitive information as
discussed in section privacy-considerations.  Unlike Evidence, which
is often very device- and vendor-specific, Attestation Results can be
vendor-neutral, if the Verifier has a way to generate vendor-agnostic
information based on the appraisal of vendor-specific information in
Evidence.  This allows a Relying Party's appraisal policy to be
simpler, potentially based on standard ways of expressing the
information, while still allowing interoperability with heterogeneous
devices.
Draft: draft-ietf-rats-architecture

Commentary: Section 10 . I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test . In most other section , generic interaction of roles , artifacts , their associated topologies , and high level security properties was noted . This section delves into specific implementation choices . In particular , Is the WG sure that it needs all of the details of Section 10.3 . Even among all of the Section in 10 . , this stands out . It does n't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept . Section 12.3 
 I agree with the observation , but do n't believe it requires any changes . 
 This was carefully discussed and weighed over the entire editorial WG phase , actually . We found delicate consensus that might have also resulted in an unusual high level of attention to detail , but that detailed is most certainly warranted here especially . I think the text reflects the WG consensus building in an appropriately nuanced fashion today and am very hesitant with trying to refactor it again ( even if it suddenly spikes to a maybe surprising level of detail ) as I deem it unlikely that it will improve by that , tbh . 
 " This section is intended for those creating protocols or solutions to understand the options available to ensure freshness "
Paragraph (version B):
This section provides a number of details.  It does not however
define any protocol formats, the interactions shown are abstract.
This section is intended for those creating protocols and solutions
to understand the options available to ensure freshness.  The way in
which freshness is provisioned in a protocol is an architectural
decision.  Provisioning of freshness has an impact on the number of
needed round trips in a protocol, and therefore must be made very
early in the design.  Different decisions will have significant
impacts on resulting interoperability, which is why this section goes
into sufficient detail such that choices in freshness will be
compatible across interacting protocols, such as depicted in
multievidence_diag.
Draft: draft-ietf-rats-architecture

Commentary: Fixes issue 
 In we now explicitly say that " confidentiality protection of Evidence and Attestation Results " is required in some form . In we now explicitly say that " Many Claims in Evidence , many Claims in Attestation Results , and   potentially contain Personally Identifying Information ( PII ) " . See my point already ? Maybe protection of   is " technically out - of - scope " , but expressing this side by side makes a curious impression to me . 
 ` 
 Yes . However , without a suitable privacy tracking identifier , it might not be possible to correlate privacy sensitive information in the policy with the actions of the Attester . 
 We should add privacy applies to appraisal policy to Privacy section .
Paragraph (version A):
Many Claims in Evidence and Attestation Results are potentially
Personally Identifying Information (PII) depending on the end-to-end
use case of the remote attestation procedure.  Remote attestation
that goes up to include containers and applications, e.g., a blood
pressure monitor, may further reveal details about specific systems
or users.
Paragraph (version B):
Many Claims in Evidence, many Claims in Attestation Results, and
Appraisal Policies potentially contain Personally Identifying
Information (PII) depending on the end-to-end use case of the remote
attestation procedure.  Remote attestation that includes containers
and applications, e.g., a blood pressure monitor, may further reveal
details about specific systems or users.
Draft: draft-ietf-rats-architecture

Commentary: Fixes line in privacy section that was unclear about using encryption as a privacy protection approach . 
 In we now explicitly say that " confidentiality protection of Evidence and Attestation Results " is required in some form . In we now explicitly say that " Many Claims in Evidence , many Claims in Attestation Results , and   potentially contain Personally Identifying Information ( PII ) " . See my point already ? Maybe protection of   is " technically out - of - scope " , but expressing this side by side makes a curious impression to me . 
 ` 
 I suggest sticking to defined terminology such as ' conveyance protocol ' instead of ' protecting protocols ' . The ' kinds of information disclosed ' is terminology for ' Claims ' . It might make sense to include the line " If there is n't confidentiality protection of Evidence and Attestation Results in the conceptual messages , the underlying conveyance protocol should provide these protections . " 
 " for example , if there is n't object - level confidentiality protection of messages , then the transport protocol should provide it " " If there is n't confidentiality protection of Evidence and Attestation Results in the conceptual messages , the underlying conveyance protocol should provide these protections . "
Paragraph (version A):
Evidence and Attestation Results are expected to be integrity
protected (i.e., either via signing or a secure channel) and
optionally might be confidentiality protected via encryption.  If
confidentiality protection of the conceptual messages is omitted or
unavailable, the protecting protocols that convey Evidence or
Attestation Results are responsible for detailing what kinds of
information are disclosed, and to whom they are exposed.
Paragraph (version B):
Evidence and Attestation Results are expected to be integrity
protected (i.e., either via signing or a secure channel) and
optionally might be confidentiality protected via encryption.  If
there isn't confidentiality protection of Evidence and Attestation
Results, the underlying conveyance protocol should provide these
protections.
Draft: draft-ietf-rats-architecture

Commentary: ` 
 This is trying say that the Target Environment ca n't lie to the Attesting Environment about its trustworthiness properties . 
 Spot on . A text proposal ( NEW ) based on  's comment :
Paragraph (version A):
Evidence is a set of Claims about the target environment that reveal
operational status, health, configuration or construction that have
security relevance.  Evidence is appraised by a Verifier to establish
its relevance, compliance, and timeliness.  Claims need to be
collected in a manner that is reliable.  Evidence needs to be
securely associated with the target environment so that the Verifier
cannot be tricked into accepting Claims originating from a different
environment (that may be more trustworthy).  Evidence also must be
protected from man-in-the-middle attackers who may observe, change or
misdirect Evidence as it travels from Attester to Verifier.  The
timeliness of Evidence can be captured using Claims that pinpoint the
time or interval when changes in operational status, health, and so
forth occur.
Paragraph (version B):
Evidence is a set of Claims about the target environment that reveal
operational status, health, configuration or construction that have
security relevance.  Evidence is appraised by a Verifier to establish
its relevance, compliance, and timeliness.  Claims need to be
collected in a manner that is reliable such that a Target Environment
cannot lie to the Attesting Environment about its trustworthiness
properties.  Evidence needs to be securely associated with the target
environment so that the Verifier cannot be tricked into accepting
Claims originating from a different environment (that may be more
trustworthy).  Evidence also must be protected from man-in-the-middle
attackers who may observe, change or misdirect Evidence as it travels
from Attester to Verifier.  The timeliness of Evidence can be
captured using Claims that pinpoint the time or interval when changes
in operational status, health, and so forth occur.
Draft: draft-ietf-rats-architecture

Commentary: Reads like I might have broken that meaning & I am in violent agreement with the fix .
Paragraph (version A):
Evidence and Attestation Results are expected to be integrity
protected (i.e., either via signing or a secure channel) and
optionally might be confidentiality protected via encryption.  If
confidentiality protection via signing the conceptual messages is
omitted or unavailable, the protecting protocols that convey Evidence
or Attestation Results are responsible for detailing what kinds of
information are disclosed, and to whom they are exposed.
Paragraph (version B):
Evidence and Attestation Results are expected to be integrity
protected (i.e., either via signing or a secure channel) and
optionally might be confidentiality protected via encryption.  If
confidentiality protection of the conceptual messages is omitted or
unavailable, the protecting protocols that convey Evidence or
Attestation Results are responsible for detailing what kinds of
information are disclosed, and to whom they are exposed.
Draft: draft-ietf-rats-architecture

Commentary: Note that section 10.4 ( Freshness . Discussion ) already said : So the intro text tries to be consistent with that phrasing . Signed - off - by :   
 pushed to fix the CI 
 Appendix A needs more introduction text to highlight its value to the reader . 
 LGTM
Paragraph (version B):
freshness discussed various issues and requirements around freshness
of evidence, and summarized three approaches that might be used by
different solutions to address them.  This appendix provides more
details with examples to help illustrate potential approaches, to
inform those creating specific solutions.
Draft: draft-ietf-rats-architecture

Commentary: reference to TEEP , cited TPM reference in section 3.3 . 
 First mentioning of TEE , eSE , and TPM need reference in section Two Types of Environments of an Attester . 
 These terms need to have references : Trusted Execution Environments ( TEEs ) , embedded Secure Elements ( eSEs ) , Trusted   ( TPMs ) , or BIOS firmware . 
 We do n't think we need to expand BIOS , and that it should be on the RFC editor  list .
Paragraph (version A):
A Trusted Application Manager (TAM) server is responsible for
managing the applications running in a Trusted Execution Environment
(TEE) of a client device.  To achieve its purpose, the TAM needs to
assess the state of a TEE, or of applications in the TEE, of a client
device.  The TEE conducts Remote Attestation Procedures with the TAM,
which can then decide whether the TEE is already in compliance with
the TAM's latest policy.  If not, the TAM has to uninstall, update,
or install approved applications in the TEE to bring it back into
compliance with the TAM's policy.
Paragraph (version B):
A Trusted Application Manager (TAM) server is responsible for
managing the applications running in a Trusted Execution Environment
(TEE) of a client device, as described in TEEParch.  To achieve its
purpose, the TAM needs to assess the state of a TEE, or of
applications in the TEE, of a client device.  The TEE conducts Remote
Attestation Procedures with the TAM, which can then decide whether
the TEE is already in compliance with the TAM's latest policy.  If
not, the TAM has to uninstall, update, or install approved
applications in the TEE to bring it back into compliance with the
TAM's policy.
Draft: draft-ietf-rats-architecture

Commentary: Maybe a sentence to tie unprotected Evidence to the " concept of trust " in the Verifier section of the Trust Model super - rsection might be useful in order to illustrate to the reader why that is covered there ? At the moment it talks about " secure channels " and the ties to trust are mainly implied ?
Paragraph (version B):
As illustrated in I-D.birkholz-rats-uccs, an entity that receives
unprotected Evidence via a trusted conveyance channel always takes on
the responsibility of vouching for the Evidence's authenticity and
freshness.  If protected Evidence is generated, the Attester's
Attesting Environments take on that responsibility.  In cases where
unprotected Evidence is processed by a Verifier, Relying Parties have
to trust that the Verifier is capable of handling Evidence in a
manner that preserves the Evidence's authenticity and freshness.
Generating and conveying unprotected Evidence always creates
significant risk and the benefits of that approach have to be
carefully weighed against potential drawbacks.
Draft: draft-ietf-rats-architecture

Commentary: The example used in roles and entities actually do not illustrate two aggregated / collapsed roles that talk with each other , as they seem to be entities in two different RATS setups ? 
 Agreed to delete paragraph:"For example , an entity that both connects to a wide - area network and to a system bus is taking on both the Attester and Verifier roles . As a system bus - connected entity , a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles . As a wide - area network connected entity , it may implement an Attester role . "
Paragraph (version A):
For example, an entity that both connects to a wide-area network and
to a system bus is taking on both the Attester and Verifier roles.
As a system bus-connected entity, a Verifier consumes Evidence from
other devices connected to the system bus that implement Attester
roles.  As a wide-area network connected entity, it may implement an
Attester role.
Draft: draft-ietf-rats-architecture

Commentary: What is that sentence trying to tell me ? Control over which keys ? Not the attestation keys , I think .
Paragraph (version A):
In many cases the user or owner of a device that takes on the role of
Attester must not be able to modify or extract keys from its
Attesting Environments.  For example, the owner or user of a mobile
phone or FIDO authenticator might not be trusted to use the keys to
report Evidence about the environment that protects the keys.  An
essential value-add provided by RATS is for the Relying Party to be
able to trust the Attester even if the user or owner is not trusted.
Paragraph (version B):
In many cases the user or owner of a device that includes the role of
Attester must not be able to modify or extract keys from the
Attesting Environments, to prevent creating forged Evidence.  Some
common examples include the user of a mobile phone or FIDO
authenticator.  An essential value-add provided by RATS is for the
Relying Party to be able to trust the Attester even if the user or
owner is not trusted.
Draft: draft-ietf-rats-architecture

Commentary: Many of the things that we are writing in the security considerations are really security requirements on implementations , rather than concerns with the architecture .
Paragraph (version B):
This document provides an architecture for doing remote attestation.
No specific wire protocol is documented here.  Without a specific
proposal to compare against, it is impossible to know if the security
threats listed below have been mitigated well.  The security
considerations below should be read as being essentially requirements
against realizations of the RATS Architecture.  Some threats apply to
protocols, some are against implementations (code), and some threats
are against physical infrastructure (such as factories).
Draft: draft-ietf-rats-architecture

Commentary: Maybe move this paragraph to the super - section ? Maybe this is intentional due to the proximity to a syntax example ? Yet , the suffix syntax style is not placed here , correspondingly .
Paragraph (version B):
In the figures below, curly braces indicate containment.  For
example, the notation Evidence{foo} indicates that 'foo' is contained
in the Evidence and is thus covered by its signature.
Paragraph (version A):
In the figures above and in subsequent sections, curly braces
indicate containment.  For example, the notation Evidence{foo}
indicates that 'foo' is contained in the Evidence and is thus covered
by its signature.
Draft: draft-ietf-rats-architecture

Commentary: by removing the sentence which did n't add any critical point . Also mention replaying in the list of potential nefarious activities . Signed - off - by :   
 In context , I am not sure what that sentence is trying to tell me . 
 I think it means that an  might or might not have actually received the epoch ids from the epoch i d distributor .
Paragraph (version A):
Handles, described in epochfreshness, can be tampered with, dropped,
delayed and reordered by an attacker.
Paragraph (version A):
An attacker could be either external or belong to the distribution
group, for example if one of the Attester entities have been
compromised.
Paragraph (version B):
Handles, described in epochfreshness, can be tampered with, replayed,
dropped, delayed, and reordered by an attacker.