On Mon, Jul 20, 2026 at 01:08:05PM +0200, Emil Lundberg wrote: > Thanks Ilari, and sorry for the late reply. I don't mean to ignore these > concerns, I just lost track of this thread in between other work. > > By "reserved", I mean likes of A192CTR in JOSE. Those are used by > > WebCrypto, not JOSE. > > > > Sorry, I still don't understand what you mean here. > The "Name" values like ESP256-split are indeed not registered, they're just > used as more human-readable aliases of the COSE numbers. Is something like > that what you mean?
I mean defining the algorithm in WebAuthn and then registering it to COSE algorithm registry, even if is not useful for COSE. That should be possible. RFC8126 says this about Specification Required: "[...]and the values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible." (Then there are ranges that are Expert Review, which is looser than that.) > > I would expect stuff like this to be passed as a parameter of JSON > > object type. And then the API code marshalls it into whatever form is > > required by the token. > > > > Yes, but that would require the JSON/JS API to define bindings for every > individual signing algorithm, and would require browsers to implement each > of them individually. We would have to update the extension specification > and all browser implementations of it every time we want to add a new > algorithm. Okay, so fields vary in complicated ways. > > If direct access to underlying CBOR passed to the token is needed (e.g., > > because the fields vary in complicated ways), I would expect the CBOR > > structure to be defined by WebAuthn. That structure just seems useless > > for COSE. > > It needs to be defined in a registry external from WebAuthn so that you can > add algorithms without a whole new WebAuthn release. We figured COSE was > the most natural place for it, and we've tried to design COSE_Sign_Args so > that it can also be useful outside this WebAuthn extension, even if it's > not directly necessary for producing or consuming other COSE structures. One potential issue is specification for the new algorithm. RFC is much too heavyweight for that. And while everybody accepts specifications from other SDOs, not all accept Internet Drafts (TLS definitely does, but COSE/JOSE might not). This is not affected by who publishes spec for COSE_Sign_Args. And COSE_Sign_Args does not seem useful outside WebAuthn, as it is not a useful message by itself, nor part of defined usful message (e.g., command from digester to signer to sign some stuff). > > Now, that API uses COSE algorithm identifiers to identify algorithms, > > but those algorithms are not of any supported type in COSE. This to me > > seems exactly analogous to the WebCrypto algorithms in the JOSE > > registry. > > > > Sorry, I don't follow what you mean by "those algorithms are not of any > supported type in COSE". Do you mean that not every COSE algorithm > identifier is valid for use in WebAuthn? Not every COSE algorithm identifier is valid for use in COSE. This is similar to not every JOSE algorithm identifier being valid in JOSE. > If so, then isn't that already the case even internally in COSE? It would > be nonsensical to set `alg: -34 (ECDH-SS + A256KW)` in a COSE_Sign1 header, > just as it would be nonsensical to request -34 as a credential key > algorithm in WebAuthn. Yes, it is the case already. E.g., alg 34 is nonsensical in any message. And as you note, even if algoirithm makes sense to put somewhere in COSE does not mean it makes any sense everywhere. > I agree that it's a bit of a "design smell" that the "*-split" algs are an > additional subset of COSE signature algorithm identifiers that aren't valid > for use in all places that take COSE signature algorithm identifiers. I > don't think that's a big enough problem to warrant a separate new registry > for them, though, since it's already the case that not all algorithm > identifiers are valid in all places that take algorithm identifiers. No need for a new registry, since algorithm identifiers can be valid for only external purposes. > > So for any needed algorithm identifiers, I would expect WebAuthn to > > request allocation (the allocations are subject to Expert Review). > > Yes, and that's precisely what we're doing, no? :) I would expect COSE to only come in for either: - New algorithm for existing COSE message (which is the case for the prehashed EdDSA algorithms). - New complete COSE message. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
