<trackbot> Date: 26 November 2012

<hhalpin> trackbot, start meeting

<trackbot> Meeting: Web Cryptography Working Group Teleconference

<trackbot> Date: 26 November 2012

<mountie> hi

<mountie> am i in right channel?

<ddahl> mountie: yes

<mountie> ok hi david

<ddahl> hi mountie:) how's SF?

<mountie> not so cold. good climate

<ddahl> mountie: I asked a few mozillians about meeting up with you but never heard back - I saw that you were in contact with Gen, so thats good

<mountie> ddahl i don't mind

<virginie> who is on the call ?

<mountie> mountie is online

<Karen> 257.aaaa is probably Karen

<rsleevi> mountie: Are you on the phone?

I can be the scribe

<virginie> chair Virginie

<rsleevi> scribe: Wan-Teh

<rsleevi> scribenick: wtc

virginie: the agenda: mercurial repository, use cases, key storage, low-level API, etc. Anyone would like to add something else to the agenda?
... the agenda is approved.

<virginie> http://www.w3.org/2012/11/12-crypto-minutes.html

virginie: the minutes of the previous meeting are approved: http://www.w3.org/2012/11/12-crypto-minutes.html
... we can go to the first agenda item.
... mercurial repository'

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0115.html

rsleevi: harry has set up the mercurial repository. It allows the editors and authors to move away from CVS for revision control.

<hhalpin> Just tell me if you need any help!

rsleevi: mercurial allows us to post a URL that shows the diffs of a change to the spec.
... mercurial also facilitates making incremental (smaller) changes rather than a big change.

virginie: who is able to use it?
... is it just the Editors? Can a member make changes?

<hhalpin> Yes, any member can make changes

<hhalpin> Non-members can't

<hhalpin> but they can follow commits

<hhalpin> make sense?

rsleevi: the editors should be responsible for incorporating changes to the documents.

<rsleevi> @hhalpin: I suppose the question is "can" and "should". Any member today *can* make changes via CVS, but that hasn't happened

hhalpin: any member can make changes. Non-members can't, but they can follow commits.

<hhalpin> Thus, the process does not change re editors

<hhalpin> If another member of the WG makes changes, we can follow it

<hhalpin> and its tracked

<hhalpin> so there should be no problems

<hhalpin> i.e. the editors can delete changes

<hhalpin> if say, a "rogue" member does a commit :)

<hhalpin> (apologies, very bad voice connection)

<rsleevi> Resolution: The process continues with editors making changes to the spec based on WG consensus

rsleevi: Resolution: The process continues with editors making changes to the spec based on WG consensus [12:17] * rsleevi Zakim, close this agendum [12:17] * Zakim I do not know what agendum had been taken up, rsleevi

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

virginie: skipped Use Cases because Arun is not here.
... Action List

<hhalpin> ddahl - any idea what happened to Arun?

virginie: does anyone have an action to close?

<ddahl> hhalpin: unfortuantly, no

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

<hhalpin> If you need any help re HG, ping me rsleevi

<hhalpin> it should just work :)

virginie: what's the status of http://www.w3.org/2012/webcrypto/track/actions/57?

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

rsleevi: I already made some edits before the mercurial repository was set up, Will migrate my edits to Mercurial

<hhalpin> Note I will delay my blog post item till we publish our second heartbeat in Dec.

virginie: next agenda item: key storage
... we have the proposal from Mark Watson.
... Mark made it clear that it is important for Netflix to have key storage.
... But the privacy concerns must be considered and addressed.

<mountie> keystorage is also important in Korea UseCase.

mountie: keystorage is also important in Korea UseCase.

virginie: this issue is difficult to resolve and make progress on.
... issues: key discovery, key import, and privacy

<hhalpin> Note that "key import/export, a common method for accessing and defining properties of keys" is a secondary feature

<hhalpin> but obviously, lots of folks want key import/export.

virginie: I would like the parties involved to work together on this.
... would it be OK to work together, with more time (say, two months), on this?

<mountie> agree. need to work more.

