Add "sign" extension

[emlun]

This extension allows for signing arbitrary data using a key associated with but different from a WebAuthn credential key pair. Motivating use cases of this include:

• Enabling use of attested, hardware-bound signing keys for applications such as digital identity wallets and similar verifiable credentials (client-RP layer)
• Using FIDO security keys (possibly unattended) for general-purpose digital signatures, with seamless interoperability with existing cryptographic protocols (client-authenticator layer)

By "signing arbitrary data" we mean a distinction from a WebAuthn assertion signature, which signs not over the challenge parameter provided by the RP or client, but over the concatenation of authenticator data and a hash of a JSON object embedding that challenge. In contrast, signatures returned from this extension are made over the given input unaltered. The signing key pair is distinct from its parent WebAuthn credential key pair, so this arbitrary input cannot be used to bypass the domain binding restrictions for WebAuthn credentials.

This addresses some of the same use cases as #1895 would, but goes a step further to enable truly hardware-bound keys. As discussed at some length in #1945, WebCrypto keys are never truly unextractable unless the client enforces domain separation before converting PRF outputs to CryptoKeys. Even then, those keys are not hardware-bound as they are exposed to the client process. This PR is what was meant by "pursuing [...] other ways" in https://github.com/w3c/webauthn/pull/1945#issuecomment-1813211351.

This extension does not cover encryption use cases as #1895 and #1945 would, but instead we intend to also propose an architecturally analogous kem (key encapsulation mechanism) extension to address those use cases.

---

Preview | Diff