[jose] Use of AES-HMAC algorithm

["Jim Schaad" <[e-mail]>]

<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