hhalpin: I just wanted to point out "key import/export, a common method for accessing and defining properties of keys" is a secondary feature
... I don't want it to delay our progress on the first version.

<mountie> we need to list up every available issues related keyStorage.

<hhalpin> My concern is that we will not 1) respond to reviews from first draft and 2) we need to cover primary features by mid-Dec.

hhaplin: (quality of the voice connection was poor so the scribe may not have fully captured his words)

<hhalpin> I am just wondering if rsleevi thinks we can still do a second heartbeat

hhalpin: My concern is that we will not 1) respond to reviews from first draft and 2) we need to cover primary features by mid-Dec.

<hhalpin> that covers the above

hhaplin: I am just wondering if rsleevi thinks we can still do a second heartbeat that covers the above

rsleevi: our proposal has been that the spec does not address key storage.
... we define the key object but don't define where the key objects come from. This is consistent with other W3C APIs such as the File API and WebGL.
... our proposal has been to take any proposal for key storage as a separate proposal due to the WG charter and timeline.
... to clarify, I see the key storage as a separate specification. It doesn't need to be part of the core API,

<pal> is this the current charter? -> http://www.w3.org/2011/11/webcryptography-charter.html

<mountie> I know the keystorage will not be addressed in the spec.

rsleevi: the timeline and opportunities for implementors to experiment with different methods of implementation are the reasons.

<mountie> but I need to know how keyStorage is secured.

<pal> Primary API Features [...] key storage and control beyond the lifetime of a single session

markw: key import and export are necessary for access to pre-provisioned keys.

<hhalpin> Yes, but that "key storage and control beyond the lifetime of a single session" is handled by structured clone, if that's what the WG wants

markw: we understand pre-provisioned keys to be in the API. We object to removing support for pre-provisioned keys (by removing the key storage API).
... I understand from rsleevi that Google isn't interested in working on that. I think we should let parties interested in that feature to work on that.

<hhalpin> I mean, we could branch things out into different specs, vote, etc.

markw: whether this (key discovery) would be a separate document depends on the timeline.

<hhalpin> There are no process problems with a separate document I believe, although it may not be Rec-track.

markw: but I happen to believe we can get it done within the timeframe.

<hhalpin> Its hard to change Rec Track docs due to IP commitements to charter, but Working Group Notes are always possible

<hhalpin> Another possibility is to work it out in a separate document and then bring the document at a later point to the WG.

pal: just wanted to confirm the charter does list key storage as a primary feature.

<markw> @hhalpin: 'although it may not be Rec-track' would count as a 'process problem', IMO

pal: wanted to understand the reluctance to support it.

hhalpin: (explained the the charter (the initial draft) but the voice was barely intelligible)

<mitchz> Harry: really difficult to understand you

<hhalpin> As I said, key storage means putting keys in local storage

pal: I heard some statement that key storage is not primary work. I just wanted to point out the charter states in plain English that it is in the primary features.

hhalpin: key storage means putting keys in local storage

rsleevi: providing a structure clone algorithm using existing storage mechanism such as Indexed DB meets the "key storage" requirement in the WG charter.
... "key storage" as in secure elements and smart cards is out of scope.

<hhalpin_> Note that key storage is covered by localStorage/structured clone technically, but again, hoping we can get something more sophisticated

rsleevi: I'm trying to provide an incremental solution in the API based on our timeline.

virginie: when we wrote the charter, we said we would not write anything that is secure element specific.

markw: both the key storage and pre-provisioned keys are in the first public working draft.
... the Lyon meeting was the first time anyone proposed to have them removed from the API.
... smart cards (not origin specific) are a different problem from pre-provisioned keys in the first public working draft.
... we should try to address the technical issues.

<hhalpin_> My belief is that we need to prioritize the second heartbeat requirements

<hhalpin_> for the next few weeks

<hhalpin_> and that in makes sense however to revisit

<hhalpin_> the key storage questions (and import/export variations, which to me seem rather sensible as proposed by MarkW)

<hhalpin_> after the second heartbeat, and go for these on the third heartbeat

<hhalpin_> and see if we can get consensus

ddahl: in the high-level API we could use a local storage. I can see we need some kind of key ID that is implicitly drawing from some kind of key storage mechanism, however...

