jiebi/CodeConvo huggingface dataset:
Code change:
MUST be equal to that of the "iss" claim contained within the Referenced Token. <del> "sub": REQUIRED.  The "sub" (subject) claim MUST specify a unique string identifier for the Status List Token.  The value MUST be equal to that of the "uri" claim contained in the "status_list" claim of the Referenced Token. </del> <ins> "sub": REQUIRED.  The "sub" (subject) claim MUST specify the URI of the Status List Token.  The value MUST be equal to that of the "uri" claim contained in the "status_list" claim of the Referenced Token. </ins> "iat": REQUIRED.  The "iat" (issued at) claim MUST specify the time at which the Status List Token was issued.

Related discussion:
text: The first and second sentence of this description seem contradictory to me. The first sentence seems to state that (all?) Status List Tokens should have a unique identifier included as their claim. The second sentence directly contradicts this uniqueness requirement. Perhaps I'm misunderstanding what is meant by 'uniqueness' in the first sentence, but in that case the language is quite ambiguous. As the claim seems to have been added solely for including the from the Referenced Token in the Status List Token (as described in ), perhaps the sentences should simply be reworded to not mention uniqueness. So something like: : REQUIRED. The (subject) claim MUST be equal to the claim contained in the claim of the Referenced Token.
The is basically the URI by which the Status List Token is retrieved. As Status List Tokens may be downloaded for offline use, further re-transmission or archiving, its important to also store the URI in the Token, such that it can be compared by others to the of the claim of the Referenced Token. I see that the text may be confusing, it should be clearer as "URI" may be better than "unique string identifier" and URI is unique anyway. How about: : REQUIRED. The (subject) claim MUST specify the URI of the Status List Token. The value MUST be equal to that of the claim contained in the claim of the Referenced Token.
Yes thank you, this wording clears it up. If you wanted to be very precise instead of you could write . But perhaps my suggestion is too verbose, what you've written gets the idea across.
Code change:
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.25. Multiple applications and protocols could apply HTTP signatures on the same message simultaneously.  A naive verifier could become confused in processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the "context" signature parameter.  For example, a signature targeting an application gateway could require "context="app-gateway"" as part of the signature parameters for that application. </ins> 8. 8.1.

Related discussion:
text: Adds an optional parameter to signatures, to allow applications to signal specific usage between the signer and verifier. This PR does not add this to any examples yet, but we probably should if accepted.
NAME NAME I've walked the language in the definition back a bit and added it to an example. I think this is sufficient to include as a new feature.
[This came up at the IETF-113 session, credit to Jonathan Hoyland] A signature context mitigates oracle attacks, where a sender can be made to sign data that’s partly controlled by the attacker, and the signed string is then used for unexpected purposes, either within the same protocol or outside it. The context includes the higher level protocol that utilizes the signature mechanism, as well as other information such as sender and receiver identities. Signature context is used in TLS 1.3 (see RFC 8446, Sec. 4.4.3, “context string”) as well as the similar parameter in . The simplest way to add context to Message Signatures is as an additional parameter. We suggest that the context value should NOT be defined by this draft, but it should be mandatory to send, and mandatory to validate upon receipt. This prevents cross-protocol attacks but assumes that the higher level protocol is able to protect itself e.g. by ensuring that the receiver’s identity is included in the signed components. The context is fully defined by the higher level protocol, and no IANA registry is established for it. cc: NAME
Thanks for writing this up. I want to make sure I understand the request for addition: Define a signature parameter "context" as a string, whose content is outside the scope of this spec Define the use for this field aligned with the above Add a security considerations on the use of this in outside protocols I think this is a relatively light weight add, and I am ok with those pieces. Where I don't think I agree is the "mandatory to send and interpret" portion, if we're not going to define anything to put into the field. In this case is becomes just another value, right? I can see a lot of confusion in people trying to apply this without clear guidance. I would be fine with this field being recommended to send by the signer and mandatory to interpret by the verifier if it's present, and applications can make the field required and even have required values, like the example above.
Code change:
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.25. Multiple applications and protocols could apply HTTP signatures on the same message simultaneously.  A naive verifier could become confused in processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the "context" signature parameter.  For example, a signature targeting an application gateway could require "context="app-gateway"" as part of the signature parameters for that application. </ins> 8. 8.1.

