jiebi/CodeConvo huggingface dataset:
I believe some of this is covered by the recently updated GOAWAY section and I'm not sure what else to add here.
I don't think these TODOs have been covered yet. That being said, I would rather we file issues for these so there can be a conversation, rather than litter the draft with TODOs.
I'm unsure what's unresolved, but if you can file new issues as appropriate and link them to this PR, that would be helpful.
This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
Update query parameter generation in examples,
I verified that B.2.3 is fixed, but did not implement the "ttrp" example.
The Example from uses the following request defined in B.2 The signing string is meant to be But that does not work because in the request we have and the date in the signing string is one minute later
Thanks, all the examples need to get re-generated and I'll work on that soon. The current generation script is at URL ... it's very manual right now but I'm thinking of reworking it to do actual HTTP message parsing under the hood like we have at URL instead, so we don't end up with inconsistencies like this in the results.
I am also developing a test suite for the examples in the spec, which is why I am reporting the bugs I find here :-) That can help you later verify that your new setup is correct. I just found a last error in the Signing String. The Signing string given there is my test tells me that the diff should be: But the implementation having is correct I think.
Examples have been regenerated by , please check the new example for consistency.
Just saw this other comment, yes it looks like there's a bug in the query value generator that drops the question mark!
Btw. My EU project just ended, so I am looking for extension projects. But perhaps someone here knows companies that need me to work on the implementation? (Ie,Java or JS or Scala)... I don't really know where one can ask this. A bit of a specialized thing :-)
NAME please check the updated examples in -- I re-ran the script with some bugfixes in place which should fix both B.2.3 and the TTRP example in the appendix.
:Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request). Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYNSTREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYNREPLY. The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc. If we include the settings as part of the initial Upgrade GET then 1) Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler. 2) Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!
Should we leave these open until after IESG last call, or just apply them now?
Good Q. NAME ?
I think it'd be preferable to not cut another version until we get through the IETF last call. However, if we want to merge this and just keep a note of the changes, I don't see any issue.
I think it would be preferable, just to avoid people raising the same issues again, and also to get the Index into the last call version.
HEAD says whereas the new text for GET is and similarly for DELETE. We should update HEAD as well to be
Digging in the change logs: the text for GET comes from URL (with subsequent tuning).
This PR adds a definition for a timeline track format, along with details about how to identify timeline tracks in the catalog and how to update timeline tracks. and
I like it! Regarding "The publisher MUST publish a complete timeline in the first MOQT Object of each MOQT Group." it means that the first object of the group strictly inflates with time. For an open range track (for example a 24/7 video channel), it may become excessively long. We may allow summarization of old times in the timeline csv.
A special ‘timeline’ track is produced which describes the availability of groups and objects with respect to media time and wallclock time. May also carry media time events which can be used by the player in constructing a UI, for example “Goal”, “Penalty”. This track can be used by the player for seeking to request specific portions of a DVR window in a live stream, or to any portion of a VOD asset. This may be used for advertising insertion at a later date. In the proposed structure below, the metadata field may be empty. If present, it must be enclosed inside double quotes and may hold any string data. In this example, JSON and XML metadata entires are shown.
I like the idea. Note that some have advocated for KLV as the support for timed metadata for live video. Here is a Demuxed talk about it a couple of years ago URL
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!
and . Switches to zlib instead of gzip encoding and adds the recommendation to use the best available compression.
I'm working on a TypeScript implementation of this spec, and have the encoding / decoding of the status list implemented. It seems to work based on the example in the spec and the example python scripts, with one slight difference. When I encode either the 1 or 2 bit example it will output one character difference , while mine outputs an . The decoding seems to work fine, and maybe this is a gzip thing, but I'm wondering if the examples use certain gzip features to get this output? I've adapted my implementation to use compression level 9 (default for python lib) and set the mtime to the same value The input byte array is the same as for the python implementation and the examples in the spec, so it's really something that is happening during the gzip encoding (the output byte array here is different) any idea what is going on here? The implementation and tests can be found here: URL
Seems to be a difference in the header - from the position I would assume the timestamp (even though you seem be setting it to the fixed value used in the examples in the draft)? There is also a header entry for the operating system - that would also be a very likely candidate for the difference. I will take a look at it when I am back from IIW. We were discussing switching from gzip to zlib (or deflate directly) for that reason - we don't really need these headers and most languages seem to support both gzip and zlib (which was our concern when we initially thought about this). Related Issue:
Thanks for testing! There is a header as well in zlib, but it's considerably smaller. The zlib header does not include a timestamp which makes it better for reproducible results and test vectors. I think we should also give a recommendation for the used compression level, I suspect either default or highest. It would be interesting if the underscore vanishes in zlib?
I changed the python implementation to use zlib with level 9 and did the same for your typescript implementation --> both resulted in the same: We should really change that imho (and also add the text to recommend compression level).
I'm a proponent of using zlib instead of gzip. As suggested in the other issue, we don't really need the other metadata. And the result is smaller as well :)
Not sure that this needs a citation.
URL describes how HTTP/2 can be used to remove some network-induced jitter from the timing measurements. If your server has timing side channels, then putting requests that can be compared in the same IP packet ensures that the server receives them at the same time. This doesn't help if timing differences are masked by server queuing, CDNs or load balancers, or response delivery, but it can help reduce measurement noise. Consider documenting this.
I'm reading this as editorial not normative (or at least not changing the wire protocol); seems uncontroversial.
Yeah, I'm not sure what else we can say here. There are risks here, there are not really many mitigations available.
The five authentication parameters are offset in various ways throughout the document. Examples: using the Parameter (Section 3.3) using the v Parameter (Section 3.2) The REQUIRED "p" (proof) parameter (Section 4.3) Additionally, the word "directive" is used instead of parameter in Section 4.4. It might be advisable to align the document on always using one of these, with a possible difference where the parameter is being defined.
Agreed. I'll write a PR that standardizes on parameter and not directive "p" when defining a new parameter when referencing the parameter
As discussed with NAME and NAME because the proof is scoped under , when , and is ultimately wrapped in bstr to make parsing optional, there is no need to obtain assignments for keys it uses internally. This PR is assigning values, and removing the requested assignments accordingly. Edit: I've found that it's possible to be more precise about sizes in CDDL, so I've tightened the schema a bit.
NAME if you have a minute to have a look ahead of today's meeting, that'd be wonderful :)
NAME CCF tests now automatically check some of the proofs against the schema: URL Since this is approved, can it be merged?
NAME yes :-)
lgtm! Thanks a ton.
I think this is strictly an editorial clarification, not a technical change, but something that came up in discussions within the team. If there's any question about that, feel free to push it back and we'll discuss on-list.
This looks like , sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too.
Similar issue, different layer…. is talking about multiple instances of the same setting value in a single SETTINGS frame. This commit is talking about multiple instances of the “HTTP2-Settings” header in an HTTP/1.1 request that’s offering Upgrade. From: martinthomson [mailto:EMAIL] Sent: Thursday, July 18, 2013 3:49 PM To: http2/http2-spec Cc: Mike Bishop Subject: Re: [http2-spec] Clarify no duplicate instances of HTTP2-Settings () This looks like URL, sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too. — Reply to this email directly or view it on URL
Ahh, I don't see this as a big deal, since "a header field" and "exactly one header field" seem equivalent to me. I'll pull it in.
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).
My take on trying to make registration auditable. This is still very open-ended in terms of implementation choice
I have made optional, but still supported
Steve, Is it too late to add another service API to SCRAPI: Retrieve Registration Policy Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Hi, NAME Once the Architecture is settled, we plan to put more focus on SCRAPI, and yes, we can certainly add/edit/remove.
NAME this PR contains guidance for SCRAPI enabling registration policies to be retrieved: URL It also adds optional endpoints for retrieving signature and payloads, not just receipts.
Thanks NAME NAME I'm still not sure how the architecture handles a revoked certificate used to sign the registry log. Would a new log be started with a different signing key and the old log would remain available for reference - with a warning that the signing key has been revoked or is expired? Still trying to figure out implementation details so that REA can support the initiative. I assume the results of a SCRAPI query would contain a warning that the returned results are from a log that has a revoked signing key.
SCITT does not have any messages currently related to revoked certificates. What messages do you propose?
It can be as simple as a warning in response to a query i.e. “Warning: The signing certificate has been revoked or has expired” Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Dealing with expired or revoked TS certificates should be straightforward, as you can always obtain a fresh receipt for a previously registered transparent statement. For issuer certificate this is a non-issue as SCITT only guarantees the issuer certificate was valid at registration.
Thanks, Antoine. Is this also the case when the certificate used to maintain log integrity has been revoked or has expired. I’m presuming the registry log integrity is also maintained using a digital certificate – correct?
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788
Yes, that's what I called the "TS certificates", i.e. the certificate used to sign the COSE receipt/countersignature. That's the only certificate relying parties would care about - if there are other internal certificates it's up to the TS implementation to expose the details to auditors through the audit API
Antoine, What is the set of criteria that the TS should use during the registration policy evaluation? Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership Never trust software, always verify and report! URL Email: NAME NAME Tel: +1 978-696-1788 From: Antoine Delignat-Lavaud NAME Sent: Monday, March 4, 2024 8:50 AM To: ietf-wg-scitt/draft-ietf-scitt-architecture NAME Cc: Dick Brooks (REA) NAME Mention NAME Subject: Re: [ietf-wg-scitt/draft-ietf-scitt-architecture] Registration auditability requirements () (PR ) NAME commented on this pull request. In draft-ietf-scitt-URL : -Transparency Services MUST, at a minimum, perform the following checks before registering a Signed Statement: +During registration, a Transparency Services MUST, at a minimum, authenticate the Issuer of the Signed Statement by validating the COSE signature and checking the identity of the issuer against one of its configured trust anchors, using the (34), (33) and (4) protected headers of the Signed Statement as hints. +For instance, in order to authenticate X.509 Signed Statements, the Transparency Service MUST build and validate a complete certificate chain from the Issuer's certificate identified by , to one of the root certificates most recently registered as a trust anchor of the Transparency Service. +The Transparency Service MUST evaluate the registration policy that was most recently added to the Append-only Log. See the updated comment thread on line 403 (now 405) about possible weakening of this requirement — Reply to this email directly, view it on GitHub , or unsubscribe .
You are receiving this because you were mentioned.Message ID: NAME
Since the refactor and the shift to X.509-based claim signature, the authentication of issuers is no longer auditable - i.e. it is no longer possible for verifiers and auditors to re-validate the claim signature and issuer authentication performed by a TS at registration, which massively increases the trust in the TS (which may now try to register forged claims with plausible deniability - by claiming the TS lost the issuer's certificate used at registration even if none existed). Part of the issue is that claims use x5t instead of x5c. This means there is no mechanism for auditors to obtain the certificate chain used to sign a claim from the TS at registration. Even if x5c was used instead of x5t, only the leaf certificate is required to appear in x5c. Reconstructing the full issuer certificate chain requires at least the TS configuration to link to the configured root CAs used by the TS. Since roots and intermediate certificates expire (or can be updated, as is often the case with PKIX root programs from Mozilla, Google and Microsoft), it is not possible to assume that verifiers can just store the root configuration with the TS's certificate. There are further issues with issuer authentication: >When x5t is present, iss MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a distinguished name. This is not well-specified without a reference to such a regular expression. Is this supposed to mean RFC4514 string representation of a distinguished name? The language of RFC4514 doesn't appear to be regular (it is context free), so this must be clarified. There is also no requirement for the issuer's serialized distinguished name to be produced from the claim's X.509 leaf subject. A malicious issuer can put a different issuer's serialized distinguished name in the iss field and is likely to confuse a verifier who cannot detect the mismatch since issuer authentication is not auditable. This makes iss essentially useless for verifiers, and it may be preferable to set iss to nil if x5t/x5c is used.
I propose we require in the architecture that the full certificate chain used to identify the issuer and verify its signature at the time of registration be authenticated by the TS via the resulting receipt.
Given a transparent statement (and possibly auxiliary transparent statement from the TS log recording root and intermediate certificates) verifiers must be able to retrieve and review the full certificate chain. This clearly separates PKI issues (delegated to certificate issuance) and the evidence required to keep them transparent and auditable. The text included a a way to implement this requirement based on transparent configuration statements, which I found useful but may be too detailed/prescriptive for the architecture.
I don't think its in the spirit of COSE to include the full cert chain in a protected header. A thumbprint to a certificate that is in a chain is more concise.
This issue will be closed if no PR is raised by Friday.
Closed with
These changes seem appropriateI suggested a couple of improvements, but overall I support this PR. LGTM
by adding an explicit bool indicating whether any Objects were published for a subscription, similar to the explicit bool added to SUBSCRIBE_OK in .
and define: However, what happens if no objects were ever produced/sent?
Individual Comment: Oops. Two possible ways to handle this: 1) Flag indicating presence of these fields (Use Location now that is defined elsewhere?) 2) Change the semantics of the fields to be exclusive (eg: it is the first object NOT sent), so 0/0 means none.
I'm inclined towards 0/0, because optional fields are more complex to parse and I would expect the existing logic to work correctly with 0/0.
Let's say the last object delivered by the relay is . Does the relay send RESET or ? Is the subscriber able to infer the presence of future objects? What if either of those objects actually exist in the cache?
Individual Comment: If we use exclusive encoding then I'd say that the receiver shouldn't infer the existence of non-existence of the named object, and either 5/30 or 6/0 works, but 5/30 is preferable?
If you define there will be no objects greater than or equal to these, then 0/0 makes total sense. So 0/0 for null case and say the last group ID of the last object publish was 10 then the value in SUB_FIN would be 11.
In we went with an explicit flag, so I'm inclined to do the same here for consistency.
Included feedback based on
Section 3.6 (the section about an attacker emulating an enterprise application) is the canonical example of an illicit consent grant attack leveraging the device authorization grant. One of the key things that makes this attack particularly scary is the fact that everything the targeted user sees (outside of perhaps the non-ordinary flow involving user_code entry) indicates to them that they're signing into a trusted enterprise application, since you can use a trusted app's client ID when initiating the flow. In reality, however, they're just completing the second leg of a flow initiated by some attacker's script. While you mention "emulating an enterprise application", I don't think that provides the clearest example of why this is particularly scary. I think you could go a bit further and emphasize that everything the user sees in this sort of attack is: a) trusted UX and b) indicates that they're signing into a trusted application.