<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
