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

Commentary: Signed - off - by :   
 What is the “ it ” in “ That is , it ”
Paragraph (version A):
That is, it might appraise the trustworthiness of an application
component, operating system component, or service under the
assumption that information provided about it by the lower-layer
firmware or software is true.  A stronger level of assurance of
security comes when information can be vouched for by hardware or by
ROM code, especially if such hardware is physically resistant to
hardware tampering.  In most cases, components that have to be
vouched for via Endorsements because no Evidence is generated about
them are referred to as roots of trust.
Paragraph (version B):
That is, a Verifier might appraise the trustworthiness of an
application component, operating system component, or service under
the assumption that information provided about it by the lower-layer
firmware or software is true.  A stronger level of assurance of
security comes when information can be vouched for by hardware or by
ROM code, especially if such hardware is physically resistant to
hardware tampering.  In most cases, components that have to be
vouched for via Endorsements because no Evidence is generated about
them are referred to as roots of trust.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 While   have a strong focus on conveyance and data format ,   do not . Is there a specific reason for this asymmetry ? Additionally , there is a statement on scope on the Reference Value that does not exist for   . Does that imply something ? 
 Add some additional words to  policy like : 
 Agreed to also move to section 6 , about appraisal / etc . combinations .
Paragraph (version B):
The actual data format and semantics of any Appraisal Policy is
implementation specific.
Paragraph (version A):
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.
Paragraph (version B):
The actual data format and semantics of any Reference Values are
specific to Claims and implementations.
Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :   
 At the IETF 110 meeting ,   asked why local clocks are a problem since even MCUs have them . Currently we have text in the doc like ... in the nonce section : in the handles section : I answered this by saying in the TEE use case for example , attesting the TEE needs a trusted clock , and having a trusted clock is not common .  suggested clarifying the clock text . 
 Is n't it synchronized clocks that are the requirement ? When you say " trusted clocks " , do you mean , I can trust that they are securely synchronized ? ( Or that I can trust that Cesium still has that frequency , and that the laws of physics have n't been altered ? ) 
 I mean a clock for which code outside the TEE can not tamper with . Whether it 's synchronized or not is not about whether the clock itself is trusted . If a TEE wants to know how much time has passed since a previous event , and it has to ask the REE , and the REE can lie , then that clock is not trusted by the TEE . 
 Add text to TEE section about how it needs a local clock , and then add to the example involving nonces .
Paragraph (version B):
In some use cases, however, a trustworthy clock might not be
available.  For example, in many Trusted Execution Environments
(TEEs) today, a clock is only available outside the TEE and so cannot
be trusted by the TEE.
Paragraph (version A):
Like the nonce approach, this allows associating a "rough" epoch
without requiring a reliable clock or time synchronization in order
to generate or appraise the freshness of Evidence or Attestation
Results.  Only the Handle Distributor requires access to a clock so
it can periodically send new epoch handles.
Paragraph (version B):
Like the nonce approach, this allows associating a "rough" epoch
without requiring a trustworthy clock or time synchronization in
order to generate or appraise the freshness of Evidence or
Attestation Results.  Only the Handle Distributor requires access to
a clock so it can periodically send new epoch handles.
Draft: draft-ietf-rats-architecture

Commentary: Once we Reference Value Provider as a role , the diagram was n't updated . The " A , B , and C " part is about reference values , not the endorsing of signing capabilities , which is just about A. Signed - off - by :
Paragraph (version A):
Claims about a root of trust typically are asserted by Endorsers.
Paragraph (version B):
Claims about a root of trust typically are asserted by an Endorser.
Draft: draft-ietf-rats-architecture

