<trackbot> Date: 10 December 2012

hi virginie

<mountie> hi

<zooko> hello!

<ddahl> hi zooko

<zooko> Hi ddahl

<arunranga> Use Cases document in HG: http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f94c/Overview.html

<mountie> I'm at home. not available to use voice

virginie: Thanks to people for making the effort to join this call, especially US folks for whom it's early, Asia for whom it's late

[agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0005.html]

<scribe> scribenick: wseltzer

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

virginie: any objection to previous minutes? Approved.

Use Cases

<arunranga> zakim unmute me

virginie: Arun, can you introduce the use cases?

arunranga: http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f94c/Overview.html

<markw> I know, sorry!

arunranga: Still chasing down a few people, including Mark, to give a bit more from a Netflix perspective.
... Goal is to give use cases, show sample code.
... Got lots of good feedback from Facebook, a real-world use-case.
... Questions still remain, such as whether we can do better with HMAC.
... Good feedback from Tantek, who wants to use public keys.
... If all follow up with me, we can have a draft by mid-week for heartbeat.

virginie: questions for Arun?
... as you can see: banking transactions, video services, code sanctity, encrypted communications

arunranga: nobody should be misled by the fact that I may have used Korean names, not a one-to-one match with S. Korea
... tried to construct the use-case around mountie's email

<hhalpin> did we test to get consent to publish?

virginie: people who need to provide arun with additional details, please have a close look
... we are trying to get this published at next heartbeat, WG consensus to go forward for publication on 17 Dec.

<hhalpin> So everyone has a deadline to read it by the 17th :)

<zooko> +1

virginie: Any objection to having the spec go for publication 17 Dec?

<hhalpin> +1

<virginie> +1

<ddahl> +1

[+1 = no objection]

<mountie> +1

<hhalpin> Just this one for now

pal: is this publication of this spec alone, or others?

