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

Commentary: Signed - off - by :   
 " It is assumed that the Attester is located in an isolated environment of a device like a process , a dedicated chip a TEE or such that collects the Claims , formats them and signs them with an Attestation Key . " The grammar seems off to me . Should be : " It is assumed that the Attester is located in an isolated environment of a device such as ; a process , a dedicated chip , a TEE , a virtual machine , a secure mode of operation or other forms of domain isolation that allows collection of Claims from the target environment where the target environment can not lie or interfere with the claims collection function . Additionally , the Attester formats collected Claims and integrity protects them with an Attestation Key that also is domain isolated such that the target environment or some other entity other than the Attester is not able to undermine the Attester 's protections "
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.  When 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 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 A):
It is assumed that the Attester is located in an isolated environment
of a device like a process, a dedicated chip a TEE or such that
collects the Claims, formats them and signs them with an Attestation
Key. The Attester must be protected from unauthorized modification to
ensure it behaves correctly.  There must also be confidentiality so
that the signing key is not captured and used elsewhere to forge
evidence.
Paragraph (version B):
It is assumed that an Attesting Environment is sufficiently isolated
from the Target Environment it collects Claims for and signs them
with an Attestation Key, so that the Target Environment cannot forge
Evidence about itself.  Such an isolated environment might be
provided by a process, a dedicated chip, a TEE, a virtual machine, or
another secure mode of operation.  The Attesting Environment must be
protected from unauthorized modification to ensure it behaves
correctly.  There must also be confidentiality so that the signing
key is not captured and used elsewhere to forge Evidence.
Draft: draft-ietf-rats-architecture

Commentary: Clarify that recentness of Evidence depends primarily on the appraisal policy and that clock skew is only secondary . 
 Section " 16.1 . Example 1 " , third para : I find the reference to clock skew slightly confusing . The Threshold value here is more likely to depend on a verification policy that defines what is an acceptable " age " of the sampled claim rather than on considerations about clocks drifting .
Paragraph (version A):
If time(VG_a) is also included in the Evidence along with the claim
value generated at that time, and the Verifier decides that it can
trust the time(VG_a) value, the Verifier can also determine whether
the claim value is recent by checking "time(RG_v) - time(VG_a) <
Threshold", again where the threshold is large enough to account for
the maximum permitted clock skew between the Verifier and the
Attester.
Paragraph (version B):
If time(VG_a) is also included in the Evidence along with the claim
value generated at that time, and the Verifier decides that it can
trust the time(VG_a) value, the Verifier can also determine whether
the claim value is recent by checking "time(RG_v) - time(VG_a) <
Threshold".
The threshold is decided by the Appraisal Policy for Evidence, and
again needs to take into account the maximum permitted clock skew
between the Verifier and the Attester.
Draft: draft-ietf-rats-architecture

Commentary: The last sentence of the abstract is : but " such " remote attestation procedures are not defined earlier . 
 This abstract literally reads more self - consistent . +1
Paragraph (version A):
In network protocol exchanges, it is often the case that one entity
(a Relying Party) requires evidence about a remote peer to assess the
peer's trustworthiness, and a way to appraise such evidence.  The
evidence is typically a set of claims about its software and hardware
platform.  This document describes an architecture for such remote
attestation procedures (RATS).
Paragraph (version B):
In network protocol exchanges it is often the case that one entity
requires believable evidence about the operational state of a remote
peer.  Such evidence is typically conveyed as claims about the peer's
software and hardware platform, and is subsequently appraised in
order to assess the peer's trustworthiness.  The process of
generating and appraising this kind of evidence is known as remote
attestation.  This document describes an architecture for remote
attestation procedures that generate, convey, and appraise evidence
about a peer's operational state.
Draft: draft-ietf-rats-architecture

Commentary: From Five separate trivial updates requested Section 2 : Reference Value Provider Currently : ... Reference Values help Verifiers appraise the authenticity of Evidence Proposed : ... Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6 : Currently : One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied . This is a significant problem , Proposed : There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied . This can be a significant problem , Section 4 : Currently : pppraisal policy Proposed : appraisal policy Section 11 : Currently : as well as any users the device is associated with . Proposed : as well as potentially any users of the device . Section 12.1 Currently : Key Material Proposed : key material 
 I disagree with the first nit : if only known and acceptable claims have been recorded by    I disagree : 1 ) Evidence might be considered trustworthy even if additional ( not " known " to the Verifier ) claims are inserted . E.g. there may be vendor - specific claims whereas the Verifier might only care about standard claims . 2 ) The appraisal process is not just about claims and the proposed text narrows it to only be about claims . The rest of the process includes checks like whether the signature is valid , whether the signer chains to something in the Verifier 's trust anchor store , etc . These are not claims . As such , the current text is more correct . 
 The issue I have with the current text is that it intertwines authenticity and   . Evidence can still be authentic even if   are not what is passed .
Mailing list commentary: As part of WGLC , I have reviewed draft - ietf - rats - architecture-07 , and believe it an excellent document . Below are three minor comments and five nits which I believe are worth addressing . Major Comments
Paragraph (version A):
An entity (typically a manufacturer) whose Reference Values help
Verifiers appraise the authenticity of Evidence.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 ` Huh ? I thought a   came from a Reference Value Provider
Paragraph (version A):
Reference Values used in appraisal might be specified as part of the
appraisal policy itself, or might be obtained from a separate source,
such as an Endorsement, and then used by the appraisal policy.
Paragraph (version B):
Reference Values used in appraisal come from a Reference Value
Provider and are then used by the appraisal policy.  They might be
conveyed in any number of ways, including: * as part of the appraisal
policy itself, if the Verifier Owner either: acquires Reference
Values from a Reference Value Provider or is itself a Reference Value
Provider; * as part of an Endorsement, if the Endorser either
acquires Reference Values from a Reference Value Provider or is
itself a Reference Value Provider; or * via separate communication.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 ` What ’s the difference between claim and evidence ? Maybe you start with a Claim , then sign it and that makes it into Evidence ? Is Evidence a ‘ set of claims ’ ? [ and what ’s the difference between a ‘ set of information ’ and ‘ information ’ ? ] 
 Maybe " A signed set of Claims about an Attester ... " ? ( Want to make sure it 's not " just " a set of claims , since the signing is important too . )
Paragraph (version A):
A set of information about an Attester that is to be appraised by
a Verifier.  Evidence may include configuration data,
measurements, telemetry, or inferences.
Paragraph (version B):
A set of Claims generated by an Attester to be appraised by a
Verifier.  Evidence may include configuration data, measurements,
telemetry, or inferences.
Draft: draft-ietf-rats-architecture

Commentary: Line had the closing " } " in the wrong place in the diagram . While touching this text , phrase about disadvantage of the nonce approach , to provide more balanced discussion of timestamps vs nonces vs handles . Signed - off - by :
Paragraph (version A):
The following example illustrates a hypothetical Passport Model
solution that uses nonces and thus does not require that any clocks
are synchronized.
Paragraph (version A):
As a result, the receiver of a conceptual message containing a
timestamp cannot directly compare it to its own clock or timestamps.
Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for
Relying Party) on the IDs below indicating which clock generated
them, since times from different clocks cannot be compared.  Only the
delta between two events from the sender can be used by the receiver.
Paragraph (version B):
The following example illustrates a hypothetical Passport Model
solution that uses nonces instead of timestamps.  Compared to the
timestamp-based example, it requires an extra round trip to retrieve
a nonce, and requires that the Verifier and Relying Party track state
to remember the nonce for some period of time.
Paragraph (version B):
The advantage is that it does not require that any clocks are
synchronized.  As a result, the receiver of a conceptual message
containing a timestamp cannot directly compare it to its own clock or
timestamps.  Thus we use a suffix ("a" for Attester, "v" for
Verifier, and "r" for Relying Party) on the IDs below indicating
which clock generated them, since times from different clocks cannot
be compared.  Only the delta between two events from the sender can
be used by the receiver.
Draft: draft-ietf-rats-architecture

Commentary: Looked at all uses of " entity " in the doc to be sure it was n't referring to Verifier or RP which are roles and found a few issues in the Freshness section .
Paragraph (version A):
A remote entity (Verifier or Relying Party) may need to learn the
point in time (i.e., the "epoch") an Evidence or Attestation Result
has been produced.  This is essential in deciding whether the
included Claims and their values can be considered fresh, meaning
they still reflect the latest state of the Attester, and that any
Attestation Result was generated using the latest Appraisal Policy
for Evidence.
Paragraph (version B):
A Verifier or Relying Party may need to learn the point in time
(i.e., the "epoch") an Evidence or Attestation Result has been
produced.  This is essential in deciding whether the included Claims
and their values can be considered fresh, meaning they still reflect
the latest state of the Attester, and that any Attestation Result was
generated using the latest Appraisal Policy for Evidence.
Draft: draft-ietf-rats-architecture

Commentary: Also , my assumption is that all messages , configs and such go over one of the arrows in the figure . There are no back channels for things that are vital to or a major part of attestation . Seems like it would be a poor document if the major parts of attestation are not explicitly carried in the flows depicted .
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, or might be
obtained via some other mechanism such as being configured in the
Verifier by an administrator.
Paragraph (version A):
The Relying Party uses Attestation Results by applying its own
Appraisal Policy to make application-specific decisions such as
authorization decisions.  The Appraisal Policy for Attestation
Results might, for example, be configured in the Relying Party by an
administrator.
Paragraph (version B):
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 Relying Party uses Attestation Results by applying its own
Appraisal Policy to make application-specific decisions such as
authorization decisions.  The Appraisal Policy for Attestation
Results is configured in the Relying Party by the Relying Party
Owner, and/or is programmed into the Relying Party.
Draft: draft-ietf-rats-architecture

Commentary: Be clear Attesters do n't just do measurements and that they can exist anywhere .
Paragraph (version A):
Claims are collected from Target Environments, as shown in twotypes-
env.  That is, Attesting Environments collect the raw values and the
information to be represented in claims, such as by doing some
measurement of a Target Environment's code, memory, and/or registers.
Attesting Environments then format the claims appropriately, and
typically use key material and cryptographic functions, such as
signing or cipher algorithms, to create Evidence.  Places that
Attesting Environments can exist include 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
or memory and so on 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.
Draft: draft-ietf-rats-architecture

Commentary: Change " Evidence Appraisal Policy " -"Appraisal Policy for Evidence " Fixes editorial nit reported to me by  Acar Signed - off - by :   
 looks good .
Paragraph (version A):
The Verifier uses the Evidence, and any Endorsements from Endorsers,
by applying an Evidence Appraisal Policy 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, or might be
obtained via some other mechanism such as being configured in the
Verifier by an administrator.
Paragraph (version B):
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, or might be
obtained via some other mechanism such as being configured in the
Verifier by an administrator.
Draft: draft-ietf-rats-architecture

Commentary: Address . There are on the order of 1 billion users of biometric authentication 
 Discussion : everything you can do , RATS can do better :) Aka every authentication / access control use case is an attestation use case . Laurence to take a first shot at adding text into intro above use cases . Details would be in a doc from FIDO or W3C. 
 FIDO and Android are attestation use cases with billions of users today and are different from all the ones currently listed , so at least one of them should be . 
 Ok to merge
Paragraph (version B):
In the Fast IDentity Online (FIDO) protocol WebAuthN, CTAP, the
device in the user's hand authenticates the human user, whether by
biometrics (such as fingerprints), or by PIN and password.  FIDO
authentication puts a large amount of trust in the device compared to
typical password authentication because it is the device that
verifies the biometric, PIN and password inputs from the user, not
the server.  For the Relying Party to know that the authentication is
trustworthy, the Relying Party needs to know that the Authenticator
part of the device is trustworthy.  The FIDO protocol employs remote
attestation for this.
Paragraph (version B):
The FIDO protocol supports several remote attestation protocols and a
mechanism by which new ones can be registered and added.  Remote
attestation defined by RATS is thus a candidate for use in the FIDO
protocol.
Paragraph (version B):
Other biometric authentication protocols such as the Chinese IFAA
standard and WeChat Pay as well as Google Pay make use of attestation
in one form or another.
Paragraph (version B):
Every FIDO Authenticator contains an Attester.
Paragraph (version B):
Any web site, mobile application back end or service that does
biometric authentication.
Draft: draft-ietf-rats-architecture

