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

Commentary: This proposes to add ROLIE to the list of potential conveyance protocols . 
  's review
Paragraph (version A):
In this diagram, the protocol between Attester and a Relying Party
can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x,
OPC UA, etc.), depending on the use case.  Such protocols typically
already have mechanisms for passing security information for purposes
of authentication and authorization.  Common formats include JWTs
RFC7519, CWTs RFC8392, and X.509 certificates.
Paragraph (version B):
In this diagram, the protocol between Attester and a Relying Party
can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE
RFC8322, 802.1x, OPC UA, etc.), depending on the use case.  Such
protocols typically already have mechanisms for passing security
information for purposes of authentication and authorization.  Common
formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates.
Draft: draft-ietf-rats-architecture

Commentary: Kathleen 's review
Paragraph (version A):
of claims collection for a given Target Environment.  Attesting
Environments are designed specifically with claims collection in
mind.
Paragraph (version B):
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: This splits example 3 out of pull request 
 Also covered in PR
Paragraph (version B):
The following example illustrates a hypothetical Background-Check
Model solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party.
Paragraph (version B):
The time considerations in this example are equivalent to those
discussed under Example 1 above.
Draft: draft-ietf-rats-architecture

Commentary: health - hygiene 
  's comment : Did you consider the more commonly used , " hygiene " ?
Paragraph (version A):
Network operators want a trustworthy report that includes identity
and version of information of the hardware and software on the
machines attached to their network, for purposes such as inventory,
audit, anomaly detection, record maintenance and/or trending reports
(logging).  The network operator may also want a policy by which full
access is only granted to devices that meet some definition of
health, and so wants to get claims about such information and verify
their validity.  Remote attestation is desired to prevent vulnerable
or compromised devices from getting access to the network and
potentially harming others.
Paragraph (version B):
Network operators want a trustworthy report that includes identity
and version of information of the hardware and software on the
machines attached to their network, for purposes such as inventory,
audit, anomaly detection, record maintenance and/or trending reports
(logging).  The network operator may also want a policy by which full
access is only granted to devices that meet some definition of
hygiene, and so wants to get claims about such information and verify
their validity.  Remote attestation is desired to prevent vulnerable
or compromised devices from getting access to the network and
potentially harming others.
Draft: draft-ietf-rats-architecture

Commentary: text proposal for changes in 
 OLD : NEW :
Paragraph (version A):
One significant problem is malware that holds a device hostage and
does not allow it to reboot to prevent updates from being applied.
Remote attestation aids in the verification process that may occur
locally as well as it is less likely that the policy or verification
processes have also been compromised if hosted on a separate system.
This is a significant problem, because it allows a fleet of devices
to be held hostage for ransom.
Paragraph (version A):
A hardware watchdog can be implemented by forcing a reboot unless
remote attestation to a server succeeds within a periodic interval,
and having the reboot do remediation by bringing a device into
compliance, including installation of patches as needed.
Paragraph (version B):
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, because it allows a fleet of devices
to be held hostage for ransom.
Paragraph (version B):
In the case, the Relying Party is the Watch Dog timer in the TPM/
secure enclave itself, as described in TCGarch section 43.3.  The
Attestation Results are returned to the device, and provided to the
enclave.
Paragraph (version B):
If the watch dog does not receive regular, and fresh, Attestation
Results as to the systems' health, then it forces a reboot.
Draft: draft-ietf-rats-architecture

Commentary: This is based upon comments in . 
 Ok with me , but I thought there was some resistance to " telemetry " so I thought others might want that word removed . I 'm ok either way . 
  's comment : For evidence , should this definition be more about what evidence is rather than about the roles involved ? The attester may not be the same component or system that attests to the evidence as well . Evidence could be measurement data , telemetry ( e.g. counters on a system interface - YANG or SNMP ) , results of a policy comparison to configuration data ) . Perhaps : 
 I think attestation pertains to the claims that most directly affect trustworthiness . Since a telemetry , auditing , AV scan etc … are code that is presumed to be telling the truth , they depend on Attestation for evidence they ’re valid . They are examples of what might be in a Target Environment .
