Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)

From: Justin Richer <[email-masked]>
Date: Fri, 27 Mar 2015 13:07:09 -0500

I believe an implementers note is appropriate here.

-- Justin
/ Sent from my phone /

-------- Original message --------
From: Brian Campbell <[email-masked]> 
Date: 03/27/2015  12:15 PM  (GMT-06:00) 
To: Mike Jones <[email-masked]> 
Cc: [email-masked], Vladimir Dzhuvinov <[email-masked]> 
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5) 

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-masked]> wrote:

Thanks a bunch, Vladimir.  That definitively answers the question.
 
                                                            -- Mike

From: jose [mailto:[email-masked]]
On Behalf Of Vladimir Dzhuvinov

Sent: Friday, March 27, 2015 9:36 AM

To: [email-masked]

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-masked]
<mailto:[email-masked]>> 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-masked]
<mailto:[email-masked]>] *On Behalf Of *Mike Jones

    *Sent:* Friday, June 20, 2014 7:03 PM 

    *To:* Shaun Cooley (shcooley) 

    *Cc:* [email-masked] 
<mailto:[email-masked]>; 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-masked]] *On Behalf Of *Mike Jones

    *Sent:* Friday, June 13, 2014 2:27 PM 

    *To:* Shaun Cooley (shcooley) 

    *Cc:* [email-masked] 
<mailto:[email-masked]>; 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-masked]]

    *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-masked] 
<mailto:[email-masked]> 

    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-masked] 
<mailto:[email-masked]> 

    https://www.ietf.org/mailman/listinfo/jose

_______________________________________________ 

jose mailing list 

[email-masked] 

https://www.ietf.org/mailman/listinfo/jose

_______________________________________________ 

jose mailing list 

[email-masked] 

https://www.ietf.org/mailman/listinfo/jose

-- 
Vladimir Dzhuvinov :: [email-masked]

_______________________________________________

jose mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/jose