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. On Mar 26, 2015 6:41 PM, "Mike Jones" <[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-ENC should 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]] *On Behalf Of *Mike Jones > *Sent:* Friday, June 20, 2014 7:03 PM > *To:* Shaun Cooley (shcooley) > *Cc:* [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]; 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] > Phone: *+1 408 902 3344 <%2B1%20408%20902%203344>* > Mobile: *+1 310 293 2087 <%2B1%20310%20293%202087>* > > [image: 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] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
