Invalid algorithm specified and enhanced RSA Provider about jose-jwt

[rmbrunet]

Hello @dvsekhvalnov,

Thanks for your answer. Yes, I was comparing the results from your library and Microsoft's implementation of JwtSecurityTokenHandler.

I tested re-importing the key and, as you said, it works fine. Then there seems to be two ways of getting it right;

a) Re-importing the parameters.

b) Specifying the "Microsoft Enhanced RSA and AES Cryptographic Provider" provider when creating the certificate. For example, I used the following line to create a certificate that then used to sign a JWT without re-importing the private key:

makecert -n "CN=JOSE_TEST" -ic "JOSE_ROOT.cer" -iv "JOSE_ROOT.pvk" -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 -a sha256 -sky exchange -pe -sr LocalMachine -ss My

I have a another question. When signing a JWT we normally use a private key belonging to the issuer of the JWT and then the consumer of the JWT uses the corresponding public key to validate it. With encryption it seems that we need to use just the public key of the consumer and the certificate of the issuer plays no role. This seems strange to me (probably I am missing something) as there is no way for the consumer to validate the origin of the token. Is there a way to use different keys for encrypting and signing? What I am missing here?

Thanks again.

Roberto

[dvsekhvalnov]

Hi @rmbrunet , are you talking about https://github.com/dvsekhvalnov/jose-jwt#rs--and-ps--family ?

If you using keys via RSACryptoServiceProvider you need to re-import key to get SHA-2 crypto provider (by default it is always SHA-1).

There is a link in doc to http://clrsecurity.codeplex.com/discussions/243156 which provides details. Also you can check https://github.com/dvsekhvalnov/jose-jwt/blob/master/UnitTests/TestSuite.cs#L2346

As far as i remember it was always like this, if you know better workaround let me know or submit a patch set :)

If i didn't get your question correctly please submit minimal unit test so i can try.

Thank you.

[rmbrunet]

I think I found the answer (in RFC 7519) to my own question: Nested JWT. Here is a gist with a test in linqpad: https://gist.github.com/rmbrunet/b0036422202d0919698a6a872c5f7671

[dvsekhvalnov]

@rmbrunet , yes you can use nested token (sign then encrypt) or also depending on your use-case you can try different keys for different parties and use key to identify origin. Check out 2-phase validation section for idea: https://github.com/dvsekhvalnov/jose-jwt#two-phase-validation

[rmbrunet]

Thanks! Great work!