Hi Ilari, Den fre 21 nov. 2025 kl 15:16 skrev Ilari Liusvaara < [email protected]>:
> This gives these algorithms very magical properties, enough that the > algorithms need to be considered reserved from COSE_Sign perspecive > (similarly to how JOSE has some algorithms reserved for WebCrypto that > are meaningless in JOSE itself). This implies that verifiers MUST NOT > support these algorithms. > Agreed. These identifiers should not appear as the `alg` of a COSE_Sign structure. We declare this in section 2 of the draft <https://www.ietf.org/archive/id/draft-lundberg-cose-two-party-signing-algs-03.html#name-split-signing-algorithms> too: The algorithm identifiers defined in this specification MAY appear in COSE > structures used internally between the digester and the signer in a split > signing protocol, but SHOULD NOT appear in COSE structures consumed by > signature verifiers. COSE structures consumed by signature verifiers SHOULD > instead use the corresponding conventional algorithm identifiers for the > verification algorithm. I do agree that this is a bit of a "design smell": that we're defining COSE algorithm identifiers that are not valid for all uses of COSE algorithm identifiers. But on the other hand, we already have that: it is nonsensical to set `alg: -27 (ECDH-SS + HKDF-256)` in a COSE_Sign header, or `alg: -9 (ESP256)` in a COSE_Encrypt header, for example. I don't think it's fundamentally different that `alg: [ESP256-split]` is also nonsensical in a COSE_Sign header. Hm, though I guess it is a bit different in that `alg: [ESP256-split]` is nonsensical in *both* COSE_Sign and COSE_Encrypt. But then the draft also introduces COSE_Sign_Args, where split identifiers *are* appropriate (not for ESP256 specifically since it doesn't need extra parameters, but a COSE_Sign_Args could be used to convey a HashML-DSA `ctx` argument tagged with a `alg: HashML-DSA-split`). If you know some other registry more appropriate for this than the COSE Algorithms registry, I would definitely consider targeting that instead. > ESP512-split should presumably be ESP521-split, as any parametric hash > is irrelevant in this kind of application. Hm, good point. I would prefer to model these identifiers as special cases of fully-specified concrete algorithms, which is why we've named it ESP512-split rather than 521... but you're right that the hash algorithm is fully irrelevant to the *signer* and there's no way the *signer* could tell a difference between a SHA-512 and a SHA3-512 digest, for example (and so a hypothetical ESP521-SHA3-512-split identifier would be entirely redundant). Hrm, I'll need to have a good think about that. > And HashEdDSA is very poorly supported. > Yeah, it's included in the draft mostly as an example, not for any concrete use case (same with HashML-DSA in draft version -01). I still think that for archiving goals of this (signing data too large > to transfer to signer), it would be better to have COSE_sign-level pre- > hash extension. > Heh, the problem there is that our motivating use case - this WebAuthn signing extension <https://yubicolabs.github.io/webauthn-sign-extension/4/#sctn-sign-extension> - doesn't actually use COSE_Sign, rather it just emits standalone signatures meant for integrating into any cryptographic protocol. So the signature *could* end up in a COSE_Sign structure, but more likely it'll be a Key Binding JWT signature or JWS proof in an OpenID4VP presentation. But the WebAuthn extension is unopinionated about what the signature will be used for - you could in principle use it to sign software releases, Git commits, emails, or whatever, and some of those things could need large payloads. Concretely, what we want is that new algorithms can be added to the above WebAuthn extension without needing to publish a new version of the extension spec. So that's why we'd like to just reference an external registry for the algorithm definitions, and since the top level of WebAuthn already uses the COSE Algorithms registry for that purpose (but for negotiating the algorithm for authentication keys, rather than arbitrary data signing keys), it would be natural if we could use the COSE Algorithms registry in this extension too. Cheers, Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> > > > > -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]
