jiebi/CodeConvo huggingface dataset:
Code change:
Signed-off-by: Dave Thaler
` Isolate? From what? “Isolation” seems to be used several times in this and later sections without saying who’s isolating what from whom.
I don't understand that sentence either. Propose removing it. Another sentence: Propose removing "isolation and" Other uses of isolation I think are fine, where it means that an Attesting Environment cannot be modified by a Target Environment it measures. Any way of protecting that might be called "isolating" the two environments from each other in some way.

Related discussion:
text: 12.1. <del> Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. </del> <ins> Implementers need to pay close attention to the protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because an attacker can forge Evidence or manipulate the Attesting Environment.  For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, by isolating the two environments from each other in some way. </ins> Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to
Code change:
` 1) Is this a normative statement? 2) I think the next paragraph says that maybe it’s not an asymmetric key, and anyways, keys are out of scope for RATS Arch
In a layered device architecture the previous layer "provisions" the next layer. Hence, it isn't possible for the 'manufacturer' entity to do that. I don't know why a section on "Verifier" is going into so much detail about the Attester.

Related discussion:
text: vouched for via Endorsements because no Evidence is generated about them are referred to as roots of trust. <del> The manufacturer of the Attester arranges for its Attesting Environment to be provisioned with key material.  The key material is typically in the form of an asymmetric key pair (e.g., an RSA or ECDSA private key and a manufacturer-signed IDevID certificate) secured in the Attester. The Verifier is provided with an appropriate trust anchor, or provided with a database of public keys (rather than certificates), or even carefully secured lists of symmetric keys.  The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation of an Attestation system, but is not the subject of standardization within this architecture. </del> <ins> The manufacturer having arranged for an Attesting Environment to be provisioned with key material with which to sign Evidence, the Verifier is then provided with some way of verifying the signature on the Evidence.  This may be in the form of an appropriate trust anchor, or the Verifier may be provided with a database of public keys (rather than certificates) or even carefully secured lists of symmetric keys. The nature of how the Verifier manages to validate the signatures produced by the Attester is critical to the secure operation of an Attestation system, but is not the subject of standardization within this architecture. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the
Code change:
` Does this mean to imply that bogus policy can’t be installed by sneakernet, e.g., on a usb thumb drive??
I don'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.

Related discussion:
text: boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained <del> 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. </del> <ins> securely.  If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. </ins> The security of conveyed information may be applied at different layers, whether by a conveyance protocol, or an information encoding
Code change:
` 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.

Related discussion:
text: Claims about a root of trust typically are asserted by Endorsers. The device illustrated in layered includes (A) a BIOS stored in read- <del> only memory, (B) an updatable bootloader, and (C) an operating system kernel. </del> <ins> only memory, (B) an operating system kernel, and (C) an application or workload. </ins> Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There
Code change:
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.
NAME do you want to fix this still?
I'll add it to my list.

