I have several problems with moving the IV and/or the tag into the ciphertext field.
1. I am firmly of the belief that one needs to be able to have key management on the key used in the MAC processing. At the present time, this can only be done by defining a new algorithm that will be a null encryption with authentication algorithm. This would play havoc if you wanted to do detached content as all the applications would need to know about the IV and authentication tags that are attached to the content rather than having them be separate from the content. I realize that this is a minority viewpoint. 2. This should only be an issue for the simple dot version of the encoding; if you do the multiple recipient versions then the second layer of base64 application should not be required. Thus no double encoding. Again a minority viewpoint. 3. This does not solve the same problem for all of the other binary fields that can occur in headers. As compactness in the dot encoded format is supposed to be a requirement, this this problem needs to be addressed for ALL possible binary fields. An example of a much larger binary field would be the ephemeral DH key. While the group does not agree with me on the first two issues, I think that it should respect the last one. One possible solution is to use the current second dot field as a binary dump rather than for a single purpose. One would then add a new header for the wrapped key and specify an offset and a length for any binary data blob which occurs in that binary data field. Another would be to allow for multiple binary blobs and just provide the index of the blob that contains the data in question. Jim From: [email protected] [mailto:[email protected]] On Behalf Of Manger, James H Sent: Sunday, July 29, 2012 6:50 PM To: [email protected] Subject: Re: [jose] Open Issue: Representing the JWE IV as a dot-separated element Make the IV a prefix of the ciphertext and you save another couple of bytes. Plus the IV length would no longer be defined twice (firstly by the alg definition; secondly by the length of the IV field in the message), which avoids a potential inconsistency. While we are doing that, may as well make the AEAD authentication tag a suffix of the ciphertext. -- James Manger From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Saturday, 28 July 2012 8:49 AM To: [email protected] Subject: [jose] Open Issue: Representing the JWE IV as a dot-separated element All the JWE block encryption algorithms we’re using require an Initialization Vector. I’d originally put the IV in the JWE header because I thought it would be optional, but in practice, it’s not. As a result, we’re always double base64url encoding required content. I did an investigation and we could save 15 characters in the GCM example at http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.1 and 17 characters in the CBC example at http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.2 if we were to represent the IV as another dot-separated element rather than putting it in the header and double base64url encoding it. Since size matters a lot in some use cases, we should consider whether to do this. I’ll add it to the open issues list for us to discuss in Vancouver. -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