Paragraph (version B):
A set of information about an Attester that is to be appraised by
a Verifier.  Evidence may include configuration data,
measurements, telemetry, or inferences.
Draft: draft-ietf-rats-architecture

Commentary:   was to the author list but was n't removed from the Acknowledgements section at the time so now appears in both places . This PR corrects that . Signed - off - by :   
 Yeah . I think this is yet another artifact and  is absolutely right here .  is already an " acknowledged editor " and therefore obviously does not has to be included in a potential ack section , apparently . 
 Thanks for your careful observation .
Paragraph (version A):
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica
Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,
Wei Pan, Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten.
Paragraph (version B):
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica
Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,
Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten.
Draft: draft-ietf-rats-architecture

Commentary: replace pull request with one we can edit . This attempts to establish the architectural basis for implicit trust as a result of links . 
 new text from requires some new Security Considerations text .
Paragraph (version B):
The key material used to authenticate and integrity protect the
conveyance channel is trusted by the Verifier to speak for the
Attesting Environment(s) that collected claims about the Target
Environment(s).
Paragraph (version B):
The Root of Trust protects both the conveyance channel key
material and the Attesting Environment with equivalent strength
protections.
Paragraph (version A):
The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA) by checking "time(RA) - time(RG) <
Threshold", where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying
Party and the Verifier.
The result might then be used for some time (e.g., throughout the
lifetime of a connection established at time(RA)).  The Relying Party
must be careful, however, to not allow continued use beyond the
period for which it deems the Attestation Result to remain fresh
enough.  Thus, it might allow use (at time(OP)) as long as "time(OP)
- time(RG) < Threshold".  However, if the Attestation Result contains
an expiry time time(RX) then it could explicitly check "time(OP) <
time(RX)".
Paragraph (version B):
The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA) by checking "time(RA) - time(RG) <
Threshold", where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying
Party and the Verifier.  The result might then be used for some time
(e.g., throughout the lifetime of a connection established at
time(RA)).  The Relying Party must be careful, however, to not allow
continued use beyond the period for which it deems the Attestation
Result to remain fresh enough.  Thus, it might allow use (at
time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if
the Attestation Result contains an expiry time time(RX) then it could
explicitly check "time(OP) < time(RX)".
Draft: draft-ietf-rats-architecture

Commentary: As discussed in the design team meeting Signed - off - by :
Paragraph (version B):
Furthermore, because Evidence might contain sensitive information,
Attesters are responsible for only sending such Evidence to trusted
Verifiers.  Some Attesters might want a stronger level of assurance
of the trustworthiness of a Verifier before sending Evidence to it.
In such cases, an Attester can first act as a Relying Party and ask
for the Verifier's own Attestation Result, and appraising it just as
a Relying Party would appraise an Attestation Result for any other
purpose.
Draft: draft-ietf-rats-architecture

Commentary: Previously the text was specific to policy for Evidence , but the same applies to policy for appraising   , so generalizing the text . This also removes a redundant sentence where older text and newly merged text from this morning said the same thing . And the diffs look larger than they really are , since some text was just moved around to be in a different order . Signed - off - by :
Paragraph (version A):
For example, for some claims the Verifier might check the values of
claims in the Evidence against constraints specified in the Appraisal
Policy for Evidence.  Such constraints might involve a comparison for
equality against reference values, or a check for being in a range
bounded by reference values, or membership in a set of reference
values, or a check against values in other claims, or any other test.
Paragraph (version A):
Such reference values might be specified as part of the Appraisal
Policy for Evidence itself, or might be obtained from a separate
source, such as an Endorsement, and then used by the Appraisal Policy
for Evidence.  The actual data format and semantics of a known-good
value are specific to claims and implementations.  There is no
general purpose format for them or general means for comparison
defined in this architecture document.  Similarly, for some claims
the Verifier might check the values of claims in the Evidence for
membership in a set, or against a range of values, or against known-
bad values such as an expiration time.  These reference values may be
conveyed to the Verifier as part of an Endorsement or as part of
Appraisal Policy or both as these are the two input paths to the
Verifier.
Paragraph (version B):
The Verifier, when appraising Evidence, or the Relying Party, when
appraising Attestation Results, checks the values of some claims
against constraints specified in its Appraisal Policy.  Such
constraints might involve a comparison for equality against a
reference value, or a check for being in a range bounded by reference
values, or membership in a set of reference values, or a check
against values in other claims, or any other test.
Paragraph (version B):
Such reference values 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):
The actual data format and semantics of any reference values are
specific to claims and implementations.  This architecture document
does not define any general purpose format for them or general means
for comparison.
Draft: draft-ietf-rats-architecture

