Yes, we could also propose algorithm combinations for key agreement followed
GCM key wrapping but I didn't think that was an ask from the working group.
The Denver minutes just recorded my action item as "key wrap draft for
AES-GCM-keywrap", so that's what I did. We could have a discussion on Monday's
call and on the list about whether the working group is also interested in
other algorithms.
Remember, the beauty of having the algorithms registry is that algorithms can
be added "just in time" - as actual need for them is demonstrated. We don't
have to register all conceivable algorithm combinations up front for the
JWE/JWA specs to be complete.
As for how the AEAD parameters are handled I used a parameter encoding that
doesn't result in double base64url encoding anything. I could have instead
introduced separate "iv" and "tag" header parameter values, but didn't do so
for that reason. But if people would prefer that approach because it's more
parallel to the use of GCM for plaintext encryption, I have no problem with
that.
I do believe that the objective of my draft was met - demonstrating that AEAD
key wrapping can be easily done with the current drafts. The details of how
the algorithm parameters are encoded is secondary to that and
algorithm-specific; several reasonable choices are possible within the current
JWE framework - one of which was described in my draft.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Jim
Schaad
Sent: Wednesday, June 26, 2013 11:30 AM
To: Mike Jones; [email protected]
Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping
<no hat>
<sarcasm level="heavy">
I am shocked that you would possibly support this proposal. It provides for
two ways of dealing with something. It is my understanding that you never
support anything that has two ways of doing something.
How the AEAD algorithm parameters is handled completely differently for this
proposal and for the same algorithms being used in a CEK context. This is
going to lead to confusion.
</sarcasm>
Your specification is missing some items that still need to be registered Thus
you also need to have ECDH-ES+A128GCMKW and ECDH-ES+A256GCMKW defined in your
document as well.
Your document ends up with a registration complexity that needs to be thought
about and dealt with as well. For every new key wrap algorithm added, you will
need to register not only it alone but also it with every different key
agreement algorithm that is supported. Thus adding a single key wrap algorithm
becomes a slight issue in terms of adding in all of the different ways that it
might be used. This is a complexity issue that is not discussed in the current
draft.
I have not necessarily found that document size equals code size. I have
implemented some very simple documents that were very difficult to code and
implemented some very long documents that were very easy to code. So I would
not use that fact as a deciding factor.
(Once again I regret the fact that the group did not go with an object
descriptor for algorithms as this would have made all of this much simpler. I
actually immediately map from the string to an object description in my JOSE
implementation for simplicity reasons. Not to mention that this is way it
needs to be done for the WebCrypto specficiation.)
Jim
From: Mike Jones [mailto:[email protected]]
Sent: Tuesday, June 25, 2013 4:18 PM
To: 'Jim Schaad'; [email protected]<mailto:[email protected]>
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping
http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 seems like a
substantially simpler approach than
http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01. This is evident
by several metrics:
* Number of proposed changes: The Jones draft proposes no changes to
any of the current specs. It simply defines an encoding for GCM and adds
registry entries for it. Whereas the Barnes draft proposes a major
restructuring - listing 4 major changes in the introduction and 4 smaller
changes.
* Normative text size: The Jones GCM key wrap approach requires only 7
normative sentences in 1/2 page of text. The Barnes draft has four pages of
normative text, along with an extensive introduction describing the proposed
complete restructuring of JWS and JWE.
We don't need to boil the ocean with a total redesign to enable AEAD key
wrapping. It can already easily be done with the current specs simply by
defining new algorithms. The approach taken in
http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 would work for
any AEAD algorithm.
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Tuesday, June 25, 2013 9:53 AM
To: [email protected]<mailto:[email protected]>
Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping
We now have two documents - one from Richard and one from Mike - which provide
the two different ways that have been proposed for doing key wrapping with an
AEAD algorithm.
Please review the two documents and provide comments to the list.
Jim
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
