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

Commentary: You want to say " Certification Authority " not " Certificate Authority " 
 yeah . thanks for catching that !
Paragraph (version A):
Thus, trusting a Verifier might be expressed by having the Relying
Party store the Verifier's key or certificate in its trust anchor
store, or might be expressed by storing the public key or certificate
of an entity (e.g., a Certificate Authority) that is in the
Verifier's certificate path.  For example, the Relying Party can
verify that the Verifier is an expected one by out-of-band
establishment of key material, combined with a protocol like TLS to
communicate.  There is an assumption that between the establishment
of the trusted key material and the creation of the Evidence, that
the Verifier has not been compromised.
Paragraph (version B):
Thus, trusting a Verifier might be expressed by having the Relying
Party store the Verifier's key or certificate in its trust anchor
store, or might be expressed by storing the public key or certificate
of an entity (e.g., a Certification Authority) that is in the
Verifier's certificate path.  For example, the Relying Party can
verify that the Verifier is an expected one by out-of-band
establishment of key material, combined with a protocol like TLS to
communicate.  There is an assumption that between the establishment
of the trusted key material and the creation of the Evidence, that
the Verifier has not been compromised.
Draft: draft-ietf-rats-architecture

Commentary: a branch for minor edits / not as reported by COMMENTS
Paragraph (version A):
Amongst other things, this document is about trust and
trustworthiness.  Trust is a choice one makes about another system.
Trustworthiness is a quality about the other system that can be used
in making one's decision to trust it or not.  This is subtle
difference and being familiar with the difference is crucial for
using this document.  Additionally, the concepts of freshness and
trust relationships with respect to RATS are elaborated on to enable
implementers to choose appropriate solutions to compose their Remote
Attestation Procedures.
Paragraph (version B):
Amongst other things, this document is about trust and
trustworthiness.  Trust is a choice one makes about another system.
Trustworthiness is a quality about the other system that can be used
in making one's decision to trust it or not.  This is a subtle
difference and being familiar with the difference is crucial for
using this document.  Additionally, the concepts of freshness and
trust relationships with respect to RATS are elaborated on to enable
implementers to choose appropriate solutions to compose their Remote
Attestation Procedures.
Paragraph (version A):
Implicit and explicit timekeeping can be combined into hybrid
mechanisms.  For example, if clocks exist and are considered
trustworthy but are not synchronized, a nonce-based exchange may be
used to determine the (relative) time offset between the involved
peers, followed by any number of timestamp based exchanges.
Paragraph (version B):
Implicit and explicit timekeeping can be combined into hybrid
mechanisms.  For example, if clocks exist within the Attesting
Environment and are considered trustworthy (tamper-proof) but are not
synchronized, a nonce-based exchange may be used to determine the
(relative) time offset between the involved peers, followed by any
number of timestamp based exchanges.
Draft: draft-ietf-rats-architecture

Commentary: attempt to provide forward reference as requested on Monday 
 This looks good to me , although I wonder whether the sentence would make more sense at the end of the " Implementation Considerations " section ( a couple lines earlier in the document ) . I am ok either way . 
 Works for me . That would put that into section 1 . 
 " artifacts are defined by which roles produce them or consume them " - This sentence structure seems awkward . Is " artifacts are defined by the roles that produce or consume them " better?LGTM
Paragraph (version B):
As explained in overview, artifacts are defined by which roles
produce them or consume them.  In some protocol instantiations, other
roles may cache and forward artifacts as opaque data, to one or more
entities implementing the consuming role.
Draft: draft-ietf-rats-architecture

Commentary: The Relying Party role is assigned to entities that uses   by applying its own appraisal policy to make application - specific decisions , such as authorization decisions . should be The Relying Party role is assigned to entities that use Attestation Results by applying their own appraisal policies to make application - specific decisions , such as authorization decisions . or The Relying Party role is assigned to an entity that uses   by applying its own appraisal policy to make application - specific decisions , such as authorization decisions . 
 I 'm in favor of the second option : The Relying Party role is assigned to an entity that uses   by applying its own appraisal policy to make application - specific decisions , such as authorization decisions . 
 I am okay with second option .
Paragraph (version A):
The Relying Party role is assigned to entities that uses Attestation
Results by applying its own appraisal policy to make application-
specific decisions, such as authorization decisions.  This procedure
is called the appraisal of Attestation Results.
Paragraph (version B):
The Relying Party role is assigned to an entity that uses Attestation
Results by applying its own appraisal policy to make application-
specific decisions, such as authorization decisions.  This procedure
is called the appraisal of Attestation Results.
Draft: draft-ietf-rats-architecture

Commentary: Despite fixes in ,  asks : [ Roman 's comments on -13 ] -- Section 4.1 . In the definition of relying party , what does the sentence fragment " Compare /relying party/ in [ RFC4949 ] " mean ? -- Section 4.2 . Per the definition of " Claim " , what does " Compare /claim/ in [ RFC7519 ] " mean ? -- Section 4.2 . Per the definition of " Appraisal Policy for Attestation Results " , what does " Compare /security policy/ in [ RFC4949 ] " mean ? I continue to hold the position that this language " Compare /xxx/ in RFC # # # # " is not clear . In the natural language sense , that phrase does n't parse . If the semantics are being taken from Section 2.6 of RFC4949 , please explain that . However , it seems confusing to explicitly be listing antonyms ( which RF4949 suggests is the meaning of the " Compare " notation ) . In the case of a claim , is it an antonym -- is n't a claim here in fact similar to the one in Section 2 of RFC7519 ? 
 `
Paragraph (version B):
RFC4949 has defined a number of terms that are also used in this
document.  Some of the terms are close to, but not exactly the same.
Where the terms are similar, they are noted below with references.
As explained in RFC4949, Section 2.6 when this document says
"Compare:", the terminology used in this document differs
significantly from the definition in the reference.
Paragraph (version A):
A role performed by an entity that depends on the validity of
information about an Attester, for purposes of reliably applying
application specific actions.  Compare /relying party/ in RFC4949.
Paragraph (version B):
A role performed by an entity that depends on the validity of
information about an Attester, for purposes of reliably applying
application specific actions.  Compare: /relying party/ in
RFC4949.
Paragraph (version A):
A piece of asserted information, often in the form of a name/value
pair.  Claims make up the usual structure of Evidence and other
RATS artifacts.  Compare /claim/ in RFC7519.
Paragraph (version B):
A piece of asserted information, often in the form of a name/value
pair.  Claims make up the usual structure of Evidence and other
RATS artifacts.  Compare: /claim/ in RFC7519.
Paragraph (version A):
A set of rules that informs how a Verifier evaluates the validity
of information about an Attester.  Compare /security policy/ in
RFC4949.
Paragraph (version B):
A set of rules that informs how a Verifier evaluates the validity
of information about an Attester.  Compare: /security policy/ in
RFC4949.
Paragraph (version A):
A set of rules that direct how a Relying Party uses the
Attestation Results regarding an Attester generated by the
Verifiers.  Compare /security policy/ in RFC4949.
Paragraph (version B):
A set of rules that direct how a Relying Party uses the
Attestation Results regarding an Attester generated by the
Verifiers.  Compare: /security policy/ in RFC4949.
Draft: draft-ietf-rats-architecture

Commentary: related to There is something foundational I am not following about this section . The interactions described here do not conform behaviors described in the terminology in Section 4 or the high - level reference architecture of Figure 1 . I 'm not sure how to reconcile this discrepancy . Minimally , these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4 . [ restated here but same feedback on -13 ] -- Figure 5 . Shows the Attester consuming Attestation Results -- Figure 5 . Shows the Attester producing Attestation Results -- Figure 6 : Shows Relying party consuming Evidence -- Figure 6 : Shows the Relying Party producing / passing Evidence The introductory text states that " [ t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns . " I do n't follow what is being illustrated in the context of RATS . What is the takeaway for implementers or designers from this section ? [ Author 's response ] [ Roman 's response on -15 ] The above github comment addressed a few issues from the -13 review , but not this one . 
 Reply by email : " The Attester does not consume the Attestation Result , but might cache it . " 
 The text explains the intent correctly regardless of how the lines are drawn . I can convince myself that it is correct draw the line through the box ( or not ) . The important clarifying point should be that the end - to - end message flow as described in the conceptual architecture is preserved through the various topology models that may exist . Second point is there can be a large variety of topology models ( aka hybrids ) but none of these hybrids changes the expectation of end - to - end message flow . 
 also helps .
Paragraph (version B):
The Attester does not consume the Attestation Result, but might cache
it.
Paragraph (version A):
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 following example illustrates a hypothetical Background-Check
Model solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party.  The
Attester conveys Evidence to the Relying Party, which treats it as
opaque and simply forwards it on to the Verifier.
Draft: draft-ietf-rats-architecture

Commentary: Document says : If certificates are used as trust anchors , Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor , which includes checking for certificate revocation . See Section 6 of [ RFC5280 ] for details . 
 The situation is very much use case dependant . If one is going to rely upon certificates and paths and trust anchors , then a profile should say this . It might be wise to do that . Whole document is non - normative . 
 Are there some other documents that we can cite that are more prescriptive ? There are NIST documents that explain the issues , but are reluctant to be prescriptive . 
 If certificates are used as trust anchors , Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor , which may include checking for certificate revocation .
Paragraph (version A):
If certificates are used as trust anchors, Verifiers and Relying
Parties are also responsible for validating the entire certificate
path up to the trust anchor, which includes checking for certificate
revocation.  See Section 6 of RFC5280 for details.
Paragraph (version B):
If certificates are used as trust anchors, Verifiers and Relying
Parties are also responsible for validating the entire certificate
path up to the trust anchor, which includes checking for certificate
revocation.  For an example of such a proceedure see Section 6 of
RFC5280.
Draft: draft-ietf-rats-architecture

Commentary: use " active on - path attacker " rather than " man - in - the - middle "
Paragraph (version A):
Evidence is a set of Claims about the target environment that reveal
operational status, health, configuration or construction that have
security relevance.  Evidence is appraised by a Verifier to establish
its relevance, compliance, and timeliness.  Claims need to be
collected in a manner that is reliable such that a Target Environment
cannot lie to the Attesting Environment about its trustworthiness
properties.  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.
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 appraised by a Verifier to establish
its relevance, compliance, and timeliness.  Claims need to be
collected in a manner that is reliable such that a Target Environment
cannot lie to the Attesting Environment about its trustworthiness
properties.  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 an active on-path
attacker 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 :
Paragraph (version A):
Another approach to deal with Evidence is to remove PII from the
Evidence while still being able to verify that the Attester is one of
a large set.  This approach is often called "Direct Anonymous
Attestation".  See CCC-DeepDive section 6.2 for more discussion.
Paragraph (version B):
Another approach to deal with Evidence is to remove PII from the
Evidence while still being able to verify that the Attester is one of
a large set.  This approach is often called "Direct Anonymous
Attestation".  See CCC-DeepDive section 6.2 and I-D.ietf-rats-daa for
more discussion.
Draft: draft-ietf-rats-architecture

Commentary: Changes " read - only BIOS " to " ROM " to align with the diagram 
 I think the text “ the read - only BIOS in this example , has to ensure the integrity of the bootloader ” is wrong since the example no longer has a “ read - only BIOS ” component . It should say “ ROM ” to be consistent . If ROM is determined to be ambiguous as a Root of Trust and we decide to changed it to " RoT " then this sentence would be updated accordingly . 
 do you want to fix this still ? 
 I 'll add it to my list .
Paragraph (version A):
The first Attesting Environment, the read-only BIOS in this example,
has to ensure the integrity of the bootloader (the first Target
Environment).  There are potentially multiple kernels to boot, and
the decision is up to the bootloader.  Only a bootloader with intact
integrity will make an appropriate decision.  Therefore, the Claims
relating to the integrity of the bootloader have to be measured
securely.  At this stage of the boot-cycle of the device, the Claims
collected typically cannot be composed into Evidence.
Paragraph (version B):
The first Attesting Environment, the ROM in this example, has to
ensure the integrity of the bootloader (the first Target
Environment).  There are potentially multiple kernels to boot, and
the decision is up to the bootloader.  Only a bootloader with intact
integrity will make an appropriate decision.  Therefore, the Claims
relating to the integrity of the bootloader have to be measured
securely.  At this stage of the boot-cycle of the device, the Claims
collected typically cannot be composed into Evidence.
Draft: draft-ietf-rats-architecture

Commentary: Section 10 first paragraph has the phrase " Claims and their values " ; which is redundant . " Claims " is sufficient .
Paragraph (version A):
A Verifier or Relying Party might 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 might 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
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: Signed - off - by :   
 * * Section 12.2 Any solution that conveys information used for security purposes , whether such information is in the form of Evidence , Attestation Results , Endorsements , or appraisal policy ... Should reference values be included ? 
 same changes , conceptual messages
Paragraph (version A):
Conceptual messages carrying sensitive or confidential information
are expected to be integrity protected (i.e., either via signing or a
secure channel) and optionally might be confidentiality protected via
encryption.  If there isn't confidentiality protection of conceptual
messages themselves, the underlying conveyance protocol should
provide these protections.
Paragraph (version B):
Conceptual messages (see messages) carrying sensitive or confidential
information are expected to be integrity protected (i.e., either via
signing or a secure channel) and optionally might be confidentiality
protected via encryption.  If there isn't confidentiality protection
of conceptual messages themselves, the underlying conveyance protocol
should provide these protections.
Paragraph (version A):
Security protections in RATS may be applied at different layers,
whether by a conveyance protocol, or an information encoding format.
This architecture expects conceptual messages (see messages) to be
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):
Security protections in RATS may be applied at different layers,
whether by a conveyance protocol, or an information encoding format.
This architecture expects conceptual messages to be 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: Section 12.4 . Is there any read sensitivity for the trust anchor store ? Section 12.4 . Since RFC5280 is being invoked here , is there an expectation that certificates in RATS would confirm to this profile ? 
 -"For example , see Section 6 of [ RFC5280 ] " Discussion ensued about whether there is read sensitivity vs audit requirements , and whether this is even specific to RATS at all . 
 RFC6024 ? 
 " As noted in Section 7 , Verifiers and Relying Parties have trust anchor stores that must be secured . RFC6024 contains more discussion of trust anchor store requirements . "
Paragraph (version A):
As noted in trustmodel, Verifiers and Relying Parties have trust
anchor stores that must be secured.  Specifically, a trust anchor
store must resist modification against unauthorized insertion,
deletion, and modification.
Paragraph (version B):
As noted in trustmodel, Verifiers and Relying Parties have trust
anchor stores that must be secured.  RFC6024 contains more discussion
of trust anchor store requirements.  Specifically, a trust anchor
store must resist modification against unauthorized insertion,
deletion, and modification.
Draft: draft-ietf-rats-architecture

Commentary: The current attester description in § 2.7 is ambiguous and inconsistent with the earlier ones . Right now it reads : " Attester : Every FIDO Authenticator contains an Attester . " To clarify and align the attested description with the earlier ones , I suggest replacing this text with : " Attester component contained in a FIDO authenticator " . 
 Both definitions seem OK to me . The goal of the use cases is n't to provide a technical decomposition of the FIDO device IMHO . Rather , it is to provide a cursory level mapping to the abstract roles / role messages . In fact , if a change is needed I would simply have it say " Attester : FIDO Authenticator " . 
 I agree that a technical decomposition is not the goal , however the current formulation just differs too much from the other ones . The change you suggested - " Attested : FIDO Authenticator " - is a good alternative . 
 " Attester : A FIDO Authenticator " .
Paragraph (version A):
Every FIDO Authenticator contains an Attester.
Paragraph (version B):
FIDO Authenticator.
Draft: draft-ietf-rats-architecture

Commentary: * * Section 12.1.2 . I did n't see any of the obvious text that regardless of whether the key is generated on or off device , high quality randomness is needed .
Paragraph (version B):
The keys generated in the factory, whether generated in the device or
off-device by the factory SHOULD be generated by a Cryptographically
Strong Sequence (RFC4086, Section 6.2).