[minutes] Re: W3C Web Crypto WG - agenda for 17th of september call - today

The draft minutes from today's call are available at
<https://www.w3.org/2012/09/17-crypto-minutes.html>
and in text below.

--Wendy

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

             Web Cryptography Working Group Teleconference

17 Sep 2012

   [2]Agenda

      [2]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0148.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/09/17-crypto-irc

Attendees

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

   Regrets
   Chair
          virginie

   Scribe
          Mitch

Contents

     * [4]Topics
         1. [5]Welcome
         2. [6]Actions
         3. [7]FPWD
         4. [8]Issue status and priority
         5. [9]group life
     * [10]Summary of Action Items
     __________________________________________________________

   <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

Welcome

   <hhalpin> chair: virginie

   <hhalpin> scribe: Mitch

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

     [11] http://www.w3.org/2012/09/10-crypto-minutes.html

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

     [12] http://www.w3.org/2012/09/10-crypto-minutes.html

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

   thanks, Harry

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

     [13] http://www.w3.org/2012/09/10-crypto-minutes.html

Actions

   <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

   +1

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

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

     [14] 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>
   [15]http://www.w3.org/2012/webcrypto/track/actions/16

     [15] 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

FPWD

   virginie: we need to make some noise about the FPWD

   <virginie>
   [16]http://www.w3.org/2012/webcrypto/wiki/Gathering_public_comm
   ent_for_FPWD

     [16]
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> [17]http://www.w3.org/TR/WebCryptoAPI/

     [17] http://www.w3.org/TR/WebCryptoAPI/

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

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

     [18] 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
   [19]http://monocleglobe.wordpress.com/2012/09/17/w3c-web-crypto
   -api-first-public-working-draft-published/

     [19]
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:
   [20]http://www.matasano.com/articles/javascript-cryptography/

     [20] 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>
   [21]http://www.schneier.com/blog/archives/2012/08/cryptocat.htm
   l

     [21] 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 [22]http://www.appsecusa.org/

     [22] 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 [23]http://www.chip-to-cloud.com/

     [23] http://www.chip-to-cloud.com/

   <zooko> [24]http://irtf.org/cfrg

     [24] http://irtf.org/cfrg

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

     [25]
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>
   [26]http://www.w3.org/2012/webcrypto/wiki/Issues_Priority

     [26] http://www.w3.org/2012/webcrypto/wiki/Issues_Priority

   <zooko> wtc: Yes.

   <rsleevi>
   [27]https://docs.google.com/spreadsheet/ccc?key=0ArrROMlGLrjidH
   ltOGpfa1NpZzZ1c3JoN09tRE5rd3c#gid=0

     [27]
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:
   [28]http://www.w3.org/2005/10/Process-20051014/process.html#rec
   -advance ]

     [28]
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

   +1

   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> [29]http://www.w3.org/2012/webcrypto/track/issues/6

     [29] 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
   [30]http://www.w3.org/2012/webcrypto/track/issues/40/edit .

     [30] 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 :(

   -1

   <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:
   [31]http://www.w3.org/2012/10/TPAC/#Registration ]

     [31] http://www.w3.org/2012/10/TPAC/#Registration

   <sdurbha> -1

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

     [32] 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:
   [33]https://bugzilla.mozilla.org/show_bug.cgi?id=731746

     [33] 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





-- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Monday, 17 September 2012 22:22:27 UTC