Skip to content
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

Open
bellebaum opened this issue Oct 11, 2022 · 4 comments
Open

RSA JWK parsing #523

bellebaum opened this issue Oct 11, 2022 · 4 comments
Assignees

Comments

@bellebaum
Copy link
Contributor

This came up while reworking the JWK stuff for #520

The function create_rsa_key for OpenSSL version 3 looks like this:

ASN1_SEQUENCE = %i[n e d p q dp dq qi].freeze
def create_rsa_key(rsa_parameters)
sequence = ASN1_SEQUENCE.each_with_object([]) do |key, arr|
next if rsa_parameters[key].nil?
arr << OpenSSL::ASN1::Integer.new(rsa_parameters[key])
end
if sequence.size > 2 # For a private key
sequence.unshift(OpenSSL::ASN1::Integer.new(0))
end
OpenSSL::PKey::RSA.new(OpenSSL::ASN1::Sequence(sequence).to_der)
end

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

The parameter "d" is REQUIRED for RSA private keys. The others enable optimizations and SHOULD be included by producers of JWKs representing RSA private keys. If the producer includes any of the other private key parameters, then all of the others MUST be present, with the exception of "oth", which MUST only be present when more than two prime factors were used.

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 keys kty, n, e, and d, are not guaranteed to be parseable this way.

One could try to calculate the missing values, but especially the step of finding p and q is not trivial at all...

@anakinj
Copy link
Member

anakinj commented Oct 11, 2022

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?

@bellebaum
Copy link
Contributor Author

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 :)

@anakinj
Copy link
Member

anakinj commented Oct 11, 2022

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.

@bellebaum
Copy link
Contributor Author

@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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants