jiebi/CodeConvo huggingface dataset:
Code change:
refers to the associated component value of the request that triggered the response message being signed. <ins> The "@authority" derived component SHOULD be used instead signing the "Host" header directly, see security-not-fields. </ins> 2.2.5. The "@scheme" component identifier refers to the scheme of the target

Related discussion:
text: Includes several document cleanups for signatures, to publish as -09
Also: If there is no query string should the corresponding signing text be or ie. should the query value be empty or just consist of one Should we return with this request and return on this request This is what I opted for in my implementation. See shows that http4s makes the distinction between blank queries and empty queries is simpler I think this is a corner case that is worth explicating very clearly, perhaps even with a test.
There are quite a few occurrences of the header in the draft. From an implementation point of view, Go "swallows" the header and it is not part of the standard Request structure. There's a good reason for the Go library to do it, and in fact the draft recommends to use NAME instead. Can we remove from examples, e.g. Sec. 2.1, so we don't train people to do the wrong thing?
There are only a couple instances of the "host" header in the current draft left, and one of them (section 2.1) is specifically about how to format headers. It could be removed from the other example signature input strings without affecting anything negatively. Same with the "date" header, which could be confused with the "created" parameter, see
This sentence is correct: But it's true for most reasonable uses of , and people will still be using this parameter. So why not add:
No, we explicitly did not want to conflate this with the jwa registry. We also didn't want to have a second tier choice like having "alg=jose" and then having the actual algorithm elsewhere, since a big problem with late editions of the Cavage draft were exactly that process. (See the mess around "hs2019"). The editors discussed this at length and decided the best compromise was to define a way that jwa algorithms could be used in an interoperable fashion, but not to allow runtime signaling with them. Better to have the choice of jwa be signaled within the application level. Additionally, it's preferable to not use the runtime parameter to signal the algorithm any way, which is discussed at length in the security considerations.
All good, so why aren't you using normative language?
It's not normative because this section defines the algorithms, not the parameter.
Code change:
refers to the associated component value of the request that triggered the response message being signed. <ins> The "@authority" derived component SHOULD be used instead signing the "Host" header directly, see security-not-fields. </ins> 2.2.5. The "@scheme" component identifier refers to the scheme of the target

Related discussion:
text: We didn't want to make it seem like the parameter was the "right" way to signal algorithms here, and most certainly is not required. You'll notice that none of the other sections have "MUST use the alg parameter value of 'foo'" either. Older Cavage drafts relied on the parameter, albeit in a much less secure fashion, and implementations were susceptible to algorithm substitution in the same way that naive JOSE implementations tend to be -- the "alg: none" attack all over again, more or less. The value of the parameter already MUST be something from the registry, and the registry does not (and will not) contain JWA values. So you already aren't allowed to do it, normatively, and the note is our attempt at explaining the why. Ultimately, an implementation is allowed to use whatever algorithm they want and makes sense. What this whole section does is define a set of common usable algorithms as well as provide a pattern of applying crypto primitives that applications can follow for their own algorithms. If someone defines a new algorithm that's generally useful, like we recently did with the ed25519 here, it can be registered for use with the parameter. But if a system can base the algorithm selection off of the key material or another part of the protocol (like with GNAP), that's highly preferable and less vulnerable to substitution at runtime. I'd be happy to know how we can make this clearer in the text, but I'm not comfortable with that kind of normative construct in that section.
NAME -- would you like to chime in? I recall from our discussions you having another, more specific reason for this decision, but I can't remember the details beyond us agreeing to do it the way we have it in the spec right now.
Neither Java nor JS subtleCrypto come out of the box with PKCS1 PEM support. (for java ). It is not immediately obvious to work out that the PEM formats of the private key in in PKCS1 format (the spec could point that out). When building an implementation it helps to have the test suite clearly map to the data in the spec (e.g. ) so as to make error reporting clearer. That is even though using the following openssl command to convert the keys work, it makes it difficult to see if an error was introduced at some point.
Code change:
refers to the associated component value of the request that triggered the response message being signed. <ins> The "@authority" derived component SHOULD be used instead signing the "Host" header directly, see security-not-fields. </ins> 2.2.5. The "@scheme" component identifier refers to the scheme of the target

Related discussion:
text: To support PKCS1 the developer has to depend on further less well tested libraries and add additional code (as I ) leading possibly to new bugs. Furthermore, I will need to go through the same process for JavaScript now, doubling the work. Since PKCS8 is as expressive as PKCS1 ( and see ), it would make life easier for devs if the keys were all in PKCS8 format. Unless there really is something that PKCS1 offers that PKCS8 does not? I will try doing this using the Web Crypto API next. But there we find that supports the PKCS format.
While I am at it. I am having trouble with verifying the signature for 3 out of 4 examples from the spec that I tried out in . Currently the only one that works is the . I am able to produce and verify a signature for , and examples, but the signatures don't correspond to what is in the spec. That may very well be a mistake in my code, which I am working on as a to bobcats scala and scala-js crypto library. But I just wanted to check how confident you were in your examples. I am going to re-implement next in JS, so that will give me another reference point.
I am working my way through this with JS. I was able to parse the and keys after translating them to pkcs8 format with openssl, but am having trouble importing in the console of Chrome, Chrome-beta, Chrome-Dev and Safari. I guess that is in pkcs8 format already. I don't have trouble parsing that key with BouncyCastle... I guess this is a little config problem, but it's difficult to work out what that could be... Perhaps someone has an idea?
NAME Since this all has to do with the examples in the text and not the spec itself, I think we'd be fine with having the keys in multiple formats if it's useful for developers. However I'll note that in many code libraries you need to add the PEM headers of and for their compliant parsers to parse an EC key in PEM format, for example. I've been able to parse these keys in both Java and Python, and in fact all the examples are generated using a python script: URL Also, note that RSA-PSS and ECDSA are non-deterministic signatures that incorporate a source of randomness into the signature calculation.
Code change:
refers to the associated component value of the request that triggered the response message being signed. <ins> The "@authority" derived component SHOULD be used instead signing the "Host" header directly, see security-not-fields. </ins> 2.2.5. The "@scheme" component identifier refers to the scheme of the target

Related discussion:
text: This might be why you're getting valid signatures that look different from the examples -- you shouldn't expect to replicate the exact signature values. RSA 1.5 is deterministic, and will always give this same signature for the same input (as will HMAC). This is just one of the reasons why it's not recommended in many environments. I think we can add some text in the examples sections that points this out, if that would be helpful.
NAME You can also test keys and examples at URL for another implementation. I am pretty confident in the values in the examples, but if there are in fact bugs in these implementations (which is always possible!) I'd love to know and fix them.
NAME you were right. I had been verifying the keys by string comparison, so I fixed that. I also worked out what the Java names for the various algorithms were and got nearly all the tests to run on JS and Java platforms. But there is one error left that is consistent across both, so I wrote it up here. URL
Nevertheless, I have not yet been able to import the private key PEM file in JS. So I looked for a way to convert it to JWK to see how that would fare. I looked online, but none of the services worked, I looked at npm but that did not work, finally I found in Java that did the conversion in 2 lines of code. With this I could get signing to work: So there is something problematic with that PEM, at least insofar as it makes it very difficult to get the example to work in JS which should be one of the main platforms. (I have not yet verified the signature in JS as I am having trouble getting verification in JS to work with a valid PSS key, even though I can create the public key with the PEM, and am able to do that Scala-JS)
I think I found the problem to be with the private key. After going through this process: transforming the spec key to JWK as described above transforming the JWK to PEM PKCS1 using node's I get the following transforming the above using Java's Bouncy Castle to PEM I get this: And with that all the JS crypto API tests pass. See the .
Code change:
refers to the associated component value of the request that triggered the response message being signed. <ins> The "@authority" derived component SHOULD be used instead signing the "Host" header directly, see security-not-fields. </ins> 2.2.5. The "@scheme" component identifier refers to the scheme of the target

Related discussion:
text: I think to understand why that final private key works with the Java Web Crypto API but not the original one from which it was derived (which worked with Bouncy-Castle) we'd need the input of someone like NAME . With that public key replaced (in commit ) and a few others commits to get Continuous Integration to work, we have all the tests pass for Scala compiled to JavaScript Those running in the browser are a bit interleaved due to asynchronous execution, something that needs still to be fixed.
Looks good!
Code change:
VCHAR H <del> Heuristic Expiration (warn-text) </del> heuristic expiration time M <del> Miscellaneous Persistent Warning (warn-text) Miscellaneous Warning (warn-text) </del> max-age (cache directive) max-stale (cache directive) min-fresh (cache directive)

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other <del> namespaces that might be controlled by the same server.  It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </del> <ins> namespaces that might be controlled by the same server (field.host). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </ins> For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure

Related discussion:
text: Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!
Code change:
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other <del> namespaces that might be controlled by the same server.  It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </del> <ins> namespaces that might be controlled by the same server (field.host). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </ins> For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure

Related discussion:
text: by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.
Code change:
consider as members of the Origin Set (set) for the connection it occurs within. <ins> 2.1. </ins> The ORIGIN frame type is 0xb (decimal 11). The ORIGIN frame's payload contains the following fields, sets of

Related discussion:
text: Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.
Code change:
because there is no explicit client-signalled initial priority.  A server can apply priority signals provided in an origin response; see the merging guidance given in merging.  In the absence of origin <del> signals, applying default parameter values could be suboptimal.  How ever a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </del> <ins> signals, applying default parameter values could be suboptimal.  By whatever means a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </ins> 10.1.

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
2.1. <del> The Device Authorization Grant (RFC8628)is an example of a cross- </del> <ins> The Device Authorization Grant (RFC8628) is an example of a cross- </ins> device flow that relies on the user copying information from the Initiating Device to the Authorization Device.  The figure below shows a typical example of this flow:

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!
Code change:
representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation. <ins> A valid can be distinguished from a valid by examining the first three characters for a DQUOTE. </ins> A client MUST NOT generate an If-Range header field in a request that does not contain a

Related discussion:
text: They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Code change:
representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation. <ins> A valid can be distinguished from a valid by examining the first three characters for a DQUOTE. </ins> A client MUST NOT generate an If-Range header field in a request that does not contain a

Related discussion:
text: Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)
Code change:
IETF community under the banner of "Media Over QUIC", provides analysis about those use cases, recommends a subset of use cases that cover live media ingest, syndication, and streaming for further <del> exploration, and describes considerations that should guide the design of protocols to satisfy these use cases. </del> <ins> exploration, and describes requirements that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: Move "considerations" to a separate draft, and do various related cleanup work (for example, removing unneeded references that supported text that has been deleted.
(but document focus is on all media categories, not just live media) (moving the considerations section to its own draft) (moving this diagram to the considerations draft)
Our diagram shows "media transport protocol" as one layer, which can be true, but the text points out that anything running over HTTP/3, or even WebTransport over HTTP/3, will have multiple media transport protocols. It would be helpful for readers if we showed this.
Sports fans of this draft may remember that this section was called Requirements, and true sports fans may remember that the contents had changed very little from when James and I thought this draft would be focused on Interactive use cases - and now it's focused on live media use cases. Rather than go into the BOF with a "Requirements" section that was a natural attraction for protocol designers, and almost completely mistargeted, I provided text for some of the considerations that I could type off the top of my head, before the I-D deadline. The existing list of considerations is not a complete list, and some of the considerations that are described in this section are "To Do", where the first thing To Do is to decide whether that consideration is a consideration for Live Media. To mention one significant example, the discussion about WebTransport doesn't mention one of the biggest advantages - the use of existing CDN infrastructure for live media streaming. But there are other examples - and I may think about this issue, and let other people also provide thoughts here, before I try to resolve the issue with PRs. (tagging the group, so you can be thinking about this as well) NAME NAME NAME NAME NAME
NAME and NAME - It is occurring to me that all the use cases we're recommending in this draft, and all the use cases that are named in , are pointing towards LIVE media. This document is even explaining why we think that's what matters first.