I believe an implementers note is appropriate here.
-- Justin
/ Sent from my phone /
-------- Original message --------
From: Brian Campbell <[email protected]>
Date: 03/27/2015 12:15 PM (GMT-06:00)
To: Mike Jones <[email protected]>
Cc: [email protected], Vladimir Dzhuvinov <[email protected]>
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 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]>> 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
--
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
