jiebi/CodeConvo huggingface dataset:
encryption. The "aesgcm" content coding uses a fixed record size.  The resulting <del> encoding is either a single record, or a series of fixed-size records.  The final record, or a lone record, MUST be shorter than the fixed record size. </del> <ins> encoding is any number of fixed-size records - which could be zero records - followed by a single partial record.  The partial record MUST be shorter than the fixed record size. </ins> The record size determines the length of each portion of plaintext that is enciphered, with the exception of the final record, which is
the content coding is reflected in a separate Encryption header field value in the order in which they were applied. <ins> Content codings that use the Encryption header field MUST always include a value for the header field when the content coding has been applied.  If no parameters are needed, then a dummy value is necessary to avoid confusion about which set of parameters applies to which content coding.  This requirement applies to uses of the "aesgcm" content coding. </ins> Encryption header field values with multiple instances of the same <del> parameter name are invalid. </del> <ins> parameter name in a single encryption-params production are invalid. </ins> Servers processing PUT requests MUST persist the value of the Encryption header field, unless they remove the content coding by
parameter can also be used to identify keys in an application- specific fashion. <del> The "salt" parameter contains a base64url-encoded octets RFC7515 that is used as salt in deriving a unique content encryption key (see derivation).  The "salt" parameter MUST be present, and MUST be exactly 16 octets long when decoded.  The "salt" parameter MUST </del> <ins> The "salt" parameter contains a base64url-encoded octets that is used as salt in deriving a unique content encryption key (see derivation).  The "salt" parameter MUST be present, and MUST be exactly 16 octets long when decoded.  The "salt" parameter MUST </ins> NOT be reused for two different payload bodies that have the same input keying material; generating a random salt for every application of the content coding ensures that content encryption
3.3. The nonce input to AEAD_AES_128_GCM is constructed for each record. <del> The nonce for each record is a 12 octet (96 bit) value is produced from the record sequence number and a value derived from the input keying material. </del> <ins> The nonce for each record is a 12 octet (96 bit) value that is produced from the record sequence number and a value derived from the input keying material. </ins> The input keying material and salt values are input to HKDF with different info and length parameters. The length (L) parameter is 12 octets.  The info parameter for the nonce is the ASCII-encoded string "Content-Encoding: nonce", a single <del> zero octet and an context: </del> <ins> zero octet and a context: </ins> The context for nonce derivation is the same as is used for content encryption key derivation.
Abstract <del> This specification nominates a selection of existing HTTP fields as having syntax that is compatible with Structured Fields, so that they can be handled as such (subject to certain caveats). </del> <ins> This specification nominates a selection of existing HTTP fields whose values are compatible with Structured Fields syntax, so that they can be handled as such (subject to certain caveats). </ins> To accommodate some additional fields whose syntax is not compatible, <del> it also defines mappings of their semantics into new Structured Fields.  It does not specify how to negotiate their use. </del> <ins> it also defines mappings of their semantics into Structured Fields. It does not specify how to convey them in HTTP messages. </ins> 1. Structured Field Values for HTTP STRUCTURED-FIELDS introduced a data model with associated parsing and serialization algorithms for use by new HTTP field values.  Fields that are defined as Structured Fields <del> can realise a number of benefits, including: </del> <ins> can bring advantages that include: </ins> Improved interoperability and security: precisely defined parsing and serialisation algorithms are typically not available for
transformed into an underlying data model which is then mapped into that defined by Structured Fields. <del> Note that while implementations can parse and serialise compatible fields as Structured Fields subject to the caveats in compatible, a sender cannot generate mapped fields from mapped and expect them to be understood and acted upon by the recipient without prior negotiation.  This specification does not define such a mechanism. </del> 1.1. <ins> Retrofitting data structures onto existing and widely-deployed HTTP fields requires careful handling to assure interoperability and security.  This section highlights considerations for applications that use Retrofit Structured Fields. While the majority of field values seen in HTTP traffic should be able to be parsed or mapped successfully, some will not.  An application using Retrofit Structured Fields will need to define how unsuccessful values will be handled. For example, an API that exposes field values using Structured Fields data types might make the field value available as a string in cases where the field did not successfully parse or map. The mapped field values described in mapped are not compatible with the original syntax of their fields, and so cannot be used unless parties processing them have explicitly indicated their support for that form of the field value.  An application using Retrofit Structured Fields will need to define how to negotiate support for them. For example, an alternative serialization of fields that takes advantage of Structured Fields would need to establish an explicit negotiation mechanism to assure that both peers would handle that serialization appropriately before using it. See also the security considerations in security. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
This document defines a mechanism for providing end-to-end integrity and authenticity for components of an HTTP message by use of a <del> detached signature.  The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application.  Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in any of the many ways permitted by HTTP. </del> <ins> detached signature on HTTP messages.  The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application.  Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in many of the ways permitted by HTTP. </ins> The signing mechanism described in this document consists of three parts:
mechanism can be used along with opportunistic or application-driven message signatures by either party. <ins> The mechanisms defined in this document are important tools that can be used to an overall security mechanism for an application.  This toolkit provides some powerful capabilities, but does not sufficient in creating an overall security story.  In particular, the requirements in application and the security considerations in security are of high importance to all implementors of this specification.  For example, this specification does not define a means to directly cover HTTP message content (defined in HTTP), but relies on the DIGEST specification to provide a hash of the message content, as discussed in security-message-content. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
1.4. <del> HTTP Message Signatures are designed to be a general-purpose security mechanism applicable in a wide variety of circumstances and applications.  In order to properly and safely apply HTTP Message Signatures, an application or profile of this specification MUST specify all of the following items: </del> <ins> HTTP Message Signatures are designed to be a general-purpose tool applicable in a wide variety of circumstances and applications.  In order to properly and safely apply HTTP Message Signatures, an application or profile of this specification MUST specify at least all of the following items: </ins> The set of covered-components and signature-params that are expected and required to be included in the covered components
when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in security-coverage and security-message- <del> content. </del> <ins> content.  This specification defines only part of a full security system for an application.  When building a complete security system based on this tool, it is important to perform a security analysis of the entire system of which HTTP Message Signatures is a part. Historical systems, such as AWS-SIGv4, can provide inspiration and examples of how to apply similar mechanisms in a secure and trustable fashion. </ins> 2.
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.5.8. The HTML form parameters format defined in the "application/x-www- form-urlencoded" section of HTMLURL, is widely deployed and supported by many application frameworks.  For convenience, some of these frameworks in particular combine query parameters that are found in the HTTP query and those found in the message content, particularly for POST message with a Content-Type value of "application/x-www- form-urlencoded".  The "@query-param" derived component identifier defined in content-request-query-param draws its values only from the query section of the target URI of the request.  As such, it would be possible for an attacker to shadow or replace query parameters in a request by overriding the signed query parameter with an unsigned form parameter, or vice versa. To counter this, an application needs to make sure that values used for the signature base and the application are drawn from a consistent context, in this case the query component of the target URI.  Additionally, when the HTTP request has content, an application should sign the message content as well, as discussed in security- message-content. </ins> 8. 8.1.
"tr" flags, below.  For most fields, the field value is an ASCII string as recommended by HTTP, and the component value is exactly that string.  Other encodings could exist in some implementations, <del> and any characters outside the ASCII range MUST be encoded using the percent-encoding mechanism defined in URI. </del> <ins> and all non-ASCII field values MUST be encoded to ASCII before being added to the signature base.  The "bs" parameter defined in http- field-byte-sequence provides a method for wrapping such problematic field values. </ins> Unless overridden by additional parameters and rules, HTTP field values MUST be combined into a single value as defined in HTTP to
parameter's functionality is already covered when the "key" parameter is used on a dictionary item, since "key" requires strict serialization of the value.  The "bs" parameter, which requires the <del> raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </del> <ins> raw bytes of the field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters can be defined in the HTTP Signature Component Parameters registry established in component-param-registry.
request message.  The component value is canonicalized by taking the value of the method as a string.  Note that the method name is case- sensitive as per HTTP.  While conventionally standardized method <del> names are uppercase US-ASCII (STD80), no transformation to the input method value's case is performed. </del> <ins> names are uppercase ASCII, no transformation to the input method value's case is performed. </ins> For example, the following request message:
according to the "application/x-www-form-urlencoded parsing" section of HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each component identifier <del> contains the "nameString" of a single query parameter as a String value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. The component value of a single named parameter is calculated by the following process: Parse the "valueString" of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded Encode the "valueString" using the "percent-encode after encoding" process defined by the "application/x-www-form-urlencoded serializing" section of HTMLURL, which results in an ASCII string This ASCII string is the component value Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" have an empty string as the component value. </del> <ins> contains the encoded "nameString" of a single query parameter as a String value.  The component value of a single named parameter is the encoded "valueString" of that single query parameter.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components, regardless of the order they occur in the query string. The value of the "name" parameter and the component value of a single named parameter are calculated by the following process: Parse the "nameString" or "valueString" of the named query parameter defined by the "application/x-www-form-urlencoded parsing" section of HTMLURL, which is the value after percent- encoded octets are decoded. Encode the "nameString" or "valueString" using the "percent-encode after encoding" process defined by the "application/x-www-form- urlencoded serializing" section of HTMLURL, which results in an ASCII string. Output the ASCII string, Note that the component value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" have an empty string as the component value.  Note that due to inconsistencies in implementations, some query parameter parsing libraries drop such empty values. </ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the
The resulting values are encoded as follows: <del> If the encoding were not applied, the resultant value would be: </del> <ins> If the encoding were not applied, the resultant values would be: </ins> <del> This base string violates the constraints on component values, and is therefore invalid. </del> <ins> This base string contains characters that violate the constraints on component names and values, and is therefore invalid. </ins> 2.2.9.
2.5. <del> The signature base is a US-ASCII (STD80) string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </del> <ins> The signature base is a ASCII string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a
the trailer section prevents digest validation, possibly leading to processing of invalid data. <del> Not every hashing algorithm is suitable for use in the trailer section, some may require to preprocess the whole content before sending a message (e.g., see I-D.thomson-http-mice). </del> <ins> One of the benefits of using Integrity fields in a trailer section is that it allows hashing of bytes as they are sent.  However, it is possible to design a hashing algorithm that requires processing of content in such a way that would negate these benefits.  For example, Merkle Integrity Content Encoding I-D.thomson-http-mice requires content to be processed in reverse order.  This means the complete data needs to be available, which means there is negligible processing difference in sending an Integrity field in a header or trailer section. </ins> 6.5.
name in the "next-hop-aliases" list would be the name that ultimately resolved to one or more addresses. <del> The list of DNS names in "next-hop-aliases" use a comma (",") as a separator between names.  DNS names normally just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. </del> <ins> The list of DNS names in "next-hop-aliases" uses a comma (",") as a separator between names.  Note that if a comma is included in a name itself, the comma must be encoded as described in encoding. </ins> For example, consider a proxy "proxy.example.net" that receives the following records when performing DNS resolution for the next hop
aliases" to indicate that no CNAME records were encountered when resolving the next hop's name. <ins> 2.1. DNS names commonly just contain alphanumeric characters and hyphens ("-"), although they are allowed to contain any character RFC1035, Section 3.1, including a comma.  To prevent commas or other special characters in names leading to incorrect parsing, any characters that appear in names in this list that do not belong to the set of URI Unreserved Characters RFC3986, Section 2.3 MUST be percent-encoded as defined in RFC3986, Section 2.1. For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as follows: It is also possible for a DNS name to include a period character (".") within a label, instead of as a label separator.  In this case, the period character MUST be first escaped as "\.".  Since the "\" character itself will be percent-encoded, the name "dot\.label.example.com" would be encoded within a "next-hop-aliases" parameter as follows: Upon parsing this name, "dot%5C.label" MUST be treated as a single label. Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </ins> 3. In order to include the "next-hop-aliases" parameter, a proxy needs
The "next-hop-aliases" parameter does not include any DNSSEC information or imply that DNSSEC was used.  The information included in the parameter can only be trusted to be valid insofar as the <del> client trusts its proxy to provide accurate information.  This </del> <ins> client trusts the proxy to provide accurate information.  This </ins> information is intended to be used as a hint, and SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy. <ins> Inspecting CNAME chains can be used to detect cloaking of trackers or malicious hosts.  However, the CNAME records could be omitted by a recursive or authoritative resolver that is trying to hide this form of cloaking.  In particular, recursive or authoritative resolvers can omit these records for both clients directly performing DNS name resolution and proxies performing DNS name resolution on behalf of client.  A malicious proxy could also choose to not report these CNAME chains in order to hide the cloaking.  In general, clients can trust information included (or not included) in the "next-hop- aliases" parameter to the degree that the proxy and any resolvers used by the proxy are trusted. </ins> 5. This document registers the "next-hop-aliases" parameter in the "HTTP
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540. </del> <ins> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests intended for the associated origin (RFC6454) to the identified
Client certificates are not meaningful for URLs with the "http" scheme, and therefore clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT <del> present them.  Established connections with client certificates MAY be reused, however. </del> <ins> present them.  Connections that use client certificates for other reasons MAY be reused, though client certificates MUST NOT affect the responses to requests for "http" resources. </ins> 2.1.
serving "http" URLs over TLS, clients are required to perform additional checks before directing "http" requests to it. <del> Clients MUST NOT send "http" requests over a connection with the "h2" protocol identifier, unless they have obtained a valid http- opportunistic response for an origin (as per well-known), and: </del> <ins> Clients MUST NOT send "http" requests over a secured connection, unless the chosen alternative service presents a certificate that is valid for the origin - as per RFC2818 (this also establishes "reasonable assurances" for the purposes of {RFC7838}}) - and they have obtained a valid http-opportunistic response for an origin (as per well-known). </ins> <del> The chosen alternative service presents a certificate that is valid for the origin, as per RFC2818 (this also establishes "reasonable assurances" for the purposes of {RFC7838}}), and The origin object of the http-opportunistic response has a `tls- ports' member, whose value is an array of numbers, one of which matches the port of the alternative service in question, and The chosen alternative service returns the same representation as the origin did for the http-opportunistic resource. For example, this request/response pair would allow reqeusts for the origin "http://www.example.com" to be sent to an alternative service on port 443 or 8000 of the host "www.example.com": </del> <ins> For example, assuming the following request is made over a TLS connection that is successfully authenticated for those origins, the following request/response pair would allow requests for the origins "http://www.example.com" or "http://example.com" to be sent using a secured connection: </ins> 2.2.