<virginie> tentative of resolution : the pre-provision key topic will be adressed in separate specification

<ddahl> hhalpin_: you are voiping bad

<hhalpin_> In IRC

hhalpin: the WG, the people who are interested in key storage and pre-provisioned keys (the voice connection was broken...)

<markw> +

virginie: markw, what would you put to support pre-provisioned keys?

<hhalpin_> PROPOSAL: Pre-provisioned keys and key import/export addressed in second document and interested WG members can work on it, and we revisit after second heartbeat once primary features are covered.

<hhalpin_> The reason is we obviosly don't have consensus!

<hhalpin_> I.e. the editor and one implementer (Google) object

hhalpin: the reason for proposing this be a separate document is we obviosly don't have consensus!

<hhalpin_> revisit = try to get consensus again

<markw> well, there are details we have to discuss first ...

<hhalpin_> the idea is that folks in the WG should not be blocked from making progress on their proposal due to current objections

<hhalpin_> Normative documents need to track on same timeline, non-normative do not.

microsoft: if the reason is the schedule, would the separate document tracking the same time line, would it divide the work?

<ddahl> in the high level API I can see where we will need to specify private keys via an ID generated via a generate key API. The storage is implicit and I will imagine the browser will have to provide a management interface to handle key deletion, etc. There would be no additional API to manage keys, import/export, etc

<hhalpin_> i.e. different document would track to same timeline if we get consensus on it, otherwise it does not matter.

virginie: we have some motivated people...

hhalpin: different document would track to same timeline if we get consensus on it, otherwise it does not matter.

<hhalpin_> The W3C does work by consensus, but we want people to make progress.

virginie: the problem is that most of the people who want this feature think it is a primary feature.

<virginie> PROPOSAL: Pre-provisioned keys and key import/export addressed in separet document and interested WG members can work on it, and will be worked in parallel

<rsleevi> Note: We're very interested in this feature, but think that minimally the scope and use cases are clearly more than just Netflix's use cases, and thus potentially require a separate timeline. But +1 to separate document for separate discussion

<hhalpin_> The problem is that the main document needs to reflect current consensus

<virginie> PROPOSAL: Pre-provisioned keys and key import/export addressed in separate document and interested WG members can work on it, and will be worked in synchonisation

markw: what we didn't want to see is to remove something from the first public working draft and move it to a second document. I still don't see why we can't just address the technical issues.

<hhalpin_> Because document we have needs to reflect consensus and this proposed feature has an objection.

<virginie> PROPOSAL: Pre-provisioned keys and key import/export addressed in separate document and interested WG members can work on it, and will be worked in synchronisation

hhalpin: Because document we have needs to reflect consensus and this proposed feature has an objection.

<mountie> +1

rsleevi: we've been from the start very interested in alternative key storage.
... it's not that I'm opposed to the idea. But the timeline and the implementation constraints make this difficult.
... we think a separate document to address this is a way to build consensus, while allowing the primary API to make progress and gain implementation experience.

<virginie> PROPOSAL: Pre-provisioned keys and key import/export will be addressed in separate document and interested WG members can work on it, and will be worked in synchronisation with the low level API

rsleevi: we don't want the primary API to be blocked on this.

<hhalpin_> MarkW, feel free to salt and pepper the proposal to taste, since you are the main one driving this

<rsleevi> @virginie: I would define it as "Key discovery will be expressed in a separate document ..."

markw; the ability to create the key object associated with a pre-provisioned key.

<rsleevi> @virginie: Import/Export in the primary doc, and storage is already addressed via structured-clone

<virginie> PROPOSAL: Pre-provisioned keys related features (create key, find a key) will be addressed in separate document and interested WG members can work on it, and will be worked in synchronisation with the low level API

markw: and leave key wrap/unwrap in the main document.
... we should agree now that a draft for this document should be created.

<virginie> PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key, find a key) and interested WG members can work on it, and will be worked in synchronisation with the low level API

<hhalpin_> sounds good to me, I can set up another HG repo for this documet.

