On 2015-03-27 01:31, Brian Campbell wrote:
I am pretty sure you should not make that change to the JCA algorithm string.
> I'll have to search around to remember why, some oddity of Java I think, > but I'm away from my laptop right now and that one is too much to research on a phone.
Indeed, this is an old SUN bug that we have to put up with: http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html It is worth a note though. Anders
On Mar 26, 2015 6:41 PM, "Mike Jones" <[email protected] <mailto:[email protected]>> wrote: I am working on the formatting of the algorithm cross-reference tables in JWA Appendix A http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A with the RFC Editor to make them more readable. When looking at the table content (in a more readable rendition I’ll share with you soon), I noticed that this string appears for the JCA value of three algorithms:____ AES/CBC/PKCS5Padding____ which I believe should be____ AES/CBC/PKCS7Padding____ __ __ This would be consistent with the changes made in -28 for the reasons described in this thread. JAVA IMPLEMENTERS– If you are currently using AES/CBC/PKCS5Padding can you please verify that your implementation still works after changing this string to AES/CBC/PKCS7Padding and that the results are still correct and reply to us letting us know what happened? Matt, if your code for the cookbook is in Java, it would be especially good if you made this code change and verified that nothing changes in the output.____ __ __ Also, this clearly inconsistent sentence currently occurs in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____ CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS____ #7 padding using the cipher with the key X.____ __ __ I believe that the identifier CBC-PKCS5-ENCshould be changed to CBC-PKCS7-ENC.____ __ __ Unless people disagree, I will plan to apply these corrections during AUTH48.____ __ __ Thanks all,____ -- Mike____ __ __ *From:*jose [mailto:[email protected] <mailto:[email protected]>] *On Behalf Of *Mike Jones *Sent:* Friday, June 20, 2014 7:03 PM *To:* Shaun Cooley (shcooley) *Cc:* [email protected] <mailto:[email protected]>; Matt Miller (mamille2) *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____ __ __ This change has been incorporated in the -28 drafts.____ __ __ Thanks again, Shaun,____ -- Mike____ __ __ *From:*jose [mailto:[email protected]] *On Behalf Of *Mike Jones *Sent:* Friday, June 13, 2014 2:27 PM *To:* Shaun Cooley (shcooley) *Cc:* [email protected] <mailto:[email protected]>; Matt Miller (mamille2) *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____ __ __ (Adding the JOSE working group)____ __ __ I believe you’re right. I’ll plan to make this change in the next version of the spec.____ __ __ Thanks for the careful read!____ __ __ -- Mike____ __ __ *From:*Shaun Cooley (shcooley) [mailto:[email protected]] *Sent:* Friday, June 13, 2014 10:34 AM *To:* Mike Jones *Cc:* Matt Miller (mamille2) *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____ __ __ Michael –____ I am working on implementing a browser compatible JS implementation of JOSE, based on the work Matt Miller did for Node.JS. While going through the spec, I noticed that PKCS #5 is called out for the AES-CBC ciphers. Shouldn’t this be PKCS #7?____ __ __ PKCS #5 – RFC2898 section 6.2 specifies:____ The padding string PS shall consist of 8 - (||M|| mod 8) octets all having value 8 - (||M|| mod 8).____ __ __ PKCS #7 – RFC2315 section 10.3 note 2 specifies:____ For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input.____ __ __ PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas PKCS #5 is intended for block sizes of 8. This means that PKCS #7 is a superset of #5, and given that AES is a block size of 16, it seems the spec should require PKCS #7.____ __ __ Thoughts?____ __ __ *Shaun Cooley* DISTINGUISHED ENGINEER.ENGINEERING Collaboration Technology Group [email protected] <mailto:[email protected]> Phone: *+1 408 902 3344 <tel:%2B1%20408%20902%203344>* Mobile: *+1 310 293 2087 <tel:%2B1%20310%20293%202087>*____ http://www.cisco.com/web/europe/images/email/signature/logo05.jpg Cisco.com <http://www.cisco.com/>____ __ __ This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.____ For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html____ __ __ __ __ _______________________________________________ jose mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
