It may or may not warrant a note of some sort to explain the discrepancy (not sure if that's really in scope). It looks as though some providers like Bouncy Castle and the one on Android will work with "AES/CBC/PKCS7Padding". But "AES/CBC/PKCS5Padding" is what is needed for the Sun/Oracle JCA provider (I verified this again against Java 7 & 8) and is what is required by "Every implementation of the Java platform" per http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html and it actually give you PKCS7Padding even though it says 5.
On Fri, Mar 27, 2015 at 9:42 AM, Mike Jones <[email protected]> wrote: > Thanks a bunch, Vladimir. That definitively answers the question. > > > > -- Mike > > > > *From:* jose [mailto:[email protected]] *On Behalf Of *Vladimir > Dzhuvinov > *Sent:* Friday, March 27, 2015 9:36 AM > *To:* [email protected] > *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 > (PKCS #5) > > > > This is indeed a JCA oddity, when "PKCS5Padding" is specified Java > actually does "PKCS7Padding". > > If you stick "PKCS7Padding" you'll get an > > NoSuchAlgorithmException: Cannot find any provider supporting > AES/CBC/PKCS7Padding > > > > > > Vladimir > > On 27.03.2015 08:20, Anders Rundgren wrote: > > 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]> <[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] <[email protected]> > <mailto:[email protected]> <[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]> <[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] <[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]> <[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] > <[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]> <[email protected]> > Phone: *+1 408 902 3344 <tel:%2B1%20408%20902%203344 > <%2B1%20408%20902%203344>>* > Mobile: *+1 310 293 2087 <tel:%2B1%20310%20293%202087 > <%2B1%20310%20293%202087>>*____ > > > > http://www.cisco.com/web/europe/images/email/signature/logo05.jpg > Cisco.com <http://www.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]> <[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 > > > > -- > > Vladimir Dzhuvinov :: [email protected] > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
