Subject: [jose] #14: Support longer wrapped keys than OAEP allows

From: "jose issue tracker" <[email-masked]>
Date: Mon, 18 Mar 2013 23:23:27 -0000

#14: Support longer wrapped keys than OAEP allows

 The use of RSA-OAEP for key wrapping imposes a limit on the length of the
 key package being wrapped. With SHA1, this length is N-320, where N is the
 length of the RSA modulus.  Especially with larger hash functions, and
 especially for wrapping private keys, the size of key packages will be
 larger than this bound.  We should incorporate a mechanism to accommodate
 these situations.

-- 
-------------------------------------+-------------------------------------
 Reporter:  [email-masked]               |      Owner:  draft-barnes-jose-use-
     Type:  defect                   |  [email-masked]
 Priority:  major                    |     Status:  new
Component:  draft-barnes-jose-use-   |  Milestone:
  cases                              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Mon, 18 Mar 2013 23:23:55 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => draft-ietf-jose-
     [email-masked]
 * component:  draft-barnes-jose-use-cases => json-web-encryption

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |       Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |      Status:  new
Component:  json-web-    |   Milestone:
  encryption             |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 19 Mar 2013 11:16:42 +1100

Richard,

How do you get a 788-bit key length?

draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-128/192/256 and SHA-1/256/384/512. The total key lengths range from 256 bits to 512 bits.

Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key.

Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. JWA already says RSA key sizes MUST be at least 2048 bits.

This already looks sufficient.
 
--
James Manger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
> Sent: Tuesday, 19 March 2013 10:25 AM
> Subject: [jose] WebCrypto feedback on key wrapping
>
> 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.
>
> 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.
>
> --Richard

>> ----------
>> Sent: Tuesday, 19 March 2013 10:23 AM
>> Subject: [jose] #14: Support longer wrapped keys than OAEP allows
>> 
>>  The use of RSA-OAEP for key wrapping imposes a limit on the length of
>>  the key package being wrapped. With SHA1, this length is N-320, where
>>  N is the length of the RSA modulus.  Especially with larger hash
>>  functions, and especially for wrapping private keys, the size of key
>>  packages will be larger than this bound.  We should incorporate a
>>  mechanism to accommodate these situations.
>> 
>>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Mar 2013 17:40:01 -0700

Think in terms of encrypting a JWK directly not an intermediate key.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Manger, James H
> Sent: Monday, March 18, 2013 5:17 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows
> 
> Richard,
> 
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The total key lengths range from 256
> bits to 512 bits.
> 
> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key.
> 
> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key.
JWA
> already says RSA key sizes MUST be at least 2048 bits.
> 
> > 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.
> >
> > 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.
> >>  The use of RSA-OAEP for key wrapping imposes a limit on the length
> >> of  the key package being wrapped. With SHA1, this length is N-320,
> >> where  N is the length of the RSA modulus.  Especially with larger
> >> hash  functions, and especially for wrapping private keys, the size
> >> of key  packages will be larger than this bound.  We should
> >> incorporate a  mechanism to accommodate these situations.
> >>
> >>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Mar 2013 22:35:38 -0400

Well, I got to 788 by doing math incorrectly*.

Mike was correct on the other thread that 768 is the right number.
 However, that's still too big for a 1024-bit RSA key and SHA1, since 768 +
320 = 1088 > 1024.

Regardless, there is clearly an issue here when wrapping a JWK, which is
much larger, possibly containing an RSA key itself.  So if we accept the
goal that there should be one way of encrypting keys, then we'll need to
deal with getting around the OAEP size limitations.

--Richard

* This is why my degree is in mathematics, and not accounting.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 19 Mar 2013 14:23:47 +1100

768 is also the wrong number, which is another reason to use draft-mcgrew-aead-aes-cbc-hmac-sha2 instead of the JOSE-specific AEAD construction (better key size choices). But that isn’t the main issue.

> So if we accept the goal that there should be one way of encrypting keys

Having one way of encrypting ephemeral raw symmetric session keys sounds like a decent goal.
I’m far from certain that extending that to asymmetric keys and their metadata (such as certs) is a sensible goal.

--
James Manger

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, 19 March 2013 1:36 PM
To: Jim Schaad
Cc: Manger, James H; [email-masked]
Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows

Mike was correct on the other thread that 768 is the right number.  However, that's still too big for a 1024-bit RSA key and SHA1, since 768 + 320 = 1088 > 1024.

Regardless, there is clearly an issue here when wrapping a JWK, which is much larger, possibly containing an RSA key itself.  So if we accept the goal that there should be one way of encrypting keys, then we'll need to deal with getting around the OAEP size limitations.

--Richard

On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Think in terms of encrypting a JWK directly not an intermediate key.

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Manger, James H
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
JWA
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of Richard Barnes
wrapped
carry
RSA-
is
we
encrypted
best
inside
> [email-masked]<mailto:[email-masked]>

---

From: "jose issue tracker" <[email-masked]>
Date: Sat, 30 Mar 2013 22:13:42 -0000

Comment (by [email-masked]):

 As pointed out by James Manger in http://www.ietf.org/mail-
 archive/web/jose/current/msg01853.html, "Keys for all of the algorithms
 fit within OAEP with a 2048-bit RSA key. JWA already says RSA key sizes
 MUST be at least 2048 bits.

 This already looks sufficient."

 I agree with James that I know of no use case where this limit will be hit
 in practice.  However it could be that Richard is thinking of encrypting
 JWKs, rather than wrapping keys, in which case we already have a solution
 in the form of draft-miller-jose-jwe-protected-jwk.  Also, see my comments
 at http://trac.tools.ietf.org/wg/jose/trac/ticket/13#comment:2 on the
 desirability of distinguishing between (1) Encrypting the ephemeral
 symmetric key value used within a JWE and (2) encrypting a JWK or JWK Set
 containing symmetric and/or private key information and potentially other
 key attributes, enabling the encrypted JWK or JWK Set to be safely stored
 or transported.

 Finally, as Matt Miller wrote in http://www.ietf.org/mail-
 archive/web/jose/current/msg01863.html, "Personally, I don't think it's
 worth discussing this much further without a more complete counter-
 proposal on the table."  I agree that a concrete set of proposed changes
 would be needed to make this actionable.

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14#comment:2>
jose <http://tools.ietf.org/jose/>