Re: Meeting today: Agenda for Telecon Monday May 6th 20:00 GMT

On Mon, May 6, 2013 at 9:34 AM, Ryan Sleevi <sleevi@google.com> wrote:

> 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.


Sorry - maybe I worded the conclusion above with a slant that was not
intended. What I mean by (1) is just that JWE-wrapped JWK was chosen
because it was convenient and had already benefited from some study (in
JOSE).


> 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.
>

Hmm. Re-check the thread. Apologies if I gave the opposite impression, but
I was not arguing necessity for JWE-wrapped JWK.

What I did point out was that the existing JWE-wrapped JWK could not be
implemented using modified format-agnostic wrap/unwrap primitives, but only
due to a number of technicalities, not due to any fundamental design or
security reason.

The format issue can be decoupled from the bigger question of the security
rationalle for wrap/unwrap or more generally hiding keys from the JS.


>
> >>
> >> 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?
> >> >>
> >> >>
> >> >>
> >> >
> >
> >
>