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

Commentary: Incorporating text from draft - birkholz - rats - architecture and from my reading of the " bike shed " mailing list thread Signed - off - by :
Paragraph (version A):
An Attester consists of at least one Attesting Environment and
Attested Environment.  In some implementations, the Attesting and
Attested Environments might be combined.  Other implementations might
have multiple Attesting and Attested Environments.
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.  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 B):
Target Environments are measured.  They provide the raw values and
the information to be represented in claims and ultimately expressed
as Evidence.
Paragraph (version B):
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).
Draft: draft-ietf-rats-architecture

Commentary: When comparing the term ' Appraisal Policy for Evidence ' and ' Appraisal Policy for Attestation Result ' , they are both saying ' evaluates the validity of information about an Attester ' . This makes me feel Verifier and Relying Party are doing the same things and they are redundant . I think it 's more appropriate to say that the Relying Party evaluates the evaluation results generated by the Verifiers .
Paragraph (version A):
Appraisal Policy for Attestation Result: A set of rules that
direct how a Relying Party evaluates the validity of information
about an Attester.  Compare /security policy/ in [RFC4949].
Paragraph (version B):
Appraisal Policy for Attestation Result: A set of rules that
direct how a Relying Party uses the evaluation results about an
Attester generated by the Verifiers.  Compare /security policy/ in
[RFC4949].
Draft: draft-ietf-rats-architecture

Commentary: Removed incorrect text that said Remote Attestation was not defined in the doc . Moved Remote Attestation paragraph to the introduction section where I think it will ( eventually ) make sense in the context of introduction text . Signed - off - by :   
 See comments in this term gets re - introduced here , without any annotation . The appraisal policy are the rules on how to test the evidence . Here , " Attestation " is the creation of the evidence Often people use the term " Attestation " to refer to the whole process . Suggestion that we should define this term somewhere , but maybe " Remote Attestation " ? FIDO has NONE - Attestation - Type , where there is no assessment . TCG would call this Implicit Attestation . Let 's take this to the WG , and maybe we can not get consensus on this term . Charter says : " Remote attestation procedures ( RATS ) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party . " 
 PR a paragraph defining Remote Attestation , and PR does some additional cleanup . 
 Can we close this issue now that PR and PR are merged ? 
 yes
Paragraph (version A):
The document defines the term "Remote Attestation" as follows: A
process by which one entity (the "Attester") provides evidence about
its identity and state to another remote entity (the "Relying
Party"), which then assesses the Attester's trustworthiness for the
Relying Party's own purposes.
Paragraph (version B):
Remote Attestation, as used in this document, is a process by which
one entity (the "Attester") provides evidence about its identity and
state to another remote entity (the "Relying Party"), which then
assesses the Attester's trustworthiness for the Relying Party's own
purposes.
Paragraph (version A):
The term Attestation and Remote Attestation are not defined in this
document, at this time.  This document will include pointers to
industry uses of the terms, in an attempt to gain consensus around
the term, and be consistent with the charter text defining this term.
Draft: draft-ietf-rats-architecture

Commentary: Incorporates both text from birkholz arch draft and thaler arch draft . Avoids using normative language per IETF 106 discussion . Signed - off - by :   
 The Birkholz draft had the idea of roles to describe higher level concepts ( independent of transport layer security considerations ) . It also defined " Actors " that focused on trust model relationships ( and their fungibility ) . Also a higher - layer concept from transport layer security considerations . Each section in the arch spec addresses security considerations appropriate for the level of abstraction . Maybe this security considerations is aimed at transport level security considerations ?
Paragraph (version B):
Any solution that conveys information used for security purposes,
whether such information is in the form of Evidence, Attestation
Results, or Endorsements, or Appraisal Policy, needs to support end-
to-end integrity protection and replay attack prevention, and often
also needs to support additional security protections.  For example,
additional means of authentication, confidentiality, integrity,
replay, denial of service and privacy protection are needed in many
use cases.
Paragraph (version B):
To evaluate the security provided by a particular Appraisal Policy,
it is important to understand the strength of the Root of Trust,
e.g., whether it is mutable software, or firmware that is read-only
after boot, or immutable hardware/ROM.
Paragraph (version B):
It is also important that the Appraisal Policy was itself obtained
securely.  As such, if Appraisal Policy in a Relying Party or
Verifier can be configured via a network protocol, the ability to
attest to the health of the client providing the Appraisal Policy
needs to be considered.
Draft: draft-ietf-rats-architecture

Commentary: Add in text from Birkholz draft , with some wordsmithing and grammatical fixes from
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.  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 is
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):
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: Merged from draft - thaler - rats- Signed - off - by :   
 PR and PR merged text that I had , and continue to have , problems with . A summary of the problems follows : 1 ) It includes events ( CC , RP ) that are not used in any checks in the text . I had pointed this out before when the PR was generated , but the PR was merged without addressing this comment . 2 ) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism ( handles ) that is not in any RFC or WG document . I believe that such replacement is inappropriate . If the WG adopts a document that talks about a handle distribution mechanism , then a section can be . Or if there is a standard from another org that can be referenced then it 's fine to add one in that case too . But I think it should not replace the section discussing the well known technique of synchronized clocks ( e.g. , using secure NTP , or PTP ( IEEE 1588 - 2002 ) or whatever other standard mechanism ) . 3 ) time(HD ) is problematic as phrased since all the other events are times as seen by a single entity , whereas time(HD ) does not clearly say whose perspective ( i.e. , whose clock ) it is from ... is it the distributor 's ? Text is unclear . 4 ) It talks about nonces in a timestamp section , which I think causes confusion since there 's already a separately section about nonces and this section is labeled to be scoped to timestamps . Addressing might address this naturally , if it uses a different section title . 5 ) There are some editorial typos , such as capital " The " in the middle of a sentence , etc . 6 ) I have no idea what " delta(time(HD),time(EG))distribution - interval " is supposed to mean . Normally I would expect an equality for any condition to be evaluated , but I have no idea what this check is . 7 ) time(HD ) and time(EG ) are according to different clocks ( if my guess about point 3 above is right ) and so the delta is not directly comparable . I 'm not sure how point 6 accounts for this . 8) The phrase " A nonce not predictable to an Attester ( recentness & uniqueness ) is sent to an Attester " has " ( recentness & uniqueness ) " which does n't read well ( sounds like bad grammar ) to me , and is not explained . 
 Hopefully PR now addresses this issue . 
 PR reverts the text , leaving the work in progress in PR 
 fixed by .
Paragraph (version B):
This document does not require any actions by IANA.
Draft: draft-ietf-rats-architecture

Commentary: Also split long line into multiple source lines Signed - off - by :
Paragraph (version A):
An entity (a relying party) requires a source of truth and evidence
about a remote peer to assess the peer's trustworthiness.  The
evidence is typically a believable set of claims about its host,
software or 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
(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).