On Wed, Mar 25, 2026 at 05:56:21PM +0100, Emil Lundberg wrote: > Then there are issues with the way *-split algorithms are specified. > > These codepoints are not reserved, but are not interoperable nor even > > usefully constrain the implementation. > > > I don't understand what you mean here. I notice now that Section 2 > <https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-07.html#name-split-signing-algorithms> > lists > the COSE values as TBD while Section 6.1 > <https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-07.html#name-cose-algorithms-registratio> > does > list explicit requested assignments for some of the algorithms. Are the > TBDs what you mean by "codepoints are not reserved"? What do you mean is > not interoperable, and what constraints are missing?
By "reserved", I mean likes of A192CTR in JOSE. Those are used by WebCrypto, not JOSE. > Then COSE_Sign_args is not enough for signature request (it is missing > > the digest), and there is no structure that contains it. > > Indeed, that is by design. We assume that signing APIs already have a > dedicated "data to be signed" parameter, and COSE_Sign_Args would be used > for algorithm-specific *additional arguments*. This way new algorithms can > add additional parameters without having to change the signing API itself, > so for example the WebAuthn raw signing extension [1] does not need to > define new WebIDL to support ARKG algorithms. Oh, this is for Javascript API, not for protocol between digester and signer? CBOR (that is not crypto blobs) in such context seems rather cursed to me. 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. 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. 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. So for any needed algorithm identifiers, I would expect WebAuthn to request allocation (the allocations are subject to Expert Review). So if one removes from this draft all the stuff that I think should be done by WebAuthn, that only leaves Ed25519ph and Ed448ph. > I'm not really opposed to adding an optional "data to be signed" parameter > into COSE_Sign_Args, and I've considered adding a `kid (2)` parameter > analogous to COSE_Key too (indicating the key to sign with). They're not > needed in the WebAuthn raw signing extension (the motivating use case) > because we have dedicated JS-level parameters for them, which is why we so > far haven't defined them in COSE_Sign_Args. In that extension we'd like to > keep COSE_Sign_Args completely optional for algorithms that don't need it, > because then calling applications don't need to produce or parse CBOR if > they're only using algorithms that don't need additional parameters. Note that to eliminate need for CBOR in the no-additional-parameters case, one would need to move the algorithm identifier away from the parameters. As long as algorithm numbers are kept below four quadrillion or so, representing the COSE algorithm numbers in JSON should not be an issue. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
