Web Cryptography Working Group Teleconference

17 Sep 2012


See also: IRC log


Attendees were emily, virginie, JimD, ddahl, wseltzer, asad, selfissued, cjkula, wtc, rsleevi, arunranga, zooko, markw, mitchz, sdurbha, hhalpin, vgb


<trackbot> Date: 17 September 2012

<virginie> :)

<selfissued> Mike Jones joined before you did

<rsleevi> Hrm, Zakim does not have us listed. I suspect we may have been the P7

<virginie> Hi all, we will wait few more 1 minutes and than start

<zooko> Hello.

<wseltzer> scribenick: mitchz


<hhalpin> chair: virginie

<hhalpin> scribe: Mitch

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

<hhalpin> PROPOSAL: Approve http://www.w3.org/2012/09/10-crypto-minutes.html as the official meeting minutes

<virginie> Hi all, we will wait few more 1 minutes and than start

thanks, Harry

<hhalpin> RESOLVED: Approved http://www.w3.org/2012/09/10-crypto-minutes.html as the official meeting minutes


<wseltzer> trackbot, close ACTION-45

<trackbot> ACTION-45 And wseltzer to move the Editors Draft to TR space and communicate to the chairs@w3.org, the Director, and Comms Team over the FPWD publication closed

<hhalpin> +1

<virginie> +1

<wtc> +1

<asad> +1

<cjkula> +1

<emily> +1

<ddahl> +1

<JimD> +1

<zooko> +1


<wtc> Do actions also need to be closed with a vote in general?

<virginie> - http://www.w3.org/2012/webcrypto/track/actions/open

wseltzer: patent stuff taking a while
... hoping to bring to group soon

<wseltzer> trackbot, close ACTION-14

<trackbot> ACTION-14 Change naming scheme to use a "createX" approach rather than just "X" closed

rsleevi: actions ... 43, 14, should be closed

<wseltzer> trackbot, close ACTION-33

<trackbot> ACTION-33 text proposal for key pair handling closed

rsleevi: 42 should also be closed

<wseltzer> trackbot, close ACTION-42

<trackbot> ACTION-42 Normative description of the algorithm for key generation, derivation, importing, and exporting closed

<wseltzer> trackbot, close ACTION-41

<trackbot> ACTION-41 Propose text for key neutering closed

<hhalpin> agree, we should only give the editors actions when there's clear WG consensus on putting the text in.

<hhalpin> otherwise its still an open issue.

virginie: we should start taking action to fulfill needs of issues
... we still have pending review actions
... ACTION-16

<wseltzer> ACTION-16?

<trackbot> ACTION-16 -- Ryan Sleevi to add the key query mechanism to editors draft, checking in with ddahl's edit -- due 2012-08-20 -- PENDINGREVIEW

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

virginie: should be closed

<wseltzer> trackbot, close ACTION-16

<trackbot> ACTION-16 Add the key query mechanism to editors draft, checking in with ddahl's edit closed

rsleevi: can close ACTION-16

virginie: we can switch to the issues


virginie: we need to make some noise about the FPWD

<virginie> http://www.w3.org/2012/webcrypto/wiki/Gathering_public_comment_for_FPWD

virginie: started to list the actions to make noise
... need to gather comments & deliver something usable

selfissued: will send the FPWD to the IETF group

<wseltzer> http://www.w3.org/TR/WebCryptoAPI/

virginie: Oxford U. is listed
... b/c they're working a lot on security

<wseltzer> [FPWD link: http://www.w3.org/TR/WebCryptoAPI/ ]

virginie: gathering together Gemalto, G&D and others
... want to see if it maps with secure elements

<hhalpin> I have already emailed IETF Web Security (Web Sec) Group, IETF SAAG (Security Area), Ron Rivest, and NIST (John Kelsey).

virginie: and Sony which is working on JS draft API which may use some of WebCrypto

<zooko> Who proposed whgat?

virginie: pinging people from Twitter & elsewhere
... and Financial Times
... also sent to webappsec working group
... need to ask the group to do more
... if you have any way to communicate out or take the message to conferences, that would be "really great"

<ddahl> virginie: ddahl just blogged this http://monocleglobe.wordpress.com/2012/09/17/w3c-web-crypto-api-first-public-working-draft-published/

hhalpin: there was a debate around "Is JS security possible"
... in the blogosphere last year

<hhalpin> argh

<ddahl> my blog is also in the planet mozilla feed

Harry dropped off the line

<hhalpin> yes I've noticed

<hhalpin> have JimD and asad go first :)

<hhalpin> I'll be back in a sec

<zooko> Example of that debate: http://www.matasano.com/articles/javascript-cryptography/

JimD: going to publicize to US govt related agencies

<ddahl> virginie: that was just an announcement - i plan on blogging more about the API soon

