Web Cryptography Working Group Teleconference

08 Jul 2013

See also: IRC log


+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, +, hhalpin


<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

[agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0007.html ]

<virginie> http://www.w3.org/2013/06/03-crypto-minutes.html and http://www.w3.org/2013/06/17-crypto-minutes.html and http://www.w3.org/2013/06/24-crypto-minutes.html

virginie: any objection to these minutes (3, 17, and 24 June)?
... no objection

Web Crypto API (code name low level API)

vgb: sent some write-up on key agreement proposal
... any comments?


<trackbot> ACTION-84 -- Richard Barnes to vgb and jimsch to discuss key generation/derivation/agreement -- due 2013-05-21 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/84

[ http://lists.w3.org/Archives/Public/public-webcrypto/2013Jun/0001.html ]

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> http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0002.html

rsleevi: that's the current status
... 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?

virginie: ryan?

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 wrap/unwrap text
... where the construction is up to the javascript
... 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 beginning
... 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 list
... 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

<MichaelH> +q

<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 progress
... we can ask Mark, Ryan, Jim, to work on it.
... Work on wrap/unwrap and try to reach consensus

<MichaelH> +q

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 prevented
... 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 v2
... what's the group's appetite for that?

rsleevi: I would love to see streaming; the chunking problem exists with FileAPI as well
... 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

Web Crypto Key Discovery (next step)

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

Web Crypto use cases

virginie: if Arun can integrate changes, we can bring forward for next working draft. not normative, but useful

status on high level api

<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

group life (summer activities and priorities)

virginie: Keep working through summer
... 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 August IETF
... when you hang up, think about what you can do for wrap/unwrap!

<karen> exit

<israelh> Tracking issue for stream API support in Webcrypto: https://www.w3.org/2012/webcrypto/track/issues/49

trackbot, end teleconf

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-07-08 21:01:38 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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, +, 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 + 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]