jiebi/TextFlow huggingface dataset:
Original text:
As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas <del> the Homenet Zone is hosted on the HNA.  Motivations for keeping these two zones identical are detailed in sec-views, and this section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </del>  In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the

Reviewer comments:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Revised text:
As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas  <ins> the Homenet Zone is hosted on the HNA.  This section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </ins> In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the
Original text:
Reasons for signing the zone by the HNA are: <del> 1) Keeping the Homenet Zone and the Public Homenet Zone equal to </del>  securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the

Reviewer comments:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Revised text:
Reasons for signing the zone by the HNA are:  <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely optimize DNS resolution.  As the Public Zone is signed with DNSSEC, RRsets are authenticated, and thus DNS responses can be validated even though they are not provided by the
Original text:
otherwise a resolution with the Public Authoritative Server(s) would be performed. <del> 2) Keeping the Homenet Zone and the Public Homenet Zone equal to </del>  securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home

Reviewer comments:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Revised text:
otherwise a resolution with the Public Authoritative Server(s) would be performed.  <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home
Original text:
lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s). <del> 3) Keeping the Homenet Zone and the Public Homenet Zone equal to guarantee coherence between DNS responses.  Using a unique zone is one way to guarantee uniqueness of the responses among servers and places.  Issues generated by different views are discussed in more details in sec-views. 4) Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </del>  Reasons for signing the zone by the Outsourcing Infrastructure are:

Reviewer comments:
…ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.

Revised text:
lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s).  <ins> Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </ins> Reasons for signing the zone by the Outsourcing Infrastructure are:
Original text:
This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a <del> verifier evaluates the validity of information about an Attester. </del>  Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that <del> direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. </del>  Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where

Reviewer comments:
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.

Revised text:
This document uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a  <ins> Verifier evaluates the validity of information about an Attester. </ins> Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that  <ins> direct how a Relying Party uses the evaluation results about an Attester generated by the Verifiers.  Compare /security policy/ in [RFC4949]. </ins> Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where
Original text:
transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be <del> collected from or about each layer.  The corresponding claims can be </del>  structured in a nested fashion that reflects the nesting of the <del> Attester's layers. </del>  The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system

Reviewer comments:
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."

Revised text:
transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be  <ins> collected from or about each layer.  The corresponding Claims can be </ins> structured in a nested fashion that reflects the nesting of the  <ins> 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. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system
Original text:
Relying Party or for a Verifier, then integrity of the process is compromised. <del> 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 </del>  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

Reviewer comments:
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 doesn’t seem to be about integrity; it says Evidence must be confidential. Is that actually a requirement?
I don'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 don't see a problem with the proposed text.
I am inclined to agree with Ned 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 doesn't matter.

Revised text:
Relying Party or for a Verifier, then integrity of the process is compromised.  <ins> 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 </ins> 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
Original text:
measures appropriate for its value. The degree of protection afforded to this key material can vary by <del> device, based upon considerations as to a cost/benefit evaluation of the intended function of the device.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </del>  encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form.  The physical

Reviewer comments:
** Section 12.1.2.1. Would it be more precise to say: OLD The degree of protection afforded to this key material can vary by device, based upon considerations as to a cost/benefit evaluation of the intended function of the device. NEW The degree of protection afforded to this key material can vary by the intended function of the device and the specific practices of the device manufacturer or integrator.

Revised text:
measures appropriate for its value. The degree of protection afforded to this key material can vary by  <ins> the intended function of the device and the specific practices of the device manufacturer or integrator.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </ins> encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form.  The physical
Original text:
constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its <del> public key algorithm and parameters. </del>  Thus, trusting a Verifier might be expressed by having the Relying <del> Party store the Verifier's public 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 </del>  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

Reviewer comments:
Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?

Revised text:
constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its  <ins> public key algorithm and parameters.  In the context of this document, a trust anchor may also be a symmetric key, as in TCG-DICE- SIBDA or the symmetric mode described in I-D.tschofenig-rats-psa- token. </ins> Thus, trusting a Verifier might be expressed by having the Relying  <ins> 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 </ins> 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
Original text:
As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion <del> of trust anchor store requirements.  Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification. </del>  If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate

Reviewer comments:
Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?

Revised text:
As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion  <ins> of trust anchor store requirements for protecting public keys. Section 6 of NIST-800-57-p1 contains a comprehensive treatment of the topic, including the protection of symmetric key material. Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification.  Additionally, if the trust anchor is a symmetric key, the trust anchor store must not allow unauthorized read. </ins> If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate
Original text:
9.  10. 11.

Reviewer comments:
Add in text from Birkholz draft, with some wordsmithing and grammatical fixes from Dave Thaler

Revised text:
9. <ins> 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. Protocols that convey Evidence or Attestation Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. </ins> 10. 11.
Original text:
for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 10. </del> 11.  This document does not require any actions by IANA. <del> 12. </del>  Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia,

Reviewer comments:
Here's a first attempt to combine terminology sections, and trust model. Includes new terms Endorser and Appraisal Policy per recent discussion. Signed-off-by: Dave Thaler
Done
Done. (But if you have feedback on a sentence like this in the future, please attach the comment directly to the code line under the "Files changed" tab, to make it easy to find which phrase you're referring to.)
Done
Updated. How about now?
I would like to discuss the possibility of combining the terms "Endorsement" and "Attestation Result". Just like we have an Appraisal Policy for a verifier and an Appraisal Policy for a relying party, some might view an Attestation Result as an Endorsement for use by the relying party. I'm ok either way, but wanted to discuss this in our next call to see if others think it would help or confuse things.
I still believe my original definition of Attestation is good, I haven't seen any comments here about what the problem was. For comparison, URL says it's "The process of validating the integrity of a computing device such as a server needed for trusted computing.". I'm also ok with that definition.
I’m OK with that wording for introducing the concept. It may break down if the terminology for ‘device’ and ‘trusted computing’ become overly specified / specific.
The word 'health' is generally being used where other words such as 'trustworthiness', or 'state' could be used. I'm concerned that 'health' might not easily be synonymous with 'trust'. It also seems to bias the architecture toward NEA (RFC5209) which IMO does not define attestation.

Revised text:
for detailing what kinds of information are disclosed, and to whom they are exposed.  11. <ins> 12. </ins> This document does not require any actions by IANA.  <ins> 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia,
Original text:
Issuer completes the issuance flow by computing a blinded response as follows:  The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status <del> code 200 whose body consists of "blind_sig", with the content type </del>  set as "message/token-response". 6.3.

Reviewer comments:
Generated from . cc NAME NAME NAME
These test vectors should cover the whole flow of the protocol, starting with the input and producing a output.

Revised text:
Issuer completes the issuance flow by computing a blinded response as follows: <ins> This is encoded and transmitted to the client in the following TokenResponse structure: </ins> The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status  <ins> code 200 whose body consists of TokenResponse, with the content type </ins> set as "message/token-response". 6.3.
Original text:
TokenChallenge message, along with information about what keys to use when requesting a token from the issuer.  The TokenChallenge message has the following structure: The structure fields are defined as follows:

Reviewer comments:
Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.

Revised text:
TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. <ins> Origins that support this authentication scheme need to handle the following tasks: Select which issuer to use, and configure the issuer name and token-key to include in WWW-Authenticate challenges. Determine a redemption context construction to include in the TokenChallenge, as discussed in context-construction. Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin names containing the origin. </ins> The TokenChallenge message has the following structure: The structure fields are defined as follows:
Original text:
names for which current connection is not authoritative (according to the TLS certificate). <del> Note that it is possible for the WWW-Authenticate header to include multiple challenges, in order to allow the client to fetch a batch of multiple tokens for future use. For example, the WWW-Authenticate header could look like this: </del>  <del> If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client. </del>  2.1.1.

Reviewer comments:
Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.

Revised text:
names for which current connection is not authoritative (according to the TLS certificate).  <ins> Caching and pre-fetching of tokens is discussed in caching. </ins>  <ins> Note that it is possible for the WWW-Authenticate header to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header could look like this: </ins> 2.1.1.
Original text:
address prefix). An empty redemption context is not bound to any property of the <del> client session. </del>  2.2.

Reviewer comments:
Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.

Revised text:
address prefix). An empty redemption context is not bound to any property of the  <ins> client session.  Preventing double spending on tokens requires the origin to keep state associated with the redemption context.  The size of this state varies based on the size of the redemption context.  For example, double spend state for unique, per-request redemption contexts does only needs to exist within the scope of the request connection or session.  In contrast, double spend state for empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. 2.1.2. Clients can generate multiple tokens from a single TokenChallenge, and cache them for future use.  This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoid any overhead of receiving new tokens via the issuance protocol. Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info.  Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match.  Note that each token has a unique client nonce, which is sent in token redemption (redemption). If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client. </ins> 2.2.