Hi COSE and JOSE WGs, I'm currently working on an extension to WebAuthn <https://github.com/w3c/webauthn/pull/2078> [1] for signing arbitrary data. The current draft uses `COSEAlgorithmIdentifier`s to negotiate what signature algorithm to use, and the same `COSEAlgorithmIdentifier` is also emitted in generated `COSE_Key`s to communicate the signature algorithm to the signature verifier.
However, for several reasons we want the caller of this signing API to pre-hash the data to be signed before passing it into the extension. The question then is: how should we communicate, _generically_, which steps of the signing algorithm are performed in advance by the caller and which are performed by the WebAuthn authenticator? In some cases the division is fairly obvious. For example, ESP256 <https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-05.html> [2] hashes the input only once, so it's obvious that the caller performs the hash and the WebAuthn authenticator interprets the input as a raw P-256 scalar. Ed25519ph <https://www.rfc-editor.org/rfc/rfc8032#section-5.1> [3] hashes the input once without the key and then hashes the digest again with the key, so clearly only the first hash can be performed by the caller (and Ed25519 is impossible to implement in this way). But for other algorithms it's less obvious - for example, for HashML-DSA <https://csrc.nist.gov/pubs/fips/204/final> [4], the caller could compute only PH_M and submit PH_M and the hash OID into the signing API, or the caller could compute M' and submit only M' into the signing API (I think the former is clearly preferable, but the point is that both options exist). Similarly for RSASSA-PSS <https://www.rfc-editor.org/rfc/rfc8017#section-9.1.1> [5], should the caller submit `mHash` or `EM`? This "division of labour" between the caller and the WebAuthn authenticator needs to be defined somehow. So, that is my question: how should we define and communicate this division of labour? - Is there some way we can do it generically, without defining any new algorithm identifiers? - Should we define new algorithm identifiers for "pre-hashing for two-party signing" in some existing registry? - Should we define a new registry of algorithm identifiers? - Should we define some new "signing request" data structure, which can describe whether and how data is pre-hashed (perhaps similar to COSE Hash Envelopes <https://cose-wg.github.io/draft-ietf-cose-hash-envelope/draft-ietf-cose-hash-envelope.html#name-hash-envelope-cddl> [6]?)? - Other options? Any insight and guidance on this would be much appreciated. Of course I'm also happy to elaborate on anything that is unclear. Thank you. [1]: https://github.com/w3c/webauthn/pull/2078 [2]: https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-05.html [3]: https://www.rfc-editor.org/rfc/rfc8032#section-5.1 [4]: https://csrc.nist.gov/pubs/fips/204/final [5]: https://www.rfc-editor.org/rfc/rfc8017#section-9.1.1 [6]: https://cose-wg.github.io/draft-ietf-cose-hash-envelope/draft-ietf-cose-hash-envelope.html#name-hash-envelope-cddl Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