<zooko> The same debate was still ongoing this year, centered especially around Nadim Kobeissi's cryptocat app

virginie: can do something for France

asad: chip security in Nice
... can also bring to app security conference in Austin in Oct.
... "chip to cloud" conference in Nice

<zooko> http://www.schneier.com/blog/archives/2012/08/cryptocat.html

hhalpin: the JS security debate has died

would be useful to get folks who looked at original proposal to look at WebCrypto

hhalpin: people from Wired were interested
... the more eyes the better
... Harry needs some quotes from people
... please email Harry directly

<ddahl> hhalpin: I am sure quinnorton will be happy to tweet a link to your post

hhalpin: is the list interested in talking to others about WebCrypto
... worth mentioning that the APIs will be used
... not just theoretical

Harry: let's talk offline

we're clearly going to do WebCrypto

<hhalpin> not a theoretical product, but something that will actually be used.

<zooko> If the JS security debate has died, then it has ended with the majority of security experts concluding that the "JS crypto is useless" side was right.

<hhalpin> Just email public-webcrypto-comments@w3.org

selfissued: how should we publicize this to ??

<asad> AppSecUSA link is http://www.appsecusa.org/

<Zakim> rsleevi, you wanted to respond to selfissued

rsleevi: the public webcrypto comments list would work to help publicize

<zooko> +q

<hhalpin> zooko, that's why I thought this API+CSP that mean it was time to reignite the debate :)

rsleevi: jose would be interesting to have review esp. the algorithms

zooko: the CFRG is the Cryptographer Consultants, part of IETF
... they will review WebCrypto for us
... zooko will send WebCrypto for review

<hhalpin> It would also be useful to get some broader review from JS app developers as well, arun?

<asad> Chip to Cloud link is http://www.chip-to-cloud.com/

<zooko> http://irtf.org/cfrg

<wseltzer> [Wiki with contacts; http://www.w3.org/2012/webcrypto/wiki/Gathering_public_comment_for_FPWD]

<zooko> hhalpin: I agree. I hope the debate will be reignited.

Issue status and priority

<wtc> David McGrew is a member of the CFRG and is already on our mailing list.

<zooko> FWIW, I think a lot more invention needs to be completed before the current expert consensus will no longer be correct... But that's probably out of scope for this meeting...

<virginie> http://www.w3.org/2012/webcrypto/wiki/Issues_Priority

<zooko> wtc: Yes.

<rsleevi> https://docs.google.com/spreadsheet/ccc?key=0ArrROMlGLrjidHltOGpfa1NpZzZ1c3JoN09tRE5rd3c#gid=0

virginie: this is a proposal
... we can have debate about this
... perhaps Ryan can describe the classifications

rsleevi: trying to break into subcategories
... crypto are things that require understanding of crypto
... if you don't care about crypto, you can ignore
... functional is core to the api
... it's about the functionality of the API
... and is closely related to usability

<JimD> (javascript or other language)

rsleevi: usability about JS paradigm
... single threaded issues
... rendering and scrolling & how it affects these
... access control fits into keys and key management and determining how they're accessed
... key tainting, multi-origin, etc.
... design category is about broad questions about API
... high level vs. low level
... "next" is about the next set of issues that may actually be primary features, but depend on the other issues

markw: "key" vs. "functional" is unclear
... and then I have comments on prioritization

virginie: key domain was my proposal

trying to isolate problematic issues of pre-provisioning

markw: "key" fits functional

virginie: any reason to merge / not merge?

rsleevi: the split has some utility
... trying to separate distinction btw. functional for "web platform" vs. ...
... not related to keys themselves
... conversation about indexDB, web storage, etc.
... about functionality of overall web platform
... but we can merge if we need to

virginie: the "key" domain is something we can work on in parallel
... if that's agreeable
... it's not to isolate and forget

markw: it's not clear enough that it's useful for organizing our work
... we can work on issues whatever category they're in

asad: why a separate domain?
... after hearing this, it makes sense to separate
... we would be able to more easily focus on the segregated issues

vijay: utility of dividing into domains is to focus attention
... dividing the issues is good
... for "keys" perhaps have a "key storage" category
... for origin, access, etc.

perhaps this conflicts with "access control"?

virginie: this would bring in some of "access control" into "key storage"
... we can do that
... is that ok for you, Mark?

markw: could make sense
... there are related things in functional section, also

<zooko> To me, access control and key management are so interrelated that they are almost the same thing.

markw: not clear that this helps split things up.

<rsleevi> The solution: tag clouds ;)

virginie: other way is to keep fragmented domains
... we need to think a bit more on this
... let's check back in one week
... ranking was to increase priority of items that are dependencies

markw: how do priorities relate to next deliverables?

virginie: goal was to resolve all the issues for next draft

markw: if we will deal with all issues, then this seems fine

hhalpin: 3 months is standard for next draft

