feedback to v3.public PASETO / k3.secret PASERK

[panva]

I'm attempting to do a universal javascript (Node, Electron, CloudFlare Workers, Browsers, Deno) module for all PASETO versions and purposes with local, public and secret PASERK as key inputs.

Turns out there is a lightweight JS implementation for (x)chacha20(poly1205) and ed25519 that could support everything that's not in Node's crypto module or Web Cryptography API. That's great because bundling libsodium's JS implementation is a no go.

But in the surprising turn of events, v3.public is a problem to support in browsers because the lack of support for raw (or SPKI) compressed public EC keys as well as private-only PKCS8 private EC keys.

WebKit (ergo all browsers on iOS and macOS Safari) as well as regular desktop Firefox don't support this. This wouldn't be that big of an issue for the verify operation and public key inputs as calculating y from x and the sign can be done in a few lines of code using BigInt math.

The same cannot be said about calculation of the x and y from d for the purposes of adding the exclusive ownership to preAuth when it comes to signing v3.public. tokens.

Given it took firefox 8 years to add PKCS8 EC key import support to their webcrypto I doubt this will be solved - i've opened two issues in bugzilla regardless ¹² and i'll try to do the same for webkit³⁴, with similar doubts about it being ever resolved.

If k3.secret followed similar format as k2 (and k4) does - that is, private key would be d || compress(x) - this wouldn't be that big of an issue. It would limit the browser versions supporting this to ones with BigInt support (ES2020) but it's at least something.

Leaving this here for your consideration wrt. changing PASERK (as it is rather new) or simply for your consideration wrt. to future versions utilizing EC keys.

Footnotes

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1743582 ↩

2. https://bugzilla.mozilla.org/show_bug.cgi?id=1743583 ↩

3. https://bugs.webkit.org/show_bug.cgi?id=233704 ↩

4. https://bugs.webkit.org/show_bug.cgi?id=233705 ↩