- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 6 May 2013 09:34:06 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Harry Halpin <hhalpin@w3.org>
On Mon, May 6, 2013 at 9:30 AM, Mark Watson <watsonm@netflix.com> wrote: > > > On Mon, May 6, 2013 at 9:21 AM, Ryan Sleevi <sleevi@google.com> wrote: >> >> >> On May 6, 2013 9:08 AM, "Mark Watson" <watsonm@netflix.com> wrote: >> > >> > >> > >> > On Mon, May 6, 2013 at 6:13 AM, Harry Halpin <hhalpin@w3.org> wrote: >> >> >> >> We'll be meeting today, same time and place as usual: >> >> >> >> +1.617.761.6200, 27978# (CRYPT) >> >> IRC irc.w3.org:6665 #crypto >> >> 20h GMT >> >> >> >> I'm filling in for Virginie writing this agenda - here's my take on >> >> high >> >> priority things to discuss, feel free to amend! >> >> >> >> 1) Futures examples and integration into editors draft - next public >> >> working draft? >> >> >> >> 2) new use-cases - scheduling folks time with Arun >> >> >> >> 3) Key wrap/unwrap integration as "feature at risk" >> > >> > >> > The issue Ryan and I have been discussing is whether there is ever any >> > security significance to the API boundary (between UA and JS). Or, put >> > another way, whether there is a reasonable use-case for never exposing keys >> > to the JS (in the absence of pre-provisioned keys). >> > >> > We've agreed to include key wrap/unwrap as a "feature at risk" (twice). >> > I don't think we should revisit the inclusion of that in the next editor's >> > draft. >> > >> > We do need to discuss the boundary topic, as that is a point of >> > significant disagreement which might affect what we do with wrap, unwrap and >> > other features in future. >> >> I think the format bears some discussion - how coupled is it to the >> security assumptions being made and how separable is JOSE, even with >> wrap/unwrap being included as at risk. > > The format can be decoupled. I think we bottomed that out on the list: > (1) technically, we could design our own format that would be just as good > as JOSE - except that we're starting a lot later than them > (2) the API could be factored so that the format is determined by the JS, > but with the same "never expose keys to JS" properties. That design couldn't > support the existing JOSE format due to various technicalities (which could > potentially be addressed). These conclusions certainly come as a surprise to me - and not what I took away from the other (ongoing) thread. I was not proposing we design our own format. Merely explore how much of the choice for JWE-wrapped JWK was done because it was necessary and how much was done because it was convenient. The point of necessity seems to be tied to the assumptions of security, which is why I don't think we've really reached a good place at all. >> >> That said, I feel like were making good progress on list on this, and >> don't know if its necessary yet to couple it to the call, given the >> technical subtleties of what we're discussing. > > We have a fundamental disagreement about whether hiding keys from the JS is > ever useful (absent pre-provisioned keys). I think that bears discussion. At > least we should surface that issue to the group in the form to which we have > distilled it, since not everyone follows the email threads to their bitter > ends ;-) Agreed. > > ...Mark >> >> > >> > ...Mark >> > >> >> >> >> >> >> 3) Next week, optional high-level API meeting >> >> >> >> 4) Inviting more review - for example, getting Dan Boneh et al. >> >> actually >> >> write down their critiques on mailing list. Dan Boneh offered to join a >> >> telecon - shall we aim for the next 2 week? >> >> >> >> >> >> >> > > >
Received on Monday, 6 May 2013 16:34:33 UTC