virginie: PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key, find a key) and interested WG members can work on it, and will be worked in synchronisation with the low level API

<markw> The group will decide when they have seen the draft whether to remove the material from the main document

<hhalpin_> Noting we timing we need to do this all before our next hearbeat, i.e. mid-Dec.

<rsleevi> markw: The text was already removed per our previous resolution

<virginie> PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key, find a key) and interested WG members can work on it, and will be worked in synchronisation with the low level API. Once principle of the draft approved, those features will be removed fofrom Low level API

<markw> otherwise we are not 100% clear on the scope of the material that is moving from main draft to new draft

markw: when we see that draft, the WG will decide whether to remove the material from the main document

<virginie> PROPOSAL: A draft specification will be created about pre-provisioned keys related features (create key object, find a key) and interested WG members can work on it, and will be worked in synchronisation with the low level API. Once principle of the draft approved, those features will be removed fofrom Low level API

<rsleevi> -1

Karen: to clarify: "create key" means creating the key object, because the key already exists.

<markw> +1

<mitchz> +1

<hhalpin_> What bit do you disagree with rsleevi?

<hhalpin_> i.e. the "removed"

<hhalpin_> or something else?

<Karen> +1

<rsleevi> @virginie: The objection is "key discovery" instead of pre-provisioned, and the added text regarding "removing features" was already addressed in a previous resolution

rsleevi: the objection is: "key discovery" instead of pre-provisioned, and the added text regarding "removing features" was already addressed in a previous resolution
... so it's procedural.

<markw> No, have not agreed to remove KeyStorage

<markw> It is in the draft up on the web

<hhalpin_> There is editors draft and next heartbeat

<hhalpin_> i.e. "heartbeat" = Working Draft

<markw> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#KeyStorage-interface

<hhalpin_> Working Draft needs to reflect consensus

<rsleevi> @virginie: PROPOSAL: A draft specification will be created about key discovery and interested WG members can work on it, and will be worked in synchronisation with the low level API

<hhalpin_> Editors Draft not necessarily so

<hhalpin_> How about times for next meeting?

<markw> Well, there's certainly no consensus to publish a heartbeat without it, right now

<hhalpin_> I suggest given things up in the air, we meet next week.

virginie: our next call is the 10th of December, in two weeks.

<johnsim_> i agree

virginie: we will address the items we didn't have time to address today.

<hhalpin_> We are in a bit of a mess, Virginie, given we need a heartbeat by mid-Dec.

<hhalpin_> We need to have that doc ready by next call

<hhalpin_> Rsleevi, do you think that's possible?

<rsleevi> @hhalpin: The update? Yes.

<hhalpin_> Given a review by Alex Russell as well?

<hhalpin_> I.e. we need to address 1) Security considerations 2) usability and 3) IRTF comments

<rsleevi> hhalpin_: Yes, there's a lot of stuff to propose there

<virginie> @harry yeap, sorry that we could not adress that topic

<rsleevi> hhalpin_: regarding usability, I don't know if we'll have that fully in the next heartbeat

<rsleevi> hhalpin_: That obviously requires more discussion than we've had thus far :)

<hhalpin_> rsleevi, if you get Alex's comments in, I can also run it by Robin Berjon etc.

<virginie> harry, ryan, david d, what do you think about a call to define what is feasible for our next heartbeat ?

<hhalpin_> yes, the problem is that this KeyStorage discussion continously distracts us from primary features

<hhalpin_> I think we should at least do a call next week with the editors to prepare for the next heartbeat

<hhalpin_> trackbot, end meeting

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Wan-Teh
Found ScribeNick: wtc

WARNING: No "Topic:" lines found.

Default Present: ddahl, +1.512.257.aaaa, +1.650.525.aabb, virginie, wtc, rsleevi, WSeltzer, Karen?, +1.408.540.aacc, markw, pal, mitchz, hhalpin, [Microsoft]
Present: ddahl +1.512.257.aaaa +1.650.525.aabb virginie wtc rsleevi WSeltzer Karen? +1.408.540.aacc markw pal mitchz hhalpin [Microsoft]

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 26 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/26-crypto-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report