Re: [Cfrg] [jose] Use of authenticated encryption for key wrapping

[John Bradley <[e-mail]>]

That is true.

However the main reason AES-GWC would be used is to allow transport of keys (RSA, EC and Symmetric)  that are intended for use outside the crypto module.

Where I agree, is that it is probably not such a good idea to start using AESKW on the message body just because that body contains a JWK with a private key.

I think that is where this particular question started.  Some people thought that only AES-KW was appropriate for encrypting keys.

My preference is to keep AES-KW for wrapping session keys,and not change to the newer version that would allow us to encrypt arbitrary length messages.

That at least still provides some additional protection for session keys in that the KW alg remains internal, so can not be used to expose session keys accidentally if that is what you are getting at.

Regards,
John B.

On 2013-03-15, at 2:42 PM, Russ Housley <[e-mail]> wrote:

> There are some system design issues to be considered.  The use of different modes for encryption of user data and keying material makes it easier to prevent the decryption of keying material outside of the crypto module.
> 
> Russ
> 
> 
> On Mar 15, 2013, at 11:42 AM, Brian Weis wrote:
> 
>> Jim Schaad gave a presentation on JOSE to CFRG today (<http://www.ietf.org/proceedings/86/slides/slides-86-cfrg-5.pdf>). The question came up as to whether AES key wrap was necessarily the only method that was safe for key wrapping in JOSE. The other algorithm under consideration is AES-GCM. 
>> 
>> Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says:
>> 
>> "Previously approved authenticated-encryption modes—as well as combinations of an approved encryption mode with an approved authentication method—are approved for the protection of cryptographic keys, in addition to general data."
>> 
>> So if one considers that to be good enough advice, AES-GCM would indeed be an acceptable method of key wrapping. The chairs asked me to cross-post this for discussion.
>> 
>> Brian
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg