jiebi/CodeConvo huggingface dataset:
Code change:
Christian Bormann, Christian Paquin, David Bakker, David Waite, Fabian Hauck, Filip Skokan, Giuseppe De Marco, John Mattsson, Justin Richer, Kushal Das, Matthew Miller, Mike Jones, Mike Prorock, Nat <del> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Pieter Kasselman, Ryosuke Abe, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </del> <ins> Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt, Vittorio Bertocci, and Yaron Sheffer for their contributions (some of which substantial) to this draft and to the initial set of implementations. </ins> The work on this draft was started at OAuth Security Workshop 2022 in Trondheim, Norway.

Related discussion:
text: to
In draft 06 section there is a list of steps: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. If Key Binding is required, create a Key Binding JWT. >3. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT, the selected Disclosures and, if applicable, the Key Binding JWT. >4. Send the Presentation to the Verifier. Now that draft 06 also has the requirement to add (section ) to Key Binding JWTs, a more natural order for the steps would be to create the SD-JWT for Presentation with the selected Disclosures before the Key Binding JWT, as the presentation is needed for calculating the required digest for the Key Binding JWT. E.g. something like this: >For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps: >2. Assemble the SD-JWT for Presentation, including the Issuer-signed JWT and the selected Disclosures. >3. If Key Binding is required, create a Key Binding JWT and add it to the Presentation. >4. Send the Presentation to the Verifier. With that step 2. constructs the input required for the digest computation in step 3. For extra clarity, the requirement to compute and include the integrity protection digest to the Key Binding JWT could be mentioned also here with a reference to section 5.3.1. for details.
That makes sense, thank you!
Code change:
The "keyid" parameter corresponds to the "keyid" parameter in the Encryption header field. <del> The "aesgcm128" parameter contains the URL-safe base64 RFC4648 octets of the input keying material. </del> <ins> The "aesgcm" parameter contains the URL-safe base64 RFC4648 octets of the input keying material. </ins> The "dh" parameter contains an ephemeral Diffie-Hellman share. This form of the header field can be used to encrypt content for a

Related discussion:
text: In order to allow existing applications to update from one octet of padding per record to two (PR , Issue ), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
NAME - for your consideration I updated the hashes, but would like you to verify those when you've got a moment (they include the uint8 -> uint16 change). I wasn't able to reproduce the output of the explicit example using the current spec.
Awesome. I'm still awaiting the return of my implementation (I'm annoyed that I put it on a boat), but I will verify when able. It's entirely possible that one (or more) of the examples are in error.
I still need to double-check the examples, but I won't be able to do that for a while now. Stupid travel. Might as well make progress at least. Thanks for putting this all together NAME
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case. Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding. I raised this on the ietf-http-wg list here: URL Martin about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
This was fixed in and .
Code change:
specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with <del> that server has been protected for confidentiality and integrity through the use of strong encryption. </del> <ins> that server has confidentiality and integrity protection that is acceptable to both client and server. </ins> The origin server for an "https" URI is identified by the

Related discussion:
text: In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.
Code change:
allow for application in constrained node environments a simple and low cost way to update the configuration of a system <del> component in charge of validity or authenticity cecking </del> <ins> component in charge of validity or authenticity checking </ins> There is no standardized way to:

Related discussion:
text: Thanks for merge. I realize these are minor things (especially in developing a draft), so know that I am reading and digesting/thinking on the actual content. Thanks for your and the others' efforts.
LGTM! Sincere thanks for spotting them!
Code change:
specifies and matches a "match-dest" takes precedence over a match that does not use a destination.  1.  Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. <del> 1.  Given equivalent destination and path precedence, the dictionary with the longest "match-search" takes precedence.  1.  Given equivalent destination, path and search precedence, the most recently fetched dictionary takes precedence. </del> <ins> 1.  Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </ins> 2.3.

Related discussion:
text: This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by
Code change:
The SCITT architecture consists of a very loose federation of Transparency Services, and a set of common formats and protocols for <del> issuing, registering and auditing Transparent Statements. </del> <ins> issuing, registering Signed Statements and auditing Transparent Statements. </ins> In order to accommodate as many Transparency Service implementations as possible, this document only specifies the format of Signed

Related discussion:
text: NAME This is a fundamental bug in the spec, we need to correct it ASAP!
NAME Thank you for the review. I agree with most of your edits.
NAME Thanks, I have done all the required edits, please have a look!
LGTM Line item at 962 could be done later
Code change:
the verification result ("V") as a boolean: This section contains several common algorithm methods.  The method <del> to use can be communicated through the algorithm signature parameter defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </del> <ins> to use can be communicated through the explicit algorithm signature parameter "alg" defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </ins> 3.3.1.

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:
the verification result ("V") as a boolean: This section contains several common algorithm methods.  The method <del> to use can be communicated through the algorithm signature parameter defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </del> <ins> to use can be communicated through the explicit algorithm signature parameter "alg" defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </ins> 3.3.1.

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:
the verification result ("V") as a boolean: This section contains several common algorithm methods.  The method <del> to use can be communicated through the algorithm signature parameter defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </del> <ins> to use can be communicated through the explicit algorithm signature parameter "alg" defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </ins> 3.3.1.

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:
the verification result ("V") as a boolean: This section contains several common algorithm methods.  The method <del> to use can be communicated through the algorithm signature parameter defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </del> <ins> to use can be communicated through the explicit algorithm signature parameter "alg" defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </ins> 3.3.1.

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:
the verification result ("V") as a boolean: This section contains several common algorithm methods.  The method <del> to use can be communicated through the algorithm signature parameter defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </del> <ins> to use can be communicated through the explicit algorithm signature parameter "alg" defined in signature-params, by reference to the key material, or through mutual agreement between the signer and verifier. </ins> 3.3.1.

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:
likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on <del> the received precondition header fields and their precedence, as defined in precedence.  The </del> <ins> the received precondition header fields and their precedence.  In summary, the </ins> and <del> conditional header fields are not applicable to a cache. </del> <ins> conditional header fields are not applicable to a cache, and takes precedence over . See precedence for a complete specification of precondition precedence. </ins> A request containing an

Related discussion:
text: There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.
Code change:
likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on <del> the received precondition header fields and their precedence, as defined in precedence.  The </del> <ins> the received precondition header fields and their precedence.  In summary, the </ins> and <del> conditional header fields are not applicable to a cache. </del> <ins> conditional header fields are not applicable to a cache, and takes precedence over . See precedence for a complete specification of precondition precedence. </ins> A request containing an

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
This document describes a use of HTTP Alternative Services I-D.ietf- httpbis-alt-svc to decouple the URI scheme from the use and configuration of underlying encryption, allowing a "http" URI RFC7230 <del> to be accessed using TLS RFC5246 opportunistically. </del> <ins> to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </ins> Serving "https" URIs require acquiring and configuring a valid certificate, which means that some deployments find supporting TLS

Related discussion:
text: I think that I caught everything in the first round of discussion. There aren't any substantial changes here, but it's a PR so that others can confirm.
Code change:
4xx Client Error 5xx Server Error safe <ins> section </ins> secured selected representation sender

Related discussion:
text: The practice of combining list-form fields into a single value is widespread, and the document addresses this pretty clearly. However it never really says that this combination needs to be limited to a single field section. It's pretty clear that trailers need to be kept discrete, but there is nothing so direct. It's probably worth adding "within a field section" somewhere.
Agree, but I can't find the definition of "field section" neither in MESSAGING nor in SEMANTICS :)
I was pointed to URL which is good, but it doesn't really say that this combining only applies to a single field section (and yes, that is not a term that is defined in the document as far as I can see).
Thanks, this works nicely. Shame that you had to add a new term, but we already got that in QUIC.