jiebi/CodeConvo huggingface dataset:
Change:
I also deleted a bunch of the (outdated) system design text. I'm sure this can be simplified, but I think this captures the basic assumptions (at least in my mental model).
Indeed, the text doesn't require any specific mitigation, and I don't see why it should. Aggregators could do the thing described in the appendix, or they could keep a huge list of all reports seen thus far. There could even be some simpler variant in the future I don't think we lose anything by eliding the implementation details here.

Discussion:
In addition, for each PDAParam instance, leaders are required to: <del> Ensure that, for each report, all aggregator shares are either included or not in a given batch; </del> Implement and store state for the form of inter- and intra-batch replay mitigation in anti-replay; and
Change:
One possible extension would be an opaque blob to carry client attestation information (for ), if desired. The current set is empty, but I suspect we'll need freedom to extend here as this gets used without totally changing the protocol version. If folks are generally supportive of this, it should probably land after , which touches and renames PDAUploadReq to PDAReport.
Both (1) and (2) are external to the protocol. The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report, as is done here. This is done in the change. This is not meant to close the attestation issue. It's meant to give us the mechanics to address it later.
Right you are. What threw me off was the following statement: The "then these extensions are required to be echoed..." makes it sound as if they're not echoed, which they are. I'm happy with this PR modulo fixing this statement.

Discussion:
to ensure that each report appears at most once in a batch.  (See anti-replay.) <ins> "extensions" is a list of extensions to be included in the Upload flow; see upload-extensions. </ins> "encrypted_input_shares" contains the encrypted input shares of each of the aggregators.

