W3C

- DRAFT -

Web Cryptography Working Group Teleconference

15 Oct 2012

See also: IRC log

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


<trackbot> Date: 15 October 2012

<selfissued> Mike Jones

rsleevi, I think the aaff is me

<karen> aabb is Karen

<scribe> ScribeNick: arunranga

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

<wseltzer> [Agenda: 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> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0097.html for Harry's updated security considerations

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

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

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> 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 : 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> 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> 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> 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> 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 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]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/10/15 20:04:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/contribute/contribute via concrete text proposals/
Succeeded: s/??:/Tolga:/
Found ScribeNick: arunranga
Inferring Scribes: arunranga

WARNING: No "Topic:" lines found.

Default 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
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
Found Date: 15 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/15-crypto-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]