Subject: [jose] JWA replicating mcgrew-aead-aes-cbc-hmac-sha2

From: "Manger, James H" <[email-masked]>
Date: Mon, 29 Apr 2013 01:03:25 +1000

JOSE is at last using draft-mcgrew-aead-aes-cbc-hmac-sha2, but why is so much duplicated in JWA instead of referenced? JOSE should have 1 sentence saying:

  The JOSE "alg" strings "A128CBC-HS256" and "A256CBC-HS512" correspond to the AEAD_AES_128_CBC_HMAC_SHA_256 and AEAD_AES_256_CBC_HMAC_SHA_512 algorithms defined in [I-D.mcgrew-aead-aes-cbc-hmac-sha2].

That should be enough. Drop the other 4 pages of JWA on this.

If we really insist on breaking the RFC 5116 AEAD model, add 1 more paragraph.

  In [I-D.mcgrew-aead-aes-cbc-hmac-sha2] the ciphertext includes the CBC initialization vector as a prefix and the truncated HMAC as a suffix. In a JOSE these two fields are separated from the ciphertext and treated as the JWE Nonce and JWE Authentication Tag respectively. The JWE Ciphertext is the remaining ciphertext (ie minus the prefix and suffix).

Why does JWA duplicate test cases for AES_CBC_HMAC_SHA2 (Appendix C) that will be in draft-mcgrew-aead-aes-cbc-hmac-sha2? The test cases are not even JOSE messages. I hope this is a temporary addition pending the publication of draft-mcgrew-aead-aes-cbc-hmac-sha2-02 (with the test cases).

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 May 2013 06:35:55 +0000

Hi James,

The text was duplicated so that there would be a complete description of the new algorithms, including test cases for implementers, in time for the interim JOSE working group meeting held the last two days.

Once the McGrew draft has been refactored to separate the description of the calculation steps (which JOSE is using) from the AEAD representation steps (which JOSE is not using), and to include test vector values that show results without performing the AEAD representation concatenations, I agree that we'll be able to just reference it, rather than duplicating it.

(I have no objection to the McGrew draft also describing the additional AEAD representation steps and including additional test result values that combine the outputs in the AEAD manner for implementations that choose to use that encoding - indeed, I agree that there's value in doing so for some use cases - they just need to be factored out, because they're separable from the cryptographic algorithm itself.)

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Sunday, April 28, 2013 8:03 AM
To: [email-masked]
Subject: [jose] JWA replicating mcgrew-aead-aes-cbc-hmac-sha2

--
James Manger
_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose