Support for raw cryptographic signatures

[cybercent]

Issue To Be Solved

Allow raw cryptographic signatures using Webauthn.

Suggest A Solution

Allow user to request raw signature of the RP challenge from the hardware key.

Add a new extension: rawSignature:

var options = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([8,18,33 /* 29 more random bytes generated by the server */]),
  timeout: 120000,  // 2 minutes
  allowCredentials: [acceptableCredential1, acceptableCredential2],
  extensions: { 'rawSignature': true }
};

The assertion object returned from the get() call:

PublicKeyCredential {
    id: 'ADSUllKQmbqdGtpu4sjseh4cg2TxSvrbcHDTBsv4NSSX9...',
    rawId: ArrayBuffer(59),
    rawSignature: ArrayBuffer(70) // the raw signature of the challenge
    ..
}

Context

With the rise of web applications that use blockchains as a backend, instead of a centralized database,
users are required to authenticate to these websites using a private key.

The private key is used to create a raw signature that is passed along by the website to the underlying blockchain for authentication.

There is no easy way for a user to use a private key in a browser, so websites require users to store their private keys in the browser cache, which is highly insecure and leads to data loss.
Example:

Website: https://www.sign-art.app

[ghost]

Adding my support for this.

I just posted a similar proposal in WebCrypto issues just FYI (see here).

[dwaite]

This appears to be a duplicate of #1595 and #1608.

A raw signature provides integrity but does not provide the guarantees necessary for authentication. The purpose of the public key credentials is exclusively about providing information about the associated authentication event handled by the hardware. It is highly unlikely the same key pair would be allowed to be used to sign arbitrary messages, as this would allow interception of requests and forgery of authentication responses.

Putting this aside, authenticator implementations today would also not support this extension, leaving compatibility to a subset of future platform versions and hardware - possibly subsetted further by the tendency of such distributed systems to use more exotic cryptography primitives.

In addition, there are no guarantees about the permanence of Web Authentication public key credentials by authenticators. A platform authenticator may theoretically be backed by local storage, with the same removal policy as a non-exportable WebCrypto key in javascript.

[selfissued]

Per a decision on the 19-May-21 working group call, we're closing this for the reasons cited by @dwaite above, just as we closed #1595 and #1608.

[earonesty]

signatures are not only about authentication, and failing to provide them means people will continue to roll their own insecure solutions. since the purpose of this standard is to prevent that very thing, this decision seems quite shortsighted.

[dwaite]

@earonesty This group is related to defining messages and APIs to support a specific protocol for web authentication, not generalized cryptography.

The WebCrypto work (in particular, proposals against w3c/webcrypto#263 mentioned above) is more appropriate for generalized cryptographic operations.