Commentary: Address issue 
 Attestation Result is far more than compliance / non - compliance for many / most use cases . Attestation Results may contain lots claims that are passed through from the device ( e.g. , GPS location ) . I would also expect information from the Endorsement to be passed through , particularly in the case where the Verifier is an aggregator . Implied claims would also show up in the Attestation Result . 
 Section 7.3 starts out " Attestation Results may indicate compliance or non - compliance with a Verifier 's   " implying binary yes / no results . Section 7.3 needs to get rewritten some so results can be very rich with dozens of claims that are input to the RP 's risk engine . 
 The -05 draft with   moved to section 8.3 still has too much emphasis on compliance / non - compliance .
Paragraph (version A):
Attestation Results may indicate compliance or non-compliance with a
Verifier's Appraisal Policy.  A result that indicates non-compliance
can be used by an Attester (in the passport model) or a Relying Party
(in the background-check model) to indicate that the Attester should
not be treated as authorized and may be in need of remediation.  In
some cases, it may even indicate that the Evidence itself cannot be
authenticated as being correct.
Paragraph (version B):
Attestation Results are the input used by the Relying Party to decide
the extent to which it will trust a particular Attester, and allow it
to access some data or perform some operation.  Attestation Results
may be a Boolean simply indicating compliance or non-compliance with
a Verifier's Appraisal Policy, or a rich set of Claims about the
Attester, against which the Relying Party applies its Appraisal
Policy for Attestation Results.
Paragraph (version B):
A result that indicates non-compliance can be used by an Attester (in
the passport model) or a Relying Party (in the background-check
model) to indicate that the Attester should not be treated as
authorized and may be in need of remediation.  In some cases, it may
even indicate that the Evidence itself cannot be authenticated as
being correct.
Draft: draft-ietf-rats-architecture

Commentary: this is not complete and does not pass xml2rfc yet . Please add / fix your name / email . Or remove your email . Or foo at example dot com it .
Paragraph (version B):
Thomas Hardjono created older versions of the terminology section in
collaboration with Ned Smith.  Eric Voit provided the conceptual
separation between Attestation Provision Flows and Attestation
Evidence Flows.  Monty Wisemen created the content structure of the
first three architecture drafts.  Carsten Bormann provided many of
the motivational building blocks with respect to the Internet Threat
Model.
Draft: draft-ietf-rats-architecture

Commentary: Kathleen 's review Further privacy considerations : Remote attestation also provides a way to profile systems as well as the user behind that system . If attestation results go higher in the stack to include containers and applications , it could reveal even more about a system or user . The scope of access needs to be emphasized , including the administrators access to data ( or restrictions ) . If there is a way to make inferences about attestations from their processing , that should be noted as well . 
 Pull request tries to start .
Paragraph (version A):
The conveyance of Evidence and the resulting Attestation Results
reveal a great deal of information about the internal state of a
device.  In many cases, the whole point of the Attestation process is
to provide reliable information about the type of the device and the
firmware/software that the device is running.  This information might
be particularly interesting to many attackers.  For example, knowing
that a device is running a weak version of firmware provides a way to
aim attacks better.
Paragraph (version B):
The conveyance of Evidence and the resulting Attestation Results
reveal a great deal of information about the internal state of a
device as well as any users the device is associated with.  In many
cases, the whole point of the Attestation process is to provide
reliable information about the type of the device and the firmware/
software that the device is running.  This information might be
particularly interesting to many attackers.  For example, knowing
that a device is running a weak version of firmware provides a way to
aim attacks better.
Paragraph (version B):
Many claims in Attestation Evidence and Attestation Results are
potentially PII (Personally Identifying Information) depending on the
end-to-end use case of the attestation.  Attestation that goes up to
include containers and applications may further reveal details about
a specific system or user.
Paragraph (version B):
In some cases, an attacker may be able to make inferences about
attestations from the results or timing of the processing.  For
example, an attacker might be able to infer the value of specific
claims if it knew that only certain values were accepted by the
Relying Party.