Mike> (narrowing the discussion scope to only JWA 5.2 and draft-mcgrew-aead-aes-cbc-hmac-sha2)
Section 5.2 - The write up of this section seems a bit more complicated than necessary. It seems it would have just been simpler to state that the sizes vary as required by the algorithms and key lengths used rather than providing the differences from one to the next. Can you simplify this? After looking through some of the mailing list discussions, it seems there was already agreement to slim this and other sections down by pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2 http://www.ietf.org/mail-archive/web/jose/current/msg02276.html Can I get an update as to where that stands, referencing what you can from that draft as opposed to duplicating text? Thanks! Mike> Sure. The key part of the message you cited is “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.” The problem is that the refactoring was never done. The algorithm description in draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the ciphertext C, as described, also includes the IV value as a prefix and the authentication tag T as a suffix, rather than treating each of those as separate values. The test vectors do the same. Yes, David added appendix B saying that the values could be treated as separate, but the write-up does no favors to implementers, as both the core algorithm description and the test vectors assume they are combined. (I personally know that working out how to treat them as separate from David’s current draft is a tedious and error-prone exercise, having had to do so to tease them apart for the current JWA write-up.) David has been asked about doing the refactoring several times by multiple parties, but he’s a busy guy, and I don’t think it’s ever reached the top of his queue. As it is, the JWA description is clear and semantically equivalent and implementers have shown that they can successfully build it. Finally, we wouldn’t want to take a normative dependency upon a draft that appears to have been largely abandoned (or at least neglected), as doing so could indefinitely stall publication of RFC versions of the JOSE specs. [JLS] I always considered this to be a sufficient refactoring to use the mcgrew draft as a basis. I did not have the same type of problems with breaking the test vectors apart that you seem to have had. Mike> It’s not just the test vectors – a bigger source of confusion with the current draft-mcgrew-aead-aes-cbc-hmac-sha2 write-up is that he’s using terms such as “Ciphertext” in the main body of the document to mean something different than what it usually means. For instance, the document says: 6. The AEAD Ciphertext consists of the string S, with the string T appended to it. This Ciphertext is returned as the output of the AEAD encryption operation. Contrast this to NIST Special Publication 800-38D “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC”, which says: The following two bit strings comprise the output data of the authenticated encryption function: A ciphertext, denoted C, whose bit length is the same as that of the plaintext. An authentication tag, or tag, for short, denoted T. The JOSE documents use the terms “Ciphertext” and “Authentication Tag” in the same manner as the GCM doc (and many other crypto specs). There’s even more subtle problems. You’ll find that the “S” values in the test vectors also includes the Initialization Vector as a prefix, whereas the definition of “S” in the body of the draft is does not include this prefix: S = CBC-ENC(ENC_KEY, P || PS), That’s *very* likely to result in implementers getting it wrong. All of this is fixable. (If it becomes a blocking factor to completing JWA and JOSE, and David is willing, I’d even be willing to take a crack at producing an updated draft of draft-mcgrew-aead-aes-cbc-hmac-sha2 that fixes it, provided that there’s a clear path for making it a standards-track RFC in a timeframe that doesn’t significantly delay JOSE.) But I don’t think we can take a normative reference to it unless these things are in fact, fixed. I also don’t want us to take a normative dependency upon a draft without a similar timeline to becoming an RFC as the JOSE specs, which it doesn’t appear to be at present. Cheers, -- Mike P.S. This issue is tracked at http://trac.tools.ietf.org/wg/jose/trac/ticket/147.
_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
