W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2021

Re: [webauthn] PROPOSAL: Add support for general (hardware backed) cryptographic signatures and key exchange (#1608)

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Wed, 05 May 2021 00:00:36 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-832330308-1620172835-sysbot+gh@w3.org>
I think to keep this really focused there should be a clear distinction between if this is for:

* Data Verification - The client hashes the data, and then the hash is signed in an extension to assert that the extra data is as it was known on the client.
* Signature Creation - An extension exists that allows arbitrary data to be signed by this private key (or an associated derived key). It's worth noting due to the use of the key directly, this has implications based on which key types (ecdsa, rsa etc) are used and the ability of the RP to consume these signatures. 

Both of these types have their use and have both been requested in the former thread. We have had one request for the ability to provide a verification of data from a camera (the first suggestion), and another about using the keys for signing arbitrary data for other cryptographic applications (the second). 

As previously mentioned, there are also potential security risks to the second due to the use of the key in arbitrary ways.

Verification is much easier to provide as an extension, where the client (browser) can simple pre-hash the data, then the hash is signed through the extensions. My initial suggestion is that data verification be the first step since it is the simpler of the two to provide, and has the least risk with regard to the usage of the key. There is much more thought needed for the second IMO. 

-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1608#issuecomment-832330308 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 May 2021 00:00:39 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:43 UTC