<hhalpin> although we hope to publish all three (API, Mark's document, use-cases) in the next heartbeat

virginie: To start, I asked just about the Use Cases.
... I'd like to get consensus for publication of each separately.

pal: Recommend asking the question specifically so people know what they're approving.

virginie: Any objection to having Use Cases doc published 17 Dec?

pal: no objection

virginie: great, we'll go forward with the use cases on 17 Dec

arunranga: Main goal is to produce primary, achievable use cases, that the API as it's emerging in draft can accomplish
... not secondary use cases

<hhalpin> Its OK to list secondary use-cases as long as they are clearly marked as "secondary" and without consensus.

virginie: Did you make any statement re relation between WebCryptoAPI and use cases?

arunranga: I'd be happy to take feedback and add a note to that effect.

<scribe> ACTION: virginie to propose language on relation between WebCryptoAPI and use cases [recorded in http://www.w3.org/2012/12/10-crypto-minutes.html#action01]

<trackbot> Created ACTION-70 - Propose language on relation between WebCryptoAPI and use cases [on Virginie GALINDO - due 2012-12-17].

virginie: The way you're writing this, we could later add new secondary features

arunranga: yes

markw: Clarify that use cases should be able to include pre-provisioned keys?

arunranga: yes, we can include pre-provisioned keys. Looking to you (markw) for detail
... we can include a caveat that this particular feature may not be included in the WebCryptoAPI yet, but members of the WG are actively discussing

markw: I don't consider it a secondary use case. It should either be published in the main draft or in the additional doc we're working on.

New Spec Key Discovery

virginie: I'm sure you're all aware of how Mark came to prepare new specification on key discovery
... how to identify keys that may be pre-provisioned, so separate document.
... is there any problem or objection, or anyone who'd like to help Mark?

markw: The intent is that this spec will have the same timeframe and Rec status as the main API
... either we should publish this at the same time as the main API loses support for pre-provisioned keys, so it's an atomic change
... when writing the new draft, only included suppor tfor origin named pre-provisioned keys.
... no reason it couldn't include others, so the timeframe is not impacted

<arunranga> Link to draft?

markw: added some material on privacy, based on indexdb document

<virginie> Key discovery specification proposal http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0001.html

<hhalpin> I'll work on this after the phone call

markw: Attached document to email because couldn't yet get it into hg tree

<hhalpin> its possible there's an issue re permissions

virginie: when you say we're publishing at the same time, do you mean heartbeat or more formal steps?

markw: I mean for the heartbeat.

<hhalpin> i.e. by Dec 17th

markw: can we do it this time?

virginie: I have no problem putting them on the same track. Will we be ready for 17 Dec?

<arunranga> notes rsleevi is on the q

virginie: question for the group, who has something to say about new spec? any objection to publishing?

<rsleevi_> +1

<hhalpin> +1

rsleevi_: My suggestion would be to keep different forms of key discovery in different specs, for what implementers need.
... Mark's approach is good, useful to implementers interested in that functionality.
... There are technical concerns, but no reason not to publish the draft.

virginie: thanks

hhalpin: We can release multiple docs in the heartbeat.
... We need to specify when we release whether we expect them to be normative.
... And we'll say with Mark's doc that we expect it will be normative.
... Both API and Key Discovery will have to go through the same process.
... To become W3C recs, they need implementation, testing, vote from W3C AC
... let's send both docs down the normative track. Try to keep them to the same schedule

virginie: +1 to what harry said.

<hhalpin> Just to make sure W3C process is clear here

virginie: Mark, anything more we need before publication?

<hhalpin> its OK to publish drafty things

markw: I expect comments over the week, but don't see any problem with going ahead.

virginie: Any further comments? We'll go through formal process to approve pub next week.
... Thanks Mark for doing this quickly.
... Thanks both Ryan and Mark for working on docs.

Web Crypto API

<rsleevi_> https://dvcs.w3.org/hg/webcrypto-api/log

rsleevi_: obviously lots of changes.
... most of the focus is trying to resolve usability issues, tighten up API
... total 22 changes, some more significant than others.
... Highlighting: removal of key storage and key attributes.
... keystorage has been discussed at length on ml.
... intent to add text highlighting key discovery elsewhere.
... Key attributes, tightly coupled with notion of key storage
... e.g. if something is stored on a smartcard, attributes might change without the user agent
... exposing attribs as persistent not a good fit.
... so instead, make just the core functions of the key are attribs; others are stored where you store the key.
... application-specific or advisory attribs should be defined along with how you get the key from storage.
... e.g. synchronous, handles, etc.
... Concat added as an algorithm.
... Another change, overall workflow.
... earlier draft closer to PKCS11. init, process... , complete
... intent to share the objects, but implementers had concern it was too specific.
... explicit initialization step removed.
... that also removes the recyclability of crypto ops.
... added ability to supply data to be processed in call, e.g. hashing
... those are some of the major changes.
... easiest way to see them in practice is to look at examples doc.
... process data flow and state machine transition simplified for both developer and implementer.

virginie: Any questions for Ryan?

hhalpin: sounds sensible. 2 Qs: what did we do re zooko's questions on taxonomy of labeling?
... did we have any usability feedback?

rsleevi_: taxonomy label distinct from security considerations.

<slightlyoff> I have provided some feedback to rsleevi_ in private mail

rsleevi_: didn't think the taxonomy was a good fit.

<hhalpin> The taxonomy wasn't accepted I remember, but checking on security considerations

<zooko> +q

rsleevi_: Security considerations have not yet been incorporated.
... focus this time was usability.

hhalpin: we might want to have security considerations in this round.

<rsleevi_> Security considerations will not happen in next ED

<slightlyoff> in particular, I continue to think that the CryptoOperation class needs to be a form of Promise

<rsleevi_> (at least, I don't have time, ddahl?)

hhalpin: to address earlier comments, if we can.

<slightlyoff> and it's not today

rsleevi_: I disagree it's necessary for the next WD. Don't see that I can add it.
... don't need to duplicate IRTF doc.

virginie: we might have more developments re security review when David Rogers takes it up.

<rsleevi_> slightlyoff: A non-multi-part CryptoOperation yes, but I don't think a multi-part operation fits in the promise model

<mountie> for security consideration, we need to reference WebAppSec WG CSP

<hhalpin> its generally good to be able to point to our response from a previous heartbeat in a new hearbeat, but we do of course only have so much time.

markw: We haven't discussed removal of key attribs before
... is the intent that other specs might add attribs?

<ddahl> rsleevi: Perhaps, I thought we had some new language for that section?

markw: re pre-provisioned keys, we discussed ID attrib.
... re unwrapping, there might be attributes inside the wrapper, exposed on unwrapping.
... that would resurrect the requirement for attribs on the key.

rsleevi_: key attribs relies on things not yet specified by JOSE
... would prefer not to include something on which there's no proposal for how it's going to work.

<slightlyoff> rsleevi_: if there's a single answer to the operation (a single result), then it fits.

rsleevi_: once there's more work from JOSE re key wrapping, we may reconsider.

<rsleevi_> slightlyoff: Agreed

<Zakim> rsleevi_, you wanted to respond to mark

markw: can other specs add attributes?

<hhalpin> In W3C process terms, there's no problem with specifying certain key attributes in a different document

arunranga: also my Q. if a web developer wants to determine validity, they need to engage with the app?

<hhalpin> it just makes things more confusing for readers.

rsleevi_: start-date and end-date removed at our first face-to-face. too much variation.
... all these notions of validity are more closely related to application than to key storage.
... they're not universal concepts.
... very few APIs, except PKCS11, allow you to add attribs

<slightlyoff> rsleevi_: 12.1's multi-part steps suggest to me that there's a single return value

rsleevi_: Problem: exposing attrib directly leaves it undefined for all keys that don't have the attrib
... either you're defining default values or saying it may be present.
... Problematic if the underlying external storage system changes attribs, how do I reflect that to the caller? what's the UA to do?
... so for key object, if you want to talk about validity, stick it in indexdb, leave it to application to both store and enforce.

<arunranga> ack

rsleevi_: having a key-value store doesn't really fit

virginie: does that make sense?
... does that mean we'll never have to use attributes in main API?

zooko: I like Ryan's latest rev of the API.

<slightlyoff> it's not using promises yet

zooko: Consistently asynchronous using promises; a few one-shot.
... still think it would be good for usability and security to label algorithms as to whether they provide encryption, hashing, or something else

<hhalpin> I'm partial to attributes personally, but I'm not going to object.

rsleevi_: considering adding a table of contents, listing algorithms and supported ops.

zooko: Sounds like a way to express what algorithms do, will look.

markw: pre-provisioned keys creates a sub-class with attribs

virginie: any comments, send them and proposed resolution to Ryan
... so prepare for WG decision on publication 17 Dec.

<hhalpin> US-friendly time.

<hhalpin> 20:00 UTC

virginie: Additional call next week, 17 Dec. 20 UTC (3pm Boston, Noon Pacific)
... Quick question to David Dahl, progress on high-level API?

ddahl: Drafts on github, getting comments from Richard Barnes, Mike Jones. Will ping them again.

<mountie> 20:00 UTC ==> 05:00 AM KST

virginie: please share on public list when in shape.

Group Life

<rsleevi_> @slightlyoff: Both single and multi-part operations may result in multiple outputs (via progress events), along with a final event (oncomplete) indicating that the operation is completed / final values are calculated (or validated). Example of multiple onprogress events would be an encrypt (single part or multi-part), example of intermediate onprogress events but a single oncomplete would be a decrypt/MAC verify

virginie: We'll have to decide when to hold our next meeting.
... We have offers from Korea and Boston for hosting.
... but first I'd like to find a date. Please fill out the doodle.
... We'll continue alternating phone call timing.
... In January, one call every two weeks, alternating times.

<rsleevi_> @zooko: Consider something like Table 34 of http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pdf or http://www.w3.org/TR/xmlenc-core1/#sec-Table-of-Algorithms

<slightlyoff> rsleevi_: so in the multiple progress for multi-part encrypt, are the chunks handed to the progress events also part of the final result?

virginie: Next week, 17 Dec call to prepare publication.
... thanks to all the editors for their hard work

<rsleevi_> @slightlyoff: That's what I think we're trying to figure out and nail down ;)

virginie: Ryan, Arun, Mark, thank you!

<rsleevi_> @slightlyoff: Whether to follow the File API model (which is "Yes"), or to follow the "save memory model" (which is "no")

virginie: next week, focus on getting consensus to go for publication.
... talk to you in a week and on ml.

RRSAgent: make minutes

<slightlyoff> rsleevi_: if we want a streaming crypto operation, we should do that orthoginally

trackbot, end teleconf

<zooko> rsleevi_: this comment confused me:

<zooko> // Unlike the signing example, which showed multi-part encryption, here we

<zooko> // will perform the entire AES operation in a single call.

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)

Succeeded: i/virginie: I'm sure you're all/Topic: New Spec Key Discovery
Succeeded: s/wouls/would/
Succeeded: s/as to/to label algorithms as to/
Succeeded: s/supporting/supported/
Found ScribeNick: wseltzer
Inferring Scribes: wseltzer
Default Present: +1.571.335.aaaa, Wendy, Nat_Sakimura, +1.408.458.aabb, Scott_Kelly, +1.303.543.aacc, zooko, ddahl, +1.512.257.aadd, +1.415.867.aaee, markw, virginie, arunranga, +47.40.22.aaff, +1.650.525.aagg, pal, Havard_Molland, +82.22.14.0.aahh, mountie, Alex_Russell, +1.512.343.aaii, karen, hhalpin, [Google], [Microsoft]
Present: +1.571.335.aaaa Wendy Nat_Sakimura +1.408.458.aabb Scott_Kelly +1.303.543.aacc zooko ddahl +1.512.257.aadd +1.415.867.aaee markw virginie arunranga +47.40.22.aaff +1.650.525.aagg pal Havard_Molland +82.22.14.0.aahh mountie Alex_Russell +1.512.343.aaii karen hhalpin [Google] [Microsoft]
Found Date: 10 Dec 2012
Guessing minutes URL: http://www.w3.org/2012/12/10-crypto-minutes.html
People with action items: virginie