Thank you Ilari for elaborating! No. I do not think this is a good way to solve the underlying problem, > which is signing data too large to transfer to the signer.
> What I think should be done is adding a mechanism to COSE (and maybe > also JOSE) that hashed the payload before signing. Note that this is > subtly different from what hash envelope does (uses a hash to represent > some content). Large content is only *one* of the underlying problems we want to solve. Perhaps we've emphasized that one too much in our presentations and the introduction section. The other problem is signature algorithms that require more than the traditional two inputs of key and message. One example is ML-DSA and SLH-DSA, which both have an additional domain separation parameter `ctx`. This needs to be set during signing to the value the verifier expects, so we need somewhere to put it if we're building a signing API using COSE. Which is precisely what the WebAuthn raw signing extension <https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-raw-signing-extension> [1] would be, and it's the motivating use case for this draft: it uses COSE algorithm identifiers and the COSE_Sign_Args structure to communicate these signing inputs from the WebAuthn-invoking web application to the authenticator that holds signing private keys. A stronger example, though, is signing with a key derived using ARKG <https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/> [2], in which case two additional parameters `kh` and `ctx` are needed in order to derive the private signing key. Unlike `ctx` in ML-DSA and SLH-DSA (and ARKG), the `kh` parameter here cannot be worked around by for example declaring that it's always empty, because it is core to how the cryptographic algorithm works. A prehash mechanism in COSE could solve the large content issue, but it would not help at all with signature algorithms that need additional parameters, such as ARKG. The approach used by this draft seems mostly limited to ECDSA, as: Indeed the pre-hashing aspect relates mostly to ECDSA, though externalMu-ML-DSA could also be added in the future if desired. But in practice we're more interested in this for enabling ARKG and other multi-input algorithms (including a couple of proposed BBS device binding constructions that also have a `ctx` parameter separate from the message), not just prehash ECDSA. 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? The draft says that the digest is "usually" transmitted in the data > to be signed argument. What does that mean? Fair point, we should just say that the digest *is* the "data to be signed" argument for these algorithms. 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. 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. Adding COSE_Sign_Args parameters for "data to be signed" and `kid` would duplicate the JS-level `tbs` and `kh` parameters in the WebAuthn extension, introducing the possibility of confusing them or setting both duplicates to mismatched values. But if the COSE WG believes it is better for COSE to have these parameters inlined in COSE_Sign_Args, I'm okay with doing that. And why would verifier know anything about *-split algorithms other > than to reject the whole message as malformed? Indeed they shouldn't (see Section 4.3 <https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-07.html#name-incorrect-use-of-split-sign>). I would be fine with making it a required hard error as you suggest. - Replace COSE_Sign_args with something like three-element array: I would prefer not, since the `hash` parameter is not always needed (like in the WebAuthn extension where we have a dedicated JS-level parameter for it), and not always a hash either (for example, COSE_Sign_Args could be used to request signing with an ARKG-derived ESP256 key *without* prehashing, or to sign with ML-DSA with a nonempty `ctx`). `hash: bstr / null` would be just a worse version of an optional map entry, and saying "set `hash` to empty bstr if unused" would be the worst kind of evil special case that would inevitably lead to security bugs. I think keeping COSE_Sign_Args a map is a better design. Thank you again for reviewing! Do the above clarifications and proposed adjustments address your concerns? [1]: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-raw-signing-extension [2]: https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/ Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den tis 24 mars 2026 kl 17:02 skrev Ilari Liusvaara < [email protected]>: > On Mon, Mar 23, 2026 at 10:43:23AM +0100, Ivaylo Petrov wrote: > > Dear all, > > > > This note starts a three-week call for adoption for *Split Signing > > Algorithms for COSE* > > > https://datatracker.ietf.org/doc/draft-lundberg-cose-two-party-signing-algs/ > . > > Please indicate here *by Monday, April 13, 2026* whether you are in favor > > of adoption or not, and the reasons for your position. > > No. I do not think this is a good way to solve the underlying problem, > which is signing data too large to transfer to the signer. > > What I think should be done is adding a mechanism to COSE (and maybe > also JOSE) that hashed the payload before signing. Note that this is > subtly different from what hash envelope does (uses a hash to represent > some content). > > > Then to the draft itself: > > The approach used by this draft seems mostly limited to ECDSA, as: > > - Ed25519ph and Ed448ph are very poorly supported. > - Hash-(ML|FN|SLH)-DSA is an operational disater. And likely > poorly supported too. > - For ML-DSA, there is signmu, but it is unclear if it would be > used (LAMPS WG did go with ML-DSA signmu to support signing > large amounts of data with ML-DSA). > > > 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. > > The draft says that the digest is "usually" transmitted in the data > to be signed argument. What does that mean? > > Or that *-split algorithms can appear in "COSE structures". What COSE > structures? > > Then COSE_Sign_args is not enough for signature request (it is missing > the digest), and there is no structure that contains it. > > And why would verifier know anything about *-split algorithms other > than to reject the whole message as malformed? > > > Suggest something along following lines: > > - *-split algorithms MUST NOT appear in COSE signatures nor keys. > Such algorithms MUST either be treated as unknown, or the whole > message rejected as malformed. > > - Replace COSE_Sign_args with something like three-element array: > > * alg: int/tstr > * hash: bstr > * extra_args: { label => value } > > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
