jiebi/CodeConvo huggingface dataset:
URL [ ] In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. [ ] In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” The draft looks good to me. I have two minor suggestions. In section 3.2, there is language about minimizing dependencies by using the same hash for the timestamp and the signature. This suggestion does not seem to be unique to CTT, so I’d either repeat the language in 3.1 or move the language to a more general location that covers both use cases. In section 4, I suggest changing “the receiver MUST make sure that the message imprint in the embedded timestamp token matches either the payload or the signature fields, depending on the mode of use” to something like “the receiver MUST make sure that the message imprint in the embedded timestamp token matches a hash of the payload, signature, or signatures field, depending on the mode of use and type of COSE structure” From: Michael Jones Date: Tuesday, July 30, 2024 at 1:53 PM To: "EMAIL" Subject: [COSE] WGLC for draft-ietf-cose-tsa-tst-header-parameter Hi all, This message starts the Working Group Last Call (WGLC) for URL The WGLC will run for two weeks, ending on Tuesday, August 13, 2024. Please review and send any comments or feedback to the working group. Even if your feedback is “this is ready for publication”, please let us know. Thank you, -- Mike and Ivaylo, COSE Chairs _____ COSE mailing list -- EMAIL To unsubscribe send an email to EMAIL
Missed in
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free
In this PR, I generalized the examples: Right now, there is a lot of repetition in the code for each of the three examples. With more examples (W3C VC) and more example code (claims merging) to come, things will get more complicated. I therefore moved the examples into a separate directory as YAML files. I used YAML, because this means that we can store all data required for each example as separate JSON documents in one YAML file (JSON is a subset of YAML). The code can now be called with a YAML file as the input and will run the demo for the example defined in the file. This will make it easier for us to add more examples in the future. Also in this pull request: Cleaned up the code to produce just one example each time - there is no need to calculate all examples when only one is used in each run Cleaned up the code to produce both the CLI output and the spec examples from the same set of data to avoid repetitions This means that placeholders in URL are now strictly named as follows: , where refers to the identifier of the data produced in the example run (see file). Fix for example output: serialized SVC was not shown, but serialized SD-JWT twice Renamed to (not sure what was meant to say) Fix for norandomness: RNG was seeded to static value even when no_randomness was not used
Yes, it was in my backlog, thanx. This first proposal was to get all the examples in a single shot, we can add a CLI parameter, I'll have a look for that This means that placeholders in URL are now strictly named as follows: example-{exampleid}-{artifactid}, where artifactid refers to the identifier of the data produced in the example run (see sdjwt file). Thank you, I wanted to make a proposal for this, you did it My bad it was "selected example" but artifacts is better anyway OK!
Issue Also harmonize title with other endpoints
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
On internal or truly public instances this could be MAY
Define a signature algorithm named that indicates the use of ECDSA using curve P-384 DSS and SHA-384. The algorithm description is probably just 3.3.4 with "256" replaced with "384", but should validate that assumption with actual crypto folks.
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's extensible.
I agree with not defining every possible algorithm; however we should include those with known use cases, and AWS intends to use -384. Since the spec isn't finalized and the addition is trivial, it seems reasonable to add it here rather than punting it to an extension spec.
Based on comment: URL and responses: URL URL it is clear that the SNAC stub router solution may in some cases not work if the IPv6 Host on the AIL that needs to send an IPv6 packet to a host on a stub network is a Type A or Type B Host. In fact, our assumption so far has been that it is a Type C host. Proposal: add clarification that solution scope is intended for Type C hosts on the AIL. (Though it might work for Type A and B hosts in particular cases, this is not in our scope.) Refer to RFC 4191 Section for the 3 host types. (FYI NAME
Looks like a good place to add this scoping information - in the goals section. Thanks Hello, I can try to respond from my viewpoint. This could help to identify the open issues. I don't see how RFC 8028 is relevant here. It has the following applicability: IPv6 host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering The network/link (AIL) considered for SNAC-simple is a link with a single IPv6 on-link prefix. Either a global/ULA prefix allocated by e.g. a home router, or if that is missing, a ULA prefix allocated by one of the stub routers. So there's not "more than one prefix" and I don't see immediately if any problem would occur if we would have > 1 prefix. For example the IPv6 host on the AIL would remain reachable from an on-stub-network host, regardless of the IPv6 source address that the host on the AIL used. See also below for more info on this case for the packets in the other direction. This part I agree should be clarified in SNAC-simple. I assumed a Type C host for sure. And I would consider Type A and Type B to be even out of scope if required to keep the solution simple! One question is: what if a Type A/B host sent an IPv6 packet to the ULA dest address of a stub-Host ; and the packet would be routed to the default router of the home network? (E.g.
home router / Wi-Fi AP / ISP box) Wouldn't that default router immediately discover that the correct route is to send it to the stub router, based on the RA RIO advertisements? So the routing is not most efficient then but it works. If that is the case, we can still support Type A/B hosts although with some degraded performance/latency. I think we could clarify that the stub router must never ever advertise itself as a default router (or advertise a default route ::/0) on the AIL. This isn't in the draft yet. Not sure if that is what you meant here? The existing mentions of "default route(r)" in SNAC-simple are pertain to advertising itself as default route on the stub network side, not the AIL side, I believe. Given the above, even if the host would not follow rule 5.5, it would pick another source address, but still that address would be based on an IPv6 prefix that is on-link. So it means the stub router can correctly route back to that prefix and use IPv6 ND to find the host back on the link. And the IPv6 host if it is type C would still use the RA RIO advertisements to pick the next-hop router, regardless of its IPv6 source address. The only question I have is for the Type A/B hosts - they might pick a default router instead and the question is there if it would route back the packet to the right stub router on the AIL instead of sending the packet out onto the wider Internet. (My expectation is that it would work, but ... ) But this Type A/B host problem is there independent of the source address selection. Or am I missing something? Also keep in mind that there are in total 3 possible cases for a given stub router: Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another stub-router (there may be N stub routers in total, each with a different stub network) has assigned the AIL prefix. That means the prefixes don't use a shared ULA prefix. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another non-stub-router (e.g.
home AP) has already assigned a prefix for the AIL. That means the prefixes don't use a shared ULA prefix. So we cannot rely on features that only work well when a single ULA prefix is used to derive the AIL on-link prefix and the stub network on-link prefix. Esko -----Original Message----- From: Snac On Behalf Of Erik Auerswald Sent: Sunday, August 20, 2023 20:24 To: SNAC List Subject: [Snac] Host Requirements for SNAC Use? Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple?
If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems Snac mailing list EMAIL URL
Hi, I was looking for existing methods for a host to select the correct gateway when there are more than one. RFC 8028 is one example. I agree. I would not expect an existing home router to look at any RAs from inside the home network, much less to populate its routing table with the information from those. As such, the home router would either forward the packet via its default route, or drop it. I doubt that to be the case. I think that a stub router following the new SNAC ideas could learn routes from RAs received on the AIL, and use these to forward packets towards the home router or even other stub networks. But as fas as I know this is not common home router behavior.
This might be nice to avoid breaking Internet connectivity when adding a stub router to a home network But for reliable connectivity to the stub network, the host would still need to select the stub router as gateway. If the stub router sends an RA with a non-zero lifetime, it advertises itself as a default router. An RFC 4191 type B or C host would evaluate a default router preference and should thus prefer the home router if the stub router uses a Low Preference (unless the home router were also to use a Low Preference), but an RFC 4191 type A host does not evaluate the Preference. I would suggest to require a stub router to use a Low Preference in the RA, but a High Preference for its stub network prefix(es). I have read RFC 6724 again, and I think I made a mistake. RFC 6724 expects that the first hop gateway is selected via destination address, and then describes how to optionally choose a better source address for use with this gateway. This does pertain to RFC 8028, but not to SNAC. I think you are correct. I would expect independent stub networks to use different 48-bit ULA prefixes. In general, a single stub network should suffice with using a single 48-bit ULA prefix, but current implementations may not restrict themselves to this since it is not seen as necessary. I think we cannot rely on many features to be consistently present in existing home networks. Currently, SNAC implicitly requires RFC 4191 type C host behavior. This could be made explicit. I think that would improve the draft. I do not see a rationale for the requirement of a single ULA prefix in draft-ietf-snac-simple-02. It seems logical that a stub router would not need more than one ULA prefix, and one such prefix might be nice. It might help in troubleshooting. It might help keep RAs sufficiently small. It might help keeping routing tables small. It might work together with source address selection to help selecting the stub router as first hop gateway (but that is not described in RFC 6724, but a rather different idea). With no explicit reasons for a single ULA prefix, the requirement could be reduced to a SHOULD or even dropped from the draft.
The current motivation to drop the single ULA prefix requirement seems to be that an existing stub router implementation does not limit itself to a single prefix. I find this reasoning quite weak. I wrongly interpreted RFC 6724 section 5 rule 5.5 to help select a gateway after selecting the source address, but it works the other way around. Thus I do not have a strong reason for a single 48-bit ULA prefix any more. I do think that it would be neat to have just one 48-bit ULA prefix per stub network, but that is insufficient for a MUST, I'd say. Best regards, Erik The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- Edsger W. Dijkstra
Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network.
Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems
There is currently a discrepancy in the spec regarding invalid values in the SameSite cookie attribute. For example, this cookie: Set-Cookie: foo=bar; SameSite=bogus is expected to be dropped entirely according to the "Server Requirements" under Section 4.1.2.7: If the "SameSite" attribute's value is neither of these [ "Lax", "Strict" ], the cookie will be ignored. whereas under Section 5.3.7 of "User Agent Requirements", the cookie is to be kept but the attribute is ignored: If cookie-av's attribute-value is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av". Additionally, the end of Section 4.1.2 also matches the behavior described in Section 5.3.7: User agents ignore unrecognized cookie attributes (but not the entire cookie). From a forward-compatibility point of view, the behavior described in section 5.3.7 is the ideal one since it allows for future expansion of this feature such as: Set-Cookie: foo=bar; SameSite=medium
NAME
Done. Let me know if I missed anything else.
URL Section 3.1 of the spec states that "SameSite" alone (without an attribute value) is a valid token: URL Section 4.1 URL states If "cookie-av"'s "attribute-value" is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av".
Ah. URL draft is outdated vs. URL The latter no longer allows a bare "SameSite" token, and it calls for the cookie to be dropped in the event that the samesite-value isn't either "strict" or "lax". However, I think this text isn't quite right: If 's is not a case-insensitive match for "Strict" or "Lax", ignore the . The in this case is 'SameSite=whatever' and we want to ignore the whole cookie, not just the invalid attribute?
is my proposal to fix this. We ran into this issue in the Firefox implementation: URL
Thanks!
In its current wording, I interpret to allow to be used in the following two situations: The requested operation is forbidden in the current state of the resource. The requested operation is forbidden (for the user identified) by the provided authentication credentials. This ambiguity is established in the following paragraph: The ambiguity is somewhat lifted (but not entirely) by the last sentence: However, I believe the ambiguity exists and causes a lot of developers to believe that is only applicable to authorization errors. I think the wording in the previous paragraph: …the example given in : …and the wording in : …as well as existing practice establishes that is the correct status code to respond with when the requested operation is not allowed in the current state of the application (use-case 1 above), regardless of the header provided. Introducing the ambiguity of only being applicable to the provided authorization when authorization is available makes the status code harder to reason about and therefore harder to use in practice. Would it be possible to remove this ambiguity somehow? Here's some suggested wording:
ISTM that the phrase "authorize it" in the first sentence of 6.5.3 is the root of the issue. I note that 2616 used "fulfill it" instead; we should dig around and see if that was an intentional change.
I agree "authorize it" is the root issue, but think it's exacerbated by the following paragraph. It would be good to clarify the entire section to make it obvious that the presence of an header doesn't require the semantics to change.
Discussed in Montreal; ok to change.
The change from “authorize” to “fulfill” helps to resolve the ambiguity, although I would like to see a in the following paragraph: >If authentication credentials were provided in the request, the server consider them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials.
I don't think a "MAY" helps here. The current text is: That's a statement of fact. If the credentials would have been sufficient, there wouldn't be an error. (It does not necessarily imply that things would have worked with different credentials).
I think that’s exactly what the current text implies: That sufficient credentials would have lead to a successful request, regardless of the state of the resource.