jiebi/CodeConvo huggingface dataset:
Code change:
Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid connection header.  A <del> frame (GTFO) MAY be omitted if it is clear that the peer is not using HTTP/2. </del> <ins> frame (GOAWAY) MAY be omitted if it is clear that the peer is not using HTTP/2.0. </ins> 4.

Related discussion:
text: It is more fitting than GOAWAY, but once you have read GTFO your mind is sort of made up, since you spelled GTFO in full in your head, as soon as reading the acronym. My suggestion on this one is: Simply get rid of "General" / "G" and add "of" to the acronym! TOFO still has a nice ring to it, is quick and easy to pronounce and "Termination Of Future Operations" would be sufficiant descriptive. regards (yes, that's my real lastname :P ) On Jan 29, 2014 8:31 AM, "Eugene Ciurana" EMAIL wrote:
Code change:
interchangeably by the same issuer.  For instance, declare whether a status list can reference both JWT and CWT tokens. <del> 8. </del> <ins> 9. </ins> <del> 8.1. </del> <ins> 9.1. </ins> TODO elaborate on risks of incorrect parsing/decoding leading to erroneous status data <del> 8.2. </del> <ins> 9.2. </ins> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data <del> 8.3. </del> <ins> 9.3. </ins> TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section <del> 8.4. </del> <ins> 9.4. </ins> TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> TODO elaborate on herd privacy, size of the status list <del> 9.2. </del> <ins> 10.2. </ins> TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list <del> 9.3. </del> <ins> 10.3. </ins> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO

Related discussion:
text: Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.
Code change:
An intermediary that receives any field that requires removal before forwarding (see HTTP) MUST remove or replace those header fields when forwarding messages.  Additionally, intermediaries should take care <del> when forwarding messages containing Content-Length fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </del> <ins> when forwarding messages containing fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </ins> 10.4.

Related discussion:
text: : Should "Content-Length" be enclosed in "" elements in the XML file? We ask because we see three instances of " header field" in the XML for Original:
Probably, yes.
Code change:
correctly-defined verification function for the algorithm in question and not do a simple comparison. <ins> 7.20. Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components.  In most cases, it is more desirable to sign the non-field alternative.  In particular, the following fields should usually not be included in the signature unless the application specifically requires it: </ins> 8. 8.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:
correctly-defined verification function for the algorithm in question and not do a simple comparison. <ins> 7.20. Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components.  In most cases, it is more desirable to sign the non-field alternative.  In particular, the following fields should usually not be included in the signature unless the application specifically requires it: </ins> 8. 8.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:
correctly-defined verification function for the algorithm in question and not do a simple comparison. <ins> 7.20. Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components.  In most cases, it is more desirable to sign the non-field alternative.  In particular, the following fields should usually not be included in the signature unless the application specifically requires it: </ins> 8. 8.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:
correctly-defined verification function for the algorithm in question and not do a simple comparison. <ins> 7.20. Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components.  In most cases, it is more desirable to sign the non-field alternative.  In particular, the following fields should usually not be included in the signature unless the application specifically requires it: </ins> 8. 8.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:
correctly-defined verification function for the algorithm in question and not do a simple comparison. <ins> 7.20. Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components.  In most cases, it is more desirable to sign the non-field alternative.  In particular, the following fields should usually not be included in the signature unless the application specifically requires it: </ins> 8. 8.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:
CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> Signed Certificate Timestamps are checked by Relying Parties </del> <ins> Signed Certificate Timestamps, Signed Tree Heads, and their respective consistency proofs are checked by Relying Parties </ins> The Append-only Log can be checked by Auditors

Related discussion:
text: I would argue that in CT Auditors are checking more than Signed Certificate Timestamps
NAME there is a lot of detail there and I am not sure how far you/others want to go, but I decided to keep it simple and I propose adding slightly more detail in URL I am sure you and others will let me know if that is too little (I doubt/hope it is not too much.)
NAME thanks for the issue. Did you have an intent for what to scope? Reading the , it implies a unique focus on x.509, rather than x.509 is one example of identity types that are supported. Considering CT in terms of SCITT: I'd suggest we limit the focus on x.509, and focus on the generalization that an issuer signs the protected header, which includes producing a timestamped signed statement and a timestamped receipt.
LGTM
Code change:
. This sequence MUST be followed by a SETTINGS frame (SETTINGS), which MAY be empty.  The client sends the client connection preface <del> immediately upon receipt of a 101 (Switching Protocols) response (indicating a successful upgrade) or as the first application data octets of a TLS connection.  If starting an HTTP/2 connection with prior knowledge of server support for the protocol, the client connection preface is sent upon connection establishment. </del> <ins> as the first application data octets of a connection. </ins> The server connection preface consists of a potentially empty SETTINGS frame (SETTINGS) that MUST be the first frame the server

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
For example, a malicious Issuer could generate a unique value for the Issuer identifier per Holder, e.g., <del> and host the JWT Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD-JWT VC is verified.  This would allow the malicious Issuer to keep track where and how often the SD-JWT VC was used. </del> <ins> and host the JWT VC Issuer Metadata.  The Verifier would create a HTTPS GET request to the Holder-specific well-known URI when the SD- JWT VC is verified.  This would allow the malicious Issuer to keep track where and how often the SD-JWT VC was used. </ins> Verifiers are advised to establish trust in an SD-JWT VC by pinning specific Issuer identifiers and should monitor suspicious behaviour

Related discussion:
text: This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier.