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

Commentary: ` Is there a reason to enumerate the failure cases ? How can it be argued that there are only three ? What if the device fails part way through ? What if the relying party fails ? What if the relying party is unreachable ? What if something happens that was n’t anticipated in the appraisal policy ? Put another way , what are we learning about RATS from this example ?
Paragraph (version A):
There are three ways in which the process may fail.  First, the
Verifier may not issue a positive Attestation Result due to the
Evidence not passing the Appraisal Policy for Evidence.  The second
way in which the process may fail is when the Attestation Result is
examined by the Relying Party, and based upon the Appraisal Policy
for Attestation Results, the result does not pass the policy.  The
third way is when the Verifier is unreachable or unavailable.
Paragraph (version B):
First, the Verifier may not issue a positive Attestation Result
due to the Evidence not passing the Appraisal Policy for Evidence.
Paragraph (version B):
The second way in which the process may fail is when the
Attestation Result is examined by the Relying Party, and based
upon the Appraisal Policy for Attestation Results, the result does
not pass the policy.
Paragraph (version B):
The third way is when the Verifier is unreachable or unavailable.
Draft: draft-ietf-rats-architecture

Commentary: ` 1 ) Is this a normative statement ? 2 ) I think the next paragraph says that maybe it ’s not an asymmetric key , and anyways , keys are out of scope for RATS Arch 
 In a layered device architecture the previous layer " provisions " the next layer . Hence , it is n't possible for the ' manufacturer ' entity to do that . I do n't know why a section on " Verifier " is going into so much detail about the Attester .
Paragraph (version A):
The manufacturer of the Attester arranges for its Attesting
Environment to be provisioned with key material.  The key material is
typically in the form of an asymmetric key pair (e.g., an RSA or
ECDSA private key and a manufacturer-signed IDevID certificate)
secured in the Attester.
Paragraph (version A):
The Verifier is provided with an appropriate trust anchor, or
provided with a database of public keys (rather than certificates),
or even carefully secured lists of symmetric keys.  The nature of how
the Verifier manages to validate the signatures produced by the
Attester is critical to the secure operation of an Attestation
system, but is not the subject of standardization within this
architecture.
Paragraph (version B):
The manufacturer having arranged for an Attesting Environment to be
provisioned with key material with which to sign Evidence, the
Verifier is then provided with some way of verifying the signature on
the Evidence.  This may be in the form of an appropriate trust
anchor, or the Verifier may be provided with a database of public
keys (rather than certificates) or even carefully secured lists of
symmetric keys.
Paragraph (version B):
The nature of how the Verifier manages to validate the signatures
produced by the Attester is critical to the secure operation of an
Attestation system, but is not the subject of standardization within
this architecture.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :
Paragraph (version B):
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: Based on  's proposal and  's comments . 
 : This is a complete re - write of the paragraph which needs to be read in its entirety . I 'm not sure whether a line - by - line diff is of any help ? That said , if you really want I could do that easily . 
   < : It helps with the next edit that comes along . 
 OK , done in 
 I do n't understand what this para is supposed to communicate : Also , pick one of " nested " , " staged " or " chained " and drop the rest . 
 For context : this is now https://ietf - rats- " Layered Attestation Environments " How about this as a new starting point : Effectively , I removed the last sentence , as I had a hard time to understand what it intended to add to the content here . My proposal is intended as a rework of this paragraph that goes beyond editorial changes . The current last sentence still seems a bit out of place to me . 
 Looks very good as a starting point . Thanks ! 
 All good so far . This sentence can be confusing , since I think it could include claims about itself in Evidence , as admitted in your point below ( " Claims can be collected from or about each layer , including roots of trust . " )  with " must be endorsed " . Either the verifier has to trust the root of trust itself ( e.g. , put the root of trust 's public key into its trust anchor store directly ) OR must be endorsed ( e.g. , put the endorser 's public key into the verifier 's trust anchor store ) . Fine .
Paragraph (version A):
By definition, the Attester role creates Evidence.  An Attester may
consist of one or more nested or staged environments, adding
complexity to the architectural structure.  The unifying component is
the root of trust and the nested, staged, or chained attestation
Evidence produced.  The nested or chained structure includes Claims,
collected by the Attester to aid in the assurance or believability of
the attestation Evidence.
Paragraph (version B):
By definition, the Attester role generates Evidence.  An Attester may
consist of one or more nested environments (layers).  The root layer
of an Attester includes at least one root of trust.  In order to
appraise Evidence generated by an Attester, the Verifier needs to
trust the Attester's root of trust.  Trust in the Attester's root of
trust can be established either directly (e.g., the Verifier puts the
root of trust's public key into its trust anchor store) or
transitively via an Endorser (e.g., the Verifier puts the Endorser's
public key into its trust anchor store).  In layered attestation, a
root of trust is the initial Attesting Environment.  Claims can be
collected from or about each layer.  The corresponding claims can be
structured in a nested fashion that reflects the nesting of the
Attester's layers.
Draft: draft-ietf-rats-architecture

Commentary: ` It sounds like the Verifier “ does ” the authentication , and the relying party relies on the answer ? 
 Besides , there 's a slight imprecision here : the web site / mobile app backend service do n't do biometric auth . Instead , the authenticator binds biometric info to crypto material so that the web site can deal with usual crypto auth . 
 For context , this is https://ietf - rats- How about :
Paragraph (version A):
Any web site, mobile application back end or service that does
biometric authentication.
Paragraph (version B):
Any web site, mobile application back-end, or service that relies
on authentication data based on biometric information.
Draft: draft-ietf-rats-architecture

Commentary: Why not ? What ’s the message you want to convey here ? What would disqualify an execution environment from being capable of claims collection ? How would you know if an Execution Environment is an Attesting Environment ? 
 What does it mean to be capable of claims collection ? If this example had a TPM , then this function would be entirely inside the TPM , no ? 
 subsequent line now reads : ` Should this explicitely say , " TPM " as well , or is that implied ?
Paragraph (version A):
Claims are collected from Target Environments, as shown in twotypes-
env.  That is, Attesting Environments collect the values and the
information to be represented in Claims, by reading system registers
and variables, calling into subsystems, taking measurements on code,
memory, or other security related assets of the Target Environment.
Attesting Environments then format the claims appropriately, and
typically use key material and cryptographic functions, such as
signing or cipher algorithms, to create Evidence.  There is no limit
to or requirement on the places that an Attesting Environment can
exist, but they typically are in Trusted Execution Environments
(TEE), embedded Secure Elements (eSE), and BIOS firmware.  An
execution environment may not, by default, be capable of claims
collection for a given Target Environment.  Execution environments
that are designed to be capable of claims collection are referred to
in this document as Attesting Environments.
Paragraph (version B):
Claims are collected from Target Environments, as shown in twotypes-
env.  That is, Attesting Environments collect the values and the
information to be represented in Claims, by reading system registers
and variables, calling into subsystems, taking measurements on code,
memory, or other security related assets of the Target Environment.
Attesting Environments then format the claims appropriately, and
typically use key material and cryptographic functions, such as
signing or cipher algorithms, to create Evidence.  There is no limit
to or requirement on the types of hardware or software environments
that can be used to implement an Attesting Environment, for example:
Trusted Execution Environments (TEEs), embedded Secure Elements
(eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An
arbitrary execution environment may not, by default, be capable of
claims collection for a given Target Environment.  Execution
environments that are designed specifically to be capable of claims
collection are referred to in this document as Attesting
Environments.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 The paragraph : seems to reshuffle the content of the preceding one . The two can be combined / streamlined . 
 Maybe : " However , like in the Passport model , an Attestation Result is still consumed by the Relying Party and so the ability to convey it in the same serialization format as the Evidence allows minimizing the code footprint and attack surface area , which is especially important if the Relying Party is a constrained node . " 
 Personally , I like the new content here that elaborates on motivation and intent . Anyone else like to chime in here to have in impact on that expositional text ? 
 The meaning of is wrong , i.e. , format same as the Evidence . Instead the meaning is format same as the resource access protocol natively uses .
Paragraph (version A):
However, like in the Passport model, an Attestation Result is still
consumed by the Relying Party and so the serialization format of the
Attestation Result is still important.  If the Relying Party is a
constrained node whose purpose is to serve a given type resource
using a standard resource access protocol, it already needs the
parser(s) required by that existing protocol.  Hence, the ability to
let the Relying Party obtain an Attestation Result in the same
serialization format allows minimizing the code footprint and attack
surface area of the Relying Party, especially if the Relying Party is
a constrained node.
Paragraph (version B):
However, like in the Passport model, an Attestation Result is still
consumed by the Relying Party.  Code footprint and attack surface
area can be minimized by using a serialization format for which the
Relying Party already needs a parser to support the protocol between
the Attester and Relying Party, which may be an existing standard or
widely deployed resource access protocol.  Such minimization is
especially important if the Relying Party is a constrained node.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 ` Isolate ? From what ? “ Isolation ” seems to be used several times in this and later sections without saying who ’s isolating what from whom . 
 I do n't understand that sentence either . Propose removing it . Another sentence : Propose removing " isolation and " Other uses of isolation I think are fine , where it means that an Attesting Environment can not be modified by a Target Environment it measures . Any way of protecting that might be called " isolating " the two environments from each other in some way .
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.  The entity, as a system bus Verifier, may choose to
fully isolate its role as a wide-area network Attester.
Paragraph (version B):
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):
Implementers need to pay close attention to the isolation and
protection of the Attester and the factory processes for provisioning
the Attestation key material.  If either of these are compromised,
the remote attestation becomes worthless because the attacker can
forge Evidence.
Paragraph (version B):
Implementers need to pay close attention to the protection of the
Attester and the factory processes for provisioning the Attestation
key material.  If either of these are compromised, the remote
attestation becomes worthless because an attacker can forge Evidence
or manipulate the Attesting Environment.  For example, a Target
Environment should not be able to tamper with the Attesting
Environment that measures it, by isolating the two environments from
each other in some way.
Draft: draft-ietf-rats-architecture

Commentary: update the " Combinations " section to fix issue . 
 How does this show that both models are required in this example ? I suggest changing this sentence in this way . Because I think the combinations have several possibilities and there is no need to detail all possibilities . Any other thoughts ?
Paragraph (version A):
It is also worth pointing out that the choice of model is generally
up to the Relying Party.  The same device may need to create Evidence
for different Relying Parties and/or different use cases.  For
instance, it would provide Evidence to a network infrastructure
device to gain access to the network, and to a server holding
confidential data to gain access to that data.  As such, both models
may simultaneously be in use by the same device.
Paragraph (version B):
It is also worth pointing out that the choice of model is generally
up to the Relying Party.  The same device may need to create Evidence
for different Relying Parties and/or different use cases.  For
instance, it would use one model to provide Evidence to a network
infrastructure device to gain access to the network, and the other
model to provide Evidence to a server holding confidential data to
gain access to that data.  As such, both models may simultaneously be
in use by the same device.
Draft: draft-ietf-rats-architecture

Commentary: adding the Reference Values to fix issue 185 
 ` And the Verifier uses the Reference Values 
 I agree that   should be mentioned here .
Paragraph (version A):
The Verifier uses the Evidence, and any Endorsements from Endorsers,
by applying an Appraisal Policy for Evidence to assess the
trustworthiness of the Attester, and generates Attestation Results
for use by Relying Parties.  The Appraisal Policy for Evidence might
be obtained from an Endorser along with the Endorsements, and/or
might be obtained via some other mechanism such as being configured
in the Verifier by the Verifier Owner.
Paragraph (version B):
The Verifier uses the Evidence, any Reference Values from Reference
Value Providers, and any Endorsements from Endorsers, by applying an
Appraisal Policy for Evidence to assess the trustworthiness of the
Attester, and generates Attestation Results for use by Relying
Parties.  The Appraisal Policy for Evidence might be obtained from an
Endorser along with the Endorsements, and/or might be obtained via
some other mechanism such as being configured in the Verifier by the
Verifier Owner.
Draft: draft-ietf-rats-architecture

Commentary: There seems to be some confusion : initially it is said that the " Relying Party is the watchdog timer in the TPM . " Subsequently , the Relying Party is defined as " A remote server that will securely grant the Attester [ ... ] " . So , what is it ? 
 For context , this is now : https://ietf - rats- This is plainly wrong ( probably due being left over as an artifact after revising the text ) . How about : " Relying Party : The watchdog capable to trigger a procedure that resets a device into a remediatable operational state . " 
 WFM , except I am not sure " remediatable " is a word . You want to use " known , good " instead ? 
 Sry for my native language habit of concatenating and mangling existing terms . " Known , good " reads very appropriate . Thanks ! 
 The sentence above says that the replying party is inside the TPM ? ? I think this sentence , relying party is a remote server , is more likely what you mean . In the above paragraph , it says that the Relying Party is inside the TPM . I think this is the correct description . The Relying Party is n't remote in this use case because it has the essential capability to force the device to reboot . 
 This issue is the same as
Paragraph (version B):
A watchdog capable of triggering a procedure that resets a device
into a known, good operational state.
Draft: draft-ietf-rats-architecture

Commentary: The three sentences " There are multiple [ ... ] " , " This section includes [ ... ] " and " This is not intended [ ... ] " are slightly vague . It does n't seem to me that their information content is enough to justify them being independent sentences . They should probably be combined . 
 OLD : NEW : 
 ( slight refinement ) " Figure 1 shows an abstract model for communication between an Attester , a Verifier , and a Relying Party . The Attester conveys its Evidence to the Verifier for appraisal , and the Relying Party gets the Attestation Result from the Verifier . This section refines it by describing two reference interaction schemes ( topological models ) , as well as one possible compositions thereof . The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns . " 
 Reads good to me . Any other comments ? ( starting a virtual going once ... )
Paragraph (version A):
dataflow shows a basic model for communication between an Attester, a
Verifier, and a Relying Party.  The Attester conveys its Evidence to
the Verifier for appraisal, and the Relying Party gets the
Attestation Result from the Verifier.  There are multiple other
possible models.  This section includes some reference models.  This
is not intended to be a restrictive list, and other variations may
exist.
Paragraph (version B):
dataflow shows a data-flow diagram for communication between an
Attester, a Verifier, and a Relying Party.  The Attester conveys its
Evidence to the Verifier for appraisal, and the Relying Party gets
the Attestation Result from the Verifier.  This section refines it by
describing two reference models, as well as one example composition
thereof.  The discussion that follows is for illustrative purposes
only and does not constrain the interactions between RATS roles to
the presented patterns.
Draft: draft-ietf-rats-architecture

Commentary: We say : I 'm not sure it " is up to the RP " _ . Maybe better saying it " depends on the RP application " ( or similar ) because it 's typically not a choice of the RP but of the use case / protocol flow in which the RP operates ... 
 +1 
 Proposal : " Individual applications , use cases or protocol flows interacting with the same Attester can use different models . "
Paragraph (version A):
It is also worth pointing out that the choice of model is generally
up to the Relying Party.  The same device may need to create Evidence
for different Relying Parties and/or different use cases.  For
instance, it would use one model to provide Evidence to a network
infrastructure device to gain access to the network, and the other
model to provide Evidence to a server holding confidential data to
gain access to that data.  As such, both models may simultaneously be
in use by the same device.
Paragraph (version B):
It is also worth pointing out that the choice of model depends on the
use case, and that different Relying Parties may use different
topological patterns.
Paragraph (version B):
The same device may need to create Evidence for different Relying
Parties and/or different use cases.  For instance, it would use one
model to provide Evidence to a network infrastructure device to gain
access to the network, and the other model to provide Evidence to a
server holding confidential data to gain access to that data.  As
such, both models may simultaneously be in use by the same device.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 ` I think what you mean is that “ some flexibility on the requirement for freshness is a key component … ” , i.e. , it ’s the willingness to accept a result that ’s been around for a while enables caching . 
 agree .
Paragraph (version A):
Freshness is assessed based on the Appraisal Policy for Evidence or
Attestation Results, that compares the estimated epoch against an
"expiry" threshold defined locally to that policy.  There is,
however, always a race condition possible in that the state of the
Attester, and the appraisal policies might change immediately after
the Evidence or Attestation Result was generated.  The goal is merely
to narrow their recentness to something the Verifier (for Evidence)
or Relying Party (for Attestation Result) is willing to accept.
Freshness is a key component for enabling caching and reuse of both
Evidence and Attestation Results, which is especially valuable in
cases where their computation uses a substantial part of the resource
budget (e.g., energy in constrained devices).
Paragraph (version B):
Freshness is assessed based on the Appraisal Policy for Evidence or
Attestation Results, that compares the estimated epoch against an
"expiry" threshold defined locally to that policy.  There is,
however, always a race condition possible in that the state of the
Attester, and the appraisal policies might change immediately after
the Evidence or Attestation Result was generated.  The goal is merely
to narrow their recentness to something the Verifier (for Evidence)
or Relying Party (for Attestation Result) is willing to accept.  Some
flexibility on the freshness requirement, however, is a key component
for enabling caching and reuse of both Evidence and Attestation
Results, which is especially valuable in cases where their
computation uses a substantial part of the resource budget (e.g.,
energy in constrained devices).