search

lestrrat-go / jwx

Implementation of various JWx (Javascript Object Signing and Encryption/JOSE) technologies
MIT License
1.94k stars 160 forks source link

Support the new fully-specified JOSE algorithms #1110

Open decentralgabe opened 6 months ago

decentralgabe commented 6 months ago

Abstract Support for the updated fully specified JOSE algorithms as defined by this RFC.

Describe the proposed solution/change

At the least this code needs to be updated from:

    RegisterVerifier(jwa.EdDSA, VerifierFactoryFn(func() (Verifier, error) {
        return newEdDSAVerifier(), nil
    }))

to

    for _, alg := range []jwa.SignatureAlgorithm{jwa.EdDSA, jwa.Ed25519} {
        RegisterVerifier(alg, func(alg jwa.SignatureAlgorithm) VerifierFactory {
            return VerifierFactoryFn(func() (Verifier, error) {
                return newEdDSAVerifier(alg), nil
            })
        }(alg))
    }

It does not look like Ed448 is currently supported so that can be ignored. newEdDSAVerifier may be renamed to newEd25519Verifier.

Similar changes could be made for ESP256 (ECDSA using P-256 and SHA-256), ESP384 (ECDSA using P-384 and SHA-384), and ESP512 (ECDSA using P-521 and SHA-512) for completeness.

Analysis This update provides the benefits of aligning with the latest standards, and avoids the confusion with so-called "polymorphic" algorithm identifiers, where information beyond the alg identifier is necessary to determine the cryptographic operation(s) to be performed. These new unambiguous identifiers provide clarity and implementation simplification.

Additional context The only possible concern would be adopting the draft before it has an official RFC number. I understand if the maintainer(s) wish to wait until the Internet Draft is further along.

Waiting is tough for implementers, however, since we will get an unsupported signature alg error message when trying to use the new types.

lestrrat commented 6 months ago

The only possible concern would be adopting the draft before it has an official RFC number

Right, I'm reluctant to implement such a thing without a compelling use case and rationale to support its expedited inclusion.

Alternatively I suppose there could be a golang.org/x/ type of mechanism to add its support on demand somehow, on top of some core changes for such flexibility. This way, going forward it might be easier for new algorithms to be incorporated. (unconfirmed, but you might need the dynamic JWK key type addition only available on v3?)

Either way, I'm not against the idea per se. But if you want this done sooner than later, I think it would be best if you tried coming up with a PR (hint: I'd suggest starting with tests). This will not be high priority on my list of things to do because of the fact that the RFC is still in draft stage. If you're not in a hurry, I will probably come around to implementing it, just not now and I won't be making immediate promises as to when :)

decentralgabe commented 6 months ago

I have a workaround for now so I am fine. Not much urgency, but if that changes I will be sure to open up a PR against the v3 branch. Thanks for the quick response!