jiebi/CodeConvo huggingface dataset:
defined as an sf-string is allowed to fail when processing this field section: <del> If parsing fails - including when calling another algorithm - the entire field value MUST be ignored (i.e., treated as if the field were not present in the section).  This is intentionally strict, to improve interoperability and safety, and specifications referencing this document are not allowed to loosen this requirement. </del> <ins> If parsing fails, either the entire field value MUST be ignored (i.e., treated as if the field were not present in the section), or alternatively the complete HTTP message MUST be treated as malformed. This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement. </ins> Note that this requirement does not apply to an implementation that is not parsing the field; for example, an intermediary is not
HTTPS over a mutually-authenticated TLS connection.  Use of the header fields outside that intended use case, however, may undermine the protections afforded by TLS client certificate authentication. <del> Therefore, steps MUST be taken to prevent unintended use, both in sending the header field and in relying on its value. </del> <ins> Therefore, steps such as those described below need to be taken to prevent unintended use, both in sending the header field and in relying on its value. </ins> Producing and consuming the "Client-Cert" and "Client-Cert-Chain" header fields SHOULD be configurable options, respectively, in a TTRP
The communication between a TTRP and backend server needs to be secured against eavesdropping and modification by unintended parties. <del> The configuration options and request sanitization are necessarily functionally of the respective servers.  The other requirements can </del> <ins> The configuration options and request sanitization are necessary functionality of the respective servers.  The other requirements can </ins> be met in a number of ways, which will vary based on specific deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the
6.5. <del> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </del> <ins> Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports mulitple compression levels.  Such encoding parameters are generally not communicated as representation 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 content coding defined RFC8188. Since it is possible for there to be variation within content coding, the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) content is persisted. </ins> 6.6.
the IANA Hash Algorithms for HTTP Digest Fields registry; see establish-hash-algorithm-registry. <del> The "standard" algorithms listed in this document are suitable for many purposes, including adversarial situations where hash functions might need to provide resistance to collision, first-preimage and second-preimage attacks.  Algorithms listed as "insecure" either provide none of these properties, or are known to be weak (see NO-MD5 and NO-SHA). For adversarial situations, which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  As there is no negotiation, endpoints that depend on a digest for security will be vulnerable to attacks on the weakest algorithm they are willing to accept. </del> Transition from weak algorithms is supported by negotiation of hashing algorithm using "Want-Content-Digest" or "Want-Repr-Digest" (see want-fields) or by sending multiple digests from which the
While algorithm agility allows the migration to stronger algorithms it does not prevent the use of weaker algorithms.  Integrity fields <del> do not provide any mitigiations for downgrade or substitution attacks </del> <ins> do not provide any mitigations for downgrade or substitution attacks </ins> (see Section 1 of RFC6211) of the hashing algorithm.  To protect against such attacks, endpoints could restrict their set of supported algorithms to stronger ones and protect the fields value by using TLS
7.2. <del> This memo sets this specification to be the establishing document for the Hash Algorithms for HTTP Digest Fields [2] registry defined in </del> <ins> IANA is requested to create the new "Hash Algorithms for HTTP Digest Fields" registry at https://www.iana.org/assignments/http-digest- hash-alg/ [1] and populate it with the entries in iana-hash- algorithm-table.  The procedure for new registrations is provided in </ins> algorithms. <del> IANA is asked to initialize the registry with the entries in iana- hash-algorithm-table. </del> 8.  References 8.1.  URIs <del> [1] https://www.iana.org/assignments/http-dig-alg/ [2] https://www.iana.org/assignments/http-structured-dig-alg/ </del> <ins> [1] https://www.iana.org/assignments/http-digest-hash-alg/ </ins>
insensitive components such as field names, request URI scheme, or host. <del> Addition or removal of leading or trailing whitespace to a field value. Addition or removal of "obs-fold" from field values. </del> Changes to the request target and authority that when applied together do not result in a change to the message's target URI, as defined in HTTP. <ins> Additionally, there are some transformations that are either deprecated or otherwise not allowed, but still could occur in the wild.  These transformations can still be handled without breaking the signature, and include things such as: Use, addition, or removal of leading or trailing whitespace in a field value. Use, addition, or removal of "obs-fold" in field values (HTTP1). </ins> We can identify these types of transformations as ones that should not prevent signature verification, even when performed on message components covered by the signature.  Additionally, all changes to
Some examples of these kinds of transformations, and the effect they have on the message signature, are found in example-transform. <ins> Other transformations, such as parsing and re-serializing the field values of a covered component or changing the value of a derived component, can cause a signature to no longer validate against a target message.  Applications of this specification need to take care to ensure that the transformations expected by the application are adequately handled by the choice of covered components. </ins> 1.4. HTTP Message Signatures are designed to be a general-purpose security
Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in HTTP1.  Note that this <del> behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification which do not allow internal line folding. </del> <ins> behavior is specific to HTTP/1.1 and does not apply to other versions of the HTTP specification which do not allow internal line folding. </ins> Concatenate the list of values together with a single comma (",") and a single space (" ") between each item.
material, or use some pre-configured algorithm agreed upon by the signer and verifier. <del> A means of determining that a given key and algorithm presented in the request are appropriate for the request being made.  For </del> <ins> A means of determining that a given key and algorithm used for a signature are appropriate for the context of the message.  For </ins> example, a server expecting only ECDSA signatures should know to reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.
Within a single list of covered components, each component identifier MUST occur only once.  One component identifier is distinct from <del> another if either the component name or its parameters differ. Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct.  The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality.  That is to say, ""foo";bar;baz" cannot be in the same message as ""foo";baz;bar", since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form. </del> <ins> another if the component name differs, or if any of the parameters differ for the same component name.  Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct, such as ""foo";bar" and ""foo";baz".  The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality checks.  That is to say, ""foo";bar;baz" cannot be in the same message as ""foo";baz;bar", since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form. </ins> The component value associated with a component identifier is defined by the identifier itself.  Component values MUST NOT contain newline
allowed to combine values of HTTP fields with any amount of whitespace between the commas, and if this behavior is not accounted for by the verifier, the signature can fail since the signer and <del> verifier will be see a different component value in their respective </del> <ins> verifier will see a different component value in their respective </ins> signature bases.  For robustness, it is RECOMMENDED that signed messages include only a single instance of any field covered under the signature, particularly with the value for any list-based fields
This would result in the following unsigned response message: <ins> The server signs the response with its own key, including the "@status" code and several header fields in the covered components. </ins> To cryptographically link the response to the request, the server <del> signs the response with its own key and includes the method, authority, and the signature value "sig1" from the request in the covered components of the response.  The signature base for this example is: </del> <ins> 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: </ins> The signed response message is: <del> Since the request's signature value itself is not repeated in the response, the requester MUST keep the original signature value around long enough to validate the signature of the response that uses this component identifier. </del> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. <ins> Since the signature component values from the request are not repeated in the response, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier.  In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application. Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values as the client would not be able to validate the resulting signature. Applications needing this type of binding have to sign sufficient portion the request to ensure that it is uniquely tied to the response.  Signing the signature value of a signed request alone does not provide sufficient coverage in most cases, as discussed in security-sign-signature. The response signature can only cover what is included in the request.  Therefore, if an application needs to bind the message content of the request in its response, the client needs to include a means for covering that content, such as a Content-Digest field.  See the discussion in security-message-content for more information. </ins> The "req" parameter MUST NOT be used in a signature that targets a request message.
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- <del> signatures).  To counter this, the proxy adds its own signature over the new message before passing it along.  The proxy includes the new "@authority" derived component and the Forwarded header, which it added to the message.  The proxy's signature also includes the client's signature value from the original message in its covered components, as a dictionary field member under the label "sig1". Note that since the client's signature already covers the client's Signature-Input value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  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 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> 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: </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. <del> The proxy's signature and the client's original signature can be verified independently for the same message, based on the needs of the application.  Since the proxy's signature covers the client signature, the backend service fronted by the proxy can trust that the proxy has validated the incoming signature. </del> 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. <ins> 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 field in the request, the server is unable to include a signature that covers the request's content. </ins> 7.3. 7.3.1.
level algorithm specification instead, preventing an attacker from substituting the algorithm specified. <ins> 7.3.7. When applying content-request-response or signature-multiple to a message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value.  While it would seem that this practice would transitively cover the components under the original signature in a verifiable fashion, the attacks described in JACKSON2019 can be used to impersonate a signature output value on an unrelated message. In this example, Alice intends to send a signed request to Bob, and Bob wants to provide a signed response to Alice that includes a cryptographic proof that Bob is responding to Alice's incoming message.  Mallory wants to intercept this traffic and replace Alice's message with her own, without Alice being aware that the interception has taken place. Alice creates a message, "Req_A" and applies a signature "Sig_A" using her private key "Key_A_Sign". Alice believes she is sending "Req_A" to Bob. Mallory intercepts "Req_A" and reads the value "Sig_A" from this message. Mallory generates a different message "Req_M" to send to Bob instead. Mallory crafts a signing key "Key_M_Sign" such that she can create a valid signature "Sig_M" over her request "Req_M" using this key, but the byte value of "Sig_M" exactly equals that of "Sig_A". Mallory sends "Req_M" with "Sig_M" to Bob. Bob validates "Sig_M" against Mallory's verification key, "Key_M_Verify".  At no time does Bob think that he's responding to Alice. Bob responds with response message "Res_B" to "Req_M" and creates signature "Sig_B" over this message using his key, "Key_B_Sign". Bob includes the value of "Sig_M" under "Sig_B"'s covered components, but nothing elese from the request message. Mallory receives the response "Res_B" from Bob, including the signature "Sig_B" value.  Mallory replays this response to Alice. Alice reads "Res_B" from Mallory and verifies "Sig_B" using Bob's verification key, "Key_B_Verify".  Alice includes the bytes of her original signature "Sig_A" in the signature base, and the signature verifies. Alice is led to believe that Bob has responded to her message, and believes she has cryptographic proof of this happening, but in fact Bob responded to Mallory's malicious request and Alice is none the wiser. To mitigate this, Bob can sign more portions of the request message than just the Signature field, in order to more fully differentiate Alice's message from Mallory's.  Applications using this feature, particularly for non-repudiation purposes, can stipulate that any components required in the original signature also be covered separately in the second signature.  For signed messages, requiring coverage of the corresponding Signature-Input field of the first signature ensures that unique items such as nonces and timestamps are also covered sufficiently by the second signature. </ins> 7.4. 7.4.1.
algorithm-table.  The procedure for new registrations is provided in algorithms. <ins> 7.3. IANA is requested to deprecate the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml [2]. </ins> 8.  References 8.1.  URIs [1] https://www.iana.org/assignments/http-digest-hash-alg/ <ins> [2] https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml </ins>
exporter is used to generate a 32-byte key which is then used as a nonce. <ins> Because the TLS keying material exporter is only secure for authentication when it is uniquely bound to the TLS session RFC7627, the Signature and HMAC authentication schemes require either one of the following properties: The TLS version in use is greater or equal to 1.3 TLS. The TLS version in use is greater or equal to 1.2 and the Extended Master Secret extension RFC7627 has been negotiated. Clients MUST NOT use the Signature and HMAC authentication schemes on connections that do not meet one of the two properties above.  If a server receives a request that uses these authentication schemes on a connection that meets neither of the above properties, the server MUST treat the request as malformed. </ins> 3. The "Unprompted-Authentication" header field allows a user agent to
mechanism QUIC-TLS. The user agent leverages a TLS keying material exporter KEY-EXPORT to <del> generate a nonce which can be signed using the user's key.  The </del> <ins> generate a nonce which can be signed using the chosen key.  The </ins> keying material exporter uses a label that starts with the characters "EXPORTER-HTTP-Unprompted-Authentication-" (see schemes for the labels and contexts used by each scheme).  The TLS keying material
4.1. <del> The OPTIONAL "u" (user ID) parameter is a byte sequence that specifies the user ID that the user agent wishes to authenticate. </del> <ins> The OPTIONAL "k" (key ID) parameter is a byte sequence that identifies which key the user agent wishes to use to authenticate. This can for example be used to point to an entry into a server-side database of known keys. </ins> 4.2. The OPTIONAL "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the <del> credential that matches its user ID. </del> <ins> credential that matches its key ID. </ins> 4.3.
5.1. The "Signature" HTTP Authentication Scheme uses asymmetric <del> cryptography.  User agents possess a user ID and a public/private key pair, and origin servers maintain a mapping of authorized user IDs to their associated public keys.  When using this scheme, the "u", "p", </del> <ins> cryptography.  User agents possess a key ID and a public/private key pair, and origin servers maintain a mapping of authorized key IDs to their associated public keys.  When using this scheme, the "k", "p", </ins> and "s" parameters are REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication- Signature" and the associated context is empty.  The nonce is then signed using the selected asymmetric signature algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using Ed25519 </del> <ins> For example, the key ID "basement" authenticating using Ed25519 </ins> ED25519 could produce the following header field (lines are folded to fit): 5.2. The "HMAC" HTTP Authentication Scheme uses symmetric cryptography. <del> User agents possess a user ID and a secret key, and origin servers maintain a mapping of authorized user IDs to their associated secret key.  When using this scheme, the "u", "p", and "h" parameters are </del> <ins> User agents possess a key ID and a secret key, and origin servers maintain a mapping of authorized key IDs to their associated secret key.  When using this scheme, the "k", "p", and "h" parameters are </ins> REQUIRED.  The TLS keying material export label for this scheme is "EXPORTER-HTTP-Unprompted-Authentication-HMAC" and the associated context is empty.  The nonce is then HMACed using the selected HMAC algorithm and transmitted as the proof directive. <del> For example, the user ID "john.doe" authenticating using HMAC-SHA-512 </del> <ins> For example, the key ID "basement" authenticating using HMAC-SHA-512 </ins> SHA could produce the following header field (lines are folded to fit):