Related discussion:
text: Yes, you have it right. This is analogous to the JWT claim whose goal is to prevent cross-protocol (or really, cross-usage) attacks. So making this mandatory is important. I think mandating verification is nice in theory but I'm not sure it would be effective in practice. Instead, we could give guidance that makes it trivial to use, like in my example: include the protocol's name and possibly version. Just doing that would narrow the "blast radius" of cross-protocol attacks significantly. A "nonce" () is a well defined term. This is not a nonce. The on is weaker than I would like, but it's still a SHOULD for new types of JWTs. Here we have an opportunity to get it right from day one.
I appreciate the position, but what if the application is literally just "I am signing this message"? What would we put in that mandatory field that isn't either a random value or just "http"?
Then put the application/service name there, instead of a protocol name.
What's the application or service name, then? I don't think it's always as well defined as you're assuming it to be in practice.
It's guidance, not interoperable normative text. Whether people use "myapp" or "myapp/1" or even "myfile.c" doesn't matter all that much. Basically anything is better than a missing context.
If it's not interoperable normative text, then it has no business being a MUST here.
Existence and verification of the parameter are both normative. Its content is not.
NAME Could you provide an example attack scenario that cannot be mitigated by signing additional semantically relevant message components, and is mitigated by the addition of a parameter? The JWT claim is necessary because often there is nothing in a JWT that ties it to a particular message. This is a feature of JWTs, as it allows things like reusing JWT-formatted access tokens across multiple requests. I'm not familiar enough with TLS internals to say whether the same concept applies to the TLS "context string" parameter. In contrast, reuse across messages is not a use case for HTTP Message Signatures. If a signature is reusable across two semantically different messages, that would suggest to me that the signature is not covering the right message components.
Code change:
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.25. Multiple applications and protocols could apply HTTP signatures on the same message simultaneously.  A naive verifier could become confused in processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the "context" signature parameter.  For example, a signature targeting an application gateway could require "context="app-gateway"" as part of the signature parameters for that application. </ins> 8. 8.1.

Related discussion:
text: So cross-protocol attacks where the signature is presented as a message signature for a different message are mitigated by signing the semantically relevant components. (e.g., , or parts thereof, etc.) Attacks where the signature is presented as some other type of signature (i.e., not an HTTP message signature) are partially mitigated by the fact that the signature base includes the signature parameters, which is likely to distinguish it from content that may be signed in other contexts. For example, the format of the signature base means that an HTTP message signature cannot be passed off as a signature for a JWS. If the overall format and the footer is not already enough for this, I don't see how adding an additional parameter would help. If an attacker can mold the signature input in another context to match the HTTP message signature format as it is, it seems unlikely to me that adding to the end would help.
Hi NAME I'll start with your last paragraph. I agree what we have now is only partial mitigation. This kind of attacks is never fully mitigated, because you need to make assumptions on what implementations of a different, unknown protocol would do. But in general IMHO a unique prefix is a much better way to distinguish between signatures, because something further down in the signature base may be ignored by verifiers. Concretely, having a mandatory as the first line of the signature base would be a much better mitigation. Now back to the : again, we are talking about two different protocols, each of which may have both spec and implementation errors. Of course if both protocols are defined and implemented perfectly, the right fields would be covered and validated, and would also define unique semantics. Life is not perfect - people are lazy and will sign too few fields - and a context protects some protocols/implementations from others.
I'm not sure I buy this. If a non-HTTPSig consumer of signed content can be tricked into accepting as a valid message then I don't see why we should assume it would be any harder to get it to accept Okay, can we walk through the failure modes? An API that exposes multiple operations on different paths could fail to require callers to sign the target URI's path. In order for to help, it would have to be set to a unique value per operation, e.g., "ExampleApp.doExampleThing".
Code change:
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.25. Multiple applications and protocols could apply HTTP signatures on the same message simultaneously.  A naive verifier could become confused in processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the "context" signature parameter.  For example, a signature targeting an application gateway could require "context="app-gateway"" as part of the signature parameters for that application. </ins> 8. 8.1.

Related discussion:
text: That seems like way more work than just signing the right things. An app could fail to require all of an operation's inputs to be signed. In this case, the only way helps is if it is unique per request, e.g., a hash of all the operation inputs. This is definitely way more work than just signing the right things. Two apps could fail to require the request audience (e.g., the target URI authority) to be signed, allowing signatures to be replayed across them. Here only helps if it is set to something that is app specific. That rules out the use of standardized values based on protocol (e.g., ) or intent (e.g., ). And if is being set to something app-specific, why not just sign the app-specific thing that is already in the request? Are there other failure modes that I'm not considering, where would prove more useful? So far this leaves me feeling that is more likely to encourage bad habits and give implementers a false sense of security than it is to address any actual security risks.
I do not see how having a fixed signature prefix will solve any security issues with signature base generation. All the same problems with bad implementations occur internally in the signature base, the only difference is that you've got MAYBE a good first line -- and as NAME mentioned this is not stopping people from doing different bad things like having newlines in the content identifier. We can add a security or implementation considerations section on newlines in the signature base. Even then, I am failing to see how this prefix idea is related to the signature context concept. And as NAME said, apps failing to sign enough is an issue for the app. Having a signature context isn't going to magically get that necessary content signed, nor will it make a badly written verifier reject unsigned required content. Again, I'm fine with adding context as an optional parameter for applications that want to make use of it for signaling, but I don't think it solves things in the way that is being presented here.
Works for me. Thanks!
Code change:
or <del> frame, with the END_HEADERS or END_PUSH_PROMISE flag set, or </del> <ins> frame, with the END_HEADERS flag set, or </ins> a or <del> frame with the END_HEADERS or END_PUSH_PROMISE flag cleared and one or more </del> <ins> frame with the END_HEADERS flag cleared and one or more </ins> frames, where the last

