That is not the experience that we have seen with TLS. In this case people want to constantly register the entire matrix of items. I would not expect that desire to change.
Jim From: Mike Jones [mailto:[email protected]] Sent: Wednesday, June 26, 2013 9:01 PM To: Jim Schaad; [email protected] Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping 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:[email protected]] Sent: Wednesday, June 26, 2013 8:18 PM To: Mike Jones; [email protected] 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:[email protected]] Sent: Wednesday, June 26, 2013 12:22 PM To: Jim Schaad; [email protected] 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: [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] 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]] On Behalf Of Jim Schaad Sent: Tuesday, June 25, 2013 9:53 AM To: [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
