jiebi/CodeConvo huggingface dataset:
Code change:
it be taken from the fields of the message.  The algorithm discussed in create-sig-input provides a safe order of operations. <ins> 7.19. Some cryptographic primitives such as RSA PSS and ECDSA have non- deterministic outputs, which include some amount of entropy within the algorithm.  For such algorithms, multiple signatures generated in succession will not match.  A lazy implementation of a verifier could ignore this distinction and simply check for the same value being created by re-signing the signature input.  Such an implementation would work for deterministic algorithms such as HMAC and EdDSA but fail to verify valid signatures made using non-deterministic algorithms.  It is therefore important that a verifier always use the correctly-defined verification function for the algorithm in question and not do a simple comparison. </ins> 8. 8.1.

Related discussion:
text: Adds text to clarify algorithms in several places: encode ECDSA signature as raw bytes, mark ECDSA and RSAPSS as non-deterministic note non-determinism of ECDSA and RSAPSS in examples, add security consideration of nondeterministic algorithms. Add ed25519,
NAME and NAME : this PR updates the text around non-deterministic algorithms and how to match them, please take a look. It also is more explicit about encoding the ECDSA signature as a raw byte array (as was indicated on the list).
It's been a very long time since I added the RSA signature test vectors to the appendix of the HTTP Signatures spec. We should replace them with more modern examples. My suggestion would be to use ed25519 examples, or secp256r1 (P-256) examples. The former would need a , which would be a good thing.
We should add new examples, not remove ones that are there and are functional. All of the test vectors in the spec have been re-generated from scratch in the latest draft, so none of the older tests should still be in the draft at this point.
Additional tests for HMAC and ECDSA were added in
Keeping this issue open as a call for adding support for Ed25519 and others.
Ed25519 support seems to have been implemented in the wild by libraries like URL and URL Tagging an implementor: NAME could you help define the parameters for Ed25519 support in the core spec?
You can do HTTP message signing with profile and key management using (a Rust programming language with Lua scripting) and its Content Management System, (aka Lighttouch). The crypto implementation is in its and , and database is in . has a refined basic example to see how it works. I'm working on a web site for URL with installation instructions, a getting started guide, organized documentation links, and example projects. If you need any help, I'd be happy to answer your questions.
I've implemented what I think is a reasonable version of Ed25519 using pynacl and added it to the demo generation script, if someone else can confirm this code and its results that would be best. I had to do a lot of unpacking of the key values by hand because support wasn't natively there in the libraries I could find. URL NAME perhaps?
Code change:
it be taken from the fields of the message.  The algorithm discussed in create-sig-input provides a safe order of operations. <ins> 7.19. Some cryptographic primitives such as RSA PSS and ECDSA have non- deterministic outputs, which include some amount of entropy within the algorithm.  For such algorithms, multiple signatures generated in succession will not match.  A lazy implementation of a verifier could ignore this distinction and simply check for the same value being created by re-signing the signature input.  Such an implementation would work for deterministic algorithms such as HMAC and EdDSA but fail to verify valid signatures made using non-deterministic algorithms.  It is therefore important that a verifier always use the correctly-defined verification function for the algorithm in question and not do a simple comparison. </ins> 8. 8.1.

