I glanced over it a bit, and it seems like an implementation -only detail that doesn't need external dependencies.

https://auth0.com/docs/get-started/applications/signing-algorithms

Unlike RS256, the same JWT header and payload will generate a different signature each time.

If that's true (I didn't look further), then I encourage starting a patch.

I'm unsure if the current Signer interface is compatible with this design though.

I confirm that the current interfaces are enough to get it working without external deps.

The good news end here though: no PHP tool exist to help you with the low-level implementation, so the calculations have to be done hardcoded "by hand".

@Spomky has already did it nicely in his https://github.com/web-token/jwt-framework library:

1. Implementation: src/SignatureAlgorithm/RSA/Util/RSA.php
2. Test with RFC link and dataset: tests/SignatureAlgorithm/RSA/RSAPSSSignatureTest.php

Hi @Slamdunk,

Note that without GMP or BCMath, it will be very slow to compute or verify the signatures.

@Spomky make it work, make it fast in a second step :-)

@FractalizeR would you like to send a PR implementing it?

I was looking at this issue, investigating options, and I wouldn't mind some feedback.

So PS256 effectively is RS256 with a different padding scheme. However, PHP isn't currently supporting it, despite the openssl library possibly offering support (I suppose, because of https://bugs.php.net/bug.php?id=80495 which sounds like the PHP openssl extension would just be missing some parameters that can be passed).

So whatever implementation would make it happen has to do a userland implementation, and as has been stated, the algorithm for the padding (PS256 https://datatracker.ietf.org/doc/html/rfc7518#section-3.5 referencing https://datatracker.ietf.org/doc/html/rfc3447#section-8.1) requires treating a bytestring as a big integer and vice versa for the important algorithm steps.

There are implementations that do this work already. Simply doing BigInteger math is done by "brick/math", but if pulling in external packages, one might also opt for "phpseclib/phpseclib", which offers the entire hashing implementation ready-to-go. Both would cover utilizing extensions like GMP or BCMATH and fallback to a native implementation - no need to reinvent the wheel here.

However, even though PhpSecLib is actively maintained, version 2 allows PHP >=5.3.3, and version 3 (which has dependencies) asks for PHP >=5.6.1 - feels a bit awkward. At the same time, nobody questions the age of openssl_sign(). :)

So what would you be willing to do here? Add PS256 to this library at the cost of dealing with another dependency?

Hmmm, I see no reaction from PHP core developers on the bug (nor any mention of it on the indexed entries of https://externals.io/)...

Although it's a niche need, having that ability at the language level might be interesting.
@Girgias would you have thoughts and/or tips on how to approach that?

Bringing that to userland is also okay (even with phpseclib)...
Sure, it comes at the expense of adding dependencies/extensions.
Having big integer math can also facilitate the processing of JWKs, so we might not have a way out of it in the end.

For the OpenSSL thing, open an issue on php-src. I don't really know anything about OpenSSL nor do I maintain that extension, soooo there might be a good reason for no support, or it is just an oversight.