Subject: [jose] RSA-OAEP-256 Example

From: Brian Campbell <[email-masked]>
Date: Mon, 5 May 2014 20:40:00 -0700

The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key
encryption but, AFAIK, there are no examples using it. I recently added
support for it to https://bitbucket.org/b_c/jose4j and am looking to get
some kind of confirmation that I've done it correctly (other than self
interop). With that in mind, here is a JWE using RSA-OAEP-256 which I've
produced and I'm hopeful that someone on this WG list will be able to
decrypt. The RSA key that was used (in JWK format with both public and
private parts) is below the JWE.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.Oyeg4hbq2HjtHOcXduK9UhhIXervPzOTLAqKphCyeK55cFgKtF32DhD26sfnG6h9az3Ogrn4QwYJeZkjJK36teyjl9oKIW_9ItP8cYhOriDOOZFho53Bsttqj8pc0UPrMJ448yQsgkgyqmfWZQs3u_qCaSLXpegE3o-YJ520-Xu_ElS5pNy_vfSME1CeP5unPQPf06Xc6iMVWx9-K_7lxC7acYI_fSSUwuFw-vxrVJMRKf0NDikdmcoI5WW7h5gLXSu4EZvW8xHxA_QoEFnSeYgg8NQNOGLf_PaBddAdn8ck_mhtJdgfc0W251nTviMAwPAjsG0FMnPox7GdtzTdmA.3DJSCmGDd9WI-DI3sBRm8Q.ncFI9vUEdKkuhPR0h3nOJP5dBgKrcS5f9Q7Z58AZTTdTV53FlzJIHwdme-1xipwDifTOL8yi7beuEEiXg_CSzw.UmNlvrfeCGnhWT9qyuUSSA

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 6 May 2014 09:34:29 +0000

Hi Brian,

I will give a try and let you know

regards

antonio

On May 6, 2014, at 5:40 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg for key encryption but, AFAIK, there are no examples using it. I recently added support for it to https://bitbucket.org/b_c/jose4j and am looking to get some kind of confirmation that I've done it correctly (other than self interop). With that in mind, here is a JWE using RSA-OAEP-256 which I've produced and I'm hopeful that someone on this WG list will be able to decrypt. The RSA key that was used (in JWK format with both public and private parts) is below the JWE.

{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 6 May 2014 13:25:12 +0000

Well, as of this moment, they're on DOUBLE SECRET PROBATION!

On May 6, 2014, at 11:34 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

regards

antonio

---

From: Brian Campbell <[email-masked]>
Date: Tue, 6 May 2014 06:29:28 -0700

>From the venerable film Animal House, of course,
https://www.youtube.com/watch?v=vVXEQ8hjyGI

Thanks for checking that Antonio.

Hopefully we could get a non Java based implementing to verify it too.

On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <[email-masked]> wrote:

>  On May 6, 2014, at 11:34 AM, Antonio Sanso <[email-masked]> wrote:
>
>  Hi Brian,
>
>  On May 6, 2014, at 5:40 AM, Brian Campbell <[email-masked]>
> wrote:
>
> [email-masked]

-- 
    <https://www.pingidentity.com/>
Brian Campbell
Portfolio Architect
  @ [email-masked]   +1 720.317.2061  Connect
with us…   <https://twitter.com/pingidentity> [image:
youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
logo] <https://www.facebook.com/pingidentitypage> [image: Google+
logo]<https://plus.google.com/u/0/114266977739397708540> [image:
slideshare logo] <http://www.slideshare.net/PingIdentity> [image: flipboard
logo] <http://flip.it/vjBF7> [image: rss feed
icon]<https://www.pingidentity.com/blogs/>
   [image: Register for Cloud Identity Summit 2014 | Modern Identity
Revolution | 19–23 July, 2014 | Monterey,
CA]<https://www.cloudidentitysummit.com/>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 6 May 2014 13:32:54 +0000

hi Brian,

On May 6, 2014, at 3:29 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

>From the venerable film Animal House, of course, https://www.youtube.com/watch?v=vVXEQ8hjyGI

just for completeness I did *not* use jose4j to verify it… (just to be safe)

regards

antonio

On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:
Well, as of this moment, they're on DOUBLE SECRET PROBATION!

Hi Brian,

regards

antonio

--
[Ping Identity logo]<https://www.pingidentity.com/>
Brian Campbell
Portfolio Architect
@       [email-masked]<mailto:[email-masked]>
[phone] +1 720.317.2061
Connect with us…
[twitter logo]<https://twitter.com/pingidentity> [youtube logo] <https://www.youtube.com/user/PingIdentityTV>  [LinkedIn logo] <https://www.linkedin.com/company/21870>  [Facebook logo] <https://www.facebook.com/pingidentitypage>  [Google+ logo] <https://plus.google.com/u/0/114266977739397708540>  [slideshare logo] <http://www.slideshare.net/PingIdentity>  [flipboard logo] <http://flip.it/vjBF7>  [rss feed icon] <https://www.pingidentity.com/blogs/>

[Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 6 May 2014 07:00:27 -0700

But you probable did do something very similar to what I did in jose4j -
i.e. just getting a cipher instance with
"RSA/ECB/OAEPWithSHA-256AndMGF1Padding"?

I think that's the right thing to do (and JWA even implies it) but a check
from a different language/platform would help verify that assumption. I
don't know if maybe more specifics need to be provided to the cipher via
OAEPParameterSpec or something - the JCA APIs can be a bit mysterious at
times.

On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <[email-masked]> wrote:

>  hi Brian,
>
>
>  On May 6, 2014, at 3:29 PM, Brian Campbell <[email-masked]>
> wrote:
>
> logo] <https://www.facebook.com/pingidentitypage> <https://plus.google.com/u/0/114266977739397708540> [image:
> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
> flipboard logo] <http://flip.it/vjBF7> <https://www.pingidentity.com/blogs/>
> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>
>
>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 06 May 2014 16:14:47 +0200

https://bugs.openjdk.java.net/browse/JDK-7038158

Anders

