Re: [jose] WebCrypto feedback on key wrapping

[Richard Barnes <[e-mail]>]

I don't disagree that the minimum size is a good thing for implementors to
do.  I just don't think that that restriction is necessary in a formatting
document like JW*, since it has no impact on interoperability.  At most, it
should be RECOMMENDED in the security considerations.  It should not be a
MUST.

--Richard


On Mon, Mar 18, 2013 at 11:28 PM, Mike Jones <[e-mail]>wrote:

>  I believe that the 2048 restriction was motivated by a NIST evaluation
> on acceptable key lengths in which the use of 1024 bit RSA keys has already
> been deprecated.  Eric Rescorla’s presentation to the working group several
> IETFs ago specifically recommended this, as well as the other key size
> restrictions in JWA.
>
> At the time, the working group felt that requiring that people use keys of
> acceptable lengths for the current cryptographic client for new
> applications was a good thing - especially since JWS and JWE have no legacy
> applications to support.
>
> -- Mike
>
>  *From:* Richard Barnes
> *Sent:* March 18, 2013 7:31 PM
> *To:* Mike Jones
> *CC:* [e-mail]
> *Subject:* Re: [jose] WebCrypto feedback on key wrapping
>
> ISSUE-(n+1): Remove silly restriction on key sizes.  We're a formatting
> working group, not a crypto parameters working group.
>
>  --Richard
>
>
> On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones <[e-mail]>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.****
>>
>> ** **
>>
>>                                                                 -- Mike**
>> **
>>
>> ** **
>>
>> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
>> Of *Richard Barnes
>> *Sent:* Monday, March 18, 2013 4:25 PM
>> *To:* [e-mail]
>> *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****
>>
>
>