Related discussion:
text: Script output: Base String: Signature:
I am just in the process of pulling out my implementation of Signing HTTP Messages to its independent repository . But I can check that the signatures work in JS and Java for ...
After asking around, I've updated the code to run a SHA-512 hash on the input base string before feeding it to the signer, to have some things to compare to. This results in the following signature instead, with all other parameters being the same: This simple change is in URL
After even further investigation, I'm still not sure whether the pre-hash is really the right approach here or not.
Would having other implementations help decide this? (I have not gotten round to it trying an implementation) What is it that is making you undecided? (Perhaps knowing that could help me give you an answer by implementing)
Other implementations are always welcomed. What's getting me right now is that I can't see if it's necessary or expected with Ed25519, as it would be with other signature schemes like RSA or ECDSA.
To my knowledge, the pre-hash variant of Ed25519 is not very well supported relative to the "pure" variant.
In Java I found the following: In the Java Web Crypto API I found a proposal to from Feb 2020. I found an issue in Chrome's Blink-dev which linked to an issue . From that it seems that there is no built in implementation in Browsers. It seems people have been building their own implementations in JS. There are implementations such as aimed at URL But I can't tell which are well built, or not. So that means that on the JS side there is quite a lot of work to do. So that is something to keep in mind when developing ...
/cc NAME -- I know we've had this discussion w/ a number of vendors, where did we end up -- what seemed to be the most "used by default" approach for EdDSA w/ Ed25119?
This code from the RFC shows that there's an internal hash in the algorithm applied to the message: URL This is true whether PH(M) is a SHA function or an identity function, so I'm now really not seeing the value in having PH(M) be an additional hash.
I got NAME first signature above to work in Java with this commit: URL That did not require me to set any hash.
Code change:
it be taken from the fields of the message.  The algorithm discussed in create-sig-input provides a safe order of operations. <ins> 7.19. Some cryptographic primitives such as RSA PSS and ECDSA have non- deterministic outputs, which include some amount of entropy within the algorithm.  For such algorithms, multiple signatures generated in succession will not match.  A lazy implementation of a verifier could ignore this distinction and simply check for the same value being created by re-signing the signature input.  Such an implementation would work for deterministic algorithms such as HMAC and EdDSA but fail to verify valid signatures made using non-deterministic algorithms.  It is therefore important that a verifier always use the correctly-defined verification function for the algorithm in question and not do a simple comparison. </ins> 8. 8.1.

Related discussion:
text: I've backed out the prehash changes from the generator script, and we'll be adding a definition that use PureEdDSA with no PH function. Other functions can, of course, be defined on their own in the future.
+1 for PureEdDSA with no PH function.
No PH seems like the right thing
Code change:
Recommended HTTP status code: 502 <del> 3.30. </del> <ins> 3.29. </ins> Name: http_request_error

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
Structured Field (a Dictionary), respectively. In each case, cookie names are Tokens.  Their values are Strings, <del> unless they can be represented accurately and unambiguously using the textual representation of another structured types (e.g., an Integer or Decimal). </del> <ins> unless the value can be successfully parsed as the textual representation of another, bare Item structured type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean). </ins> Set-Cookie parameters map to Parameters on the appropriate SF-Set- Cookie member, with the parameter name being forced to lowercase.

Related discussion:
text: ... and apparently some other stuff.
Should we recognise e.g., binary content in cookie values? If so, how?
Do you mind expanding on what you mean?
This is for the retrofit spec's cookie mapping](URL). Since many cookie's payloads are base64, it seems like it'd be beneficial to figure out a way to carry them as binary. I've been meaning to start a discussion with the cookie authors about this section of the spec generally to a) make sure it's a good idea and b) it's correct / doesn't cause problems. PTAL if you have time.
Maybe the right thing to do here is to introduce a new parameter that indicates the type of the value.
... except parameters aren't available on Cookie; just Set-Cookie. hmm.
Perhaps the most we can do is to say that the SF-cookie headers can have a value in any type, but they get mapped to the string value in "normal" headers. That way you can automatically convert SF-cookie to cookie, but not the other way around. The only alternative I see is to carry the type information in a separate header, which is not great.
Code change:
RFC6455 over a single stream of an HTTP/2 connection.  It defines an Extended CONNECT method which specifies a new ":protocol" pseudo header field and new semantics for the ":path" and ":authority" <del> pseudo header fields.  It also defines a new HTTP/2 SETTING sent by a </del> <ins> pseudo header fields.  It also defines a new HTTP/2 setting sent by a </ins> server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection

Related discussion:
text: To be fair, RFC 8441 says . Didn't you say you liked consistency? ;)
RFC 8441 is wrong. Consistency with wrongness should be avoided.
Code change:
The server SHOULD respect representation metadata received during creation (upload-creation) and ignore any representation metadata <del> received from appending (upload-appending). </del> <ins> received from appending. </ins> If the server does not consider the upload associated with the upload resource active, it MUST respond with a "404 (Not Found)" status

Related discussion:
text: There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!
Code change:
The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the <del> recipient MUST respond with a StreamErrorHandler of type </del> <ins> recipient MUST respond with a ConnectionErrorHandler of type </ins> PROTOCOL_ERROR. 3.8.4.

Related discussion:
text: Error when stream identifier field is 0x0 is not stream error but connection error because it is impossible to send RST_STREAM of 0x0.
Code change:
in which omission of a priority parameter implies the use of their default values (see #parameters). <del> For example, when the client sends an HTTP request with </del> <ins> As a non-normative example, when the client sends an HTTP request with </ins> and the origin responds with the intermediary might alter its understanding of the urgency from <del> "5" to "1", because the server-provided value overrides the value provided by the client.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </del> <ins> "5" to "1", because it prefers the server-provided value over the client's.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </ins> incremental("i") parameter. 7.

Related discussion:
text: We still had usage of the term override, so while thinking how to address that I took the opportunity to state explicitly that no guidance is provided for how an intermediary might merge.
LGTM!
Code change:
relate to a user experience.  Congestion control algorithm can still need to share the path with other flows with different constraints. <del> 7.4. </del> <ins> 7.5. </ins> A proposed congestion control algorithm ought not to presume that all general Internet paths have a low delay.  Some paths include links

Related discussion:
text: From Juergen Schoenwaelder: The document provides guidelines for the IETF when evaluating new proposed congestion control algorithms. While important, this document is not directly influencing network operations. This update grows the document from 10 pages () to 25 pages. I found the draft well structured and easy to read and all content appears to be well justified. The draft provides helpful advice to everybody involved in the development and evaluation of congestion control algorithms. I am wondering whether section 7.1.1 really should be a sub-section of 7.1, which implies that a network circuit breaker are viewed as a special kind of an active queue management technique. Keeping the sub-sections a flat list of special cases may simplify things. I also found the title of section 7.1.1 a bit longish compared to the other section titles. Perhaps turning 7.1.1 into "7.2 Interaction with Network Transport Circuit Breakers" or just "7.2 Network Transport Circuit Breakers" leads to a simpler structure. Similarly, I wonder whether sub-section 7.7.1 should be lifted up as well. Path changes are not necessarily a transient event. Perhaps 7.7.1 should become "7.X Changes in the Path" (dropping sudden as well). The point made in the text is that paths are not static, they may change. Perhaps the above two comments make no sense, then just ignore them. I just thought I share them since they came up during my first time read of the document.
The organisation could be better, but I don't see a network circuit breaker (as policing) as a kind of an active queue management technique (as a scheduling/queuing action), they are rather different in operation and design, so I'd rather keep these separate, and just move CB's up one level? If we did that, i wouldn't object to 7.7.1 being made 7.8.
Code change:
4.4. <ins> If claim name blinding is used, is created as follows: is a placeholder used instead of the original claim name, chosen such that it does not leak information about the claim name (e.g., randomly). The contents of are modified as follows: Note that blinded and unblinded claim names can be mixed in and accordingly in . 4.5. </ins> A verifier checks that The detailed algorithm is described below.

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
protocol.version.  For brevity, the protocol-name is omitted when the received protocol is HTTP. <del> The received-by portion of the field value is normally the host and optional port number of a recipient server or client that subsequently forwarded the message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol. </del> <ins> The received-by portion is normally the host and optional port number of a recipient server or client that subsequently forwarded the message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol. </ins> <del> A sender MAY generate comments in the Via header field to identify the software of each recipient, analogous to the </del> <ins> A sender MAY generate comments to identify the software of each recipient, analogous to the </ins> and <del> header fields.  However, all comments in the Via field are optional, and a recipient MAY remove them prior to forwarding the message. </del> <ins> header fields.  However, comments in Via are optional, and a recipient MAY remove them prior to forwarding the message. </ins> For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to

Related discussion:
text: Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:
Code change:
If the number of characters after "." in input_number is greater than three, fail parsing. <del> Parse input_number as a decimal number and let output_number be the product of the result and sign. </del> <ins> Let output_number be a Decimal that is the result of parsing input_number as a decimal number. Let output_number be the product of output_number and sign. </ins> Return output_number.

Related discussion:
text: OK with me.
doesn't return . Without that, the number itself isn't necessarily enough to determine what the type is (necessary for parsing Date).
So what we need to prevent here is that: parses as date.
I don't think this is necessary; the result of Parsing a... already has a type, and that's already checked in Date parsing. Nevertheless, see PR...
The PR isn't correct; it fails to account for the different return signature everywhere it's called. Fixing that is much more invasive, so I'm going to push back on this more strongly; it isn't necessary. What Parsing an Integer or Decimal returns is typed; it's either an integer or a decimal. This can be seen in other places as well -- e.g., in Serializing a Bare Item ("If input_item is an Integer, return..."). No change is necessary here.
NAME NAME can I close this with no action, or should we take it to the list, or...?
So your assertion is that a value inherently carries a type? That's not obvious to me.
Yes. defines those types; the serialisation algorithms take them as parameters, and the parsing algorithms return them. That's reflected in the introduction text for each individual algorithm.
Code change:
of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple <del> concurrent messages on the same connection.  It also introduces </del> <ins> concurrent exchanges on the same connection.  It also introduces </ins> unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.
Code change:
statement on how to mitigate the vulnerability.  At first, the producer provides an updated software product that still uses the vulnerable software component but shields the issue in a fashion that <del> inhibits exploitation.  Later, A second update of the software </del> <ins> inhibits exploitation.  Later, a second update of the software </ins> product includes a security patch to the affected software component <del> from the software producer.  Finally, A third update includes a new </del> <ins> from the software producer.  Finally, a third update includes a new </ins> release (updated version) of the formerly insecure software component.  For this release, both the software product and the affected software component are deemed secure by the producer and

Related discussion:
text: Account for nits of punctionation, consistent Title Case usage and consistency with bulleted content. This PR does not change the definition or examples of the use cases.
The GitHub UX makes it look more than it is. This is just re-formatting of existing content into bullets.
More then spelling nits & style in , but I am okay with the addition.
Code change:
6.8. <del> A publisher issues a "SUBSCRIBE_FIN" message to all subscribers indicating it is done publishing objects on the subscribed track. </del> <ins> A publisher issues a "SUBSCRIBE_DONE" message to indicate it is done publishing Objects for that subscription.  The Status Code indicates why the subscription ended, and whether it was an error. </ins> <del> The format of "SUBSCRIBE_FIN" is as follows: </del> <ins> The format of "SUBSCRIBE_DONE" is as follows: </ins> Subscribe ID: Subscription identifier as defined in message- subscribe-req. <del> ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final Object fields will not be present. Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track. Final Object: The largest Object ID sent by the publisher in an OBJECT message in the "Final Group" for this track. 6.9. A publisher issues a "SUBSCRIBE_RESET" message to all subscribers indicating there was an error publishing to the given track and subscription is terminated. The format of "SUBSCRIBE_RESET" is as follows: Subscribe ID: Subscription Identifier as defined in message- subscribe-req. Error Code: Identifies an integer error code for subscription failure. </del> <ins> Status Code: An integer status code indicating why the subscription ended. </ins> Reason Phrase: Provides the reason for subscription error.

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
For each message component item in the covered components set (in order): <ins> Check that the component identifier (including its parameters) has not already been added to the signature base.  If this happens, produce an error. </ins> Append the component identifier for the covered component serialized according to the "component-identifier" ABNF rule. Note that this serialization places the component name in

Related discussion:
text: A signature over another signature does not provide the transitive protection that it seems it should. The examples and advice have been updated to accomodate this.
NAME NAME can you please verify the signatures on the updated examples in this PR?