status 200 and an empty body.  Malformed requests are handled as described in pa-error-common-aborts. <ins> 3.3.3. Each PAUploadReq carries a list of extensions that clients may use to convey additional, authenticated information in the report.  Each extension is a tag-length encoded value of the following form: "extension_type" indicates the type of extension, and "extension_data" contains information specific to the extension. </ins> 3.4. [TODO: Decide if and how the collector's request is authenticated.]

corresponding to a unique client report.  Sub-requests are structured as follows: <del> The "time" and "jitter" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report. [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The remainder of the structure is dedicated to the protocol-specific request parameters. </del> <ins> The "time", "jitter", and "extensions" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" field is the helper's encrypted input share as it appeared in the report.  [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall we exclude it in subsequent requests somehow?]  The remainder of the structure is dedicated to the protocol-specific request parameters. </ins> In order to provide replay protection, the leader is required to send aggregate sub-requests in ascending order, where the ordering on sub-

9. <del> TODO </del> <ins> 9.1. This document requests creation of a new registry for extensions to the Upload protocol.  This registry should contain the following columns: [TODO: define how we want to structure this registry when the time comes] </ins> 10.  References
Change:
I want to wait until we have the new definitions being worked in the CCC nailed down. (They look like they are getting close.) Then we can just reference or copy these. Eric
WFM. I have raised to track this.
LGTM, I've left a note unrelated to the change, but close enough to maybe deserve being addressed in the same PR?

Discussion:
This document recognizes three general categories of Attesters. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor <del> which continually hashes security measurements in a way which prevents an Attester from lying about measurements which have been extended into the Attesting Environment (e.g., TPM2.0.) </del> <ins> which hashes one or more streams of security measurements from an Attester within the Attesting Environment.  Maintenance of this hash enables detection of an Attester which is lying about the set of security measurements taken.  An example of a HSM is a TPM2.0 TPM2.0. </ins> Process-based: An individual process which has its runtime memory encrypted by an Attesting Environment in a way that no other

sequence, a Verifier evaluates an Attester and returns signed Attestation Results back to this original Attester no less frequently than a well-known interval.  This interval may also be asynchronous, <del> based on the changing of certain Evidence as described in I- D.birkholz-rats-network-device-subscription. </del> <ins> based on the changing of certain Evidence as described in I-D.ietf- rats-network-device-subscription. </ins> When a Relying Party is to receive information about the Attester's trustworthiness, the Attesting Environment assembles the minimal set
Change:
Based on request from Yogesh for a new Configuration encoded claim.
Thanks Eric! As you may have guessed, we have an immediate use for this 36 :-)

Discussion:
HSM-based: A Hardware Security Module (HSM) based cryptoprocessor which hashes one or more streams of security measurements from an Attester within the Attesting Environment.  Maintenance of this <del> hash enables detection of an Attester which is lying about the set of security measurements taken.  An example of a HSM is a TPM2.0 </del> <ins> hash enables detection of an Attester which is not reporting the exact set of security measurements (such as log entries) taken within the Attesting Environment.  An example of a HSM is a TPM2.0 </ins> TPM2.0. Process-based: An individual process which has its runtime memory

The configuration includes or exposes known vulnerabilities. <ins> Elements of the configuration relevant to security are unavailable to the Verifier. </ins> The configuration is unsupportable as it exposes unacceptable security vulnerabilities.

3.1.2. A simplified Background-Check Model may exist in a very specific <del> case. This is where the Relying Party and Verifier functions are co- </del> <ins> case.  This is where the Relying Party and Verifier functions are co- </ins> resident.  This model is appropriate when: Some hardware-based private key is used by an Attester while

gap with Zero Trust.  The credentials used for authentication and admission control can be manipulated on the endpoint.  Attestation can fill this gap through the generation of a compound credential <del> called AR-augmented Evidence. This compound credential is rooted in the hardware based Attesting Environment of an endpoint, plus the trustworthiness of a Verifier. The overall solution is known as "Below Zero Trust" as the compound credential cannot be manipulated or spoofed by an administrator of an endpoint with root access.  This solution is not adversely impacted by the potential drawbacks with pure background-check described above. </del> <ins> called AR-augmented Evidence.  This compound credential is rooted in the hardware based Attesting Environment of an endpoint, plus the trustworthiness of a Verifier.  The overall solution is known as "Below Zero Trust" as the compound credential cannot be manipulated or spoofed by an administrator of an endpoint with root access.  This solution is not adversely impacted by the potential drawbacks with pure background-check described above. </ins> To kick-off the "Below Zero Trust" compound credential creation sequence, a Verifier evaluates an Attester and returns signed
Change:
"There are two categorizations Verifier identities defined in this document" does not read awesomely. I am putting forward a (maybe even worse) alternative. Feel free to English-ise it.
Looks like an improvement

Discussion:
Trustworthiness Claims being relied upon from the Verifier considered the chain of trust for the Attesting Environment. <del> There are two categorizations Verifier identities defined in this document. </del> <ins> There are two categorizations of Verifier identities defined in this document: </ins> verifier build: a unique instance of a software build running as a Verifier.
Change:
Include changes from Sergei's semantic musings.
a little late, but this is an easy oneLGTM, I have inlined an editorial suggestion.

Discussion:
any distinction between a Trustworthiness Claim with enumeration '0', and no Trustworthiness Claim being provided. <del> Value 1: The Evidence received contains unexpected elements which the Verifier is unable to parse.  An example might be that the wrong type of Evidence has been delivered. </del> <ins> Value 1: The Evidence received contains unknown elements which the Verifier is unable to evaluate.  An example might be that the wrong type of Evidence has been delivered.  Another case is that of Evidence coming from a composite Attester: a Verifier may only understand only part of it and leave as "unknown" the Trustworthiness claims related to features it can't appraise. </ins> Value -1: A verifier malfunction occurred during the Verifier's appraisal processing.

No assertion <del> Verifer cannot parse unexpected Evidence. </del> <ins> Evidence contains unknown elements which inhibit Verifer evaluation. </ins> Verifier malfunction
Change:
NAME : Please let me know, your views as to how is the information flow and anything else, we need to add?

Discussion:
an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness. <ins> 7.1.1. According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section highlights the information flows bewteen the Attester, Verifier and Relying Party undergoing Remote Attestation Procedure, using these models. Passport Model The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this Model, the attestation sequence is a two step procedure.  In the first step, an Attester conveys Evidence to a Verifier which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and possibly additional Claims/evidence) to a Relying Party, which then compares this information against its own appraisal policy to establish the trustworthiness of the attestor. BackGround Check Model The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which does not process its payload, but realys the message and optionally check its signature against a policed trust anchor store.  Upon receiving the evidence the Relying Party initiates a session with the Verifier.  Once session is established, it forwards the received Evidence to the Verfier.  The Verifier, appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </ins> 7.2. Uni-Directional Remote Attestation procedures can be initiated both
Change:
fix some typos and optimize the newly added diagrams to adapt to the width limitation
Thanks Wei! My humongous backlog told me "you'll fix this later" and now you did. Awesome!

Discussion:
According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section <del> highlights the information flows bewteen the Attester, Verifier and </del> <ins> highlights the information flows bewteen the Attester, Verifier, and </ins> Relying Party undergoing Remote Attestation Procedure, using these models.

The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this model, the <del> attestation sequence is a two step procedure.  In the first step, an Attester conveys Evidence to a Verifier which compares the Evidence </del> <ins> attestation sequence is a two-step procedure.  In the first step, an Attester conveys Evidence to a Verifier, which compares the Evidence </ins> against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and

how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which <del> does not process its payload, but realys the message and optionally check its signature against a policed trust anchor store.  Upon receiving the evidence the Relying Party initiates a session with the Verifier.  Once session is established, it forwards the received Evidence to the Verfier.  The Verifier, appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </del> <ins> does not process its payload, but relays the message and optionally checks its signature against a policed trust anchor store.  Upon receiving the Evidence, the Relying Party initiates a session with the Verifier.  Once the session is established, it forwards the received Evidence to the Verifier.  The Verifier appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </ins> 7.2.
Change:
(As per Ned Smith's message of November 8, 2022)
Claim Key as specified in RFC8392 are currently called lables in the CDDL in the Appendix. "Claim Key" by itself is only used in the definition of UCCS and never again. Should we decide on a consistent use of Claim Key or highlight that is a synonym to label before the CDDL in appendix?

Discussion:
(for example, to keep the implementation complexity to a minimum) and has a secure channel, such as a local IPC, to interact with a lead Attester (see Composite Device, I-D.ietf-rats-architecture).  The <del> sub-Attester produces a UCCS with the required set of claims and </del> <ins> sub-Attester produces a UCCS with the required CWT Claims Set and </ins> sends the UCCS through the secure channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example,

Environment based on the cryptographic mechanisms used when a privacy preserving secure channel is employed. <del> In the case of a Remote Attestation, the attester must consider </del> <ins> In the case of a Remote Attestation, the Attester must consider </ins> whether any UCCS it returns over a privacy preserving secure channel compromises the privacy in unacceptable ways.  As an example, the use of the EAT UEID I-D.ietf-rats-eat Claim in UCCS over a privacy
Change:
Fixed typo identified by Alex Nelson. Also removed some extra working text that was accidentally left in an IANA section. This PR will be kept open until the WGLC concludes.

Discussion:
UTF-8 RFC3629" (see RFC7049 section 2.1).  Thus both SWID and CoSWID use UTF-8 for the encoding of characters in text strings. <del> To ensure that UTF-8 character strings are able to be encodes/decoded </del> <ins> To ensure that UTF-8 character strings are able to be encoded/decoded </ins> and exchanged interoperably, text strings in CoSWID MUST be encoded consistent with the Net-Unicode definition defined in RFC5198.

If the supplemental item is set to "true", the tag SHOULD contain at least one link item with both the rel(ation) item value of <del> "supplements" and an href item specifying an association with the </del> <ins> "supplemental" and an href item specifying an association with the </ins> software that is supplemented. If all of the corpus, patch, and supplemental items are "false",

5.6.1. <del> SWID or CoSWID by the referenced tag's tag-id.  This URI needs to be resolved in the context of the endpoint by software that can lookup other SWID or CoSWID tags.  For example, "swid:2df9de35-0aff- 4a86-ace6-f7dddd1ade4c" references the tag with the tag-id value "2df9de35-0aff-4a86-ace6-f7dddd1ade4c". </del> There is a need for a scheme name that can be used in URIs that point to a specific SWID/CoSWID tag by that tag's tag-id, such as the use of the link entry as described in section model-link) of this

[THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] <ins> Changes in version 12: Addressed a bunch of minor editorial issues based on WGLC feedback. Added text about the use of UTF-8 in CoSWID. Adjusted tag-id to allow for a UUID to be provided as a bstr. Cleaned up descriptions of index ranges throughout the document, removing discussion of 8 biut, 16 bit, etc. Adjusted discussion of private use ranges to use negative integer values and to be more clear throughout the document. Added discussion around resolving overlapping value spaces for version schemes. Added a set of expert review guidelines for new IANA registries created by this document. Added new registrations for the "swid" and "swidpath" URI schemes, and for using CoSWID with SWIMA. </ins> Changes from version 03 to version 11: Reduced representation complexity of the media-entry type and
Change:
Added back IANA registrations (as provisional) for swid and swidpath URI schemes. Slight re-wording of the intro paragraph to section 5 (discussing the schemes) to reflect this modification.

