- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 25 Mar 2013 07:51:47 -0700
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: Ryan Sleevi <sleevi@google.com>, "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
On Mar 23, 2013, at 2:41 PM, Richard Barnes wrote: > > On Mar 22, 2013, at 7:36 PM, Ryan Sleevi <sleevi@google.com> wrote: >> >> On Fri, Mar 22, 2013 at 4:21 PM, Mark Watson <watsonm@netflix.com> wrote: >> All, >> >> It occurred to me that support for key wrapping could be simplified if we made a blanket assumption that when unwrapping a key the resulting Key object always has extractable = false. >> >> This would avoid the need for a new JWK attribute indicating extractability. >> It would avoid the need for the unwrapKey method to have an extractable parameter. >> It would avoid the confusion that arises from having extractability defined both within the JWK and in the unwrapKey method. >> It would be simpler. >> >> I think this would make sense, because the act of wrapping a key and sending it to a script with access to WebCrypto is explicitly saying that you do not want the keying material to be visible except to whomever has the unwrapping key. >> >> Does anyone have a use-case where a key needs to be unwrapped into a Key which is then extractable ? >> >> …Mark >> >> >> -1. >> >> There are plenty of reasons to use key wrapping independent of extraction concerns. The most obvious one is key transport. > > +1 to Ryan, so another -1 to Mark. Ok, no problem. Just looking for opportunities for simplification, but this one obviously doesn't work. …Mark > > There's no guarantee that the thing you're sending the key to has any idea what "extractable" means, so it doesn't really make sense to require extractable=false. > > Shouldn't the wrapped key just have whatever attributes the key had? > > --Richard
Received on Monday, 25 March 2013 14:50:49 UTC