W3C

- DRAFT -

Web Cryptography Working Group Teleconference

09 Jul 2012

See also: IRC log

Attendees

Present
+1.304.367.aaaa, WSeltzer, rsleevi, +1.510.387.aabb, virginie_galindo, +1.415.294.aacc, arunranga, Mike_Jones, cjkula, hhalpin, Tommy_Cromer, vgb, ddahl, asad, Karen_, drogersuk, Wendy, +33.9.54.30.aadd
Regrets
Chair
virginie_galindo
Scribe
wseltzer, rsleevi

Contents


<trackbot> Date: 09 July 2012

<self-issued> Microsoft is Mike Jones

<ddahl_> just dialed in

Convene Meeting

<cjkula> A little frightened!

<cjkula> (Haven't studied)

<asad> I can do that next week. Today I am under the weather a bit.

<hhalpin> scribe: wseltzer

<hhalpin> scribenick: wseltzer

virginie_galindo: Minutes will be circulated for approval next week.
... Welcome IBBT, Philippe De Ryck.
... First, review use cases, then technical discussion.

Use cases

virginie_galindo: Channy and Jim are not on the call.
... Perhaps we can get a written update.

sdurbha: No update. Working with Jim if he needs help.

virginie_galindo: Anyone to add use case to the wiki?

Draft API review

<hhalpin> http://www.w3.org/2012/webcrypto/WebCryptoAPI/

ddahl_: I have updated the spec with Ryan's low-level proposal
... Adding outlines, issues under discussion and contention.
... It's in cvs, looking for feedback from editors, then mailing list.
... Originally, I proposed high-level API; Ryan proposed low-level
... For now, just want to get all the issues into the document.
... Two actions: ACTION 6, allow for access to private key material, added to the spec.
... ACTION 9: proposal for adding key ID and handling methods in there as well.
... Put everything in one place, add missing items.

hhalpin: To help people understand the issues, we should put alternatives into FPWD
... don't prematurely optimize.

ddahl_: Ryan's proposal was well-received and well-designed.
... Put everything in one place (the draft) to help reviewers.

Mailing list discussions

ddahl_: editing via hg or cvs

<ddahl_> rsleevi: i would also prefer hg:)

rsleevi: we can use mercurial for making rapid changes in response to ongoing discussions
... just sent mail with strawman on identifying algorithms
... haven't yet gotten to add those to the draft

<virginie_galindo> http://www.w3.org/2012/webcrypto/track/

<scribe> scribenick: rsleevi

virginie_galindo: Discussion actions list https://www.w3.org/2012/webcrypto/track/actions

<drogersuk> Will aim for action number 8 to be completed by the next call

rsleevi: Actions 3, 4, 5, and 7 were duplicated. Actions 3-5 have been closed, ACTION-7 will continue the discussion

ddahl_: ACTION-6 has updated the draft with a proposal for optionally keeping keying material inaccessible

drogersuk: ACTION-8 will be updated for next week with sdurbha

ddahl_: ACTION-9 has been incorporated into the draft and is pending review

sdurbha: Discovery has been a hard topic on the mailing list. Should we open an action?

virginie_galindo: Looking for suggestions to take up the action

rsleevi: Should it be an ACTION or an ISSUE?

hhalpin: ISSUES are where there are multiple design options, ACTIONS are where a concrete proposal is needed

virginie_galindo: Perhaps both

rsleevi: May just be an ISSUE?

ddahl_: Key discovery or algorithm discovery?

hhalpin: algorithm discovery

mike_jones: Regarding ACTION-7, proposal for using JOSE names for lookups seems acceptable. However, algorithm discovery may not add value, just add code. That's because even if you have an algorithm, it may not be usable with a key

sdurbha: Possibly two issues: 1) Mandatory/expectability of algorithms 2) What to do when the algorithm is not supported?
... Two different ways of discovering algorithms have been proposed. The 'objectability' (window.crypto.enc.rsa_oaep) or via a method (as proposed in the low-level API)

<sdurbha> OK

Karen_: Question about getKey() - how does the caller get access to a key?

ddahl_: The idea with using a DOMString, the idea was that you could possibly get a key pair. Is it a question of naming the method?

Karen_: The naming seems fine. One question is that it returns a "void", which seems confusing. Another question is how is access to the key managed? Can any application get that key? What if that key is pre-provisioned?

ddahl_: The return of "void" was so that the actual keying material is returned during the oncomplete event
... The current proposal does not address the ACLs or how the raw key may be accessed.
... Pre-provisioned keys will require more thinking through. How exactly access controls will be managed - such as an explicit list of domains - as well as how to handle things such as expiration.

Karen_: Raising it as a discussion point for now. Currently no proposal to address this

There was also the KeyQueryList proposal as a way to identify and discover keys

ISSUE: How to address pre-provisioned keys and managing ACLs

<trackbot> Created ISSUE-2 - How to address pre-provisioned keys and managing ACLs ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/2/edit .

<ddahl_> rsleevi: yes, indeed. I forgot to go back over that in my latest editing

virginie_gemalto: Are there any other proposals for addressing discovery?

<ddahl_> rsleevi: perhaps I should add the KeyQueryList as an additional sub-proposal for key discovery?

hhalpin: The key for the API making it through the W3C process will need to be interoperability and testability. If browsers and implementors are suggesting it's too much to implement, then that will ultimately come out in the test cases

ISSUE: Decide whether algorithm discovery is necessary

<trackbot> Created ISSUE-3 - Decide whether algorithm discovery is necessary ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/3/edit .

Karen_: Right now we're proposing a high-level and low-level API. They both have their own duties. Do we want to combine them, or will they be kept at two levels?

ddahl_: There have been ongoing discussions about this. We've had more people introduced in a low-level API, but there were still a number of people interested in a high-level API. It's possible that a high-level may be implementable in terms of a low-level in content JS, but for now and the sake of discussion, it may be good to keep them both in the draft

virginie_gemalto: Even if we keep the high-level API, we should focus on solving the issues of the low-level API first, but it does not prevent discussion of the high-level API

hhalpin: At this time, for the sake of public discussion, it would be good to keep both

Group life

virginie_gemalto: Thanks to David and Mozilla for offering to host.
... It will look to be two full days, starting around 9:30 - 10 and running until 5
... If people want to speak about particular technical items, bring them up on the mailing list so we can have as much input as possible

ddahl_: There will also be a teleconference line for remote participants

virginie_gemalto: harry or wendy to setup the details. Will work with David to setup the details
... Any other items?
... Thanks to everyone for participating. Next call will likely take another look at the ACTIONs and begin to come up with the agenda for face to face

<self-issued> Mike Jones has to sign out

ddahl_: finalize the details for mercurial vs cvs

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/07/10 10:25:08 $