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

From: Mike Jones <[email-masked]>
Date: Thu, 26 Mar 2015 23:41:18 +0000

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-masked]] On Behalf Of Mike Jones
Sent: Friday, June 20, 2014 7:03 PM
To: Shaun Cooley (shcooley)
Cc: [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
Mobile: +1 310 293 2087

[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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 26 Mar 2015 19:31:56 -0500

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-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
>
> 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
> :
>
> *From:* jose [mailto:[email-masked]] *On Behalf Of *Mike Jones
> *Sent:* Friday, June 20, 2014 7:03 PM
> *To:* Shaun Cooley (shcooley)
> *Cc:* [email-masked]; Matt Miller (mamille2)
> *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2
> (PKCS #5)
>
>
>
>                                                             Thanks again,
> Shaun,
> *From:* jose [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Mike Jones
> *Sent:* Friday, June 13, 2014 2:27 PM
> *To:* Shaun Cooley (shcooley)
> *Cc:* [email-masked]; Matt Miller (mamille2)
> *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2
> (PKCS #5)
>
>
>
> I believe you’re right.  I’ll plan to make this change in the next version
> of the spec.
>
>
>
> *From:* Shaun Cooley (shcooley) [mailto:[email-masked]
> <[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:
>
> 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*
> [email-masked]
> Phone: *+1 408 902 3344 <%2B1%20408%20902%203344>*
> Mobile: *+1 310 293 2087 <%2B1%20310%20293%202087>*
>
> 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.
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 27 Mar 2015 07:20:48 +0100

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
>     *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
>     *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]]
>     *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*
>     [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.____
>
>     http://www.cisco.com/web/about/doing_business/legal/cri/index.html____
>
>     __ __
>
>     __ __
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Shaun Cooley (shcooley)" <[email-masked]>
Date: Fri, 27 Mar 2015 00:10:55 +0000

Agreed.

-Shaun

From: Mike Jones [mailto:[email-masked]]
Sent: Thursday, March 26, 2015 4:41 PM
To: [email-masked]; Matt Miller (mamille2)
Cc: Shaun Cooley (shcooley)
Subject: RE: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)

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.

                                                            Thanks all,
                                                            -- Mike

                                                            Thanks again, Shaun,
                                                            -- Mike

I believe you’re right.  I’ll plan to make this change in the next version of the spec.

                                                            -- Mike

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?

Thoughts?

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 27 Mar 2015 16:36:29 +0200

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:
>> string.
>> 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
>> 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____
>>
>>     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.____
>>
>>     __ __
>>
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____
>>
>>
>>                                                                  --
>> Mike____
>>     *From:*jose [mailto:[email-masked]
>> <mailto:[email-masked]>] *On Behalf Of *Mike Jones
>>                                                                  --
>> Mike____
>>                                                                  --
>> Mike____
>>       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?____
>>
>>     __ __
>>
>>     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*
>>     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.____
>>

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Fri, 27 Mar 2015 14:42:01 +0000

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".

NoSuchAlgorithmException: Cannot find any provider supporting AES/CBC/PKCS7Padding

Vladimir

Anders

On Mar 26, 2015 6:41 PM, "Mike Jones" <[email-masked]<mailto:[email-masked]> <mailto:[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____

                    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.____

    __ __

    __ __

    __ __

    __ __

                                                                 Thanks all,____

                                                                 -- Mike____

    __ __

    *From:*jose [mailto:[email-masked] <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]> <mailto:[email-masked]><mailto:[email-masked]>; Matt Miller (mamille2)
    *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)____

    __ __

    __ __

                                                                 Thanks again, Shaun,____

                                                                 -- Mike____

    __ __

    *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>; Matt Miller (mamille2)

    __ __

    __ __

    I believe you're right.  I'll plan to make this change in the next version of the spec.____

    __ __

    __ __

                                                                 -- Mike____

    __ __

    __ __

    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:____

    __ __

    PKCS #7 - RFC2315 section 10.3 note 2 specifies:____

    __ __

    __ __

    Thoughts?____

    __ __

    *Shaun Cooley*
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

    http://www.cisco.com/web/europe/images/email/signature/logo05.jpg
    Cisco.com <http://www.cisco.com/><http://www.cisco.com/>____

    __ __

    __ __

    __ __

    _______________________________________________
    jose mailing list
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

--

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 27 Mar 2015 12:15:14 -0500

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:

> *From:* jose [mailto:[email-masked]] *On Behalf Of *Vladimir
> Dzhuvinov
> *Sent:* Friday, March 27, 2015 9:36 AM
> *To:* [email-masked]
> <mailto:[email-masked]> <[email-masked]>>
> wrote:
>
> that this string appears for the JCA value of three algorithms:____
>
>                     AES/CBC/PKCS5Padding____
>
> described in this thread. JAVA IMPLEMENTERS– If you are currently using
> 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.____
>
>     __ __
>
>                                                                  Thanks
> all,____
>     *From:*jose [mailto:[email-masked] <[email-masked]>
> <mailto:[email-masked]> <[email-masked]>] *On Behalf Of
> *Mike Jones
>     *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]>; Matt
> Miller (mamille2)
>                                                                  Thanks
> again, Shaun,____
>     *From:*jose [mailto:[email-masked] <[email-masked]>]
> *On Behalf Of *Mike Jones
>     *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked]>; Matt
> Miller (mamille2)
>     *From:*Shaun Cooley (shcooley) [mailto:[email-masked]
> <[email-masked]>]
>       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?____
>
>     __ __
>
> 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*
>     [email-masked] <mailto:[email-masked]> <[email-masked]>
>     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>>*____
>
>
>
>     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.____
>
>     [email-masked] <mailto:[email-masked]> <[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Fri, 27 Mar 2015 17:19:12 +0000

If an implementer tries AES/CBC/PKCS7Padding and it fails, the situation is self-correcting.  They’ll change to using what’s in the table, even though it may seem odd.  Given the RFC Editor has already done the editing and the doc is in final internal review state, I’d say that less is more at this point.

From: Brian Campbell [mailto:[email-masked]]
Sent: Friday, March 27, 2015 12:15 PM
To: Mike Jones
Cc: 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]<mailto:[email-masked]>> wrote:
Thanks a bunch, Vladimir.  That definitively answers the question.

                                                            -- Mike

From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, March 27, 2015 9:36 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] draft-ietf-jose-json-web-algorithms-27: section-5.2 (PKCS #5)

Vladimir

Anders

                    AES/CBC/PKCS5Padding____

                    AES/CBC/PKCS7Padding____

    __ __

    __ __

    __ __

    __ __

    __ __

                                                                 Thanks all,____

                                                                 -- Mike____

    __ __

    __ __

    __ __

                                                                 Thanks again, Shaun,____

                                                                 -- Mike____

    __ __

    __ __

    __ __

    __ __

    __ __

                                                                 -- Mike____

    __ __

    __ __

    Michael –____

    __ __

    __ __

    __ __

    __ __

    Thoughts?____

    __ __

    *Shaun Cooley*
    DISTINGUISHED ENGINEER.ENGINEERING
    Collaboration Technology Group
    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>
    Phone: *+1 408 902 3344<tel:%2B1%20408%20902%203344> <tel:%2B1%20408%20902%203344>*
    Mobile: *+1 310 293 2087<tel:%2B1%20310%20293%202087> <tel:%2B1%20310%20293%202087>*____

    __ __

    __ __

    __ __

--