Agreed.

-Shaun

From: Mike Jones [mailto:[email protected]]
Sent: Thursday, March 26, 2015 4:41 PM
To: [email protected]; 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.

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]<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?

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to