+1 -- Vladimir Dzhuvinov : www.NimbusDS.com : [email protected]
-------- Original Message -------- Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request From: Mike Jones <[email protected]> Date: Fri, April 05, 2013 1:13 am To: Jim Schaad <[email protected]>, "[email protected]" <[email protected]> I'm in favor of the change. I believe that this equivalent to issue http://trac.tools.ietf.org/wg/jose/trac/ticket/3 - correct? -- Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Thursday, April 04, 2013 4:51 PM To: [email protected] Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request <chair> At the request of the editors, this is a formal consensus call on the first item in the list below. If there are objects to use a single long key rather than a KDF function for the AES-CBC/HMAC algorithm please speak up now. To date nobody has said that I was wrong to assume the consensus on that item. Call ends in one week. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:21 PM > To: [email protected] > Subject: [jose] Use of AES-HMAC algorithm > > <chair> > After spending time looking at and thinking about how to resolve this issue > since I was unable to do so at the last F2F meeting. I have come up > with the > following set of issues that might need to be addressed as part of resolving > this issue. > > 1. Do we change from using KDC to having a double size key for the > algorithm? I think that there is probably a consensus that this > should be done. > > 2. Should IVs be prepended to the encrypted body as part of the > encoding steps? If so then this change should be universal. > > Doing so would eliminate one field from all of the encoding formats > which should be considered a plus. > Doing so would force code writers to understand how large the IV is > for all > algorithms as the IV would no longer be a separate item. > > 3. Should Authentication Tags be appended to the encrypted body as > part of the encoding steps? > > Doing so would eliminate one field from all of the encoding formats > which should be considered a plus. > Doing so would force code writers to understand how large the IV is > for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case > as either all recipient specific data would need to be excluded from > the authentication step or all of the recipient data would need to be > included for > by all recipients. > Changing how the recipient info is process is going to give a > performance benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and different > authentication data needs to have CFRG look at it. I am worried that > it might > be a serious security flaw. > > 4. Should we reference the McGrew draft and provide text on how things > are changed or should we "copy" the draft into our text? > > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key > wrapping, does this change how we think about any of the above questions? > > Allowing for AES-GCM for key wrapping has a benefit for hardware situations > as only the encrypt and not the decrypt functions need to be placed in > hardware. However allowing for this key wrapping give a problem as > there is > no way to encode the three fields into the encrypted value unless with > use either a JSON structure in this location or we do use the single > appended binary output stream. The first approach leads to an > expansion of the field by > double base64 encoding which is highly undesirable. > > Jim > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
