-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RSA JWK parsing #523
Comments
There are some good points here. I think we should extend the test suite for the JWKs for "incomplete" parameters. Like how does OpenSSL 2 and 3 differ in behaviour. I would not yet be confident using the DER approach as the primary way to generate keys. Are you planning doing something about this or should we take one challenge at a time and try to finish the JWK importing that is WIP? |
I was trying to do something briefly today, but decided that this will probably take more time than I can spend right now, so I am focussing on existing challenges and leaving this here as a reminder or for someone else to pick up in the meantime :) |
I will take a stab on trying to expand the test suite a little. Lets see if there are some differences in behaviours with the implementations. |
@anakinj I just wanted to say thank you for keeping up the work here ❤️ . I get emailed whenever there is progress on the Ruby OpenSSL PR :) |
This came up while reworking the JWK stuff for #520
The function
create_rsa_key
for OpenSSL version 3 looks like this:ruby-jwt/lib/jwt/jwk/rsa.rb
Lines 93 to 106 in b4f9f1d
I like the approach of converting a JWK to DER, then feeding it into OpenSSL, since this is unlikely to change (in fact, wouldn't this work for other versions of OpenSSL, making all the "legacy" implementations unnecessary?)
Anyways, the code has a few problems.
Firstly, any subset of parameters specified in
ASN1_SEQUENCE
could be present in an illformed JWK, and the resulting DER can then probably not be parsed by any SSL library.But secondly, there is an important missmatch between RFC 7518, Section 6.3.2
and RFC 3447, Appendix A.1.2, which only permits keys with all parameters present.
This implies that valid JWKs containing exactly the
kty
specific keyskty
,n
,e
, andd
, are not guaranteed to be parseable this way.One could try to calculate the missing values, but especially the step of finding
p
andq
is not trivial at all...The text was updated successfully, but these errors were encountered: