See also: IRC log
<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.
<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.
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.
<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.
<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[End of scribe.perl diagnostic output]