On 2014-05-06 16:00, Brian Campbell wrote:
> But you probable did do something very similar to what I did in jose4j - i.e. just getting a cipher instance with "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"?
> 
> I think that's the right thing to do (and JWA even implies it) but a check from a different language/platform would help verify that assumption. I don't know if maybe more specifics need to be provided to the cipher via OAEPParameterSpec or something - the JCA APIs can be a bit mysterious at times.
> 
> 
> On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     hi Brian,
> 
> 
>     On May 6, 2014, at 3:29 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>     On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         On May 6, 2014, at 11:34 AM, Antonio Sanso <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         Hi Brian,
>>>
>>>         On May 6, 2014, at 5:40 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>>         {"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30G
epLQ8nTlzeV6clx0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
>>>>         [email-masked] <mailto:[email-masked]>
>>     Ping Identity logo <https://www.pingidentity.com/> 	
>>     Brian Campbell
>>     Portfolio Architect
>>     @ 	[email-masked] <mailto:[email-masked]>
>>     phone 	+1 720.317.2061 <tel:%2B1%20720.317.2061>
>>     Connect with us…
>>     twitter logo <https://twitter.com/pingidentity> youtube logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo <https://www.linkedin.com/company/21870> Facebook logo <https://www.facebook.com/pingidentitypage> Google+ logo <https://plus.google.com/u/0/114266977739397708540> slideshare logo <http://www.slideshare.net/PingIdentity> flipboard logo <http://flip.it/vjBF7> rss feed icon <https://www.pingidentity.com/blogs/>
>>
>>     Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA <https://www.cloudidentitysummit.com/>
>>
>>
> 
> 
>     [email-masked] <mailto:[email-masked]>
> Ping Identity logo <https://www.pingidentity.com/> 	
> Brian Campbell
> Portfolio Architect
> @ 	[email-masked] <mailto:[email-masked]>
> phone 	+1 720.317.2061
> Connect with us…
> twitter logo <https://twitter.com/pingidentity> youtube logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo <https://www.linkedin.com/company/21870> Facebook logo <https://www.facebook.com/pingidentitypage> Google+ logo <https://plus.google.com/u/0/114266977739397708540> slideshare logo <http://www.slideshare.net/PingIdentity> flipboard logo <http://flip.it/vjBF7> rss feed icon <https://www.pingidentity.com/blogs/>
> 
> Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA <https://www.cloudidentitysummit.com/>
> 
> 
> 
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 6 May 2014 14:21:38 +0000

For what it's worth, this morning I copied Brian's homework and implemented the RSA-OAEP-256 algorithm in Nimbus-JOSE-JWT (on Java / BouncyCastle) using the Cipher instance he mentions below. I was able to do the decryption and get out the same clear text as Antonio.

So if we're wrong, we're all at least wrong in the exact same way.

 -- Justin

On May 6, 2014, at 10:00 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:
hi Brian,

regards

antonio

Hi Brian,

regards

antonio

--
[Ping Identity logo]<https://www.pingidentity.com/>
Brian Campbell
Portfolio Architect
@       [email-masked]<mailto:[email-masked]>
[phone] +1 720.317.2061<tel:%2B1%20720.317.2061>
Connect with us…
[twitter logo]<https://twitter.com/pingidentity> [youtube logo] <https://www.youtube.com/user/PingIdentityTV>  [LinkedIn logo] <https://www.linkedin.com/company/21870>  [Facebook logo] <https://www.facebook.com/pingidentitypage>  [Google+ logo] <https://plus.google.com/u/0/114266977739397708540>  [slideshare logo] <http://www.slideshare.net/PingIdentity>  [flipboard logo] <http://flip.it/vjBF7>  [rss feed icon] <https://www.pingidentity.com/blogs/>

---

From: <[email-masked]>
Date: Tue, 6 May 2014 21:31:53 +0200

Hi all,

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-A.2 specifies exactly these parameters.

   +-------+------------------------+--------------------+-------------+
   | JWE   | XML ENC                | JCA                | OID         |
   +-------+------------------------+--------------------+-------------+
   | RSA1_ | http://www.w3.org/2001 | RSA/ECB/PKCS1Paddi | 1.2.840.113 |
   | 5     | /04/xmlenc#rsa-1_5     | ng                 | 549.1.1.1   |
   | RSA-O | http://www.w3.org/2001 | RSA/ECB/OAEPWithSH | 1.2.840.113 |
   | AEP   | /04/xmlenc#rsa-oaep-mg | A-1AndMGF1Padding  | 549.1.1.7   |
   |       | f1p                    |                    |             |
   | RSA-O | http://www.w3.org/2009 | RSA/ECB/OAEPWithSH | 1.2.840.113 |
   | AEP-2 | /xmlenc11#rsa-oaep     | A-256AndMGF1Paddin | 549.1.1.7   |
   | 56    |                        | g                  |             |

Cheers
Axel

The code here
https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/crypto/CryptoUtils.java#410
is the code that Chuck and I used since the InformationCard days and that worked to verify the examples from the beginning of JOSE.
The parameters are the Bouncycastel default parameters (SHA-1)

From: jose [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, May 06, 2014 4:00 PM
To: Antonio Sanso
Cc: [email-masked]
Subject: Re: [jose] RSA-OAEP-256 Example

regards

antonio

Hi Brian,

regards

antonio

Brian Campbell
Portfolio Architect
@

[email-masked]<mailto:[email-masked]>

+1 720.317.2061<tel:%2B1%20720.317.2061>

Connect with us…

<https://twitter.com/pingidentity><https://www.youtube.com/user/PingIdentityTV><https://www.linkedin.com/company/21870><https://www.facebook.com/pingidentitypage><https://plus.google.com/u/0/114266977739397708540><http://www.slideshare.net/PingIdentity><http://flip.it/vjBF7><https://www.pingidentity.com/blogs/>

<https://www.cloudidentitysummit.com/>

Brian Campbell
Portfolio Architect
@

[email-masked]<mailto:[email-masked]>

+1 720.317.2061

Connect with us…

<https://twitter.com/pingidentity><https://www.youtube.com/user/PingIdentityTV><https://www.linkedin.com/company/21870><https://www.facebook.com/pingidentitypage><https://plus.google.com/u/0/114266977739397708540><http://www.slideshare.net/PingIdentity><http://flip.it/vjBF7><https://www.pingidentity.com/blogs/>

<https://www.cloudidentitysummit.com/>

---

From: Matt Miller <[email-masked]>
Date: Tue, 6 May 2014 21:39:19 -0600

Short answer:
You are all equally broken -- except from a certain point of view d-:

Long answer:
The code I have is based on OpenSSL, which is hard-coded to use SHA1
for the hash and mask generation (boo!), which means one has to
implement OAEP-SHA256 from scratch (hiss!!).

When I implemented it per RFC 3447 and
draft-ietf-jose-json-web-algorithms-26#section-4.3, I could not
decrypt the provided results.  When I hard-coded MGF1 to use "SHA1", I
could decrypt provided results.  A search through BouncyCastle's code
shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash
function of SHA-256 generate the lHash but its MGF1 uses a "SHA-1".
Further evidence is shown with how [FORGE] can be made to work with
Java (search their homepage for "Compatible with Java's
RSA/ECB/OAEPWithSHA-256AndMGF1Padding").

Reconciling all of this with
draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to be
very straight-forward.  It appears that the JCA identifier is meant to
be "MGF1 with SHA1"; that ought to be explicitly noted.  The XMLENC
reference is arguably incomplete, since
"http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to
"http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this can
probably be addressed by explicitly stating the mask generation
function is "http://www.w3.org/2009/xmlenc11#mgf1sha256" (MGF1 with
SHA-256).

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

[FORGE] Forge < https://github.com/digitalbazaar/forge >

On 5/6/14, 8:00 AM, Brian Campbell wrote:
> But you probable did do something very similar to what I did in
> jose4j - i.e. just getting a cipher instance with 
> I think that's the right thing to do (and JWA even implies it) but
> a check from a different language/platform would help verify that 
> assumption. I don't know if maybe more specifics need to be
> provided to the cipher via OAEPParameterSpec or something - the JCA
> APIs can be a bit mysterious at times.
> 
> 
> On May 6, 2014, at 3:29 PM, Brian Campbell 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>>> On May 6, 2014, at 5:40 AM, Brian Campbell 
>>> <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>> 
>>>> The latest revision of JWA added a new 'RSA-OAEP-256' JWE alg
>>>> for key encryption but, AFAIK, there are no examples using
>>>> it. I recently added support for it to 
>>>> https://bitbucket.org/b_c/jose4j and am looking to get some 
>>>> kind of confirmation that I've done it correctly (other than 
>>>> self interop). With that in mind, here is a JWE using 
>>>> RSA-OAEP-256 which I've produced and I'm hopeful that someone
>>>> on this WG list will be able to decrypt. The RSA key that was
>>>> used (in JWK format with both public and private parts) is
>>>> below the JWE.
>>>> 
{"kty":"RSA","n":"2cQJH1f6yF9DcGa8Cmbnhn4LHLs5L6kNb2rxkrNFZArJLRaKvaC3tMCKZ8ZgIpO9bVMPx5UMjJoaf7p9O5BSApVqA2J10fUbdSIomCcDwvGo0eyhty0DILLWTMXzGEVM3BXzuJQoeDkuUCXXcCwA4Msyyd2OHVu-pB2OrGv6fcjHwjINty3UoKm08lCvAevBKHsuA-FFwQII9bycvRx5wRqFUjdMAyiOmLYBHBaJSi11g3HVexMcb29v14PSlVzdGUMN8oboa-zcIyaPrIiczLqAkSXQNdEFHrjsJHfFeNMfOblLM7icKN_tyWujYeItt4kqUIimPn5dHjwgcQYE7w","e":"AQAB","d":"dyUz3ItVceX1Tv1WqtZMnKA_0jN5gWMcL7ayf5JISAlCssGfnUre2C10TH0UQjbVMIh-nLMnD5KNJw9Qz5MR28oGG932Gq7hm__ZeA34l-OCe4DdpgwhpvVSHOU9MS1RdSUpmPavAcA_X6ikrAHXZSaoHhxzUgrNTpvBYQMfJUv_492fStIseQ9rwAMOpCWOiWMZOQm3KJVTLLunXdKf_UxmzmKXYKYZWke3AWIzUqnOfqIjfDTMunF4UWU0zKlhcsaQNmYMVrJGajD1bJdy_dbUU3LE8sx-bdkUI6oBk-sFtTTVyVdQcetG9kChJ5EnY5R6tt_4_xFG5kxzTo6qaQ","p":"7yQmgE60SL7QrXpAJhChLgKnXWi6C8tVx1lA8FTpphpLaCtK-HbgBVHCprC2CfaM1mxFJZahxgFjC9ehuV8OzMNyFs8kekS82EsQGksi8HJPxyR1fU6ATa36ogPG0nNaqm3EDmYyjowhntgBz2OkbFAsTMHTdna-pZBRJa9lm5U","q":"6R4dzo9LwHLO73EMQPQsmwXjVOvAS5W6rgQ-BCtMhec_QosAXIVE3AGyfweqZm6rurXCVFykDLwJ30GepLQ8nTlzeV6clx
0x70saGGKKVmCsHuVYWwgIRyJTrt4SX29NQDZ_FE52NlO3OhPkj1ExSk_pGMqGRFd26K8g0jJsXXM","dp":"VByn-hs0qB2Ncmb8ZycUOgWu7ljmjz1up1ZKU_3ZzJWVDkej7-6H7vcJ-u1OqgRxFv4v9_-aWPWl68VlWbkIkJbx6vniv6qrrXwBZu4klOPwEYBOXsucrzXRYOjpJp5yNl2zRslFYQQC00bwpAxNCdfNLRZDlXhAqCUxlYqyt10","dq":"MJFbuGtWZvQEdRJicS3uFSY25LxxRc4eJJ8xpIC44rT5Ew4Otzf0zrlzzM92Cv1HvhCcOiNK8nRCwkbTnJEIh-EuU70IdttYSfilqSruk2x0r8Msk1qrDtbyBF60CToRKC2ycDKgolTyuaDnX4yU7lyTvdyD-L0YQwYpmmFy_k0","qi":"vy7XCwZ3jyMGik81TIZDAOQKC8FVUc0TG5KVYfti4tgwzUqFwtuB8Oc1ctCKRbE7uZUPwZh4OsCTLqIvqBQda_kaxOxo5EF7iXj6yHmZ2s8P_Z_u3JLuh-oAT_6kmbLx6CAO0DbtKtxp24Ivc1hDfqSwWORgN1AOrSRCmE3nwxg"}
>>>> _______________________________________________ jose mailing
>>>> list [email-masked] <mailto:[email-masked]> 
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @ 	[email-masked]
>> <mailto:[email-masked]> phone 	+1 720.317.2061
>> <tel:%2B1%20720.317.2061> Connect with us… twitter logo
>> <https://twitter.com/pingidentity> youtube logo 
>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo 
>> <https://www.linkedin.com/company/21870> Facebook logo 
>> <https://www.facebook.com/pingidentitypage> Google+ logo 
>> <https://plus.google.com/u/0/114266977739397708540> slideshare 
>> logo <http://www.slideshare.net/PingIdentity> flipboard logo 
>> <http://flip.it/vjBF7> rss feed icon 
>> <https://www.pingidentity.com/blogs/>
>> 
>> Register for Cloud Identity Summit 2014 | Modern Identity 
>> Revolution | 19–23 July, 2014 | Monterey, CA 
> _______________________________________________ jose mailing list 
> -- Ping Identity logo <https://www.pingidentity.com/> Brian
> Campbell Portfolio Architect @ 	[email-masked]
> <mailto:[email-masked]> phone 	+1 720.317.2061 Connect
> with us… twitter logo <https://twitter.com/pingidentity> youtube
> logo <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo 
> <https://www.linkedin.com/company/21870> Facebook logo 
> <https://www.facebook.com/pingidentitypage> Google+ logo 
> <https://plus.google.com/u/0/114266977739397708540> slideshare
> logo <http://www.slideshare.net/PingIdentity> flipboard logo 
> <http://flip.it/vjBF7> rss feed icon
> <https://www.pingidentity.com/blogs/>
> 
> Register for Cloud Identity Summit 2014 | Modern Identity
> Revolution | 19–23 July, 2014 | Monterey, CA
> _______________________________________________ jose mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/jose
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 6 May 2014 21:53:51 -0700

Thanks Matt.

That is why I was looking for someone to verify using a different platform.
Though I was hoping it'd just work.

Matt, can you try decrypting this one by chance? Using the same key. I was
more explicit with the parameters and, I think, MGF1 should be using
SHA-256 now too.

eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCjjU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpiOYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2jL6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPuBUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9_PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5GSvluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w

On Tue, May 6, 2014 at 8:39 PM, Matt Miller <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Short answer:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTaarnAAoJEDWi+S0W7cO1PHYH/3sUifwQv4vSi3PO6V5AwMad
> CuBlGYa4POF74O3QGqKF+aTHrB97MzSoj2Uz8hJCROGBpTxCSqx9CK3BOJ8hnGmI
> 6fq0FHDeA7WeCMkaxrNclX3WabaYHjB6hPlFKK+zB6z7jsr6F/sikmCJIbgNHeRn
> LI2Io02I3b2TUGDp90e4r5nZb/TlO7jV2kuwj8gprll1eBGiKfYdtlhpDiby7DPX
> QQuNNzGNlLmk90eAd4HfQvL6CrIbQgOgmgs5D0ZRXYzxn5hmABuOPBONhGlTD7xG
> xdkzNrD4frOAdLprtaC8cfarW6UYSTUOhNkyffDfFa3SIEzaF1JvnEVoMk8IW+A=
> =O9Ex
> -----END PGP SIGNATURE-----
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 7 May 2014 05:07:21 +0000

What new parameter values did you use?
________________________________
From: Brian Campbell<mailto:[email-masked]>
Sent: ‎5/‎6/‎2014 9:54 PM
To: Matt Miller<mailto:[email-masked]>
Cc: Antonio Sanso<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] RSA-OAEP-256 Example

Thanks Matt.

That is why I was looking for someone to verify using a different platform. Though I was hoping it'd just work.

Matt, can you try decrypting this one by chance? Using the same key. I was more explicit with the parameters and, I think, MGF1 should be using SHA-256 now too.

On Tue, May 6, 2014 at 8:39 PM, Matt Miller <[email-masked]<mailto:[email-masked]>> wrote:

Short answer:

Long answer:

- --
- - m&m

Matt Miller < [email-masked]<mailto:[email-masked]> >
Cisco Systems, Inc.

On 5/6/14, 8:00 AM, Brian Campbell wrote:
> On Tue, May 6, 2014 at 6:32 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> hi Brian,
>
>
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> wrote:
>
>> On Tue, May 6, 2014 at 6:25 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>> On May 6, 2014, at 11:34 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>> Hi Brian,
>>>
>>> <[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> Campbell Portfolio Architect @       [email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>> phone    +1 720.317.2061<tel:%2B1%20720.317.2061>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> Campbell Portfolio Architect @        [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> phone     +1 720.317.2061<tel:%2B1%20720.317.2061> Connect
> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 7 May 2014 08:30:21 +0000

Hi Brian,

just FYI, it looks you have used bouncy castle to produce the new JWE (please correct me if I am wrong).

Using the default Java provider gives indeed

javax.crypto.BadPaddingException: java.security.DigestException: Length must be at least 32 for SHA-256digests

as per [0].

The issue will disappear if the key is decrypted using BouncyCastle and gives the same result as the previous JWE

regards

antonio

[0] https://bugs.openjdk.java.net/browse/JDK-7038158

On May 7, 2014, at 6:53 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Matt.

Short answer:

Long answer:

- --
- - m&m

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 7 May 2014 08:31:17 +0000

hi Mike
On May 7, 2014, at 7:07 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

assuming Brian is using Java IMHO he used

 AlgorithmParameterSpec paramSpec = new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256,
                PSource.PSpecified.DEFAULT);

regards

antonio

Thanks Matt.

Short answer:

Long answer:

- --
- - m&m

---

From: <[email-masked]>
Date: Wed, 7 May 2014 10:21:22 +0200

I think that the java implementations implemented the spec and everything is ok from that POV.

These implementations are not broken.

One could argue that when we replace SHA-1 by SHA-256 in one place then we might consider to replace it in the padding too.

My feeling is that using sha-256 for the padding does not give us more security. YMMW

From: jose [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, May 07, 2014 6:54 AM
To: Matt Miller
Cc: Antonio Sanso; [email-masked]
Subject: Re: [jose] RSA-OAEP-256 Example

Thanks Matt.

Short answer:

Long answer:

- --
- - m&m

---

From: Matt Miller <[email-masked]>
Date: Wed, 7 May 2014 06:22:29 -0600

Looks like I'm on double secret probation again (-:

It's working as expected for my code.

- -- 
- - m&m

On 5/6/14, 10:53 PM, Brian Campbell wrote:
> Thanks Matt.
> 
> That is why I was looking for someone to verify using a different 
> platform. Though I was hoping it'd just work.
> 
> Matt, can you try decrypting this one by chance? Using the same
> key. I was more explicit with the parameters and, I think, MGF1
> should be using SHA-256 now too.
> 
> Short answer: You are all equally broken -- except from a certain
> point of view d-:
> 
> Long answer: The code I have is based on OpenSSL, which is
> hard-coded to use SHA1 for the hash and mask generation (boo!),
> which means one has to implement OAEP-SHA256 from scratch
> (hiss!!).
> 
> decrypt the provided results.  When I hard-coded MGF1 to use
> "SHA1", I could decrypt provided results.  A search through
> BouncyCastle's code shows that
> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a Hash function of
> SHA-256 generate the lHash but its MGF1 uses a "SHA-1". Further
> evidence is shown with how [FORGE] can be made to work with Java
> (search their homepage for "Compatible with Java's 
> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not look to
> be very straight-forward.  It appears that the JCA identifier is
> meant to be "MGF1 with SHA1"; that ought to be explicitly noted.
> The XMLENC reference is arguably incomplete, since 
> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1); this
> can probably be addressed by explicitly stating the mask
> generation function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"
> (MGF1 with SHA-256).
> 
> 
> 
>

---

From: Matt Miller <[email-masked]>
Date: Wed, 7 May 2014 06:35:07 -0600

> These implementations are not broken.

The JOSE Java implementations did not implement the spec, though.
draft-ietf-jose-json-web-algorithms § 4.3 clearly states the hash and
mask generation functions are to use the same algorithm -- SHA-1 (and
MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1 with
SHA-256) in the case of "RSA-OAEP-256".

> 
> 
> 
> One could argue that when we replace SHA-1 by SHA-256 in one place
> then we might consider to replace it in the padding too.

That is exactly what draft-ietf-jose-json-web-algorithms specified.

> My feeling is that using sha-256 for the padding does not give us

That is a separate debate, I think.  The prevailing opinion (at least
around the IETF) is "don't mix the algorithms".

- -- 
- - m&m

> 
> 
> 
> 
> *From:*jose [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM *To:* Matt Miller 
> *Cc:* Antonio Sanso; [email-masked] *Subject:* Re: [jose]
> RSA-OAEP-256 Example
> 
> 
> 
> Thanks Matt.
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 7 May 2014 06:29:18 -0700

Thanks again Matt for checking my homework.

As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"
transformation to get a cipher instance but then also initialized it with
the OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256,
PSource.PSpecified.DEFAULT), which is what gets MGF to use SHA2 as well.

I did run into the issue that Antonio pointed out [0]. Thanks BTW, I didn't
really see the applicability of it when you sent it yesterday but having
the reference was very helpful later. FWIW, I didn't use Bouncy Castle but
rather the default Sun/Oracle provider with Java 8, which seems to have
fixed that issue between 7 & 8.

I'm not sure how to articulate all that in the JWA's Key Management
Algorithm Identifier Cross-Reference [1] as
"RSA/ECB/OAEPWithSHA-256AndMGF1Padding" is correct but not sufficient. And
as Matt pointed out, the XMLENC cross-ref probably isn't quite right either.

I also agree with Matt that my first attempt at this as well as the other
Java based implementations yesterday were not properly implementing the
spec, which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 with
SHA-256" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using
SHA-256 is a separate debate but, as JWA is written now, it's MGF1 with
SHA-256.  Given that this RSA-OAEP-256 was added at the request of the AD,
it's likely to be a short debate.

[0] https://bugs.openjdk.java.net/browse/JDK-7038158
[1]
http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.appendix.A.1
[2]
tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryptionRSAOAEP

On Wed, May 7, 2014 at 5:35 AM, Matt Miller <[email-masked]> wrote:

> iQEcBAEBCgAGBQJTaih6AAoJEDWi+S0W7cO1dqMIAIgB0qPxKOkFRQ1w16tiAW0P
> KZ3bFZ0LX5RnaiL2t0bAfMo4ivSdawRmabLmNVuOrTbKZ5cPpdI9jSYqzAs/3SS6
> oLDnFFB6PHCz8nBWRvEtwxGII3t6e3LEoqW7ndcvO/1Le77uy+zAB6Xs0xh1mxWY
> NEHpVQsKs2Ytjk9ZxcqdUjivZhU17PPmam2hu2xYcZLxI8eHav8uzQJWCYTzg4my
> uVy8JTbQ6odtx7hiJSpTiY6cYOaa2TcRbroQNKmOsHIQ3em86Esme4cOlPiJ6vds
> VbBHZXh3NqSjWcmAc5ysTmP7j9ATIn1+ZWlXAZEXAi3mBKme+VGGraO079bhR7Y=
> =zfUl

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 7 May 2014 14:12:38 +0000

I've updated the Nimbus library to use the different hash, and the new token works under BouncyCastle in Java7. I did hit the bug mentioned [0] when running with the Sun provider. Also important, the old token doesn't work anymore.

 -- Justin

On May 7, 2014, at 9:29 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

As Antonio surmised, I used the "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" transformation to get a cipher instance but then also initialized it with the OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT), which is what gets MGF to use SHA2 as well.

I did run into the issue that Antonio pointed out [0]. Thanks BTW, I didn't really see the applicability of it when you sent it yesterday but having the reference was very helpful later. FWIW, I didn't use Bouncy Castle but rather the default Sun/Oracle provider with Java 8, which seems to have fixed that issue between 7 & 8.

I'm not sure how to articulate all that in the JWA's Key Management Algorithm Identifier Cross-Reference [1] as "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" is correct but not sufficient. And as Matt pointed out, the XMLENC cross-ref probably isn't quite right either.

I also agree with Matt that my first attempt at this as well as the other Java based implementations yesterday were not properly implementing the spec, which is pretty clear about "RSAES OAEP using SHA-256 and MGF1 with SHA-256" [2]. And that MGF1 with SHA-256 vs SHA-1 for RSAES OAEP using SHA-256 is a separate debate but, as JWA is written now, it's MGF1 with SHA-256.  Given that this RSA-OAEP-256 was added at the request of the AD, it's likely to be a short debate.

[0] https://bugs.openjdk.java.net/browse/JDK-7038158
[1] http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.appendix.A.1
[2] tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryptionRSAOAEP<http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#KeyEncryptionRSAOAEP>

On Wed, May 7, 2014 at 5:35 AM, Matt Miller <[email-masked]<mailto:[email-masked]>> wrote:

- --
- - m&m

>
>
>
>
> *From:*jose [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of *Brian
> *Cc:* Antonio Sanso; [email-masked]<mailto:[email-masked]> *Subject:* Re: [jose]
> RSA-OAEP-256 Example
>
>
>
> Thanks Matt.
>
> On Tue, May 6, 2014 at 8:39 PM, Matt Miller <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

---

From: Antonio Sanso <[email-masked]>
Date: Wed, 7 May 2014 14:23:34 +0000

On May 7, 2014, at 4:12 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:

I've updated the Nimbus library to use the different hash, and the new token works under BouncyCastle in Java7. I did hit the bug mentioned [0] when running with the Sun provider.

I suppose you are using Java 8 so...

regards

antonio

Also important, the old token doesn't work anymore.

 -- Justin

- --
- - m&m

---

From: <[email-masked]>
Date: Wed, 7 May 2014 16:30:49 +0200

Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that SHA-256 must be used for padding too?

I did not read it so.

Did somebody manage to use JCA correctly with one algorithm specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?

Axel

A.2.<http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.appendix.A.2> Key Management Algorithm Identifier Cross-Reference<http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#EncAlgXref>

This section contains a table cross-referencing the JWE alg (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages.
JWE

XML ENC

JCA

OID

RSA1_5

http://www.w3.org/2001/04/xmlenc#rsa-1_5

RSA/ECB/PKCS1Padding

1.2.840.113549.1.1.1

RSA-OAEP

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

RSA/ECB/OAEPWithSHA-1AndMGF1Padding

1.2.840.113549.1.1.7

RSA-OAEP-256

http://www.w3.org/2009/xmlenc11#rsa-oaep

RSA/ECB/OAEPWithSHA-256AndMGF1Padding

1.2.840.113549.1.1.7

-----Original Message-----
From: Antonio Sanso [mailto:[email-masked]]
Sent: Wednesday, May 07, 2014 4:24 PM
To: Richer, Justin P.
Cc: Brian Campbell; Matt Miller; [email-masked]; Nennker, Axel
Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example

On 5/7/14, 2:21 AM, [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>> wrote:

> I think that the java implementations implemented the spec and

> everything is ok from that POV.

draft-ietf-jose-json-web-algorithms § 4.3 clearly states the hash and mask generation functions are to use the same algorithm -- SHA-1 (and

> My feeling is that using sha-256 for the padding does not give us more

> security. YMMW

That is a separate debate, I think.  The prevailing opinion (at least around the IETF) is "don't mix the algorithms".

--

- m&m

Matt Miller < [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>> > Cisco Systems, Inc.

> *From:*jose

> [mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]%3cmailto:[email-masked]%3e>] *On

> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014 6:54 AM

> *To:* Matt Miller

> *Cc:* Antonio Sanso; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>> *Subject:*

> Re: [jose]

> Matt, can you try decrypting this one by chance? Using the same key. I

> was more explicit with the parameters and, I think, MGF1 should be

> using SHA-256 now too.

> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj

> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ

> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi

> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j

> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu

> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9

> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G

> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w

> On Tue, May 6, 2014 at 8:39 PM, Matt Miller

> <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> <mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>> wrote:

> Long answer: The code I have is based on OpenSSL, which is hard-coded

> to use SHA1 for the hash and mask generation (boo!), which means one

> has to implement OAEP-SHA256 from scratch (hiss!!).

> function of

> be "MGF1 with SHA1"; that ought to be explicitly noted.

> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"

---

From: Brian Campbell <[email-masked]>
Date: Fri, 9 May 2014 07:32:55 -0600

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4.3is
pretty clear about which parameters and hash functions to use in which
OAEP alg.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-A.2that
you refer to Axel probably needs to be updated because just listing
RSA/ECB/OAEPWithSHA-256AndMGF1Padding
for RSA-OAPE-265 isn't completely correct (well, maybe it is correct but a
bit more is also needed).

In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a Cipher
with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize it with
an OAEPParameterSpec that indicates that
SHA-256 is to be used for MGF1 too. That looks something like this (or this
is how I did it anyway):

   Cipher cipher =
Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
   OAEPParameterSpec oaepSpec = new OAEPParameterSpec("SHA-256", "MGF1",
MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
   cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec);

The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant with
what's specified in the OAEPParameterSpec but I've not been able to figure
out any other way to make it work. I don't know exactly how to say that in
the Key Management Algorithm Identifier Cross-Reference but that's
apparently what needs to be done.

On Wed, May 7, 2014 at 8:30 AM, <[email-masked]> wrote:

> Does “RSA/ECB/OAEPWithSHA-1AndMGF1Padding” mean that SHA-256 must be used
> for padding too?
>
> I did not read it so.
>
> Did somebody manage to use JCA correctly with one algorithm specifier like
> RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?
>
>
>
> Axel
> A.2.<http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.appendix.A.2> Key
> Management Algorithm Identifier Cross-Reference<http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#EncAlgXref>
>
> This section contains a table cross-referencing the JWE alg (algorithm)
> values defined in this specification with the equivalent identifiers used
> by other standards and software packages.
>
> *JWE*
>
> *XML ENC*
>
> *JCA*
>
> *OID*
>
> RSA1_5
>
> draft-ietf-jose-json-web-algorithms § 4.3 clearly states the hash and mask
> generation functions are to use the same algorithm -- SHA-1 (and
>
> Matt Miller < [email-masked]<mailto:[email-masked]> > Cisco
> Systems, Inc.
>
>
>
> >
>
> >
>
> >
>
> >
>
> > *From:*jose
>
> > [mailto:[email-masked]<mailto:[email-masked]><[email-masked]%3cmailto:[email-masked]%3e>]
> *On
>
> > *Cc:* Antonio Sanso; [email-masked]<mailto:[email-masked]> *Subject:*
>
> > Re: [jose]
>
> > RSA-OAEP-256 Example
>
> >
>
> >
>
> >
>
> > Thanks Matt.
>
> >
>
> > <[email-masked]<mailto:[email-masked]>
>
> > <mailto:[email-masked]<mailto:[email-masked]<[email-masked]%3cmailto:[email-masked]>>>>
> wrote:
>
> >
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 9 May 2014 13:43:13 +0000

I've found that it seems to work if you use NOPADDING, too:

AlgorithmParameters algp = AlgorithmParametersHelper.getInstance("OAEP", provider);
AlgorithmParameterSpec paramSpec = new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
algp.init(paramSpec);
Cipher cipher = CipherHelper.getInstance("RSA/ECB/NOPADDING", provider);
cipher.init(Cipher.DECRYPT_MODE, priv, algp);

(Note that all the AlgorithmParametersHelper does in our code is install the right provider if given.)

-- Justin

On May 9, 2014, at 9:32 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4.3 is pretty clear about which parameters and hash functions to use in which OAEP alg.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-A.2 that you refer to Axel probably needs to be updated because just listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't completely correct (well, maybe it is correct but a bit more is also needed).

In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize it with an OAEPParameterSpec that indicates that
SHA-256 is to be used for MGF1 too. That looks something like this (or this is how I did it anyway):

   Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
   OAEPParameterSpec oaepSpec = new OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
   cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec);

The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant with what's specified in the OAEPParameterSpec but I've not been able to figure out any other way to make it work. I don't know exactly how to say that in the Key Management Algorithm Identifier Cross-Reference but that's apparently what needs to be done.

On Wed, May 7, 2014 at 8:30 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Does “RSA/ECB/OAEPWithSHA-1AndMGF1Padding” mean that SHA-256 must be used for padding too?

I did not read it so.

Axel

XML ENC

JCA

OID

RSA1_5

RSA/ECB/PKCS1Padding

1.2.840.113549.1.1.1

RSA-OAEP

1.2.840.113549.1.1.7

RSA-OAEP-256

1.2.840.113549.1.1.7

-----Original Message-----
From: Antonio Sanso [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, May 07, 2014 4:24 PM
To: Richer, Justin P.
Cc: Brian Campbell; Matt Miller; [email-masked]<mailto:[email-masked]>; Nennker, Axel
Subject: ***CAUTION_Invalid_Signature*** Re: [jose] RSA-OAEP-256 Example

--

- m&m

---

From: Brian Campbell <[email-masked]>
Date: Fri, 9 May 2014 10:31:05 -0600

So while OAEPWithSHA-256AndMGF1Padding is a little redundant with the
OAEPParameterSpec, I'd say NOPADDING seems a little contradictory. But what
do I know?

I'm still not sure how to concisely explain it in the appendix.

On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P. <[email-masked]> wrote:

> AlgorithmParameterSpec paramSpec = new OAEPParameterSpec("SHA-256", "MGF1",
>  On May 9, 2014, at 9:32 AM, Brian Campbell <[email-masked]>
> wrote:
>
>
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4.3is pretty clear about which parameters and hash functions to use in which
> OAEP alg.
>
>
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-A.2that you refer to Axel probably needs to be updated because just listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding
>  In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a
> Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also initialize
> it with an OAEPParameterSpec that indicates that
> out any other way to make it work. I don't know exactly how to say that
> in the Key Management Algorithm Identifier Cross-Reference but that's
>> Did somebody manage to use JCA correctly with one algorithm specifier
>> like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?
>>
>>
>>
>> Axel
>> On 5/7/14, 2:21 AM,
>> [email-masked]<mailto:[email-masked]> wrote:
>>

---

From: Matt Miller <[email-masked]>
Date: Fri, 9 May 2014 10:38:18 -0600

As I said originally, I don't think there's a straight-forward fix
here.  It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"
gets the closest to the intent here.

I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, you can get
the Java code to the JOSE-specified configuration starting with that
identifier string, but it's rather misleading without knowing the
paramspec.

- -- 
- - m&m

On 5/9/14, 10:31 AM, Brian Campbell wrote:
> So while OAEPWithSHA-256AndMGF1Padding is a little redundant with
> the OAEPParameterSpec, I'd say NOPADDING seems a little
> contradictory. But what do I know?
> 
> On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P.
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> AlgorithmParameters algp = 
> AlgorithmParametersHelper.getInstance("OAEP", provider); 
> AlgorithmParameterSpec paramSpec = new
> OAEPParameterSpec("SHA-256", "MGF1", MGF1ParameterSpec.SHA256,
> PSource.PSpecified.DEFAULT); algp.init(paramSpec); Cipher cipher =
> CipherHelper.getInstance("RSA/ECB/NOPADDING", provider); 
> On May 9, 2014, at 9:32 AM, Brian Campbell 
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-4.3
>>
>> 
is pretty clear about which parameters and hash functions to use
>> in which OAEP alg.
>> 
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#appendix-A.2
>>
>> 
that you refer to Axel probably needs to be updated because just
>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 
>> isn't completely correct (well, maybe it is correct but a bit
>> more is also needed).
>> 
>> In order to do RSA-OAPE-265 correctly using the JCA APIs, one
>> gets a Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then
>> also initialize it with an OAEPParameterSpec that indicates that 
>> SHA-256 is to be used for MGF1 too.That looks something like
>> this (or this is how I did it anyway):
>> 
>> Cipher cipher = 
>> OAEPParameterSpec oaepSpec = new OAEPParameterSpec("SHA-256", 
>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT); 
>> The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant 
>> with what's specified in the OAEPParameterSpec but I've not been 
>> able to figure out any other way to make it work. I don't know 
>> exactly how to say that in the Key Management Algorithm
>> Identifier Cross-Reference but that's apparently what needs to be
>> done.
>> 
>> 
>> 
>> 
>> 
>> Does “RSA/ECB/OAEPWithSHA-1AndMGF1Padding” mean that SHA-256 must
>> be used for padding too?____
>> 
>> I did not read it so.____
>> 
>> RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____
>> 
>> __ __
>> 
>> Axel____
>> 
>> 
>> A.2. 
>> <http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#rfc.appendix.A.2>
>>
>> 
Key Management Algorithm Identifier Cross-Reference
>> <http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.html#EncAlgXref>____
>>
>>
>> 
This section contains a table cross-referencing the JWE alg
>> (algorithm) values defined in this specification with the 
>> equivalent identifiers used by other standards and software 
>> packages. ____
>> 
>> *JWE**____*
>> 
>> 
>> 
>> *XML ENC**____*
>> 
>> 
>> 
>> *JCA**____*
>> 
>> 
>> 
>> *OID**____*
>> 
>> RSA1_5____
>> 
>> 
>> 
>> http://www.w3.org/2001/04/xmlenc#rsa-1_5____
>> 
>> 
>> 
>> RSA/ECB/PKCS1Padding____
>> 
>> 
>> 
>> 1.2.840.113549.1.1.1____
>> 
>> RSA-OAEP____
>> 
>> 
>> 
>> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____
>> 
>> 
>> 
>> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____
>> 
>> 
>> 
>> 1.2.840.113549.1.1.7____
>> 
>> RSA-OAEP-256____
>> 
>> 
>> 
>> http://www.w3.org/2009/xmlenc11#rsa-oaep____
>> 
>> 
>> 
>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____
>> 
>> 
>> 
>> 1.2.840.113549.1.1.7____
>> 
>> __ __
>> 
>> __ __
>> 
>> -----Original Message----- From: Antonio Sanso
>> [mailto:[email-masked] <mailto:[email-masked]>] Sent:
>> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian
>> Campbell; Matt Miller; [email-masked] <mailto:[email-masked]>;
>> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re:
>> [jose] RSA-OAEP-256 Example
>> 
>> __ __
>> 
>> On 5/7/14, 2:21 AM, 
>> [email-masked]<mailto:[email-masked] 
>> <mailto:[email-masked]%3cmailto:[email-masked]>>
>>
>> 
wrote:____
>> 
>>> I think that the java implementations implemented the spec
>> and ____
>> 
>>> everything is ok from that POV.____
>> 
>>> __ __
>> 
>>> These implementations are not broken.____
>> 
>> __ __
>> 
>> The JOSE Java implementations did not implement the spec, 
>> though.____
>> 
>> draft-ietf-jose-json-web-algorithms § 4.3 clearly states the hash
>> and mask generation functions are to use the same algorithm --
>> SHA-1 (and____
>> 
>> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1
>> with____
>> 
>> SHA-256) in the case of "RSA-OAEP-256".____
>> 
>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> One could argue that when we replace SHA-1 by SHA-256 in one
>> place ____
>> 
>>> then we might consider to replace it in the padding too.____
>> 
>> __ __
>> 
>> That is exactly what draft-ietf-jose-json-web-algorithms 
>> specified.____
>> 
>> __ __
>> 
>>> __ __
>> 
>>> My feeling is that using sha-256 for the padding does not
>> give us more ____
>> 
>>> security. YMMW____
>> 
>>> __ __
>> 
>> __ __
>> 
>> That is a separate debate, I think.  The prevailing opinion (at
>> least around the IETF) is "don't mix the algorithms".____
>> 
>> __ __
>> 
>> __ __
>> 
>> --____
>> 
>> - m&m____
>> 
>> __ __
>> 
>> Matt Miller < [email-masked]<mailto:[email-masked] 
>> <mailto:[email-masked]%3cmailto:[email-masked]>> > Cisco
>> Systems, Inc.____
>> 
>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> *From:*jose ____
>> 
>>> [mailto:[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]%3cmailto:[email-masked]%3e>]
>>
>> 
*On ____
>> 
>>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014
>> 6:54 AM ____
>> 
>>> *To:* Matt Miller____
>> 
>>> *Cc:* Antonio Sanso; [email-masked]<mailto:[email-masked]
>> <mailto:[email-masked]%3cmailto:[email-masked]>> *Subject:* ____
>> 
>>> Re: [jose]____
>> 
>>> RSA-OAEP-256 Example____
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> Thanks Matt.____
>> 
>>> __ __
>> 
>>> That is why I was looking for someone to verify using a
>> different ____
>> 
>>> platform. Though I was hoping it'd just work.____
>> 
>>> __ __
>> 
>>> Matt, can you try decrypting this one by chance? Using the
>> same key. I ____
>> 
>>> was more explicit with the parameters and, I think, MGF1
>> should be ____
>> 
>>> using SHA-256 now too.____
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> 
>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cMCj____
>>
>>
>> 
> 
>> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442ZgZ____
>>
>>
>> 
> 
>> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gWpi____
>>
>>
>> 
> 
>> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE2j____
>>
>>
>> 
> 
>> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQcPu____
>>
>>
>> 
> 
>> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1s9____
>>
>>
>> 
> 
>> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH5G____
>>
>>
>> 
> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____
>> 
>>> <[email-masked]<mailto:[email-masked]
>> <mailto:[email-masked]%3cmailto:[email-masked]>>____
>> 
>>> <mailto:[email-masked]<mailto:[email-masked]
>> <mailto:[email-masked]%3cmailto:[email-masked]>>>> 
>> wrote:____
>> 
>>> __ __
>> 
>>> Short answer: You are all equally broken -- except from a
>> certain ____
>> 
>>> point of view d-:____
>> 
>>> __ __
>> 
>> hard-coded ____
>>> to use SHA1 for the hash and mask generation (boo!), which
>> means one ____
>> 
>>> has to implement OAEP-SHA256 from scratch (hiss!!).____
>> 
>>> __ __
>> 
>>> When I implemented it per RFC 3447 and ____
>> 
>>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could
>> not ____
>> 
>> "SHA1", I ____
>>> could decrypt provided results.  A search through
>> BouncyCastle's code ____
>> 
>>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a
>> Hash ____
>> 
>>> function of____
>> 
>>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1".
>> Further ____
>> 
>>> evidence is shown with how [FORGE] can be made to work with
>> Java ____
>> 
>>> (search their homepage for "Compatible with Java's ____
>> 
>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____
>> 
>>> __ __
>> 
>>> Reconciling all of this with____
>> 
>>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not
>> look to be ____
>> 
>>> very straight-forward.  It appears that the JCA identifier
>> is meant to ____
>> 
>>> be "MGF1 with SHA1"; that ought to be explicitly noted.____
>> 
>>> The XMLENC reference is arguably incomplete, since ____
>> 
>>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to ____
>> 
>>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1);
>> this can ____
>> 
>>> probably be addressed by explicitly stating the mask
>> generation ____
>> 
>>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"____
>> 
>>> (MGF1 with SHA-256).____
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>>> __ __
>> 
>> 
>> 
>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Sat, 10 May 2014 21:17:21 +0000

The fact is that there's no way to get this kind of signature *without* the param spec, since it overrides the padding definition defined by the string itself. So there's not actually a single string of any kind in JCE that will do the right thing, and the appendix ought to have both pieces in it.

 -- Justin

On May 9, 2014, at 12:38 PM, Matt Miller <[email-masked]> wrote:

> iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK
> DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL
> 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj
> 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL
> d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi
> YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc=
> =2XGV

---

From: Mike Jones <[email-masked]>
Date: Sat, 10 May 2014 21:30:04 +0000

I plan to just put both strings in the table the next time edits are made.  Are there other strings or OIDS in the tables that also should be updated, based on people's implementation experiences?

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Saturday, May 10, 2014 2:17 PM
To: Matt Miller
Cc: Antonio Sanso; Brian Campbell; Axel Nennker; [email-masked]
Subject: Re: [jose] RSA-OAEP-256 Example

 -- Justin

On May 9, 2014, at 12:38 PM, Matt Miller <[email-masked]> wrote:

>> OAEPParameterSpec, I'd say NOPADDING seems a little contradictory. 
>> But what do I know?
>> 
>> AlgorithmParameterSpec paramSpec = new OAEPParameterSpec("SHA-256", 
>> algp.init(paramSpec); Cipher cipher = 
>>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't 
>>> completely correct (well, maybe it is correct but a bit more is also 
>>> needed).
>>> 
>>> Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also 
>>> initialize it with an OAEPParameterSpec that indicates that
>>> SHA-256 is to be used for MGF1 too.That looks something like this 
>>> (or this is how I did it anyway):
>>> 
>>> Cipher cipher =
>>> exactly how to say that in the Key Management Algorithm Identifier 
>>> Cross-Reference but that's apparently what needs to be done.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that SHA-256 must be 
>>> used for padding too?____
>>> 
>>> Did somebody manage to use JCA correctly with one algorithm 
>>> specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____
>>> 
>>> __ __
>>> 
>>> Axel____
>>> 
>>> 
>>> A.2. 
>>> (algorithm) values defined in this specification with the equivalent 
>>> identifiers used by other standards and software packages. ____
>>> 
>>> *JWE**____*
>>> 
>>> 
>>> 
>>> *XML ENC**____*
>>> 
>>> 
>>> 
>>> *JCA**____*
>>> 
>>> 
>>> 
>>> *OID**____*
>>> 
>>> RSA1_5____
>>> 
>>> 
>>> 
>>> <tel:%2B1%20720.317.2061> Connect with us. twitter logo 
>>> <https://plus.google.com/u/0/114266977739397708540> slideshare logo 
>>> <http://www.slideshare.net/PingIdentity> flipboard logo 
>>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution 
>>> | 19-23 July, 2014 | Monterey, CA 
>> with us. twitter logo <https://twitter.com/pingidentity> youtube logo 
>> <https://plus.google.com/u/0/114266977739397708540> slideshare logo 
>> <http://www.slideshare.net/PingIdentity> flipboard logo 
>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution 
>> | 19-23 July, 2014 | Monterey, CA

---

From: Brian Campbell <[email-masked]>
Date: Sun, 11 May 2014 08:42:14 -0600

Yeah, I've got a few potential updates to the table based on my experience
building https://bitbucket.org/b_c/jose4j

"AESWrap" is the JCA string/transform for A128KW, A192KW and A256KW.

For ECDH-ES, the java algorithm for the key agreement part is "ECDH".
AFAIK, there is nothing in the JCA that does the KDF so that part needs to
be written 'from scratch' using a SHA-256 message digest. Dunno how much of
that you want to try and capture in the table, maybe just "ECDH" is good.
The AES key wrap part of the ECDH-ES+AxxxKW ones use same "AESWrap" as the
AxxxKW above.

A128GCMKW, A192GCMKW and A256GCMKW, which aren't currently in appendix A.2
all use the same JCA algorithm as their AxxxGCM content encryption
counterparts: "AES/GCM/NoPadding"

"PBKDF2WithHmacSHA256", "PBKDF2WithHmacSHA384" and "PBKDF2WithHmacSHA512"
would be the SecretKeyFactory JCA algorithms for the PBKDF2 part of
PBES2-HS256+A128KW, PBES2-HS384+A192KW and PBES2-HS512+A256KW
respectively.  But they aren't widely implemented (only in the Java 8
provider, I think, most providers only seem to have PBKDF2WithHmacSHA1) so
I ended up writing my own PBKDF2 using the corresponding HMAC-SHA2 Mac.
The encryption part is the same as the AxxxKW.

On Sat, May 10, 2014 at 3:30 PM, Mike Jones <[email-masked]>wrote:

> I plan to just put both strings in the table the next time edits are made.
>  Are there other strings or OIDS in the tables that also should be updated,
> based on people's implementation experiences?
>
>                                 -- Mike
>
> The fact is that there's no way to get this kind of signature *without*
> the param spec, since it overrides the padding definition defined by the
> string itself. So there's not actually a single string of any kind in JCE
> that will do the right thing, and the appendix ought to have both pieces in
> it.
>
>  -- Justin
>