Port OpenSSL code to use contemporary API

[abbra]

Port Jose code to use contemporary OpenSSL API, allowing to use external engines and algorithms provided by them.

[lumag]

It looks like JOSE already uses EVP API, as you suggested. The major place which can not do that is JWK support. You have to define/specify new JWK types and add functions to convert them to/from EVP_PKEY.

[abbra]

Thanks @lumag. So we would need to extend JWK spec for that, right?

[abbra]

Namely, https://tools.ietf.org/html/rfc7518 needs to be extended to add GOST to JWA registries

[beldmit]

I'm not sure it's so necessary. RFC 7515 (https://tools.ietf.org/html/rfc7515#section-4), 7516 (https://tools.ietf.org/html/rfc7516#section-4.1.7), 7517 (https://tools.ietf.org/html/rfc7517#section-4.6) specifies attributes x5u/x5c so for some cases we can avoid both hardcoding algorithms identifiers and algorithm-specific attributes.

[simo5]

@beldmit amending the "JSON Web Signature and Encryption Algorithms" registry is required to add any algorithm. x509 certs identifier are optional and not even implemented in many Jose libraries, and they do not influence in any way the algorithm selection.

[beldmit]

OK, so it makes sense to start adding new algorithms in JOSE RFCs. But after that we'll have a hardly maintainable case structures that should be converted in pluggable API somewhen.

[sarroutbi]

@beldmit , @simo5 : what are the next steps then? Is it necessary to add a new amend to the corresponding RFC?

[beldmit]

@sarroutbi I currently don't have plans related to Russian GOST and not aware of similar plans for anybody in Russia. I'm afraid tha library uses a lot of functions deprecated in OpenSSL 3.0 though...

[sarroutbi]

Hello @beldmit. Thanks for your quick response.

Can this issue be closed then?

[beldmit]

Unfortunately, no. Did you try compile your library against openssl 3.0 with -Wdeprecated?