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
