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

+1


2013/3/19 Mike Jones <Michael.Jones@microsoft.com>

>  I completely agree that documenting the engineering tradeoffs is in
> scope and a worthwhile exercise.  The point of my message was simply that
> we needn’t “accept the goal that there should be one way of encrypting
> keys” without doing this analysis.****
>
> ** **
>
> I think Matt Miller had it right when he wrote this morning “Personally,
> I don't think it's worth discussing this much further without a more
> complete counter-proposal on the table”.  Should a concrete
> counter-proposal to Matt’s draft be written, at that point we could have a
> much more concrete discussion.****
>
> ** **
>
>                                                                 Cheers,***
> *
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Jim Schaad [mailto:ietf@augustcellars.com]
> *Sent:* Tuesday, March 19, 2013 8:17 AM
> *To:* Mike Jones; 'Richard Barnes'
>
> *Cc:* 'James H Manger'; jose@ietf.org
> *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows***
> *
>
>  ** **
>
> <personal>****
>
> ** **
>
> The issue has been raised for discussion.  I do not believe that
> documenting what the extents of the issue are is out of scope of any and
> all follow on discussion.  Until that has been done it is not possible to
> talk about what the costs and benefits are.  If you have a full set of
> costs and benefits that would be an interesting message to see.****
>
> ** **
>
> *From:* Mike Jones [mailto:Michael.Jones@microsoft.com<Michael.Jones@microsoft.com>]
>
> *Sent:* Monday, March 18, 2013 8:24 PM
> *To:* Jim Schaad; Richard Barnes
> *Cc:* James H Manger; jose@ietf.org
> *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows***
> *
>
> ** **
>
> Since you message appears to take it as given that “there should be only
> one way of encrypting keys”, I’ll point out that I don’t think that it’s
> reasonable to assume that.  JOSE is first and foremost an engineering
> exercise, where the cost/benefit generality/complexity tradeoffs matter,
> and the goal is a ubiquitously implemented crypto format for the Web that
> solves the problems that people actually have, rather than a mathematical
> exercise, where the goal is completeness and generality.  Complexity is the
> enemy of adoption.****
>
>  ****
>
> So it’s fair game to ask “What are the costs and benefits of having only
> one way to encrypt keys”, versus taking that as a given.****
>
>  ****
>
> I happen to personally believe that encrypting a bare symmetric
> ephemeral Content Master Key is sufficiently different than encrypting a
> key that may be public, private, or symmetric and may have additional
> attributes, that it’s at least worth asking the engineering question
> whether special-casing the encryption of this bare symmetric ephemeral key
> results in engineering benefits.****
>
>  ****
>
> Encrypting a key with attributes for storage or dissemination is not the
> same kind of operation as wrapping an ephemeral symmetric key to be used
> for block encryption.  I’m personally fine with this being done
> differently.  The engineering benefit if we do it differently in the way
> that Matt’s draft proposed, at least as I see it, is that we have to invent
> nothing new.  We already have a great format for encrypting arbitrary data,
> and keys with attributes are a whole lot like arbitrary data.****
>
>  ****
>
> I respect that some with disagree with my personal view, but I’d also ask
> you to respect that the engineering tradeoffs may favor having two ways to
> do things that on the surface may seem similar, but are actually fairly
> different in nature.****
>
>  ****
>
> Best wishes,****
>
> -- Mike****
>
>  ****
>
> *From:* Richard Barnes
> *Sent:* March 18, 2013 7:36 PM
> *To:* Jim Schaad
> *CC:* Manger, James H, jose@ietf.org
> *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows***
> *
>
>  ****
>
> 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.****
>
> On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:****
>
> Think in terms of encrypting a JWK directly not an intermediate key.****
>
>
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of*
> ***
>
> > Manger, James H
> > Sent: Monday, March 18, 2013 5:17 PM
> > To: rlb@ipv.sx; jose@ietf.org
> > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows
> >
> > 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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] 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
> > >>
> > >> #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.
> > >>
> > >>
> > >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14>****
>
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>