Commentary: ` The loader environment only exists for a second or two , and has few resources … how it is supposed to report evidence to a verifier in that window ? 
 Refers to figure 3 , in section 3.4 , on layered attestation . 
 It is rare that early layers generate or convey Evidence . In critical system with appropriate protected capabilities that actually happens . I can see that it is not a common case and would not argue strongly against removing ' B ' from that conveyance arc . 
 Perhaps a better example for which the loader environment is not ephemeral would be where B is the OS and C is an application / workload process .
Paragraph (version A):
The device illustrated in layered includes (A) a BIOS stored in read-
only memory, (B) an updatable bootloader, and (C) an operating system
kernel.
Paragraph (version B):
The device illustrated in layered includes (A) a BIOS stored in read-
only memory, (B) an operating system kernel, and (C) an application
or workload.
Draft: draft-ietf-rats-architecture

Commentary: ` Yes but for real passports , the Relying Party must separately evaluate the trustworthiness of 192 different Verifiers , i.e. , nation states , no ? This seems to imply that relying parties had better get ready to validate a limitless variety of   ? [ mcr : yes , in fact , in real passports , Relying Parties do not treat all 192 nation states equally , which is why , I 'm told , Israeli Mossad agents apprently like Canadian passports ... ] 
 The detail of how the Relying Party should trust the Verifiers is described in the " Trust Model " Section . Besides , there may be Appraisal Policies for   , which will guide the Relying Party on validating the Attestation Results . I do n't think an update is needed here . 
 The passport analogy shows that there is a cardinality of : Individual ( 1)<--Evidence--(1 ) Passport Agency Individual ( 1)<--Attestation Result --(N ) Immigration Desk The text currently does not state that this implies that interoperability and standardization is more relevant for   than it is for Evidence ( in this model ) . The question I want to raise is , do we want to make that more explicit to the reader ?
Paragraph (version A):
Since the resource access protocol between the Attester and Relying
Party includes an Attestation Result, in this model the details of
that protocol constrain the serialization format of the Attestation
Result.  The format of the Evidence on the other hand is only
constrained by the Attester-Verifier remote attestation protocol.
Paragraph (version B):
Since the resource access protocol between the Attester and Relying
Party includes an Attestation Result, in this model the details of
that protocol constrain the serialization format of the Attestation
Result.  The format of the Evidence on the other hand is only
constrained by the Attester-Verifier remote attestation protocol.
This implies that interoperability and standardization is more
relevant for Attestation Results than it is for Evidence.
Draft: draft-ietf-rats-architecture

Commentary: Biggest bug in the last pull request is that the diagram had the attester sending a different Attestation Result than the one the Verifier gave it , which would invalidate the signature . Second issue was that the lines did n't line up . Third issue was that it was missing the tie to the " epoch window " discussion in { { epochfreshness } } to explain how the Relying Party deals with the mismatched handles that the example diagram has . Signed - off - by :   
 The appendix on Handles needs some work to better clarify the concepts and simplify the flow . Some things about the text : Clearly define what is a handle ; Explain its relation with epoch establishment ; Clarify network jitter impact on handle validity ; Explain what are the base rules for working with handles ; Some further points on the sequence diagram : Fix confusing legend ; Add some accompanying prose to explain the depicted use case as it 's not self - evident ; 
 Thanks for aligning the diagram , I knew I had forgotten something . The changes look good to me . Ship it !
Paragraph (version A):
In the illustrated scenario, the handle for relaying an Attestation
Result to the Relying Party is current, while a previous handle was
used to generate Verifier evaluated evidence.  This indicates that at
least one epoch transition has occurred, and the Attestation Results
may only be as fresh as the previous epoch.
Paragraph (version B):
In the illustrated scenario, the handle for relaying an Attestation
Result to the Relying Party is current, while a previous handle was
used to generate Verifier evaluated evidence.  This indicates that at
least one epoch transition has occurred, and the Attestation Results
may only be as fresh as the previous epoch.  If the Relying Party
remembers the previous handle H during an epoch window as discussed
in epochfreshness, and the message is received during that window,
the Attestation Result is accepted as fresh, and otherwise it is
rejected as stale.
Draft: draft-ietf-rats-architecture

Commentary: The list in sec 3.2 did n't render properly . Also fix  's surname which got garbled for some reason .
Paragraph (version A):
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.
Paragraph (version B):
via separate communication.
Draft: draft-ietf-rats-architecture

Commentary: Discuss the impact that altering the distribution of handles ( e.g. , delaying , suppressing ) has on the security of the protocol . Add relevant text to the Security Consideration section . 
 Is this more than just finishing ? If so , what ? 
 The scope is different : deals with the example in the appendix , this one is for text that belongs to the security considerations . Regarding the " what " : is the issue description insufficient ? If so , do you have any suggestion on how to make it clearer ?
Paragraph (version B):
For a discussion on the security of handles see handles-sec.
Paragraph (version B):
Handles, described in epochfreshness, can be tampered with, dropped,
delayed and reordered by an attacker.
Paragraph (version B):
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):
An attacker who is able to tamper with handles can potentially lock
all the participants in a certain epoch of choice for ever,
effectively freezing time.  This is problematic since it destroys the
ability to ascertain freshness of Evidence and Attestation Results.
Paragraph (version B):
To mitigate this threat, the transport should be at least integrity
protected and provide origin authentication.
Paragraph (version B):
Selective dropping of handles is equivalent to pinning the victim
node to a past epoch.  An attacker could drop handles to only some
entities and not others, which will typically result in a denial of
service due to the permanent staleness of the Attestation Result or
Evidence.
Paragraph (version B):
Delaying or reordering handles is equivalent to manipulating the
victim's timeline at will.  This ability could be used by a malicious
actor (e.g., a compromised router) to mount a confusion attack where,
for example, a Verifier is tricked into accepting Evidence coming
from a past epoch as fresh, while in the meantime the Attester has
been compromised.
Paragraph (version B):
Reordering and dropping attacks are mitigated if the transport
provides the ability to detect reordering and drop.  However, the
delay attack described above can't be thwarted in this manner.
Draft: draft-ietf-rats-architecture

Commentary: The handle - related portion of the Freshness section should provide some guidance on the extent of the " epoch window " , i.e. , the number of previously received handles that need to be kept by an appraiser to deal with propagation delay .
Paragraph (version B):
More generally, in order to prevent an appraising entity from
generating false negatives (e.g., discarding Evidence that is deemed
stale even if it is not), the appraising entity should keep an "epoch
window" consisting of the most recently received handles.  The depth
of such epoch window is directly proportional to the maximum network
propagation delay between the first to receive the handle and the
last to receive the handle, and it is inversely proportional to the
epoch duration.
The appraising entity shall compare the handle carried in the
received Evidence or Attestation Result with the handles in its epoch
window to find a suitable match.
Draft: draft-ietf-rats-architecture

Commentary: ` Does this mean to imply that bogus policy ca n’t be installed by sneakernet , e.g. , on a usb thumb drive ? ? 
 I do n't think the ' via a network protocol ' is necessary . The consideration is simply that policies have security considerations that are out of scope of the architecture .
Paragraph (version A):
It is also important that the appraisal policy was itself obtained
securely.  As such, if appraisal policies for a Relying Party or for
a Verifier can be configured via a network protocol, the ability to
create Evidence about the integrity of the entity providing the
appraisal policy needs to be considered.
Paragraph (version B):
It is also important that the appraisal policy was itself obtained
securely.  If an attacker can configure appraisal policies for a
Relying Party or for a Verifier, then integrity of the process is
compromised.
Draft: draft-ietf-rats-architecture

Commentary: It seems that all that ’s relevant to RATS is “ if the key is generated externally , the manufacturer needs to take care to protect it with measures consistent with its value ” ` This case does seem different – there is simply no known way to extract the key . 
 I agree with MCR 's summary that “ if the key is generated externally , the manufacturer needs to take care to protect it with measures consistent with its value ” . Can we replace the bulk of section 12.1.2 with this single sentence ? The expectation is that private keys ca n't be extracted ( read ) once provisioned . That should be a stated security assumption . This section reads like a tutorial or primer . That is n't the goal IMO . Security Considerations should state our our security assumptions . 
 { not my comment .  's . If you like that part , generate a pull request please ! }
Paragraph (version A):
One way to provision a key is to first generate it external to the
device and then copy the key onto the device.  In this case,
confidentiality of the generator, as well as the path over which the
key is provisioned, is necessary.  This can be achieved in a number
of ways.
Paragraph (version B):
One way to provision a key is to first generate it external to the
device and then copy the key onto the device.  In this case,
confidentiality of the generator, as well as the path over which the
key is provisioned, is necessary.  The manufacturer needs to take
care to protect it with measures consistent with its value.  This can
be achieved in a number of ways.
Draft: draft-ietf-rats-architecture

Commentary: rebased . 
 ` The first sentence seems to say ‘ you can do whatever you want ’ , but the second seems to say “ you should sign the messages ” This does n’t seem to be about integrity ; it says Evidence must be confidential . Is that actually a requirement ? 
 I do n't see where it says RATS messages have to be confidential . ' end - to - end ' means between RATS roles . Which can be achieved at different nesting levels ; where nesting is interpreted to mean nesting in the message ( data ) layers . Summary - I do n't see a problem with the proposed text . 
 I am inclined to agree with  here , but we could change the first line , while we 're at it . The reuse of the word " protected " used in the 1st sentence in the 2nd sentence now might make it more clear that this message protection can happen on many layers . 
 Ok but this PR merges into the branch instead of master . Recommend rebasing on master so that order of merge does n't matter .
Paragraph (version A):
The security of conveyed information may be applied at different
layers, whether by a conveyance protocol, or an information encoding
format.  This architecture expects attestation messages (i.e.,
Evidence, Attestation Results, Endorsements, Reference Values, and
Policies) are end-to-end protected based on the role interaction
context.  For example, if an Attester produces Evidence that is
relayed through some other entity that doesn't implement the Attester
or the intended Verifier roles, then the relaying entity should not
expect to have access to the Evidence.
Paragraph (version B):
The security protecting conveyed information may be applied at
different layers, whether by a conveyance protocol, or an information
encoding format.  This architecture expects attestation messages
(i.e., Evidence, Attestation Results, Endorsements, Reference Values,
and Policies) are end-to-end protected based on the role interaction
context.  For example, if an Attester produces Evidence that is
relayed through some other entity that doesn't implement the Attester
or the intended Verifier roles, then the relaying entity should not
expect to have access to the Evidence.
Draft: draft-ietf-rats-architecture

Commentary: 2nd to last para . in composite device section should be be given its own section heading - # # Entity 
 The second to last paragraph in Composite Device section is not describing composite devices . Instead it describes role - entity semantics . It should be given its own section heading e.g. " Entities " and the last paragraph / sentence should be moved up ( into the composite device section ) .
Paragraph (version A):
An entity can take on multiple RATS roles (e.g., Attester, Verifier,
Relying Party, etc.) at the same time.  The combination of roles can
be arbitrary.  For example, in this Composite Device scenario, the
entity inside the lead Attester can also take on the role of a
Verifier, and the outside entity of Verifier can take on the role of
a Relying Party.  After collecting the Evidence of other Attesters,
this inside Verifier uses Endorsements and appraisal policies
(obtained the same way as any other Verifier) in the verification
process to generate Attestation Results.  The inside Verifier then
conveys the Attestation Results of other Attesters, whether in the
same conveyance protocol as the Evidence or not, to the outside
Verifier.
Paragraph (version B):
An entity can take on multiple RATS roles (e.g., Attester, Verifier,
Relying Party, etc.) at the same time.  Multiple entities can
cooperate to implement a single RATS role as well.  The combination
of roles and entities can be arbitrary.  For example, in the
Composite Device scenario, the entity inside the lead Attester can
also take on the role of a Verifier, and the outer entity of Verifier
can take on the role of a Relying Party.  After collecting the
Evidence of other Attesters, this inside Verifier uses Endorsements
and appraisal policies (obtained the same way as any other Verifier)
in the verification process to generate Attestation Results.  The
inside Verifier then conveys the Attestation Results of other
Attesters to the outside Verifier, whether in the same conveyance
protocol as the Evidence or not.
Draft: draft-ietf-rats-architecture

Commentary: Updated paragraph describing collection of Evidence from sub - attesters 
 Should this section include an Informative Reference to the Trusted Computing Group “ Guidance for Securing Network Equipment ” It seems to repeat more or less the same thing , but using the RATS lexicon 
 Another comment I have on this section is about the trust model of a composite device : it looks like the lead attester needs to be trusted to collect the most fresh evidence from the other slots ? Is this discussed anywhere ? 
 Who do you mean the lead Attester needs to be trusted by ? The Verifier / Relying Party or other slots / Attesters ? The collecting capability is one of the characteristics the lead Attester has . So after the Verifier verifies the Evidence of the lead Attester successfully , it can trust the lead Attester 's collecting capability . The Evidence of other slots are signed by these slots themselves , and these slots can send Evidence to the lead Attester just as the lead Attester sends Evidence to the on - path router to the Verifier . 
 I meant the latter - apologies for the lack of precision . In particular , I am interested in the scenario where a compromised lead that has cached some previously collected evidences , can forward those instead of fresh slots ' attestations .
Paragraph (version A):
In the Composite Device, each Attester generates its own Evidence by
its Attesting Environment(s) collecting the claims from its Target
Environment(s).  The lead Attester collects the Evidence of all other
Attesters and then generates the Evidence of the whole Composite
Attester.
Paragraph (version B):
In the Composite Device, each Attester generates its own Evidence by
its Attesting Environment(s) collecting the claims from its Target
Environment(s).  The lead Attester collects the Evidence from the
other Attesters and conveys it to a Verifier.  Collection of Evidence
from sub-entities may itself be a form of Claims collection that
results in Evidence asserted by the lead Attester.  The lead Attester
generates the Evidence about the layout of the Composite Device,
while sub-Attesters generate Evidence about their respective modules.
Draft: draft-ietf-rats-architecture

Commentary: Added clarifying text - 
 " including roots of trust " from . 
 We should add the sentence " Normally , claims are not self - asserted by a layer or root of trust . " in the section describing layered attester / layering . around line 1120 ? 
 I 'd not object that . I 'd be okay with " Normally , claims are not self - asserted by a root of trust . "
Paragraph (version A):
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.
Paragraph (version B):
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.  Normally, Claims are not self-asserted, rather a
previous layer acts as the Attesting Environment for the next layer.
Claims about a root of trust typically are asserted by Endorsers.