<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
