See also: IRC log
<trackbot> Date: 10 December 2012
<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
<scribe> scribenick: wseltzer
virginie: any objection to previous minutes? Approved.
<arunranga> zakim unmute me
virginie: Arun, can you introduce the use cases?
<markw> I know, sorry!
arunranga: Still chasing down a
few people, including Mark, to give a bit more from a Netflix
... 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
... 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
... 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 :)
virginie: Any objection to having the spec go for publication 17 Dec?
[+1 = no objection]
<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
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.
virginie: I'm sure you're all
aware of how Mark came to prepare new specification on key
... 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
... 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_: 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.
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.
rsleevi_: obviously lots of
... 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
... 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
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.
rsleevi_: having a key-value store doesn't really fit
virginie: does that make
... 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.
<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, +126.96.36.199.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 +188.8.131.52.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[End of scribe.perl diagnostic output]