jiebi/CodeConvo huggingface dataset:
extensions. The authentication proofs described in this document are not bound to <del> individual HTTP requests; if the same user sends an authentication proof on multiple requests they will all be identical.  This allows </del> <ins> individual HTTP requests; if the key is used for authentication proofs on multiple requests they will all be identical.  This allows </ins> for better compression when sending over the wire, but implies that client implementations that multiplex different security contexts over a single HTTP connection need to ensure that those contexts
that it serves resources that require authentication.  This document proposes a new non-probeable cryptographic authentication scheme. <ins> Unprompted Authentication serves use cases in which a site wants to offer a service or capability only to "those who know" while all others are given no indication the service or capability exists.  The conceptual model is that of a "speakeasy".  "Knowing" is via an externally-defined mechanism by which keys are distributed.  For example, a company might offer remote employee access to company services directly via its website using their employee credentials, or offer access to limited special capabilities for specific employees, while making discovering (probing for) such capabilities difficult.  Members of less well-defined communities might use more ephemeral keys to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by having that entity metering the availability of keys temporally or geographically).  Unprompted Authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </ins> There are scenarios where servers may want to expose the fact that authentication is required for access to specific resources.  This is left for future work.
Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support <del> this specification will validate the authentication received from the client themselves, then inform the upstream HTTP server of the presence of valid authentication using some other mechanism. </del> <ins> this specification have two options: The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of valid authentication. The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </ins> 8.
However, transport-oriented integrity provides a limited utility because it is opaque to the application layer and only covers the extent of a single connection.  HTTP messages often travel over a <del> chain of separate connections, in between connections there is a </del> <ins> chain of separate connections.  In between connections there is a </ins> possibility for unintended or malicious data corruption.  An HTTP integrity mechanism can provide the means for endpoints, or applications using HTTP, to detect data corruption and make a choice
The HTTP fields defined in this document can be used for HTTP integrity.  Senders choose a hashing algorithm and calculate a digest <del> from an input related to the HTTP message, the algorithm identifier </del> <ins> from an input related to the HTTP message.  The algorithm identifier </ins> and digest are transmitted in an HTTP field.  Receivers can validate the digest for integrity purposes.  Hashing algorithms are registered <del> in the "Hash Algorithms for HTTP Digest Fields" (see algorithms). </del> <ins> in the "Hash Algorithms for HTTP Digest Fields" registry (see establish-hash-algorithm-registry). </ins> Selecting the data on which digests are calculated depends on the use <del> case of HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </del> <ins> case of the HTTP messages.  This document provides different fields for HTTP representation data and HTTP content. </ins> <del> There are use-cases where a simple digest of the HTTP content bytes </del> <ins> There are use cases where a simple digest of the HTTP content bytes </ins> is required.  The "Content-Digest" request and response header and trailer field is defined to support digests of content (RFC9110); see content-digest. <del> For more advanced use-cases, the "Repr-Digest" request and response </del> <ins> For more advanced use cases, the "Repr-Digest" request and response </ins> header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to selected representation data (RFC9110).  Basing "Repr-Digest" on the <del> selected representation makes it straightforward to apply it to use- </del> <ins> selected representation makes it straightforward to apply it to use </ins> cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see
Integer, and List. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", "user agent" and </del> <ins> "representation data", "representation metadata", "user agent", and </ins> "content" in this document are to be interpreted as described in RFC9110. This document uses the line folding strategies described in FOLDING. Hashing algorithm names respect the casing used in their definition <del> document (e.g.  SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g. "sha", "crc32c"). </del> <ins> document (e.g., SHA-1, CRC32c) whereas hashing algorithm keys are quoted (e.g., "sha", "crc32c"). </ins> The term "checksum" describes the output of the application of an algorithm to a sequence of bytes, whereas "digest" is only used in
Representations take into account the effect of the HTTP semantics on messages.  For example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on <del> the wire" is dependent on other transformations (e.g. transfer </del> <ins> the wire" is dependent on other transformations (e.g., transfer </ins> codings for HTTP/1.1 - see RFC9112).  To help illustrate HTTP representation concepts, several examples are provided in resource- representation.
reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The "standard" status is not suitable for an algorithm that is known to <del> be weak, broken or experimental.  If a registration request attempts </del> <ins> be weak, broken, or experimental.  If a registration request attempts </ins> to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional".
additional considerations when Integrity fields are included in this set. <del> There are no restrictions placed on the type or format of digitial </del> <ins> There are no restrictions placed on the type or format of digital </ins> signature that Integrity fields can be used with.  One possible approach is to combine them with HTTP Message Signatures SIGNATURES. <del> Digests explicitly depend on the "representation metadata" (e.g. the </del> <ins> Digests explicitly depend on the "representation metadata" (e.g., the </ins> values of "Content-Type", "Content-Encoding" etc).  A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering.  For example, an actor could
processing of invalid data. Not every hashing algorithm is suitable for use in the trailer <del> section, some may require to pre-process the whole payload before sending a message (e.g. see I-D.thomson-http-mice). </del> <ins> section, some may require to preprocess the whole payload before sending a message (e.g., see I-D.thomson-http-mice). </ins> 6.5. Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. <del> For example, GZIP supports mulitple compression levels.  Such </del> <ins> For example, GZIP supports multiple compression levels.  Such </ins> encoding parameters are generally not communicated as representation <del> metadata, for instance different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm </del> <ins> metadata.  For instance, different compression levels would all use the same "Content-Encoding: gzip" field.  Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm </ins> content coding defined in RFC8188. Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to <del> provide a proof of integrity "at rest" unless the whole (e.g. </del> <ins> provide a proof of integrity "at rest" unless the whole (e.g., </ins> encoded) content is persisted. 6.6.
3. <ins> In order to include the "next-hop-aliases" parameter, a proxy needs to have access to the chain of alias names and canonical names received in CNAME records. Implementations ought to note that the full chain of names might not available in common DNS resolution APIs, such as "getaddrinfo". "getaddrinfo" does have an option for "AI_CANONNAME", but this will only return the last name in the chain (the canonical name), not the alias names. An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to include the full chain, such as only including the canonical name if the implementation can only use "getaddrinfo" as described above. 4. </ins> 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
IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at <del> https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2]. </del> <ins> https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2] and replace the note on this registry with the following text: </ins> 8.  References
A means of determining the context for derivation of message components from an HTTP message and its application context. While this is normally the target HTTP message itself, the context <del> could include additional information known to the application, such as an external host name. </del> <ins> could include additional information known to the application through configuration, such as an external host name. If binding between a request and response is needed using the mechanism in content-request-response, all elements of the request and response message that would be required to provide properties of such a binding. </ins> The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is
Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same <del> named component from both the request and response message. </del> <ins> named component from both the request and response message, respectively. </ins> The "req" parameter MAY be combined with other parameters as appropriate for the component identifier, such as the "key" parameter for a dictionary field. <del> For example, when serving a response for this signed request: </del> <ins> For example, when serving a response for this request: </ins> This would result in the following unsigned response message: The server signs the response with its own key, including the "@status" code and several header fields in the covered components. <del> To cryptographically link the response to the request, the server includes the method, authority, and the signature and signature input labeled "sig1" from the request in the covered components of the response.  The signature base for this example is: </del> <ins> While this covers a reasonable amount of the response for this application, the server additionally includes several components derived from the original request message that triggered this response.  In this example, the server includes the method, authority, path, and content digest from the request in the covered components of the response.  The Content-Digest for both the request and the response are included under the response signature.  For the application in this example, the query is deemed not to be relevant to the response and is therefore not covered.  Other applications would make different decisions based on application needs as discussed in application. The signature base for this example is: </ins> The signed response message is:
origin server, changing the target host and adding the Forwarded header field defined in RFC7239. <del> While the proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server. While it is possible for the origin server to have additional information in its signature context to account for the change in authority, this practice requires additional configuration and extra care (see further discussion in security-context-multiple- signatures).  The proxy is in a position to make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.  The proxy includes the new "@authority" derived component and the Forwarded header, which the proxy has added to the message.  The proxy also includes elements from the original message that are relevant to the origin server's processing, such as the "@method", "@path", and "@query" in this example, even if those components were covered by the original signature.  The proxy additionally includes the client's signature value and signature input from the original message in the new signature's covered components.  In our example application, this is used as a way for the proxy to indicate to the origin server that the proxy has read and verified these values in their original context. While the origin server may not be able to directly verify this original signature, it can verify that the proxy has vouched for the signature's validity.  The origin server also has assurance that the message has been forwarded intact from the trusted proxy. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </del> <ins> The proxy is in a position to validate the incoming client's signature and make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server.  The proxy also includes all the elements from the original message that are relevant to the origin server's processing.  In many cases, the proxy will want to cover all the same components that were covered by the client's signature, which is the case in this example. Note that in this example, the proxy is signing over the new authority value, which it has changed.  The proxy also adds the Forwarded header to its own signature value.  The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature base of: </ins> And a signature output value of:
original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. <ins> While the proxy could additionally include the client's Signature value and Signature-Input fields from the original message in the new signature's covered components, this practice is NOT RECOMMENDED due to known weaknesses in signing signature values as discussed in security-sign-signature.  The proxy is in a position to validate the client's signature, the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server.  In this example, it is possible for the origin server to have additional information in its signature context to account for the change in authority, though this practice requires additional configuration and extra care as discussed in security-context- multiple-signatures.  In other applications, the origin server will not be able to verify the original signature itself but will still want to verify that the proxy has done the appropriate validation of the client's signature.  An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely. </ins> 5. While a signer is free to attach a signature to a request or response
signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in signature-multiple. <del> Applications that make use of content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header </del> <ins> Applications that make use of the content-request-response also need to be aware of the limitations in this functionality.  Specifically, if a client does not include something like a Content-Digest header </ins> field in the request, the server is unable to include a signature that covers the request's content.
named field as defined in HTTP.  The field value MUST be taken from the named header field of the target message unless this behavior is overridden by additional parameters and rules, such as the "req" and <del> "tr" flags, below. </del> <ins> "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, and any characters outside the ASCII range MUST be encoded using the percent-encoding mechanism defined in URI. </ins> Unless overridden by additional parameters and rules, HTTP field values MUST be combined into a single value as defined in HTTP to
this behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification. <del> Encode the bytes of the resulting field value's ASCII representation as a Byte Sequence. </del> <ins> Encode the bytes of the resulting field value as a Byte Sequence.  Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations. </ins> Add the Byte Sequence to the List accumulator.
the covered components.  Single named parameters MAY occur in any order in the covered components. <del> The component value of a single named parameter is the "valueString" of the named query parameter defined by "application/x-www-form- urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded.  Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" are included with an empty string as the component value. </del> <ins> 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. </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
: "value" <del> And the following signature base lines: </del> <ins> And the following signature base lines, with (SP) indicating a single trailing space character before the empty component value: </ins> <del> If a parameter name occurs multiple times in a request, all parameter values of that name MUST be included in separate signature base lines in the order in which the parameters occur in the target URI.  Note that in some implementations, the order of parsed query parameters is not stable, and this situation could lead to unexpected results.  If multiple parameters are common within an application, it is </del> <ins> This derived component has some limitations.  Specifically, the algorithm in HTMLURL only supports query parameters using percent- escaped UTF-8 encoding.  Other encodings are not supported. Additionally, multiple instances of a named parameter are not reliably supported in the wild.  If a parameter name occurs multiple times in a request, the named query parameter MUST NOT be included. If multiple parameters are common within an application, it is </ins> RECOMMENDED to sign the entire query string using the "@query" component identifier defined in content-request-query. <ins> The encoding process allows query parameters that include newlines or other problematic characters in their values, or with alternative encodings such as using the plus character to represent spaces.  For the query parameters in this message: The resulting values are encoded as follows: If the encoding were not applied, the resultant value would be: This base string violates the constraints on component values, and is therefore invalid. </ins> 2.2.9. The "@status" derived component refers to the three-digit numeric
uses the following ABNF rules: "VCHAR", "SP", "DQUOTE", "LF".  This document uses the following ABNF rules from STRUCTURED-FIELDS: "sf- string", "inner-list", "parameters".  This document uses the <del> following ABNF rules from HTTP: "field-content". </del> <ins> following ABNF rules from HTTP and HTTP1: "field-content", "obs- fold", "obs-text". </ins> In addition to those listed above, this document uses the following terms:
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, no transformation to the input method value's case is performed. </del> <ins> names are uppercase US-ASCII (STD80), no transformation to the input method value's case is performed. </ins> For example, the following request message:
2.5. <del> The signature base is a US-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. </del> <ins> 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. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a