jiebi/CodeConvo huggingface dataset:
Code change:
The JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm with a JOSE Implementation Requirement of "Prohibited". <del> There is no use of the explicit "alg" signature parameter when using JOSE signing algorithms, as they can be signaled using JSON Web Keys or other mechanisms. </del> <ins> JWA algorithm values from the JSON Web Signature and Encryption Algorithms Registry are not included as signature parameters.  In fact, the explicit "alg" signature parameter is not used at all when using JOSE signing algorithms, as the JWS algorithm can be signaled using JSON Web Keys or other mechanisms common to JOSE implementations. </ins> 4.

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 JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm with a JOSE Implementation Requirement of "Prohibited". <del> There is no use of the explicit "alg" signature parameter when using JOSE signing algorithms, as they can be signaled using JSON Web Keys or other mechanisms. </del> <ins> JWA algorithm values from the JSON Web Signature and Encryption Algorithms Registry are not included as signature parameters.  In fact, the explicit "alg" signature parameter is not used at all when using JOSE signing algorithms, as the JWS algorithm can be signaled using JSON Web Keys or other mechanisms common to JOSE implementations. </ins> 4.

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 JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm with a JOSE Implementation Requirement of "Prohibited". <del> There is no use of the explicit "alg" signature parameter when using JOSE signing algorithms, as they can be signaled using JSON Web Keys or other mechanisms. </del> <ins> JWA algorithm values from the JSON Web Signature and Encryption Algorithms Registry are not included as signature parameters.  In fact, the explicit "alg" signature parameter is not used at all when using JOSE signing algorithms, as the JWS algorithm can be signaled using JSON Web Keys or other mechanisms common to JOSE implementations. </ins> 4.

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:
stripped or added. Any mangling of "Digest", including de-duplication of representation- <del> data-digest values or combining different field values (see 5.3.1 of SEMANTICS) might affect signature validation. </del> <ins> data-digest values or combining different field values (see Section 5.2 of SEMANTICS) might affect signature validation. </ins> 12.7.

Related discussion:
text: Fixes field ordering reference
In 12.6: "Any mangling of Digest, including de-duplication of representation-data-digest values or combining different field values (see 5.3.1 of [SEMANTICS]) might affect signature validation." But 5.3.1 is "Request". (note that I didn't catch this earlier because it doesn't use the "Section X of [Y]" pattern; this should be gixed as well)
Code change:
The commitment made by the "HTTP-TLS" header field applies only to the origin of the resource that generates the "HTTP-TLS" header <del> field.  Requests for an origin that has a persisted, unexpired value for "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS connection. </del> <ins> field. Requests for an origin that has a persisted, unexpired value for "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS connection. </ins> Note that the commitment is not bound to a particular alternative service.  Clients SHOULD use alternative services that they become

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
JWTs (and SD-JWTs) can contain claims that are registered in "JSON Web Token Claims" registry as defined in RFC7519, as well as public <del> and private claims.  Private claims are not relevant for this specification due to the openness of the three-party-model.  Since SD-JWTs are based on JWTs, this specification aims to express the basic Verifiable Credential data model purely through JWT Claim Sets, using registered claims while allowing Issuers to use additional registered claims, as well as new or existing public claims, to make statements about the Subject of the Verifiable Credential. </del> <ins> and private claims.  This specification aims to express metadata of the properties of the Verifiable Credentials utilizing registered JWT claims, while allowing Issuers to use other registered, public, or private claims to make statements about the Subject of the Verifiable Credential. </ins> 1.3.

Related discussion:
text: Issue
Can you give an example where this is relevant? With excluding private claims we make sure all claims are uniquely identifiable across all parties of the three-party-model.
claims we make sure all claims are uniquely identifiable across all parties of the three-party-model. I dont believe this PR discourages public claims it simply reflects that there are bunch of scenarios where VC ecosystems what to interoperate on claims that are perhaps not general enough to register as public claims.
Please merge
Code change:
3. This document introduces no new security considerations beyond those <del> discussed in ORIGIN and HTTP3. </del> <ins> discussed in ORIGIN and RFC9114. </ins> 4. <del> This document registers a frame type in the "HTTP/3 Frame Type" registry (HTTP3). This allocation lists a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> This document registers a frame type in the "HTTP/3 Frame Types" registry defined by RFC9114, located at <https://www.iana.org/assignments/http3-parameters/>. </ins>

