[minutes] 15 October WebCrypto Call

Draft minutes from our call are at
http://www.w3.org/2012/10/15-crypto-minutes.html
and below.

Thanks to all who participated.

--Wendy

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

             Web Cryptography Working Group Teleconference

15 Oct 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/10/15-crypto-irc

Attendees

   Present
          +1.510.387.aaaa, +1.512.257.aabb, cjkula,
          +1.978.652.aacc, ddahl, +1.512.257.aadd, [Microsoft],
          +47.23.69.aaee, +1.415.294.aaff, wseltzer, arunranga,
          JimD, +1.408.540.aagg, virginie, markw, rsleevi?,
          haavardm, karen, +1.425.881.aahh, Tolga_Acar

   Regrets
          vgb, rbarnes, zooko, asad, sdurbha, wtc, hhalpin

   Chair
          virginie

   Scribe
          arunranga

Contents

     * [3]Topics
     * [4]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 15 October 2012

   <selfissued> Mike Jones

   rsleevi, I think the aaff is me

   <karen> aabb is Karen

   <scribe> ScribeNick: arunranga

   <virginie> [5]http://www.w3.org/2012/10/08-crypto-minutes.html

      [5] http://www.w3.org/2012/10/08-crypto-minutes.html

   <wseltzer> [Agenda:
   [6]http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct
   /0092.html ]

      [6]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0092.html

   VG: We've issued Crypto API as a FWPD. Now we are gathering
   comments from the industry.
   ... We've gotten some comments, but not enough. Harry Halpin
   has offered to write a blog post on the W3C blog.

   <rsleevi>
   [7]http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct
   /0097.html for Harry's updated security considerations

      [7]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0097.html

   WS: one of the questions that have to be addressed is whether
   it is an accurate framing of the question.

   <rsleevi>
   [8]http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct
   /0022.html - original draft post

      [8]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0022.html

   WS: … concerns that it set out questions that it wasn't
   designed to answer.

   ??: I've read the blog, and I commit to posting feedback to the
   listserv.

   RS: I think Harry's approach was right. Two classes of
   feedback: one is that you should not expose low-level
   primitives to developers, unless they know how to use crypto.
   ... That is problematic; security is based on what you're
   doing. Harry's blog post is useful. We're not trying to
   (re)define security.
   ... We are trying to give a framework…. part of the broader
   work of the web platform.
   ... Other feedback is web platform can't be secured.
   ... feedback is useful and viable.

   VG: general feedback … I found that it was large and addressing
   all the problems. If you do not have the context, you may not
   get the blog. It does not define the value of the API.
   ... For me, that's fine… since it does answer some concerns
   that were raised by the different communities that we were
   talking to.
   ... Feedback can be sent to Harry.

   seltzer, can you do the agendum toggling and the Zakim fubar?

   <virginie> [9]http://www.w3.org/2012/webcrypto/track/

      [9] http://www.w3.org/2012/webcrypto/track/

   VG: we have actions to work on. ACTION 46 to create a space for
   document use cases.

   <wseltzer> arunranga: what should a use case look like?

   AR: asked about the delta of work between Wiki and spec, and
   the use cases document.

   RS: In an ideal world, I'd like something like the MediaStream
   use case.

   <virginie> use cases :
   [10]http://www.w3.org/2012/webcrypto/wiki/Use_Cases

     [10] http://www.w3.org/2012/webcrypto/wiki/Use_Cases

   RS: Requires gathering two things. Members of this WG gathering
   what they see as important.
   ... I need to be able to sign hashes.
   ... I think trying to capture that in the spec. would be too
   much work. It would make the spec. unwieldy and large. That's
   why a second document would be useful.

   <Zakim> rsleevi, you wanted to respond to arunranga

   <rsleevi>
   [11]http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture
   /scenarios.html

     [11]
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html

   <wseltzer> AR: what level of detail do we want in the use cases
   doc? do you want code?

   <rsleevi> +1 to test cases being orthogonal/too ambitious for
   use cases

   <wseltzer> AR: Harry suggested that use cases could be turned
   into test cases. I think that's a bit too detailed.

   RS: The level of details specified above in the media stream
   document is what I want to see.

   <rsleevi> +1

   <JimD> I'm happy to help with use case work

   <markw> Ok for me!

   <rsleevi> @virginie correct. We need to describe the problem,
   then extract the technical requirements

   VG: It might be a matter of describing the scenario, then
   following up with technical reqs.

   AR: (shared with the WG some travel-related considerations).

   Mike: I did inform JOSE about the FPWD, so you can mark the
   related ACTION item closed.

   VG: ACTION 51 about value proposition of the API still has to
   be done.

   <rsleevi> sounds about right

   VG: regarding ACTION 52, it was a security consideration.

   <wseltzer> ACTION-52?

   <trackbot> ACTION-52 -- Ryan Sleevi to add text as regards
   security considerations for algorithms -- due 2012-10-01 --
   OPEN

   <trackbot>
   [12]http://www.w3.org/2012/webcrypto/track/actions/52

     [12] http://www.w3.org/2012/webcrypto/track/actions/52

   RS: I'm going to put together a new draft to put out some of
   the issues we've discussed, including security considerations
   suggested on the listserv and on Harry's blogpost

   VG: ACTION 53 was for text around CSP and the security model.

   RS: ACTION 52, 53, and 55 all tie in to expanding security
   considerations. Applies to the entire draft.
   ... Also, we want to expand security considerations for
   algorithms.
   ... So the literature considerations for various algorithms
   have to be applied, etc.

   VG: ACTION 56 was related to ISSUE 27… Wan-Teh sent out a
   proposal.

   <wseltzer> trackbot, close ACTION-56

   <trackbot> ACTION-56 Write proposal for ISSUE-27 closed

   MW: update on ACTION 17 -- Mitch is not here, but one question
   about it is why key generation and unique IDs are separate
   issues.
   ... ON Unique IDs, I was going to write a proposal about this.
   I don't think we do more than a SHOULD level proposal.

   <rsleevi> @markw Request: Define how "if it such exists" for
   implementors

   VG: the reason it was associated with Key Generation was
   because at that point, this automatic ID question came up to be
   managed.
   ... The ACTION dates to August. Changes are fine. Send
   proposal.

   MW: Regarding Key Generation, do we have a separate ISSUE or
   ACTION on key wrapping an unwrapping.

   ?

   MW: We'll need to define a format for the wrapped keys. Within
   that format, we'll need to carry the various attributes
   associated with the keys.

   <virginie> FYI : issue about wrap/unwrap is ISSUE-35

   <virginie> [13]http://www.w3.org/2012/webcrypto/track/issues/35

     [13] http://www.w3.org/2012/webcrypto/track/issues/35

   RS: We've not yet specified key wrap and unwrap. So that's one
   of several outstanding issues; different crypto algorithms
   treat wrap/unwrap differently.

   <Zakim> rsleevi, you wanted to respond to markw

   RS: (cites examples). There are also larger issues about
   conveying extended attributes. Do we go with PKCS#12?
   ... It is an outstanding issue, and is in need of proposals.

   Mike: Wearing my JOSE editor hat, and our goal of being able to
   implement JOSE specs with WebCrypto, at the minimum we'd need
   to support RFCs for key wrap.
   ... So an ECB encryption of the key with a prefix. Under the
   covers, don't care -- whether support for the RFCs or not.

   <selfissued> To support JOSE, we need to support AES Key Wrap
   per RFC 3394

   VG: The way we proceed now with the issue, we should only treat
   issues when there's a proposal to progress.

   rsleevi, can you minute yourself?

   VG: Want to remind people to contribute via concrete text
   proposals.

   <rsleevi> rsleevi: In order to make progress on issues like
   wrap/unwrap, it would be good to have rough proposals put
   forward to support specific use cases. For example, markw and
   selfissued raised desires to support key wrap - it would be
   nice to see proposals for how those APIs may look

   <rsleevi> +1 to Intel making a proposal :)

   Tolga: Can take key wrapping and unwrapping, and take a stab at
   it. And see what I generate.

   CJ: I'm wondering whether to see if a few people can go offline
   and try to work on some of these. One issue that's not on this
   is that I'm interested in working on the test suite.

   <rsleevi> @cjkula The most important thing for me is that we
   can transition from requirements to proposals. We're getting to
   a point where I think we've got most of the requirements
   captured, but we need to start proposing for how to meet them

   <selfissued> The NIST recommendation is the same as RFC 3394

   <karen>
   [14]http://csrc.nist.gov/publications/drafts/800-38F/Draft-SP80
   0-38F_Aug2011.pdf

     [14]