Commentary: Edited section 7.1 Evidence
Paragraph (version A):
Today, Evidence tends to be highly device-specific, since the
information in the Evidence often includes vendor-specific
information that is necessary to fully describe the manufacturer and
model of the device including its security properties, the health of
the device, and the level of confidence in the correctness of the
information.  Evidence is typically signed by the device (whether by
hardware, firmware, or software on the device), and its appraisal in
isolation would require Appraisal Policy to be based on device-
specific details (e.g., a device public key).
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 evaluated 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.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 I do n't understand the text  . Suggest moving it to a separate PR . 
 The existing text listed HSM and TEE as examples of Attesting Environments . However , an HSM that only provides crypto acceleration and key storage was n’t designed for claims collection . Therefore , it is n’t an Attesting Environment ( necessarily ) . The text I explains that the Attesting Environment is designed in such a way that it is capable of claims collection . For example , if the HSM was designed to have exposed a shared memory region that is shared with the Target Environment ’s executable code pages . 
 Will fix broken kramdown after pull . 
 Approve of the changes . But also have an additional comment suggested change .
Paragraph (version A):
Claims are collected from Target Environments.  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.  Examples of environments that can be used as
Attesting Environments include Trusted Execution Environments (TEE),
embedded Secure Elements (eSE), or Hardware Security Modules (HSM).
Paragraph (version B):
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.  Attesting
Environments are designed specifically with claims collection in
mind.
Draft: draft-ietf-rats-architecture

Commentary: describe the basic   without complicating the draft 
 I am uncertain about the state of this PR . were your comments addressed ? 
 ~ In both the passport and background - check models , the Attester communicates directly with the Relying Party to access some resources . But in some cases , the Attester does n't need to access resources from the Relying Party . Assume that the Attester is a network device ( router , switch , etc . ) , and the Relying Party is the network management system ( NMS ) of the network operator . In such a case , the NMS monitors the health of the device by retrieving the Attestation Result of the device from a Verifier . If the device fails the attestation process , the NMS can take countermeasures like quarantining it . So the figure above depicts this situation . 
 Is this topological model covered by the passport model or background - check model ? 
 The above flow is always the information flow . The passport model and background - check are models for how the conveyance works . 
 Also , we had that diagram in the architecture documents , and we have the above diagram as figure 1 already . 
 This is also a way in which the conveyance can work . I add two sentences to describe this basic one without duplicating the diagram . 
 We conclude that there is not a need for this additional topological flow .
Paragraph (version A):
There are multiple possible models for communication between an
Attester, a Verifier, and a Relying Party.  This section includes
some reference models, but this is not intended to be a restrictive
list, and other variations may exist.
Paragraph (version B):
dataflow shows a basic model for communication between an Attester, a
Verifier, and a Relying Party.  The Attester sends its Evidence to
the Verifier for appraisal, and the Relying Party gets the
Attestation Results from the Verifier.  There are multiple other
possible models.  This section includes some reference models, but
this is not intended to be a restrictive list, and other variations
may exist.
Draft: draft-ietf-rats-architecture

Commentary: Provide forward references Use " measure " in English text Signed - off - by :   
 ( I had to do this right away before I forgot what I was suggesting during the meeting :)
Paragraph (version A):
An Attester consists of at least one Attesting Environment and at
least one Target Environment.  In some implementations, the Attesting
and Target Environments might be combined.  Other implementations
might have multiple Attesting and Target Environments.  One example
is a set of components in a boot sequence (e.g., ROM, firmware, OS,
and application) where a Target Environment is the Attesting
Environment for the next environment in the boot sequence.
Paragraph (version A):
Another example is that of a Composite Devices: Composite Devices are
defined below, and are inherently composed of multiple nested
environments.
Paragraph (version A):
Claims are collected from Target Environments.  That is, Attesting
Environments collect the raw values and the information to be
represented in claims.  Attesting Environments then format them
appropriately, and typically use key material and cryptographic
functions, such as signing or cipher algorithms, to create Evidence.
Examples of environments that can be used as Attesting Environments
include Trusted Execution Environments (TEE), embedded Secure
Elements (eSE), or Hardware Security Modules (HSM).
Paragraph (version B):
An Attester consists of at least one Attesting Environment and at
least one Target Environment.  In some implementations, the Attesting
and Target Environments might be combined.  Other implementations
might have multiple Attesting and Target Environments, such as in the
examples described in more detail in layered-attestation and
compositeattester.  Other examples may exist, and the examples
discussed could even be combined into even more complex
implementations.
Paragraph (version B):
Claims are collected from Target Environments.  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.  Examples of environments that can be used as
Attesting Environments include Trusted Execution Environments (TEE),
embedded Secure Elements (eSE), or Hardware Security Modules (HSM).
Draft: draft-ietf-rats-architecture

Commentary: Nicer is nice ! Approved .
Paragraph (version A):
An Attestation Result that indicates compliance can be used by a
Relying Party to make authorization decisions based on the Relying
Party's Appraisal Policy.  The simplest such policy might be to
simply authorize any party supplying a compliant Attestation Result
signed by a trusted Verifier.  A more complex policy might also
entail comparing information provided in the result against known-
good reference values, or applying more complex logic such
information.
Paragraph (version B):
An Attestation Result that indicates compliance can be used by a
Relying Party to make authorization decisions based on the Relying
Party's Appraisal Policy.  The simplest such policy might be to
simply authorize any party supplying a compliant Attestation Result
signed by a trusted Verifier.  A more complex policy might also
entail comparing information provided in the result against known-
good reference values, or applying more complex logic on such
information.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :
Paragraph (version A):
A second approach is to rely on synchronized clocks, and include a
signed timestamp (e.g., using I.D.draft-birkholz-rats-tuda) along
with the claims in the Evidence or Attestation Result, so that the
remote entity knows that the claims were signed at that time, as long
as it has some assurance that the timestamp is correct.  This
typically requires additional claims about the signer's time
synchronization mechanism in order to provide such assurance.
Paragraph (version B):
A second approach is to rely on synchronized clocks, and include a
signed timestamp (e.g., using I-D.birkholz-rats-tuda) along with the
claims in the Evidence or Attestation Result, so that the remote
entity knows that the claims were signed at that time, as long as it
has some assurance that the timestamp is correct.  This typically
requires additional claims about the signer's time synchronization
mechanism in order to provide such assurance.
Draft: draft-ietf-rats-architecture

Commentary: Addresses issue And review comments on PR Signed - off - by :
Paragraph (version A):
Target Environments are measured.  They provide the raw values and
the information to be represented in claims and ultimately expressed
as Evidence.
Paragraph (version A):
Attesting Environments conduct the measuring.  They collect the
claims, format them appropriately, and typically use key material and
cryptographic functions, such as signing or cipher algorithms, to
create Evidence.  Examples of environments that can be used as
Attesting Environments include Trusted Execution Environments (TEE),
embedded Secure Elements (eSE), or Hardware Security Modules (HSM).
Paragraph (version B):
Claims are collected from Target Environments.  That is, Attesting
Environments collect the raw values and the information to be
represented in claims.  Attesting Environments then format them
appropriately, and typically use key material and cryptographic
functions, such as signing or cipher algorithms, to create Evidence.
Examples of environments that can be used as Attesting Environments
include Trusted Execution Environments (TEE), embedded Secure
Elements (eSE), or Hardware Security Modules (HSM).