Re: [jose] Issue #13 - use AES-GCM for Key Wrapping

[Breno de Medeiros <[e-mail]>]

I also don't believe that supporting the matrix of possible
algorithmic combinations satisfies any business need.

On Wed, Jun 26, 2013 at 9:01 PM, Mike Jones <[e-mail]> wrote:
> For my part, I consider the fact that people will need to register specific
> algorithm combinations that they actually need to be a feature – not a bug.
> The smaller the set of algorithm combinations registered, the more likely
> that they will be implemented and will interoperate.  Trying to claim that
> we support the combinatorial explosion of mask generation functions, hash
> functions, key derivation functions, key wrapping functions, etc. that are
> possible will almost certainly result in less interoperability and more
> developer confusion than a small set of registered choices, carefully
> considered.  I’m glad to have people consider these criteria in their
> evaluation of the two choices.
>
>
>
>
> -- Mike
>
>
>
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 8:18 PM
> To: Mike Jones; [e-mail]
>
>
> Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping
>
>
>
> My point was that there were some issues that your draft did not fully
> address that need to be evaluated as part of your proposal not that these
> algorithms would need to be added.  The n x m addition of algorithms to the
> registry is an issue that is there for your draft that is not present for
> Richard’s draft and therefore needs to be considered in the arguments.
>
>
>
> From: Mike Jones [mailto:[e-mail]]
> Sent: Wednesday, June 26, 2013 12:22 PM
> To: Jim Schaad; [e-mail]
> Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping
>
>
>
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Jim
> Schaad
> Sent: Wednesday, June 26, 2013 11:30 AM
> To: Mike Jones; [e-mail]
> 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:[e-mail]]
> Sent: Tuesday, June 25, 2013 4:18 PM
> To: 'Jim Schaad'; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Jim
> Schaad
> Sent: Tuesday, June 25, 2013 9:53 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>



-- 
--Breno