See also: IRC log
<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
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]