Interested in a meaningful contribution?

[ashcherbakov]

We've been working on a technology called DIDComm. It makes heavy use of JWKs, JWEs, and JWSs. It's being done in FOSS in conjunction with the Decentralized Identity Foundation, Trust Over IP Foundation, and Linux Foundation. Eventually the spec that we're trying to implement is going to IETF.

After studying various JS libs for JOSE, we have concluded that JOSE implementation from your lib is closest to what we'd like to start from. But we need some new features:

• ECDH-1PU support (see ECDH-1PU draft)
• JSON serialization for JWS and JWE and multi-recipient support
• AEAD_XCHACHA20_POLY1305 (XC20P) support for content encryption (see Chacha draft)
• X25519 and Ed25519 support for browsers

We could just pull some code out of your excellent library and do our own independent thing, but we're wondering if you'd like a meaningful contribution of the features I listed above.

We'd do the work; we're not trying to find someone else to do the coding for us.

But before we start that contribution, we would like to know if it makes sense for you, and what are the chances that our PRs with all the features listed above will be accepted from the contributed features point of view.

We can probably discuss contribution to backend (node.js) part and browsers part separately. node.js part will be a native code.
But as for 25519 support in the browsers, we are considering to implement it via wasm since Web Crypto API doesn't support 25519. Would you accept wasm-based implementation for browsers?

(Tagging @vimmerru and @dhh1128, who are interested in the answer).

[panva]

Hi @ashcherbakov

This library (in v3.x) makes use exclusively of platform available cryptography abstractions. That is the crypto module in Node.js runtime (backed by OpenSSL) and Web Cryptography API in the browsers (and soon[ish] Deno).

I think given some level of refactoring the additional cipher implementations and algorithm identifiers could be registered as some form of plugins. Would that be something you would be willing to contribute first?

JSON serialization for JWS and JWE and multi-recipient support

JSON General serialization is already implemented for

• JWS signing
• JWS verification
• JWE decryption

The lacking JWE encryption one would be appreciated and welcome PR.

ECDH-1PU

Once this is a stable[ish] IETF WG draft, sure. Until then I would recommend forking.

XC20P

It's worth noting that the underlying draft-irtf-cfrg-xchacha is expired. OpenSSL does not support it and will not support it in the current major, and we know how stalled 3.0 has become. WebCryptoAPI support - not likely due to lack of interest.

Once there's at least one platform natively supporting the underlying cipher and this is a stable[ish] IETF WG draft, sure.

X25519 and Ed25519 support for browsers

Not unless its implementation would be backed by Web Cryptography API. It is currently lacking implementer's interest. I would suggest to reach out to browser vendors to express their interest to support these in https://github.com/w3c/webcrypto

[panva]

I imagine it could live in this codebase but would be distributed as a separate plugin package... it would use the (to be designed/developed) api hooks to register algorithm names, their implementations, and supporting values such as IV and CEK lengths.

[panva]

Just a quick shot at how the plugin thing could work...?

https://gist.github.com/panva/55c7908d4193a854555e26fb83e503d4

Simply register the different algorithms for use with content encryption, or key management, and provide their implementation.

one would npm i jose @jose-plugin/chacha20-poly1305

then in code

import ... from 'jose'
import '@jose-plugin/chacha20-poly1305'

then its off to the races to use C20P as "cek"

[panva]

@ashcherbakov wdyt?

[ashcherbakov]

Thank you for the comments and interest to the contribution.
We are evaluating various options now. We may come back to you and discuss details if we decide to go this way.

[FabioPinheiro]

Hey @ashcherbakov I'm wandering what was the conclusion of the options you were evaluating?
Is the intention still to work on this, and add support to ECDH-1PU and XC20P ?