wseltzer: prioritizing certain things above others is for handling dependencies, not because other issues are unimportant

hhalpin: we should publish once every three months
... so long as we are targeting the primary features
... people will hopefully implement
... for secondary features, we should avoid them until we get through all the issues in primary use cases
... these questions are tricky, so let's get them sorted with consensus by next working draft if possible

<wseltzer> [W3C Process steps: http://www.w3.org/2005/10/Process-20051014/process.html#rec-advance ]

virginie: targeting everything except things marked as in domain "next"
... for next public working draft

hhalpin: yes

rsleevi: don't know how much can be done in 3 months
... as we start getting comments from community, there will be more work
... no support for smart cards or pre-provisioned keys
... want to be able to polyfill impl in JS
... these are high priority to get something useful
... after that we can address pre-provisioned keys, etc.
... important to get developers to vet this
... doesn't mean things like device specific or pre-provisioned keys are not important
... but want to get implementers started

markw: understand why we want to get something implemented in JS
... not sure why this precludes pre-provisioned keys
... we're planning to implement this
... and be user of the API
... if you include us in that then pre-provisioned keys are a necessary part

<sdurbha> +1 for pre-provisioned keys

markw: it can be done & there are people who want it immediately


virginie: we need to be careful excluding these use cases for a number of organizations
... b/c they may find the API N/A for them without including pre-provisioned keys in scope
... we need some volunteers to draft proposals to editors & to mailing list
... we won't discuss the actual issues right now
... people should check to see if the priorities are reasonable as proposed
... please volunteer
... so we have actual actions

rsleevi: we can't do polyfill for pre-provisioned keys

markw: everything has different properties when implemented in polyfill

Agreed: we should consider the non-browser use case as in scope "\n"

<wseltzer> ISSUE-6?

<trackbot> ISSUE-6 -- Concern around KeyQueryList being synchronous -- raised

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/6

if there is large latency we would be concerned about this being synchronous

would prefer an async call

please: )

rsleevi: agree about latency issue
... this is not a latency concern
... this is an action about an API that is not specified

<ddahl> rsleevi: trying to implement an object that decends from eventtarget will be less than optimal to not really that doable in a polyfill

rsleevi: we need to create a new issue that is async

virginie: agreed that new issue should point out async

works for us

<ddahl> i guess it can be faked a bit with a web worker

<rsleevi> ddahl: Yes, that's something I was looking at related to our callback/event handling.

<wseltzer> ISSUE: how should we define key discovery, noting asynchronicity

<trackbot> Created ISSUE-40 - How should we define key discovery, noting asynchronicity ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/40/edit .

virginie: will open a new issue & close the old

<wseltzer> trackbot, close ISSUE-6

<trackbot> ISSUE-6 Concern around KeyQueryList being synchronous closed

group life

<rsleevi> +1

<ddahl> +1

<wtc> +1

<markw> +1

<selfissued> +1

<cjkula> +1

<virginie> +1

I wish I could attend TPAC :(


<hhalpin> +1

<wseltzer> +1

<zooko> I wish.

<asad> not sure

<wseltzer> [TPAC attendance]

(vote was on who is attending TPAC)

<selfissued> Can someone post a link to the TPAC registration information?

<wseltzer> [Register: http://www.w3.org/2012/10/TPAC/#Registration ]

<sdurbha> -1

<rsleevi> http://www.w3.org/2012/10/TPAC/

virginie: please register
... one set fee per day

<ddahl> rsleevi: this might help with updating DOMCrypt to be like the new API: https://bugzilla.mozilla.org/show_bug.cgi?id=731746

virginie: technical session on Wednesday
... on general strategy of w3c
... it's very interesting
... lot of events, beers, etc.

wseltzer: if you haven't been to TPAC, the Wednesday meeting is an "unconference" event
... you can choose sessions to attend
... if someone wants to propose something about WebCrypto, that would be a place to propose that

virginie: pool of exchanges, very lively and interactive

<zooko> Thank you mitchz.

next conf call in one week on monday

<hhalpin> thanks!

<wseltzer> trackbot, end teleconf

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/09/17 20:23:42 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/paten/patent/
Succeeded: s/??/webappsec/
Succeeded: s/??/JimD/
Succeeded: s/if possible/"\n"/
Succeeded: s/note sure/not sure/
Found ScribeNick: mitchz
Found Scribe: Mitch

WARNING: No "Present: ... " found!
Possibly Present: Google Harry IPcaller ISSUE JimD Microsoft P11 P17 P7 PROPOSAL aaaa aabb arunranga asad cjkula ddahl emily hhalpin https is markw mitchz netflix perhaps rsleevi scribenick sdurbha selfissued trackbot vgb vijay virginie wseltzer wtc zooko
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0148.html
Found Date: 17 Sep 2012
Guessing minutes URL: http://www.w3.org/2012/09/17-crypto-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]