http://csrc.nist.gov/publications/drafts/800-38F/Draft-SP800-38F_Aug2011.pdf

   Karen: NIST had a proposal.

   <rsleevi> @karen the concern is more about defining the API
   (IMO). I'm not even worried about the various algorithms (which
   we'll need to solve), but worried about some of the API and
   representational issues that markw raised

   Mike: The RFC 3394 and the NIST recommendation are the same.

   <rsleevi> It would be good to have 10 proposals for APIs, each
   with a unique key wrap alg, than 0 proposals and 10 key wrap
   algs :)

   VG: ISSUE 27… Ryan made some remarks, so maybe we'll discuss
   that on the list in WTC's absence.

   <virginie> security [15]http://lite.framapad.org/p/t7PEEmBztz

     [15] http://lite.framapad.org/p/t7PEEmBztz

   VG: I created a collaborative pad in order to work on the
   security portions of the API.
   ... Should we close the pad?

   RS: I think there's a number of useful things captured here.
   Don't know how much should be included in the specification. i
   think that the spirit of what's being captured here is useful.

   VG: My intention was to capture the different ideas that people
   have.

   <drogersuk> I agree it is useful

   <rsleevi> sgtm

   <drogersuk> there are many points being raised (on some of the
   blogs too) that could be captured

   <virginie> +1

   <ddahl> +1

   <rsleevi> +1 to tpac attendance

   <JimD> -1

   <selfissued> +1

   <wseltzer> +1

   <haavardm> -1

   <karen> -1

   VG: poll to understand who is coming to the F2F in Lyon, France

   <drogersuk> +1

   <virginie> any interest in high levle api

   <ddahl> +1

   <rsleevi> +1

   <virginie> +1

   <drogersuk> +1

   <haavardm> +1

   <cjkula> @rsleevi yeah, just proposing a mechanism... that we
   group some of the most crucial issues together and send them
   into committees of 3 or 4, with an expectation that most or all
   members of the WG would participate on one of these committees
   and come back with some progress.

   <markw> +1 to tpac attendance

   <wseltzer> trackbot, end teleconf

Summary of Action Items

   [End of minutes]


-- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Wednesday, 17 October 2012 14:42:57 UTC