Related discussion:
text: This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.
Code change:
Cybersecurity Executive Order (EO) 14028 recommendations from NIST and will need to supply "Software Bill of Materials" (SBOM) and a "Vulnerability Disclosure Report" (VDR) NIST attestation to the DOI <del> prior to procurement. </del> <ins> prior to procurement.  Unlike SBOMs, VDRs continue to evolve over time as new vulnerabilities are discovered that may impact previously released software.  Consumers will continually check their vendors and potentially other SCITT sources for updated VDR reports providing the most up to date information on new and previously consumed software. </ins> 4.2.1.

Related discussion:
text: A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.
Code change:
an OAuth 2.0 Token Exchange RFC8693 to obtain a Txn-Token.  To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. <del> This context MAY include: </del> <ins> The context information provided to the Txn-Token Service MAY include: </ins> The external authorization token (e.g., the OAuth access token)

Related discussion:
text: See issue
In section 2.2.1 the context that may be included in a transaction token includes "The external authorization token (e.g., the OAuth access token)". To ensure this is not interpreted to mean that an access token is included in a transaction token, I would suggest the following additions, in line with section 9.3 in Security Considerations: "A reference to the external authorization token (e.g., the OAuth access token), including scopes or claims included in the authorization token, but not the unmodified authorization token (see Security Considerations, Section 9.3)"
Pieter, in that section of the spec we are describing what needs to be sent to the Transaction token service, I think in that case the full access token should be passed. However, when generating the request context, we want to ensure that the full access token is not included. Did I get my spec sections wrong?
Maybe instead we shouldn't say "This context MAY include:" but rather ... "The information provided to the Txn-Token Service MAY include" to not confuse readers who might think this data should be included in the request context.
Agreed - I missed that this was for initial token creation. I did create a PR with your suggested text.
PR approved
Looks good.
Code change:
the trailer section prevents digest validation, possibly leading to processing of invalid data. <del> Not every hashing algorithm is suitable for use in the trailer section, some may require to preprocess the whole content before sending a message (e.g., see I-D.thomson-http-mice). </del> <ins> One of the benefits of using Integrity fields in a trailer section is that it allows hashing of bytes as they are sent.  However, it is possible to design a hashing algorithm that requires processing of content in such a way that would negate these benefits.  For example, Merkle Integrity Content Encoding I-D.thomson-http-mice requires content to be processed in reverse order.  This means the complete data needs to be available, which means there is negligible processing difference in sending an Integrity field in a header or trailer section. </ins> 6.5.

Related discussion:
text: LGTM
On the list, Rob Sayre asked: I agree it seems we can improve the text here a little. Maybe NAME or NAME can elaborate as to why a digest trailer is not suitable in this case?
The reason is that in order to produce a MICE hash, you need to process the content in reverse order. Therefore, there is no reason not to put the hash in the header. The advantage you get in return is that you can process the response in natural order.
Thanks martin. We should just say it that way, because it is clearer to the reader. I'll follow up with a PR.
Code change:
AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields. <ins> If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and <del> StartObject. </del> <ins> StartObject.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> A filter type other than the above MUST be treated as error. <ins> If a subscriber wants to subscribe to Objects both before and after the Latest Object, it can send a SUBSCRIBE for the Latest Object followed by a FETCH.  Depending upon the application, one might want to send both messages at the same time or wait for the first to return before sending the second. </ins> The format of SUBSCRIBE is as follows: Subscribe ID: The subscriber specified identifier used to manage a

Related discussion:
text: Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.
Code change:
An error on the individual HTTP/2 stream. <del> Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined in RFC7230. </del> <ins> Finally, the terms "gateway", "intermediary", "proxy", "tunnel", "message body", and "payload body" are defined in RFC7230. </ins> 3.

Related discussion:
text: There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.