Related discussion:
text: This PR tracks changes under discussion with the RFC editor. (Note that I haven't renamed the file to the RFC number, because that hasn't been done in other drafts in this repo.) When AUTH48 completes, I will add the commit moving this draft to the archive and merge it.
Code change:
is unsupported (e.g. a live media server signalling it does not support receiving from a given client). <del> 4.3. </del> In the initiation of a session both client and server must perform negotiation in order to agree upon a variety of details before media can move in any direction:

Related discussion:
text: NAME could you take a look at this? I know everyone's thinking has changed on details, but we can capture those changes as the working group converges.
The subsections should be Publishing Media Naming or Identification Packaging Media Media Consumption Relays/Caches End to End Security This is only a starting point, of course, but , and it's easier to keep track of them if the document subsections match, at least for now.
NAME - ISTM that the contain a lot of material that might better be put in another section. I'll work through that before we talk (next week, right?), but please keep this note in mind, so we can fix what I get wrong. Also - ISTM that we really do need a "specific protocol considerations" requirement section, to capture things like streams/datagrams, WebTransport/H3/QUIC, one MOQ protocol, etc. I'll add that in the PR for this issue as well.
NAME most of the sections had some beginning text (and I can't remember who wrote it - was it you?). I'm copying the bullets from NAME slides into each section as a starting point. I'm not sure whether deleting the beginning text is the right thing to do, because it might or might not match the resulting subsections' contents, and of course the new subsections don't have beginning text because they didn't exist before, but let's talk about that, next week.
Code change:
wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the <del> COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle- </del> <ins> COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- </ins> tree-proofs. This section describes at a high level, the three main roles and

Related discussion:
text: Revisit ### Validation {#validation} section fully: After refactor Originally posted by NAME in URL
Please propose a new PR.
Code change:
8. <ins> Txn-Tokens need to be communicated between workloads that depend upon them to authorize the request.  Such workloads will often present HTTP RFC2616 interfaces for being invoked by other workloads.  This section specifies the HTTP header the invoking workload MUST use to communicate the Txn-Token to the invoked workload, when the invoked workload presents an HTTP interface.  Note that the standard HTTP "Authorization" header MUST NOT be used because that may be used by the workloads to communicate channel authorization. </ins> 8.1. <ins> A workload that invokes another workload using HTTP and needs to present a Txn-Token to the invoked workload MUST use the HTTP Header "Txn-Token" to communicate the Txn-Token.  The value of this header MUST be the JWT that represents the Txn-Token. 9. 9.1. </ins> A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a

Related discussion:
text: Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"
Code change:
where the last-byte-pos in the Request is much larger than the last- byte-pos returned in response to an open-ended byte-range HEAD <del> request, as described above. </del> <ins> request, as described above, and much larger than the expected maximum size of the representation.  See Security for range value considerations. </ins> In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client

Related discussion:
text: Also considering if "Security Considerations" can be "Compatibility Considerations".
I haven't renamed "Security Considerations" in this version. And I have no issue with calling this "Compatibility Considerations". But I have some recollection that this is a required section...
Yeah don't do that or various people will start to scream at you :)
Call me a perfectionist, but on reread, I realized there was a cleaner/shorter way to clarify. Let me know if you have any objection...
Thanks Martin!
Code change:
An error on the HTTP/2.0 session. <del> A bi-directional flow of bytes across a virtual channel within the HTTP/2.0 session. </del> <ins> A bi-directional flow of frames across a virtual channel within the HTTP/2.0 session. </ins> An error on the individual HTTP/2.0 stream. 2. <del> Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes.  An HTTP/2.0-capable client is therefore required to discover whether the upstream server (including intermediaries) supports HTTP/2.0. </del> <ins> HTTP/2.0 uses the same "http:" and "https:" URI schemes used by HTTP/1.1.  As a result, implementations processing requests for a target resource URIs like "http://example.org/foo" or "https://example.com/bar" are required to first discover whether the upstream server (the immediate peer to which the client wishes to establish a connection) supports HTTP/2.0. </ins> <del> Different discovery mechanisms are defined for "http:" and "https:" URIs.  Discovery for "http:" URIs is described in discover-http; discovery for "https:" URIs is described in discover-https. </del> <ins> The means by which support for HTTP/2.0 is determined is different for "http" and "https" URIs.  Discovery for "https:" URIs is described in discover-https.  Discovery for "http" URIs is described here. </ins> 2.1.

Related discussion:
text: Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,
Code change:
does not force this to occur, application constraints might make this necessary. <del> 8.3. </del> <ins> 8.4. </ins> An implementation of HPACK needs to ensure that large values for integers, long encoding for integers, or long string literals do not

Related discussion:
text: I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.
Code change:
providing those responses in parallel would be more helpful to the client than delivering the responses one by one. <del> There is no benefit in providing multiple responses with their incremental parameters set to false in parallel, as the client is not going to process those responses incrementally.  Serving non- incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </del> <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to

Related discussion:
text: A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.
Code change:
consumes the resources of both endpoints.  See also digest-and- content-location. <del> Digest fields SHOULD always be used over a connection that provides integrity at the transport layer that protects HTTP fields. A "Representation-Digest" field using NOT RECOMMENDED hashing algorithms SHOULD NOT be used in signatures. Using signatures to protect the checksum of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </del> <ins> Signatures are likely to be deemed an adversarial setting when applying Integrity fields; see algorithms.  Using signatures to protect the checksum of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </ins> Any mangling of digest fields, including de-duplication of representation-data-digest values or combining different field values

Related discussion:
text: no normative text in security considerations.
no normative statements in security considerations
Separately, this could be read to imply that a TCP checksum is sufficient. I'm not enthusiastic about that, URL Originally posted by NAME in URL In reply, I said
This has been slightly modified by ... TLS can't probably be normative, but people already knows...
Code change:
Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv <del> attribute (HTML5). </del> <ins> attribute (HTML5).  Accept-CH is a Structured Header I-D.ietf- httpbis-header-structure.  Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </ins> For example:

Related discussion:
text: NAME - can you take a look?
Migrating .. Julian:
NAME NAME per URL, how about... Does that make sense? Would appreciate your guidance on this one :)
I'm starting to wonder if Client Hints should adopt Structured Headers to avoid having to deal with these sorts of questions. Ilya, WDYT?
NAME that would hit a major reset on all existing CH implementations and set us back another couple years, I don't think this is the right call for CH. /cc NAME Surely CH is not the first instance where we had to spell out behavior for selecting one out of N header values? That said, if we don't have established verbiage for this, I'm happy to just make up some language ourselves to clarify how it should behave.. what we're aiming for ain't rocket science. :)
I wouldn't want to set CH back that much (although it is lingering on :). I only mention it because all of the defined syntax seems like it would easily fit into SH, and Chrome already has a good start on a SH parser, thanks to NAME work on signed exchanges, etc.
As an aside, the same clarification should also apply to response headers. Currently Chrome treats multiple responses headers as an error and ignores both.
NAME my preference is to get this over the finish line without introducing dependency on SH. For one, we're also relying on Feature-Policy for delegation and we decided against SH there. WDYT of suggested text in URL — warmer? NAME ack.
NAME I hear you. My thinking is: We've already waited a good while for CH, and it's not clear that it's really really done yet (I suspect we have at least one more round of doc review). People are already using CH as a framework for new hints, so getting SH in would be best now if it's going to get in. If CH are going to be commonly sent, having well-defined parsing behaviour and the possibility of better serialisations (which SH gives us) is very attractive. To be clear -- this is me as me, not me as chair.
NAME - could you clarify what you mean by CH adopting SH? Do you mean that the / headers would be defined as /? Or that they'd be define as with extended processing model (which guarantees that the last item in the list "wins")? Or something else altogether?