Yes, but at least as I see it, you wouldn't wrap a JWK with OAEP directly.
You'd encrypt an ephemeral symmetric key with OAEP and then use an
authenticated symmetric key encryption algorithm to encrypt the JWK. This is
exactly what a JWE does.
-- Mike
From: Mark Watson [mailto:[email protected]]
Sent: Tuesday, March 19, 2013 7:33 AM
To: Mike Jones
Cc: Richard Barnes; [email protected]
Subject: Re: [jose] WebCrypto feedback on key wrapping
On Mar 18, 2013, at 5:02 PM, Mike Jones wrote:
Given that we require RSA keys to be a minimum of 2048 bits in length, there's
no problem wrapping 768 bit keys with OAEP in practice.
Sure, but there would be a problem if what you are wrapping is a JWK object,
which could get much bigger than 768 bits.
...Mark
-- Mike
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Richard Barnes
Sent: Monday, March 18, 2013 4:25 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] WebCrypto feedback on key wrapping
On today's call with the W3C WebCrypto working group, I reported on the
discussion of JOSE key wrapping at the last IETF. I was asked to relay a few
bits of feedback:
1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of
favor with some parts of the cryptographic community. People prefer to be able
to use AEAD algorithms for key wrapping, since they are perceived to be faster
and offer a higher level of security than AES-KW. He gave the example that IEEE
802.1 uses AES CCM.
2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped
key objects, then we would need something other than OAEP in order to carry
arbitrary-length payloads. I agreed, and suggested that something like RSA-KEM
would be necessary. Ryan Sleevi (Google) and Vijay observed that KEM is
troublesome due to the lack of support by native crypto libraries.
It seems to me that these comments have impacts on JWE and JWS (pending
ISSUE-2), as well as the wrapping discussion. The former has more impact than
the latter.
Point number 1 implies that we should offer AEAD for key wrapping in JWE as
well as for wrapped keys. It seems to me that the simplest approach to this
would be to make the "alg" field contain an object that is semantically
equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name:
"A128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly the
same form that algorithm identifiers have in the WebCrypto API. Note that this
type of key wrapping is supported in CMS by the use of an AEAD
AlgorithmIdentifier in the KEKRecipientInfo structure.
Point number 2 likely applies for some scenarios of JWE, especially if we adopt
the McGrew approach. For example, if using HMAC-SHA1 and AES with a 256-bit
key, the total key length is 788 bits, which is too long to be encrypted with
OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. The best idea
I've got is to allow wrapped keys to nest, so that you can wrap a key inside of
another wrapped key.
I will try to take these points into account in my forthcoming key wrapping
draft, and I've filed two issues against JWE to track them.
--Richard
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