Related discussion:
text: in read-only memory, (B) a bootloader, and (C) an operating system kernel. <del> The first Attesting Environment, the read-only BIOS in this example, has to ensure the integrity of the bootloader (the first Target </del> <ins> The first Attesting Environment, the ROM in this example, has to ensure the integrity of the bootloader (the first Target </ins> 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
Code change:
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

Related discussion:
text: whether in the same conveyance protocol as part of the Evidence or not. <ins> 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. </ins> 4. RFC4949 has defined a number of terms that are also used in this
Code change:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, 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: Dave Thaler

Related discussion:
text: obtained via some other mechanism such as being configured in the Verifier by an administrator. <del> 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. 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. </del> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy
Code change:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, 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: Dave Thaler

Related discussion:
text: 4.1. <ins> 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. 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. 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. 4.2. </ins> 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
Code change:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, 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: Dave Thaler

Related discussion:
text: Environments are designed specifically with claims collection in mind. <del> 4.2. </del> <ins> 4.3. </ins> By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several
Code change:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, 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: Dave Thaler

Related discussion:
text: Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation. <del> 4.3. </del> <ins> 4.4. </ins> A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal
Code change:
only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences

Related discussion:
text: Universal Time, or might be defined relative to some other timestamp or timeticks counter. <del> We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </del> <ins> Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </ins> 15.1.
Code change:
only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences

Related discussion:
text: 15.3. The following example illustrates a hypothetical Background-Check <del> Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The time considerations in this example are equivalent to those discussed under Example 1 above. </del> <ins> Model solution that uses centrally generated identifiers for explicit time-keeping (referred to as "handle" in this example).  Handles can be qualifying data, such as nonces or signed timestamps.  In this example, centrally generated signed timestamps and - and synchronized clocks between all entities - are distributed in periodic intervals as handles.  If the Attester lacks a source of time based on an absolute timescale, a relative source of time, such as a tick counter can be used, alternatively.  In this example, evidence generation is not triggered at value generation, but at events at which the Attesting Environment becomes of changes to the Target Environment. In comparison with example 1, the time considerations in this example go into more detail with respect to the life-cycle of Claims and Evidence.  While the goal is to create up-to-date and recent Evidence as soon as possible, typically there is a latency between value generation and Attester awareness. At time(AA) the Attesting Environment is able to trigger an event (e.g. based on an Event-Condition-Action model) to create attestation Evidence that is as recent as possible.  In essence, at time(AA) the Attesting Environment is aware of new values that where generated at time(VG) and corresponding Claim values are collected immediately. Consecutively, Evidence based on relevant "old" Claims and the just collected "new" Claims is generated at time(EG).  In essence, the Claims used to generate the Evidence are generated at various time(VG) before time(AA). In order to create attestation Evidence at at time(AA), the Attester requires a fresh (i.e. not expired) centrally generated handle that has been distributed to all involved entities. In general, The duration a handle remains fresh depends on the content-type of the handle.  If it is a (relative or absolute) timestamp, clocks synchronized with a shared and trustworthy source of time are required.  If another value type is used as a handle, the reception time of the handle time(HD) provides an epoch (relative time of zero) for measuring the duration of validity (similar to a heart-beat timeout).  From the point of view of a Verifier, validity of Evidence is only given if the handle used in Evidence satisfies delta(time(HD),time(EG))distribution-interval. In this usage scenario, time(VG), time(AA), and time(EG) are tightly coupled.  Also, the absolute point in time at which a handle is received by all three entities is assumed to be close to identical. </ins> 15.4.
Code change:
cc NAME
There should be documentation that addresses the risks of the centralization in the current Privacy Pass architecture with potential solutions. This was raised in the previous WG meeting: URL This documentation should either be incorporated into the architecture document as a section when discussing the shape of the ecosystem, and/or security considerations. There is also the option of declaring a separate document for addressing this.
A draft has been put forward for this by Mark McFadden: URL, and will be discussed at IETF 110. Will leave this open for now, until this draft (or some form of it) is accepted.

Related discussion:
text: attempted against.  An empty redemption is returned when the limit has been hit: <ins> 5.4. A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants. CENTRALIZATION discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the model used to control the Web's trust model. Alternatively, Privacy Pass deployments might mitigate this problem through implementation.  For example, rather than centralize the role of attestation in one or few entities, attestation could be a distributed function performed by a quorum of many parties, provided that neither Issuers nor Origins learn which attester implementations were chosen.  As a result, clients could have more opportunities to switch between attestation participants. </ins> 6. We present a number of security considerations that prevent malicious
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin <del> authorization tokens that protect the client's anonymity during </del> <ins> authorization tokens that protect the Clients' anonymity during </ins> interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA <del> challenges can be attested to have this capability for the purposes of being ruled out as a bot or otherwise automated Client. </del> <ins> challenges can be attested to have this capability for the purpose of being ruled out as a bot or otherwise automated Client. </ins> Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the <del> number of issuance protocol invocations, the client's geographic </del> <ins> number of issuance protocol invocations, the Client's geographic </ins> region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements. <del> Each of these attestation types have different security properties. </del> <ins> Each of these attestation types has different security properties. </ins> For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats.
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In <del> Split Attester and Issuer deployments, Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow-lists. </del> <ins> Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow- lists. </ins> 3.2.2.
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that <del> an Issuer uses to produce tokens corresponds to a number of different pieces of information. </del> <ins> an Issuer uses to produce tokens corresponds to two different pieces of information. </ins> The issuance protocol in use; and
Code change:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Related discussion:
text: public metadata is metadata the client can see but cannot check for correctness.  As an example, the opaque public metadata might be a "fraud detection signal", computed on behalf of the Issuer, during <del> token issuance.  In normal circumstances, clients cannot determine if </del> <ins> token issuance.  In normal circumstances, Clients cannot determine if </ins> this value is correct or otherwise a tracking vector. <del> Private metadata is that which clients cannot observe as part of the </del> <ins> Private metadata is that which Clients cannot observe as part of the </ins> token issuance flow.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21.