jiebi/CodeConvo huggingface dataset:
3.5. Regular TCP has the means of sending a reset (RST) signal to abruptly <del> close a connection.  With MPTCP, the RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows.  MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between </del> <ins> close a connection.  With MPTCP, a regular RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows.  MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between </ins> subflows.  It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection, and this is the MP_FASTCLOSE option.
is running out of resources.  In these cases, MPTCP should send the MP_FASTCLOSE.  This option is illustrated in tcpm_fastclose. <del> If Host A wants to force the closure of an MPTCP connection, the MPTCP Fast Close procedure is as follows: </del> <ins> If Host A wants to force the closure of an MPTCP connection, it has two different options: </ins> <del> Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake.  On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSE_WAIT state. </del> <ins> Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake.  On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down.  Host A now enters FASTCLOSE_WAIT state. </ins> <del> Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </del> <ins> Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake.  Host A can tear the subflows and the connection down immediately. If a host receives a packet with a valid MP_FASTCLOSE option, it shall process it as follows : Upon receipt of an ACK with MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole
If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow <del> where the MPTCP_RST has been sent), it SHOULD retransmit the </del> <ins> where the MP_FASTCLOSE has been sent), it SHOULD retransmit the </ins> MP_FASTCLOSE.  The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific.  A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP <del> RST itself when it releases state in order to clear any remaining state at middleboxes. </del> <ins> RST with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> 3.6.
ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a <del> "taskid" member which contains the associated PPM task ID, encoded with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </del> <ins> "taskid" member which contains the associated PPM task ID, encoded in Base 64 using the URL and filename safe alphabet with no padding as defined in sections 5 and 3.2 of RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For
MUST be in the same order.  The leader's endpoint MUST be the first in the list.  The order of the "encrypted_input_shares" in a "Report" (see uploading-reports) MUST be the same as the order in <del> which aggregators appear in this list. </del> <ins> which aggregators appear in this list.  Aggregators MAY use the same endpoint for multiple tasks. </ins> "max_batch_lifetime": The maximum number of times a batch of reports may be used in collect requests.
Before the client can upload its report to the leader, it must know the public key of each of the aggregators.  These are retrieved from <del> each aggregator by sending a request to "[aggregator]/hpke_config", where "[aggregator]" is the aggregator's endpoint URL, obtained from the task parameters.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: </del> <ins> each aggregator by sending a request to "[aggregator]/hpke_config?task_id=[task-id]", where "[aggregator]" is the aggregator's endpoint URL, obtained from the task parameters, and "[task-id]" is the task ID obtained from the task parameters, encoded in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize the task ID, then it responds with HTTP error status 404 Not Found and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: [TODO: Allow aggregators to return HTTP 403 Forbidden in deployments that use authentication to avoid leaking information about which tasks exist.] </ins> [OPEN ISSUE: Decide whether to expand the width of the id, or support multiple cipher suites (a la OHTTP/ECH).]
Each report share has a corresponding task ID, report metadata (report ID and, timestamp), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", <del> "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, it constructs an "InputShareAad" message from "task_id", "metadata", and "public_share".  Let this be denoted by "input_share_aad".  Then, the aggregator looks up the HPKE config and corresponding secret key indicated by "encrypted_input_share.config_id" and attempts decryption of the payload with the following procedure: </del> <ins> "report_metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, it constructs an "InputShareAad" message from "task_id", "report_metadata", and "public_share".  Let this be denoted by "input_share_aad".  Then, the aggregator looks up the HPKE config and corresponding secret key indicated by "encrypted_input_share.config_id" and attempts decryption of the payload with the following procedure: </ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).
Implementation note: The Leader considers a batch to be collected once it has completed a collection job for a <del> CollectReq message from the Collector; the Helper considers a batch to be collected once it has responded to an </del> <ins> CollectionReq message from the Collector; the Helper considers a batch to be collected once it has responded to an </ins> AggregateShareReq message from the Leader.  A batches is determined by query (query) conveyed in these messages. Queries must satisfy the criteria covered in batch-validation.
the hash values with a bitwise-XOR operation. Then, for each Aggregator endpoint "{aggregator}" in the parameters <del> associated with "CollectReq.task_id" (see collect-flow) except its </del> <ins> associated with "CollectionReq.task_id" (see collect-flow) except its </ins> own, the Leader sends a POST request to "{aggregator}/tasks/{task- id}/aggregate_shares" with the following message:
4.5.6. <del> Before an Aggregator responds to a CollectReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </del> <ins> Before an Aggregator responds to a CollectionReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </ins> First the Aggregator checks that the batch respects any "boundaries" determined by the query type.  These are described in the subsections
batch IDs.  Thus the Aggregator needs to check that the query is associated with a known batch ID: <del> For a CollectReq containing a query of type "by_batch_id", the </del> <ins> For a CollectionReq containing a query of type "by_batch_id", the </ins> Leader checks that the provided batch ID corresponds to a batch ID <del> it returned in a previous CollectResp for the task. </del> <ins> it returned in a previous Collection for the task. </ins> For an AggregateShareReq, the Helper checks that the batch ID provided by the Leader corresponds to a batch ID used in a
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-
to the PA protocol: The helper handles each sub-request "PAAggregateSubReq" as follows. <del> It first checks that checks that "PAAggregateSubReq.proto == PAParam.proto".  If not, it aborts and alerts the leader with "incorrect protocol for sub-request".  Otherwise, it computes the HPKE context as where "sk" is its HPKE key and computes the body of the "PAAggregateSubResp".  It then updates its state according to the PA protocol.  After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </del> <ins> It first looks up the HPKE config and corresponding secret key associated with "helper_share.config_id".  If not found, then the sub-response consists of an "unrecognized config" alert.  [TODO: We'll want to be more precise about what this means.  See issue#57.] Next, it attempts to decrypt the payload with the following procedure: where "sk" is the HPKE secret key.  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.] Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PA protocol. After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </ins> 3.4.2.1.1.
structure, which specify the protocol used to verify and aggregate the clients' measurements: <ins> "nonce": A unique sequence of bytes used to ensure that two otherwise identical "PDAParam" instances will have distinct "PDATaskID"s.  It is RECOMMENDED that this be set to a random 16-byte string derived from a cryptographically secure pseurandom number generator. </ins> "leader_url": The leader's endpoint URL. "helper_url": The helper's endpoint URL.
"proto": The PDA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters. <del> Each task has a unique _task id_ derived from the PDA parameters: </del> <ins> Each task has a unique _task ID_ derived from the PDA parameters: The task ID of a "PDAParam" `is derived using the following procedure: </ins> <del> The task id is derived using the following procedure.  [TODO: Specify derivation of the task ID.] </del> <ins> Where "SHA-256" is as specified in FIPS180-4. </ins> 3.1.2.
The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PDA parameters "PDAParam" for which <del> "PDAAggregateReq.task_id" is equal to the task id derived from </del> <ins> "PDAAggregateReq.task_id" is equal to the task ID derived from </ins> "PDAParam". The response consists of the helper's updated state and a sequence of
Each POST request to an aggregator contains a "PDATaskID".  If the aggregator does not recognize the task, i.e., it can't find a <del> "PDAParam" for which the derived task id matches the "PDATaskID", </del> <ins> "PDAParam" for which the derived task ID matches the "PDATaskID", </ins> then it aborts and alerts the peer with "unrecognized task". 4.
2. This document uses the following set of terms, roles, and concepts as <del> defined in I-D.ietf-rats-architecture: Attester, Verifier, Relying Party, Conceptual Message, Evidence, Endorsement, Attestation Result, Appraisal Policy, Attesting Environment, Target Environment </del> <ins> defined in I-D.ietf-rats-architecture: Attester, Verifier, Relying Party, Conceptual Message, Evidence, Endorsement, Attestation Result, Appraisal Policy, Attesting Environment, Target Environment </ins> A PKIX Certificate is an X.509v3 format certificate as specified by RFC5280.
interaction models in general, the following set of prerequisites MUST be in place to support the implementation of interaction models: <ins> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity, used as proof of identity. </ins> The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. <del> An Attester Identity MAY be a unique identity, it MAY be included in a zero-knowledge proof (ZKP), or it MAY be part of a group signature, or it MAY be a randomised DAA credential DAA. </del> <ins> An Attester Identity MAY be a unique identity, MAY be included in a zero-knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </ins> Attestation Evidence MUST be authentic. In order to provide proofs of authenticity, Attestation Evidence SHOULD be cryptographically associated with an identity document <del> (e.g. an PKIX certificate or trusted key material, or a randomised </del> <ins> (e.g. an PKIX certificate or trusted key material, or a randomized </ins> DAA credential DAA), or SHOULD include a correct and unambiguous and stable reference to an accessible identity document.
Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This
_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a
interaction models in general, the following set of prerequisites MUST be in place to support the implementation of interaction models: <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity, used as proof of identity. </del> <ins> An Authentication Secret MUST be available exclusively to an Attesting Environment of an Attester. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence.  The Authentication Secret MUST be established before RATS can take place. A statement about a distinguishable Attester made by an Endorser. </ins> The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. <del> An Attester Identity MAY be a unique identity, MAY be included in a zero-knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </del> <ins> An Attester Identity MAY be an Authentication Secret which is available exclusively to one of the Attesting Environments of an Attester.  It MAY be a unique identity, MAY be included in a zero- knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </ins> Attestation Evidence MUST be authentic. In order to provide proofs of authenticity, Attestation Evidence SHOULD be cryptographically associated with an identity document <del> (e.g. an PKIX certificate or trusted key material, or a randomized DAA credential DAA), or SHOULD include a correct and unambiguous and stable reference to an accessible identity document. An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence.  The Authentication Secret MUST be established before RATS can take place. </del> <ins> (e.g., a PKIX certificate or trusted key material, or a randomized DAA credential DAA), or SHOULD include a correct, unambiguous and stable reference to an accessible identity document. </ins> Evidence MUST include an indicator about its freshness that can be understood by a Verifier.  Analogously, interaction models MUST
Evidence as well as all accompanying Event Logs back to the Verifier. While it is crucial that Claims, the Handle, and the Attester <del> Identity information MUST be cryptographically bound to the signature of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </del> <ins> Identity information (i.e., the Authentication Secret) MUST be cryptographically bound to the signature of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </ins> <del> As soon as the Verifier receives the signed Evidence and Event Logs, it appraises the Evidence.  For this purpose, it validates the </del> <ins> As soon as the Verifier receives the Evidence and the Event Logs, it appraises the Evidence.  For this purpose, it validates the </ins> signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference
stored or transported, as compared to the less efficient text-based form of the original vocabulary. <ins> Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see model-extension).  New constructs can be associated with a new integer index.  A deprecated construct can be replaced by a new construct with a new integer index.  An implementation can use these integer indexes to identify the construct to parse.  The CoSWID Items registry, defined in iana-coswid-items, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis.  This approach avoids the need to have an explicit CoSWID version. </ins> The root of the CDDL specification provided by this document is the rule "coswid" (as defined in tagged):
integrity measurements for files.  The ISO-19770-2:2015 XML schema uses XML DSIG to support cryptographic signatures. <del> Signing CoSWID tags follows the procedues defined in CBOR Object Signing and Encryption RFC8152.  A CoSWID tg MUST be wrapped in a </del> <ins> Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption RFC8152.  A CoSWID tag MUST be wrapped in a </ins> COSE Single Signer Data Object (COSE_Sign1) that contains a single signature and MUST be signed by the tag creator.  The following CDDL specification defines a restrictive subset of COSE header parameters
provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a timestamp). <ins> A CoSWID SHOULD be signed, using the above mechanism, to protect the integrity of the CoSWID tag.  See the security considerations (in sec-sec) for more information on why a signed CoSWID is valuable in most cases. </ins> 8. This specification allows for tagged and untagged CBOR data items