jiebi/CodeConvo huggingface dataset:
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.
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.
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 .
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!
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)
Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)
See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.
This avoids having to determine whether is an actual existing standard or not. This is an alternative to
Merging for draft cutoff.
The lists an entry for HTTP/.\, and specifically identifies "2.0" as a possible version value, as instructed by . However, this flow seems to have been superseded by "Upgrade: h2c", which was introduced in RFC 7540 and deprecated in RFC 9113. I am not aware of any implementations of "Upgrade: HTTP/2.0" in clients or servers. I think we have two main options: Status Quo: Regard "HTTP/.\" as a mechanism that is formally defined but not implemented anywhere. Provide formal analysis of its security for completeness. Deprecation: Update RFC 9110 in this draft to remove the definition of this upgrade token. Mark "HTTP" as "obsolete" in the Upgrade Tokens Registry.
Moving discussion over to the issue, perhaps. Upgrading to TLS is a defined thing that gets used; I'm not clear that we need to deprecate that. Upgrading to future HTTP versions is a little more interesting. Certainly it's illegal to upgrade to or because upgrade isn't defined by those specifications. RFC 7540 defines a distinct token, RFC 9113 deprecates it, and RFC 9114 does not define an Upgrade path for obvious reasons. It certainly looks like we've decided not to use this mechanism for changing HTTP versions. Does that mean we should eliminate it? I'm not opposed, but I'm also not certain we need to go there.
Moving to TLS with upgrade (i.e., RFC 2817) is now so much of a niche thing that I think that deprecation would be wise. We've heard that it is still in use, but it's certainly not inoperable in quite the same way as other parts of the protocol. Either way, I think it would be better to write a separate document deprecating Upgrade (either completely or more narrowly) than to sneak it in here. This document can point out that it is unsafe in the ways in which it is unsafe, but it doesn't need to make the deeper cut to achieve that.
It seems clear that we don't want to deprecate in this document, so I've removed that text from . I've kept open to discuss the fate of .
The WG seems to believe that this mechanism is already deprecated, if it was ever defined at all, and the IANA registry entry is just misleading or incorrect.
The trouble is that exists in a sort of quantum superposition of standardized and deprecated, but that will collapse if we mention it in this draft in any way. The options I see are: Don't claim (as the current text does) to present an exhaustive analysis of the defined Upgrade Tokens, and silently ignore the registration of . Treat it as a live standard. Declare that it was already deprecated. Deprecate it.
I'd say deprecating isn't particularly useful or interesting, since that doesn't impact implementations. If we can't agree on which quantum state we are in and want to be in at the same time, then I'd leave the cat in the box. The more interesting question is: should implementations do something to protect against a dangerous ? For h2, the preface should protect against smuggling. Where do we stand for other versions, is there a risk we should warn implementers about?
My expectation is that implementations of do not exist, and never will, so I don't think it's very useful to provide guidance to them. There's a question of whether one can even speak about a "downward Upgrade" from HTTP/1.1 to 0.9-1.1. Assuming that is allowed, I think 1.0 and 1.1 are safe, if we assume that the HTTP-Version line is sent/repeated at this point. (Does Upgrade: HTTP create a new HTTP connection or re-version the existing one???) They both start with "HTTP/1", which is not a valid method name due to the "/". HTTP/0.9 is possibly more interesting since it does not send an HTTP-Version line. I don't see a way for the server to figure out whether the client is speaking HTTP/1.1 (after the rejected upgrade) or HTTP/0.9 (optimistically). However, I don't think this poses a security threat, so long as the attacker-controlled data is the same in HTTP/1.1 as it is in HTTP/0.9.
There could possibly be a problem if the client, believing it is speaking HTTP/0.9, allows untrusted code to manipulate headers that were not special in HTTP/0.9 but are special in HTTP/1.1 (e.g. Content-Length, Transfer-Encoding). But as I said, this strikes me as counting angels on the head of a pin. "Upgrade: HTTP/0.9" is just not a thing, and we should all agree on that and move on.
I totally agree with you. I was more thinking about guidance for intermediaries that support other Upgrades (e.g., WebSocket) for what they should do if they encounter unknown/unexpected upgrade tokens like these. If there is no such guidance, than we can just go back to pretending that doesn't exist
HTTP intermediaries can't really do anything with unrecognized Upgrade tokens in HTTP/1.1. (Not even the useful thing, which would be to convert them to/from for Extended CONNECT.)
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .
Addresses issue NAME
From WGLC Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. URL NAME Looks great! Some small proposed tweaks: Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No preference on which one is used, but should be consistent. 6.2.3.1 Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." 6.2.3.3 Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." tim On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef wrote: >
Automatic use of client-proffered certificates was removed a while back; clients can indicate which certificate (if any) they want the server to consider by sending a frame with the flag set. There was text talking about automatic use of the server-proffered certificates, but there wasn't corresponding text disallowing that behavior for client certificates, simply the absence of permission. This PR forbids considering "available" certificates until the client indicates which certificate to use.
The secondary certificates draft leaves the authentication state of exchanges like the following unclear: In stream 1, the client is unambiguously using certificate A in the request to . Is it also using it for ? If the client believes the answer is no, while the server believes the answer is yes, secondary certificates introduces a . Some examples to consider: HTTP/2 cross-name pooling means one connection may service multiple origins. The client may choose to use a client certificate with some origins but not others. The web platform makes both anonymous and credentialed requests (see CORS). Keeping those straight is critical to avoid CSRF attacks. For now, browsers do not pool them due to various problematic connection-level auth mechanisms in HTTP/1.1, but there is discussion on relaxing this for the vast majority of connections that don't use these. This puts a heavier dependency on protocols getting these kinds of details right. This is especially important to make unambiguous because the original renegotiation-based hack for reactive client auth did rely on ambient authority. Once you renegotiated with a certificate, the unwritten interpretation was that all subsequent requests on this connection pick up the certificate. A server implementation may then be tempted to apply a similar logic to client certificates. The spec needs a MUST-level requirement not to do this, and make it clear that this is a server security vulnerability. Instead, client wishing to approximate the original renegotiation-based hack would send proactive frames on subsequent credentialed requests. This is especially important for HTTP/2, where there is both larger scope of pooling from cross-name bits and where multiplexing means we requests overlap temporally.
and a few others that had gotten out of sync
Section 4.1. Key Binding JWT, says the following: But Section 5.3 does not exist in the referred spec. Instead, it should be Section 4.3
Thanks NAME A couple sections in SD-JWT were consolidated around draft 12 or 13 and other sections were renumbered as a result. We'll fix this reference and check for others that might need updating too.
see including URL
We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Reframe use cases that had previously signed signature values to avoid problems with this approach.
This looks good to me! Summary of the changes: Explicitly flagging that the application / implementer must specify how request-response binding is to be achieved (if desired). Removed all references to request-response binding in the main body. Removed all signatures of signatures from the examples Added guidance that applications SHOULD sign all signed components of a request when generating a signed response. Added guidance that generating signatures of signatures is NOT RECOMMENDED when generating responses. Added guidance that generating signatures of signatures is NOT RECOMMENDED when acting as a proxy between a request / response.
and have pointed out that the current registration requests are rather informal and could be improved using the templates in . All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels). That indicates to me that the draft is well formed, concise, and references the other specifications appropriately that I needed to reference. I find this document useful, and we would implement and utilize in production, and support moving this forward. Two minor additional nits below: One question for the group / authors - is there a preferred set of values for the TBDs in the COSE labels section, or should that just be left as is for now? An additional style question, is it better to restate the COSE headers requested in the IANA requested format, or is it fine to reference as is done in the draft currently? e.g. current draft reads: "IANA is requested to add the two COSE header parameters described in Section 3 to the "COSE Header Parameters" subregistry of the [URL] registry." This could obviously be detailed out. Mike Prorock On Tue, Aug 13, 2024 at 11:43 AM Michael Prorock wrote:
Answering Mike P.’s question about IANA registrations, it is strongly preferred to have the IANA Considerations section follow the registration template and contain the exact values to be placed in the registry (with the Label of course, being TBD). An example of such IANA Considerations text is URL Please update the draft to add this content. Thanks, -- Mike From: Michael Prorock Sent: Friday, August 23, 2024 5:40 AM To: Michael Prorock Cc: Michael Jones ; cose Subject: Re: [COSE] Re: WGLC for draft-ietf-cose-tsa-tst-header-parameter All, I have performed a read through of the doc. A few minor language preferences for clarity have been suggested here: URL Otherwise, I was able to implement and test both modes of operation and get the desired results (with stand in labels).