See also: IRC log
<trackbot> Date: 08 July 2013
<sangrae> I think [IPcaller.a] is me
<scribe> scribenick: wseltzer
virginie: prioritization. look
with vgb at life-cycle
... ask for review of bugs
... for next call, wrap/unwrap discussion
... future of 2 other specs, key discovery and use cases
<MichaelH> @nvdbleek use aagg
virginie: approval of minutes
virginie: any objection to these
minutes (3, 17, and 24 June)?
... no objection
vgb: sent some write-up on key
... any comments?
<trackbot> ACTION-84 -- Richard Barnes to vgb and jimsch to discuss key generation/derivation/agreement -- due 2013-05-21 -- OPEN
vgb: email had edits to the then-current draft
virginie: any questions?
rsleevi: Next step is to
integrate into the draft
... Updating the key agreement and key derivation points will happen for the next update
rsleevi: that's the current
... a colleague working on implementation found a number of spec bugs
... Encourage all implementers to file bugs
... thanks to Jim for filing issues
... Please file bugs where you find typos, spec ambiguity, errors
... we'll only need to raise them on the call if complex or controversial
... Working on adding more normative text. particularly on import-key, which has been underspecified
... algorithm definitions. expect to see more normative references
... Requires careful attention to detail. Look through and report.
israelh: When do we expect to
resolve wrap/unwrap, import/export?
... from an implementation perspective, how much of a deadline can we expect?
rsleevi: It's up to the chair
virginie: Would like to have
decisions made during the summer.
... ideally, wrap/unwrap would be decided on the next call, but I understand Mark won't be able to make it
... so perhaps the next four weeks.
... On import/export, I've seen less controversy; also next 4 weeks
markw: The controversy in
wrap/unwrap is now what goes into import/export.
... because w/u refers to i/e.
virginie: My target is the coming 4 weeks
israelh: We already published an
implementation matching the pre-promises spec
... that points to an older wrap/unwrap.
... our timeframe is short to impact the next rev that will eventually ship
... next week or two
... if no resolution happens in next week or two, we'll continue to ship what we have
virginie: Can we start discussing, then?
markw: the stable part is the new
... decrypt+import; encrypt+export
<virginie> recent Mark's comments on wrap/unwrap issue : http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Notes_July
markw: how do you preserve
non-exportability when unwrapping?
... we need at least one format that supports attributes
... so we proposed mapping to/from JWK attributes
... about preserving non-extractability.
<rsleevi> Actually, lemme log that remark
<rsleevi> PKCS#11 does this by exposing attributes on the wrapping key, rather than the key-to-be-unwrapped. So it's not necessarily true that the key format uses attributes
rsleevi: not sure the key format
inherently needs attributes
... the wrapping key can be the attribute bearer
... working through accessible practice to web devs; compatible;
... appreciate Mark's work; concerned about technical scalability
markw: the notion of attaching
attributes to JWK has been part of our proposal from the
... Ryan's proposal is interesting, but what if you want to wrap and unwrap a wrapping key?
jimsch: I'm a bit worried. JOSE
doesn't know have attributes on key-wrap keys
... is there an issue if the key-wrap key is exportable?
markw: the proposal at the moment
only uses the basic JWK key representation
... if you want to maintain non-extractability, everything has to be non-extractable
virginie: ad-hoc conference call next week?
<markw> works for me
virginie: react on the mailing
... status update in two weeks
markw: Let's try to keep
implementation timeline in mind
... we should be able to solve within that time-frame
virginie: let's put this as priority #1 on the mailing list
<rsleevi> MichaelH: I already addressed this earlier in the call.
MichaelH: can Ryan fill out import/export part of the spec to identify issues?
virginie: Action to WG to make
... we can ask Mark, Ryan, Jim, to work on it.
... Work on wrap/unwrap and try to reach consensus
MichaelH: I asked whether decrypt option should be disabled on unwrap
rsleevi: that's application side, not implementation, as we discussed at f2f
MichaelH: the spec doesn't prevent a decrypt operation if decrypt isn't part of the usage?
rsleevi: if you attempt to
decrypt and don't have a decrypt operation, that will be
... there are sub-steps to be specified
MichaelH: "if the key usage does not say decrypt, then file exception"
rsleevi: file a bug
israelh: Another question: we
discussed support for streaming APIs, heard potentially
... what's the group's appetite for that?
rsleevi: I would love to see
streaming; the chunking problem exists with FileAPI as
... concern is inconsistency
<rsleevi> note: Microsoft has made a proposal based on the Streams API
israelh: we want to figure out
how to resolve the streaming issue consistently
... what do we do with multi-part now?
<jimsch> what is meant by multi-part?
israelh: do we want to provide a band-aid now?
<rsleevi> @jimsch: .process() with multiple incomplete buffers, followed by .finish()
<rsleevi> @jimsch: Which is conceptually a band-aid for a lack of a streaming API
<rsleevi> @jimsch: The question is sort of "Do we proceed with .process(), as a band-aid" or "Do we drop this, until we get a good/consistent Streaming API"
israelh: I think that's one of
the things that will come out at last call
... demand for multi-part
rsleevi: thanks Israel. this is
an issue we should consider
... it's not critical to our use cases right now, but people might well come forward with use cases at last call
... do we proceed with a solution now, that we can never remove, or do we wait and proceed holistically?
... how important are the multi-part and streaming use cases? the consistency of the web platform?
<virginie> suggests we move on on the agenda, and solve
virginie: suggest israelh file an issue to track the discussion
jimsch: big difference between multi-part and stream; don't think the band-aid solves things
<jimsch> without multipart output then streaming is not really addressed
virginie: Mark, any changes?
markw: one change pending, to
simplify getkeysbyname to getkeybyname
... without clear use case for multiple keys
virginie: On next call, bring
forward next drafts of Key Discovery and Use Cases
... in 2 weeks.
<MichaelH> @markw I have a need for multi key discovery
virginie: if Arun can integrate changes, we can bring forward for next working draft. not normative, but useful
<nvdbleek> @markW I'll send a use case for returning multiple keys this week (for a possible future version of the discovery API)
virginie: ad hoc call about high-level API. Work to start in September based on polycrypt
virginie: Keep working through
... priorities: finalize wrap/unwrap
... bugs and work on low-level API
... then address certificates, as discussed at f2f
... objective, to go for last call during f2f at TPAC, China
... any comments?
... Sept/Oct, we'll need to set up testing activity
... call for volunteers.
<hhalpin> In particular, a maintainer for the git repo for test-suite
virginie: also JOSE meeting in
... when you hang up, think about what you can do for wrap/unwrap!
<israelh> Tracking issue for stream API support in Webcrypto: https://www.w3.org/2012/webcrypto/track/issues/49
trackbot, end teleconf
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/It/It's up to the chair/ Found ScribeNick: wseltzer Inferring Scribes: wseltzer Default Present: +1.512.257.aaaa, +1.408.540.aabb, markw, Wendy, +1.650.214.aacc, vgb, +1.512.257.aadd, virginie, +1.857.928.aaee, rsleevi, MichaelH, sangrae?, jyates, +1.512.257.aaff, karen, jimsch, israelh, +31.61.877.aagg, nvdbleek, mitchz, ddahl, +1.505.665.aahh, Ben_Santos, +18.104.22.168.aaii, hhalpin Present: +1.512.257.aaaa +1.408.540.aabb markw Wendy +1.650.214.aacc vgb +1.512.257.aadd virginie +1.857.928.aaee rsleevi MichaelH sangrae? jyates +1.512.257.aaff karen jimsch israelh +31.61.877.aagg nvdbleek mitchz ddahl +1.505.665.aahh Ben_Santos +22.214.171.124.aaii hhalpin Found Date: 08 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/08-crypto-minutes.html People with action items:[End of scribe.perl diagnostic output]