Discussion:
5. <del> This specification defines the following expressions for use in CoSWID and to provide interoperability with schemes used in SWID. Because both the "swid" and "swidpath" schemes are to be interpreted within a local, rather than a global, context, neither of these scheme are URIs as defined in RFC3986 and the swid and swidpath scheme names are not registered as permanent schemes with IANA.  That noted, swid and swidpath expressions conform to all rules for URI </del> <ins> This specification defines the following scheme names for use in CoSWID and to provide interoperability with scheme names used in SWID.  Because both the "swid" and "swidpath" scheme names are to be interpreted within a local (rather than a global) context, neither of these are technically URI scheme names as defined in RFC3986.  For this reason, the swid and swidpath scheme names are registered with IANA as provisional, rather than permanent, scheme names.  However, registering these scheme names as provisional ensures that the scheme names are reserved and that they are properly defined going forward. The swid and swidpath expressions conform to all rules for URI </ins> syntax.  All uses of these expressions encountered within a CoSWID are to be interpreted as described in this section.

6.6. <ins> The ISO 19770-2:2015 SWID specification describes use of the "swid" and "swidpath" URI schemes, which are currently in use in implementations.  This document continues this use for CoSWID.  The following subsections provide registrations for these schemes in to ensure that a registration exists for these schemes that is suitable for use in the SWID and CoSWID specifications.  URI schemes are registered within the "Uniform Resource Identifier (URI) Schemes" registry maintained at IANA.uri-schemes. 6.6.1. IANA is requested to register the URI scheme "swid".  This registration request complies with RFC7595. 6.6.2. IANA is requested to register the URI scheme "swidpath".  This registration request complies with RFC7595. 6.7. </ins> The Software Inventory Message and Attributes (SWIMA) for PA-TNC specification RFC8412 defines a standardized method for collecting an endpoint device's software inventory.  A CoSWID can provide evidence
Change:
Updates to address 3 of four open issues
Version -09 The document is not consistent if the character following the pithy title is capitalized. A pass needs to be made to fix this.
Hi Jim, I only found 1 straggler in IM-URL there are others please let me know so I can fold it into the -10 draft. Thanks, Nancy
Fixed in Pull request
-version 09 There are two nits that needs to be resolved. Missing 2119 boilerplate Reference to RFC 3444 exists, but is not referred to.
Hi Jim, Will fix in -10 draft..... Thanks, Nancy
Fixed in Pull request

Discussion:
cases.  Also, this document uses terminology defined in I-D.ietf- sacm-terminology. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. When the words appear in lower case, their natural language meaning is used. </ins> 2. This document defines requirements based on the SACM use cases

models must adhere to and comply with the SACM information model. The requirements for the SACM information model include: <del> Extensible Attribute Vocabulary: the information model MUST define </del> <ins> Extensible Attribute Vocabulary: The information model MUST define </ins> a minimum set of attributes for communicating Posture Information, to ensure interoperability between data models.  (Individual data models may define attributes beyond the mandatory-to-implement

structure, and the ability to search based on patterns ("wildcard searches") as well as specific data elements. <del> Full Vs.  Partial Updates: The data model SHOULD include the </del> <ins> Full vs. Partial Updates: The data model SHOULD include the </ins> ability to allow providers of data to provide the data as a whole, or when updates occur.  For example, a consumer can request a full update on initial engagement, then request to receive deltas

Either or both confidentiality and integrity at the data layer. <ins> 4.2. SACM information may contain sensitive information about the target endpoint as well as revealing identity information of the producer or consumer of such information.  Similarly, as part of the SACM discovery mechanism, the advertised capabilities (and roles, e.g. SACM components enabled) by the endpoint may be construed as private information.  There may be applications as well as business and regulatory practicess that require that aspects of such information be hidden from any parties that do not need to know it. Data confidentiality can provide some level of privacy but may fall short where unecessary data is still transmitted.  In those cases, filtering requirements at the data model such as OP-005 must be applied to ensure that such data is not disclosed.  RFC6973 provides guidelines for which SACM protocols and information and data models should follow. </ins> 5. 5.1.
Change:
A couple of bookkeeping changes: Fix a format error in the readme Make the date be the date it was generated rather than a fixed date Change the document title to be more generic as it does not match the published numbered version on the IETF website.

Discussion:
Secure Automation and Continuous Monitoring (SACM) Terminology <del> draft-ietf-sacm-terminology-07 </del> <ins> draft-ietf-sacm-terminology-latest </ins> Abstract