Re: [jose] Feedback request on jose tracker issue#11: Should we use RFC 5116 and remove the JWE Integrity Value field?

[John Bradley <[e-mail]>]

Richard,

I don't understand your comment about merging the IV. 

To be clear I am asking to keep the current serialization with separate elements for Ciphertext, Initialization Vector, and Integrity Value.

I think there is some confusion around a subtle difference between RFC 5116 and draft-mcgrew-aead-aes-cbc-hmac-sha2.(Or perhaps it is just me:)

RFC 5116 has a nonce as a separate input and output I am fine with that, however it also implicitly assumes that T (Tag) is a fixed length value concatenated to the end of the cypher-text.   I am opposed to binary concatenation of the values.

draft-mcgrew goes a step further than  RFC 5116 where it basically fakes out the RFC 5116 interface by specifying the use of a zero length nonce (Sec 2.1)  It then creates a random IV  that is included as a prefix to the cypher-text (Sec 2.1-4 & 2.2-4).

By listing the IV as one of the elements that would be affected by the change some people may be thinking that the poll question also includes changing the serialization of the IV.

I am however OK with having the underlying library produce the IV as long as it provides that as an output to JWE.

As a matter of principal I prefer separating the crypto from the serialization.

Perhaps I am over thinking the question and my answer is 1.

John B.

On 2013-04-16, at 11:24 AM, Richard Barnes <[e-mail]> wrote:

> I'm confused.  This is not about the IV == Initialization Vector, it's about the JWE Integrity Value (inconveniently also "IV").  I don't think anyone has proposed merging in the initialization vector, both because that's not what RFC 5116 does and because it's a terrible idea :)
> 
> 
> On Mon, Apr 15, 2013 at 2:41 PM, John Bradley <[e-mail]> wrote:
> 1 ish.
> 
> Representing the nonce/IV separately should not preclude using a crypto library generated nonce/IV , as may be done in some libraries implementing  draft-mcgrew-aead-aes-cbc-hmac-sha2.
> 
> So I am in favour of the current serialization while wanting to support the crypto from  draft-mcgrew-aead-aes-cbc-hmac-sha2 if not the particular serialization which is optimized for a different use-case.   The current draft-mcgrew-aead-aes-cbc-hmac-sha2 conflates crypto and serialization.  I am hoping we can resolve that so the crypto can be supported.
> 
> John B.
> 
> On 2013-04-11, at 8:58 PM, Karen O'Donoghue <[e-mail]> wrote:
> 
>> Issue #11 http://trac.tools.ietf.org/wg/jose/trac/ticket/11 proposes restructuring the JWE representation to remove the JWE Integrity Value field and instead use the RFC 5116 (AEAD) binary serialization to represent the Ciphertext, Initialization Vector, and Integrity Value values.  If this proposal is adopted, JWEs would then have three fields – the header, the encrypted key, and the RFC 5116 combination of the Ciphertext, Initialization Vector, and Integrity Value values. 
>> This issue is also related to issue #3.  Note that the updated McGrew draft described there could be used whether or not we switched to using RFC 5116.
>>  
>> 
>> Which of these best describes your preferences on this issue?
>> 
>> 1.  Continue having separate Ciphertext, Initialization Vector, and Integrity Value values in the JWE representation.
>> 
>> 2.  Switch to using the RFC 5116 (AEAD) serialization to represent the combination of these three values.
>> 
>> 3.  Another resolution (please specify in detail).
>> 
>> 0.  I need more information to decide.
>> 
>>  
>> Your reply is requested by Friday, April 19th or earlier. 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
> 
>