See also: IRC log
<trackbot> Date: 23 April 2013
<hhalpin> Anyone in IRC not here physically?
<rsleevi> Meeting: WebCrypto WG F2F April 23, 2013
<rsleevi> Chair: virginie
<nvdbleek> scribe: nvdbleek
<scribe> scribenick: nvdbleek
<scribe> scribenick:nvdbleek
<hhalpin> scribe: hhalpin
scribenick hhalpin
virginie: introduces the agenda
<rsleevi> Agenda for F2F also at http://www.w3.org/2012/webcrypto/wiki/F2F_April2013
virginie: AOB?
... notes twitter map, use #W3CSanJose hashtag http://bluenod.com/map/sotb3
virginie: 45 participants, 12 invited experts
... real life about 15 people on calls
... Apple, Inventive Designer, Aymeric Vitte, Karen and Jim as invited expert
... deliverables extended by 9 months
... web cryptoAPI LC October
... Key Discovery API
... Use Cases Document
... some "maybe" deliverables
... high-level API
... security framework
... notes open ACTIONS and ISSUES are mostly out of date
... implementations: Polycrypt.net and now one by Inventive Designer
<rsleevi> TPAC is Nov 11-15
next f2f 11-15th of Nov in China
<wseltzer> [http://www.w3.org/2013/11/TPAC/]
notes that rsleevi and jim schaad may be at risk for next f2f
rsleevi: some open issues that I'm pushing to close them
... dependency on HTML
... support of node.js, server based environments
... wants time to discuss Futures
... event model is the only dependency we have on the DOM
... there will still be a dependency on the DOM if we transition to futures
... but it does not require mutations etc, so can polyfill
<rbarnes> futures in whatwg spec: http://dom.spec.whatwg.org/#futures
rsleevi: final decision on defaults and how to handle them
I volunteer to double-check ACTION and ISSUE list during 10:00 AM coffee break
<rsleevi> DOM Futures: http://dom.spec.whatwg.org/#futures
<rsleevi> Latest ED: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
<rsleevi> CryptoOperaiton interface: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#cryptooperation-interface
<rsleevi> KeyOperation interface: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#KeyOperation-interface
rsleevi: one concern in DOM elements is there are things that don't make sense, crypto shoudn't bubble or be cancelled in an async API
... led by script-coord and TAG is a way to look at WebApps APIs and migrating them to Futures
<ddahl> Futures are also referred to as "Promises"
rsleevi: already present in JQuery
... and many other APIs
<rsleevi> new CryptoOperation(...).process(SomeData).then(process(some_more_data)).then(process(even_more)).then(finish(...))
<slightlyoff> Futures aren't a heavy DOM dependency
<rbarnes> i actually don't think that example works
<slightlyoff> they only need the event loop, which node does provide
<slightlyoff> (sorry, can't join the call)
<rbarnes> as i understand it, then() calls don't chain like that
<slightlyoff> rsleevi:
<slightlyoff> that's some wonky API
<slightlyoff> unless process returns functions
israel: from the serverside, do we need to implement a whole DOM model
... to be crypto compliant
<slightlyoff> israelh: no, only Futures and whatever else is implied
israel: if we are to implement any kind of shimming
... bubbling and capturing come into play
... if its just async notifications then its not a big deal
<rbarnes> fwiw, here's polycrypt's half-hearted polyfill: http://polycrypt.net/common/pcevent.js
israel: that's Microsoft's main concern
rsleevi: removes bubble-able, cancelable, all you need is event loop
<slightlyoff> rbarnes: there's a polyfill for Futures here: https://github.com/slightlyoff/DOMFuture/tree/master/polyfill
ddahl: we've seen JS move away from DOM and into other place
<slightlyoff> and it runs on Node already
ddahl: its a huge plus for developers
<slightlyoff> ddahl: we don't need to implicate all of DOM for this...I'm happy to invite annevk here to help clear up the misconceptions
<rbarnes> slightlyoff: duly noted for polycrypt adaptation once ryan changes the spec :)
ddahl: using Futures, we don't have to switch contexts
<slightlyoff> 'cause I'm hearing only "it says DOM!" on the tin, not a real objection based on inspection of what Futures are
<slightlyoff> hhalpin: understood.
nvdbleek: how do you do error handling?
<slightlyoff> hhalpin: which is why I'm trying to dispel potential misconceptions early = )
<slightlyoff> .then() handers take both success and error callbacks
<tlr> slightlyoff, we can dial into bridge if you want to listen in
<rbarnes> .then(success, failure)
rsleevi: you just do normal catches with .then(), no dependencies of DOM stuff like observers
mwatson: what's the deal with ECMA and Futures?
<slightlyoff> I've asked annevk to joine
<slightlyoff> I'm on TC39
rsleevi: many of ECMA TC39 people are working on Futures, its can all be implementable in ECMA functions
<nvdbleek> ack, me
<tlr> annevk, slightlyoff -- we're not currently on bridge, but can dial in if you want to listen to discussion
<slightlyoff> and DOM moves faster than TC39, which is why it was decied we'd do it there first and them move it back into the language
rsleevi: it just uses language concepts rather than DOM concepts
<ddahl> virginie: we need the phone dialed in
rsleevi: so it will probably come in future ECMAscript
<slightlyoff> tlr: sorry, in another meeting, can't join = (
mwatson: how will migration be?
<annevk> tlr, thanks, but I'll try to follow from here
rsleevi: it should just work
<slightlyoff> hhalpin: compatible = )
<slightlyoff> hhalpin: if we do it right
rsleevi: by integrating it into language we can ofcourse optimize better
<slightlyoff> hhalpin: subsetting and/or core API compat
<slightlyoff> the best-case scenario is that this happens as a mass import and "Future" becomes a class that ES defines, not DOM
<slightlyoff> which is entirely compatible
<slightlyoff> (so logn as the APIs are)
<slightlyoff> worst case, they diverge somewhat, and ES defines "Promise"
israel: whats the issues with doing DOM in Futures?
<slightlyoff> in that case, DOM re-casts it's class as a subclass of that
<slightlyoff> in which case we still get compat
<slightlyoff> there's nothing really DOM-ish about Futures at this point
<slightlyoff> only that the event loop doesn't exist in JS-the-language yet
rsleevi: so far, no global scope problems, we haven't had problems there
<slightlyoff> and it does in DOM
<slightlyoff> and won't until ES7
<slightlyoff> which is a LONG way off
rsleevi: how to handle progressive events
... Futures is a single listener
... crypto works well for that
<markw> \me @slightlyoff: thx - makes sense
rsleevi: there is active discussion on progressive notifications, as that doesn't impact our API
... as we have the FSM with "progress" and "finish"
MichaelH: the intention is to make this API work on the serverside?
rsleevi: current security considerations are non-normative
... serverside has a different privacy model
... client side, that's why we used structured clone
... to avoid privacy issues etc.
... in node.js environment, you'll have a trusted domain, you don't have those non-normative concerns
... in a hypothetical world, you have a single-server instance with multiple applicaiton containers, you might scope key material to application containers
... but none of the normative bits of spec are impacted there
MichaelH: on client side, we can have certain security checks like same origin, isn't that done in UA?
<annevk> FWIW, futures are completely self-contained.
rsleevi: the checks aren't in the API, the checks on same origin come from structured clone, i.e. IndexedDB
... node.js would just support whatever structured clone it tends to use
... i.e. a simulation of localStorage
<annevk> We're implementing them in Mozilla and would love APIs to adopt them to give developers a saner experience long term.
mountie: in certificate side, the UI is impacted, so when we implement on server side, then there are considerations for same origin policies
<slightlyoff> we've also got an engineer lined up on the Chrome side
mountie: structured cloneable is not acceptable for the Korean use-case
<annevk> Also, personally, I think if node.js favors a different API from browsers that is okay. But for browsers futures the way forward (the future, harhar).
<annevk> is the way*
rsleevi: quick response, as regards Key Discovery there's different concerns from a web browser than from outside
... the security considerations objection from Korea as regards structured clone we should do after lunch
virginie: what's impact?
rsleevi: everything is based on event model
<slightlyoff> again, not part of the current discussion, but if anyone has questions about Futures, you can mail me
rsleevi: we still have a normative dependency on DOMSpec, but we don't use event model
<slightlyoff> (slightlyof at chromium dot org)
rsleevi: the idea is that we can get by the objections
israelh: what is impact on that for us as a browser?
... changes in our JS engine, in our browser engine?
rsleevi: alex russell (slightlyoff) can solve this, so there's a polyfill with events
... we aren't touching ECMAscript here
<ddahl> israelh: this is the mozilla bug for futures: https://bugzilla.mozilla.org/show_bug.cgi?id=856410
rsleevi: just adding javascript function to queue
IsraelH: compliancy seems we don't want polyfills
<rsleevi> http://dom.spec.whatwg.org/#futures
rsleevi: taking advantage of Javascript functions so we can implement it within JS on the DOM side, so it should be indistguishable?
<rbarnes> retroactively :)
israelh: polyfills have a dependecy on something, if we package that ahead of time, we should not be able to pull it in
rsleevi: yes, no 3rd-party pull in
... futures is so minimal so that it should be done inside API
<rsleevi> repasting slightlyoff's polyfill - https://github.com/slightlyoff/DOMFuture/tree/master/polyfill
selfissued: your description of Futures sounds like best engineering solution we have
... we're not inventing anything, small, self-contained, impact on implementations is minimal, and already existing practice on server-side
... israel is the expert here for IE
MichaelH: the idea is to replace Events with Futures model
rsleevi: so KeyOperation would just be a future
<slightlyoff> MichaelH: yeh, that's the basic idea
rsleevi: we'd entirely eliminate event model
... we are not doing progress events
<rsleevi> https://github.com/slightlyoff/DOMFuture/blob/master/reworked_APIs/WebCrytpo/after.idl
hhalpin: we should take an action to have rsleevi update to Futures unless there's an objection
<rsleevi> Coffee break; reconvene in 15 minutes
<annevk> tlr, is futures done being discussed now?
<tlr> in a side meeting
<rsleevi> hhalpin: We should just walk through the ISSUES and ACTIONS, a lot of have been defacto decided, just need to have a dejure process
<rsleevi> scribenick: rsleevi
<hhalpin> https://www.w3.org/2012/webcrypto/track/issues/open
<jinsh> exit
<ddahl> +1
<arun> annevk, we did discuss Futures. The action is that rsleevi will work on a Futures-based WebCrypto draft.
<hhalpin> PROPOSAL: New editors draft should use Futures
<hhalpin> +1
+1
<arun> +1
<nvdbleek> +1
<annevk> arun, coolio
<ddahl> +1
<markw> +1
<virginie> +1
<jin> +!
<jimsch> +1
<jin> +1
<MichaelH> +1
<MichaelH> instead
<hhalpin> RESOLVED: New editors draft should use futures
<israelh> +1 to have Ryan work on a new version of the spec that shows how futures can be integrated
https://www.w3.org/2012/webcrypto/track/issues/open
hhalpin: We're gonna go through the issues list and walk through them very quickly
... anyone who objects to closing the issue, make your voice heard
<hhalpin> scribenick: hhalpin
rsleevi: anyone who objects needs to propose a way to solve
... the issue
<rsleevi> ISSUE-5?
<trackbot> ISSUE-5 -- Public vs. private key pairs -- managing the key pair via a single or multiple handles -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/5
rsleevi: do you get one or two key pairs with asymmetric - current spec treats them separately?
... since this API provides no storage, we don't do search for them
MichaelH: How do you know they are associated?
rsleevi: your application has to make them store that state
hhalpin: on a high-level, we could imagine a library keeping track of store
rsleevi: key discovery of certificates assumes some key storage, but the question is do we need low-level coupling?
<nvdbleek> Example of layering it on top of the low level API: https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API#x509certificate
israelh: by virtue of getting both back at once the issue is solved
rsleevi: key object is a promise there is key material *somewhere*, but the key material itself doesn't necessarily go into indexedDB
... that key material may exist in keyStorage, what is stored is a exists
karen: keystorage is dependent on UA?
rsleevi: correct
... key object is a promise that key material exists, when you try to use key object then crypto-operation fails if key doesn't exist
ddahl: there is storage, the key property allows API behind the scene to get a hold of material, no public
rsleevi: default is non-exportable
virginie: any objections?
<rsleevi> ISSUE-8?
<trackbot> ISSUE-8 -- Making sure we describe the clean key neutering -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/8
<nvdbleek> issue-8?
<trackbot> ISSUE-8 -- Making sure we describe the clean key neutering -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/8
PROPOSAL: Close Public vs. private key pairs -- managing the key pair via a single or multiple handles: we generate two key objects and application maintains state
<scribe> CLOSED: Public vs. private key pairs -- managing the key pair via a single or multiple handles
<ddahl> +1
PROPOSAL: CLOSE Making sure we describe the clean key neutering key neutering
arun: its not really relevant
<rsleevi> ISSUE-9?
<trackbot> ISSUE-9 -- what will be the mean to integrate in the API the fact that key usage may need user consent ? -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/9
PROPOSAL: CLOSE ISSUE-9: what will be the mean to integrate in the API the fact that key usage may need user consent ?
<ddahl> use a french accent when speaking to the chair
arun: its using same origin, so whats the point?
rbarnes: there is postMessage for cross-origin sharing, but we don't want user consent
... for every postMessage
mountie: user consent seems dangerous, in our historical experience users always click yes
<ddahl> users will have no idea what "is it Ok for foo.com to create a keypair for you?" :)
rsleevi: no user consent considerations in current API, although maybe in Key Discovery
karen: who owns the key? currently is webapp, or is it user?
... if user owns key, then user has to consent
... all the keys are owned by the webapp
mountie: big issue, who do keys belong to?
<nvdbleek> If we close this issue could we add a comment to the issue, that this issue is about the low level API and *not* about any future key discovery API
rbarnes: key export is one way to have accountability
drogersuk: is there any kind of holding issue around the security and usability?
hhalpin: thinks that it goes into scope of key discovery
drogersuk: we should do a security review of key discovery
<drogersuk> ...and security review of web crypto api too overall
MichaelH: What about government exposing API?
rsleevi: this API will interact with other key discovery mechanisms with pre-existing key material in smart cards, platform storage, etc.
... but we are trying to avoid those
MichaelH: What's the point of the API then?
rsleevi: persona uses keys without using pre-existing keys and uses postMessage to interact with potentially hostile use-cases?
hhalpin: we are trying to move key import/export into the Key Discovery
MichaelH: Yet about sign?
<markw> @hhalpin: why ?
@markw key discovery is essentially "import", correct?
I've noted there's no export anywhere.
<rbarnes> hhalpin: i thought there was export in the API
markw: if someone can build it into polyfill without user-interaction, then why require browser to polyfill?
israel: what is expectation for user? for us to ask the user is to break application?
<markw> @hhalpin: in the main draft, import/export refers specifically to passing keying material between JS and UA
<ddahl> +1 on no more modal dialogs!
@markw: I was discussing the pre-existing key material quesiton from MichaelH
<markw> @hhalpin: key discovery is the UA accessing keys that are stored somewhere else (i.e. did not come from the script through import)
<markw> so, key discovery != import
@markw, then the real question is then should import/export be done anywhere?
karen: there are cases where consent is needed with different kinds of keys
rbarnes: that is more of an access control issue, we are not defining on what keys can be used for
<markw> @hhalpin: sure, I think several of the use-cases need import or export
karen: we should make this clear
markw: do we rely UA for access control, then your totally open to attack
... due to polyfill problems
rsleevi: we should not exist other specs
<rbarnes> well, everything *except* the key isolation is polyfill-able
<rbarnes> but that's not what we're talking about here
<markw> because the main API is polyfillable, any application which relies on UA behaviours (such as user auth) is open to attack by the page being modified to use a polyfil instead of the UA WebCrypto
rsleevi: that may not exist
<markw> this is exactly why you need key discovery some some applications, because that key is *only* available through the UA and you can then rely on the UA authorization UI
nvdbleek: we are not preventing access via some special UI
... adding extra text that its not allowed to access is not a good idea
<rsleevi> @markw: +1. New specs can add new UI as appropriate - or any other additional access controls
<arun> Ultimately, users are at the mercy of the origins ("domains") they visit. WebCrypto doesn't alter this.
<virginie> Proposal : close the issue-9, have an action for karen to suggest a sentence explaining that the key belongs on to the webapp, open a action to review the spec in terms of user interaction
PROPOSAL: CLOSE what will be the mean to integrate in the API the fact that key usage may need user consent ?
<rbarnes> +1
<MichaelH> +1
+1
<rsleevi> +1
<virginie> +1
<nvdbleek> +1
<ddahl> +1
<markw> +1
<arun> +1
<jin> +1
<vgb> +1
<MichaelH> -1
<jimsch> +0
The proposal is that no new text is necessary to add to the specification about user interaction
<israelh> +1
<mountie> +1
<nvdbleek> But not completely sure we need extra text, we need to be carful not to block use cases that are solved by the current spec
virginie: we re-visit tomorrow after MichaelH talks to rsleevi
jimschaad: not quite happy to close it, maybe the security and legal implications are not clean
<nvdbleek> ack, me
drogersuk: should we have 'userdenied"?
rsleevi: but that leaks information?
... namely, it reveals key exists
drogersuk: signing invoices, contracts on the web
nvdbleek: smart cards have popup for PIN
... that would inside smartcard, not web app
ddahl: session pop-up like geolocation, that's only what mozilla implents
<ddahl> hypothetically, it is the only kind of thing I can see Mozilla implementing, but I doubt it
<rsleevi> hhalpin: The proposal is that we say nothing in the current API
<rsleevi> ... that when other APIs exist that may need to specify additional properties, such as smart cards, they specify it then
<rsleevi> ... the only place that you can see there being maybe concerns is related to key import/export
<rsleevi> ... perhaps revisit this tomorrow morning, but that we try to close this out before the end of the F2F
<rsleevi> karen: earlier there was the comment about leaking information.
<rsleevi> ... is there a way to not tell the application the failure is because the key doesn't exist or because it was denied
<rsleevi> rsleevi: That was in the old spec, when we dealt with key discovery. That you don't have distinct error codes
drogersuk: my idea is to look at errors
... geolocation didn't work
... after 5 clicks it just remembers what you've said forever
virginie: lets revisit this issue with this action tomorrow
<rsleevi> ISSUE-10?
<trackbot> ISSUE-10 -- Making sure our API is usable with pure js environement -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/10
<rsleevi> ISSUE-12?
<trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/12
<rsleevi> ISSUE-14?
<trackbot> ISSUE-14 -- Representation of raw key material -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/14
JWK for import/export
PROPOSAL: CLOSE Representation of raw key material as we are dealing with JWK for import/export
<rsleevi> ISSUE-19?
<trackbot> ISSUE-19 -- Does it make sense to have authorized-origin and specific-origin keys -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/19
CLOSE ISSUE-19: Does it make sense to have authorized-origin and specific-origin keys - dealt with by same origin
<rsleevi> RESOLVED: Close ISSUE-14
<rsleevi> RESOLVED: Close ISSUE-19
<rsleevi> ISSUE-21?
<trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/21
<mountie> +q
mountie: we don't cover CSP in its entirety
ddahl: An informative action
... to add a little note
mountie: I found the WebAppSec approach is different than our approach in Korea
... but some things are not touched, some are not overlapped
... so we need to add a comment to WebAppSec
... or we handle it differently
<rsleevi> scribenick: rsleevi
rsleevi: The proposal was to only expose the API to web pages that had opted into CSP
mountie: Perhaps for Web Crypto, we need more policies
virginie: Can you take an action to write a proposal
<ddahl> I think we want a *note* that cautions users of this API to know about and use a Content Sec Policy that makes sense for them. there are a million ways to use CSP and mandating a specific set of rules is impossible
<rbarnes> web sites that use this spec SHOUDL use CSP
hhalpin: Options are normative note - requiring CSP - informative note - telling people CSP exists and recommending it - or saying nothing
ddahl: Trying to mandate the use of CSP is a non-starter, completely, because there's a million ways to use CSP and a million ways to enact a policy
... Perhaps a lot of this stems from my ignorance last year when I raised this (laughter)
... Propose we put this as a SHOULD - developers PLEASE read this
<scribe> ACTION: sleevi to write informative text recommending CSP [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action01]
<trackbot> Created ACTION-78 - Write informative text recommending CSP [on Ryan Sleevi - due 2013-04-30].
PROPOSAL: Close ISSUE-21 with sleevi to address it via ACTION-78
RESOLUTION: Close ISSUE-21
ISSUE-23?
<trackbot> ISSUE-23 -- Should CryptoOperations and/or Keys support Transferrable semantics? -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/23
<hhalpin> operations need to transferable rather than cloneable to maintain internal state
PROPOSAL: Close ISSUE-23 with no action to the spec
RESOLUTION: ISSUE-23 will be closed
ISSUE-24?
<trackbot> ISSUE-24 -- Defining a Synchronous API -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/24
markw: There was a point where we wanted to do synchronous operations for window.close, but we're willing to let that slip
... There needs to be an ability to perform async operations on shutdown, but that's not an issue for this WG
PROPOSAL: Close ISSUE-24 with no changes
<markw> now we would like to do asyncronous operations in onclose instead ;-)
RESOLUTION: Closed ISSUE-24
ISSUE-25
<trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/25
PROPOSAL: Close ISSUE-25
RESOLUTION: Close ISSUE-25
ISSUE-26?
<trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/26
PROPOSAL: Close ISSUE-26
mountie: Is this related to certificates or key gen?
rsleevi: Because the spec has nothing to say about key storage or discovery, theres no way to give a Key object to another origin, short of postMessage
mountie: generating the keys in one origin and using the keys in another origin
... Maybe clonable can be a technical solution, but because of the political/technical restrictions
vgb: Why is clonable not suitable?
mountie: Key generation from Origin A and Origin B wants to use the key to initiate the signature
... Then Origin B needs to access the keys from Origin A
... that means only origin A can initiate the transactions
<hhalpin> rsleevi: if we see how native APIs solve this problem
<hhalpin> ... in every national scheme, there's a smartcard middleware
<hhalpin> ... there's some autohorization
<hhalpin> ... in Origin A and Origin B generates a message and Origin A has a message it wants to be signed
<hhalpin> ... user trusts Origin A and Origin B is an arbitrary application
<hhalpin> ... you don't want to just give your key to Origin B.
<hhalpin> ... you can use existing Web technologies (i.e. postMessage), Origin B can deal with use-cases and Origin A can do inbound checks
<hhalpin> mountie: postMessage we need a response before continuing other process
<hhalpin> ... we don't want to lose our JS logic
karen: What rsleevi described is certainly a workable solution - origin A always performs the signing as a service
<arun> mountie, rsleevi was referring to using code of this kind: http://html5demos.com/postmessage2
karen: but there are privacy concerns with this, in that origin A can always see what's being signed
<arun> mountie, this would be on a "per operation" basis; thus, "operated upon" payloads might be exchanged between domains.
karen: theres another scenario with pre-existing keys where the user owns the key
... where the user should authorize that Origin B should use the key
rbarnes: ... Isn't that a different issue? Back to discovering pre-existing keys?
rsleevi: Right. That's not cross-origin sharing
virginie: Is your proposal that you want to keep the issue open? Are you objecting to closing the issue?
ISSUE-26?
<trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- closed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/26
israelh: How is that scenario what you described different from what rsleevi described
karen: It's more related to key discovery
israelh: We should separate the two - the key discovery part and the origin sharing
hhalpin: There are two elements. Do we close out ISSUE-26 because everything we've done is dealt with same-origin-policy
<hhalpin> My proposal is to close ISSUE-26
<hhalpin> but then add new actions to have Karen and Mountie work through the use-cases tomorrow
<hhalpin> arun: Let's work through these use-cases, I think we can obviate them
<hhalpin> my suggestion is to have actions on mountie and karen to write these use-cases down and work thorugh them in person tomorrow
<hhalpin> MichaelH: Can WebApp A generate a key and then pass that key object to WebApp B - both those scenarios work, via postMessage/CORs
<hhalpin> rsleevi: yes, that's how it works
<hhalpin> vgb: cloning is cloning the pointer
PROPOSAL: CLOSE Issue-26
RESOLUTION: CLOSE ISSUE-26
<scribe> ACTION: karen to write up use case for the pre-provisioned key discovery use case [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action02]
<trackbot> 'karen' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., klu, kodonog).
<scribe> ACTION: mountie to write up a use case for the origin sharing [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action03]
<trackbot> Created ACTION-79 - Write up a use case for the origin sharing [on Mountie Lee - due 2013-04-30].
<scribe> ACTION: klu to write up use case for the pre-provisioned key discovery use case [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action04]
<trackbot> Created ACTION-80 - Write up use case for the pre-provisioned key discovery use case [on Karen Lu - due 2013-04-30].
ISSUE-28?
<trackbot> ISSUE-28 -- Short-names for algorithms -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/28
ddahl: It seems like something a high-level shim could do
vgb: I agree with Richard's point that it can help to usability
... We don't have to take (Dictionary or DOMString) - we can just make it take it in the name
richard: the question is whether it should be in the API or the implementation, seems generally useful to put in the API
selfissued: I don't have a strong position on whether or not we should have a short name form in the API, but to the extent that we do, I do think they should overlap with the JOSE JWA spec
... It would be silly to use a different string should this working group decide to do that
... but not taking a position on whether we should
markw: In a discussion with Ryan the other day, I realized this relates to the discussion of separation for operation and algorithm parameters
... My question is do you want short names for algorithms, or do you also want short names for operations
vgb: Algorithm seems like it makes more sense
markw: So the example of HMAC where you have the hash algorithm - should the hash algorithm be a property of operation or of the algorithm
... My proposal would be we have a clean separation of algorithm/operation parameters, and we only have short names for algorithm parameters
It relates to ISSUE-12
(which we postponed)
rsleevi: I certainly agree to the point that ISSUE-12 and ISSUE-28 are closely coupled
selfissued: The JOSE JWA algorithms are intended to be the complete specification of the cryptographic functions
jimsch: That's not a completely true statement - the IV is not included in the name
vgb: The MGF is more an algorithm parameter, not an operation parameter
selfissued: the IV is an input
jimsch: But so is the MGF
selfissued: The choice of MGF is an input that specifies a cryptographic function, and the JWAs attempt to specify all the cryptographic functions
markw: We already have examples of properties that are not intrinsic properties of keys. We have to make a (hopefully) non-arbitrary decision about what to bind to properties of keys
... I would err on the side of binding stuff to the key
jimsch: Would you argue that the hash (for RSA keys) is such a property
rbarnes, vgb: Yes
vgb: I would argue you want to early bind parameters
ISSUE-29?
<trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
PROPOSAL: Close 29
<vgb> +1
RESOLUTION: Treat ISSUE-29 as part of ISSUE-12
ISSUE-30?
<trackbot> ISSUE-30 -- How does the application know where the key is stored ? -- closed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/30
ISSUE-32?
<trackbot> ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/32
<scribe> ACTION: sleevi to describe we're not storing key material itself in IDB [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action05]
<trackbot> Created ACTION-81 - Describe we're not storing key material itself in IDB [on Ryan Sleevi - due 2013-04-30].
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security
<hhalpin> hhalpin: I've noted lots of confusion around structured clone that the minimum requirement (plain text) and maximum security requirements.
<hhalpin> ... perhaps an informative note would be useful?
PROPOSAL: Close ISSUE-32
RESOLUTION: Close ISSUE-32
<hhalpin> ACTION: vgb to write sentence about how structured clone relates to different types of key storage and that that key storage may have high-security implications (not in our spec!) [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action06]
<trackbot> Created ACTION-82 - Write sentence about how structured clone relates to different types of key storage and that that key storage may have high-security implications (not in our spec!) [on Vijay Bharadwaj - due 2013-04-30].
<rbarnes> so, would it be considered bad form to open issues during this meeting?
<rbarnes> there are a couple of things that were raised on the list that i don't think are reflected in the tracker
rbarnes: Only if we can't resolve them before lunch
<virginie> Diner location and time : 19:30 @ Scott's Seafood 185 Park Avenue San Jose, CA 95113 (408) 971-1700 scottsseafoodsj.com
<scribe> scribenick: nvdbleek
<hhalpin> https://www.w3.org/2012/webcrypto/track/issues/open
selfissued: Can you summarise issue 12
<wseltzer> Issue-12?
<trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/12
<hhalpin> I've generally seen "raised" used when your getting mailing list comments and trying to figure out if they are genuine problems or not.
rsleevi: You shouldn't mix algorithms for the same key
<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-oaep
rsleevi: how do you decide what goes were key algorithm or parameters
... There is a proposal
jimsch: How much of the parameters are encoded in the underlying key?
rsleevi: In most underlying APIs they don't store this specfic information, they don't prevent mixing algorithms
rbarnes: The UA should track this extra information
... besides tracking where the key lives
... The difference is things that are fixed for the live time of the key apposed to things that vary per operation (can be changed)
... I it could result in simplification
... it removes all duplication
selfissued: I had reason to read some cryptographic specs
... selfissued spec doesn't specify an encryption function
... The HMAC spec is in-depended from the algorithm
<rbarnes> virginie: what's on the agenda for >15:00 ?
selfissued: split-up by bound to key and data
... bake AES in GCM , but not IV
<rbarnes> virginie: i can scribe for that
vgb: I'm in favour of decomposition
... it makes it clear to naive implementers
... operation parameters must be changed per operation, the others won't change that often
<markw_> It makes it clear to *any* implementors ;-)
rsleevi: the counter argument of not being able to change this is that you have to know everything upfront
vgb: It depends on the use-cases
... not being able to change this will make it easier for users as it guides them what they should be able to do securely
rsleevi: we need to have a good definition to decide what goes were, otherwise we are going to have an inconsistent API
rbarnes: We could go by instinct for now, and then see what rules applies
rsleevi: Mark has documented everything
<rsleevi> ACTION: vgb and rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action07]
<trackbot> Created ACTION-83 - And rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition [on Vijay Bharadwaj - due 2013-04-30].
ACTION-83 due in 3 weeks
<trackbot> Set ACTION-83 And rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition due date to 3 weeks.
virginie: We keep the issue open
<wseltzer> ISSUE-29?
<trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
<rsleevi> ISSUE-29?
<trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
<rsleevi> scribenick: rsleevi
<nvdbleek> rsleevi: prupose to close issue 29
PROPOSAL: ISSUE-29 to be closed with no action
<rbarnes> the main reason i brought up padding was that the test vectors i was using for PolyCrypt *didn't* use PKCS7
ISSUE-39?
<trackbot> ISSUE-39 -- Add abort() to the KeyOperation interface -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/39
<nvdbleek> scribenick: nvdbleek
rsleevi: The keyOperation will become a Future
... In most API's you can't abort key generation
<rsleevi> michaelh: Question about generating a key and then exiting the browser
rsleevi: If you are using something that isn't specified in this spec, which requires user interaction, you may want an abort
michaelh: What happens when you create a key in an onAbort
<rsleevi> vgb: From the Windows side, it depends on what you were doing
<rsleevi> ... If you were using a software provider, it would just unload the DLL
<rsleevi> ... if you were using a smart card, it would reset the card. What that does is up to the card os
????: It varies on the type of key/device
<rsleevi> ... If you were using a network provider, it might reset the network connection
<rsleevi> ... it depends on what you were doing and whether or not cleanup would happen
<rsleevi> israelh: It really depends on where in the pipeline we're cancelling the call
<rsleevi> ... if we're cancelling while the task is still pending, before we've hit the native code, we can just not run it
israelh: It depends on were the cncelation happens before are after the native API call
<rsleevi> ... if we're in native code, it depends... we're not gonna return a JS object
rsleevi: That is why abort is tricky
jmackay: If you switch to the future, it is just never calling setvalue, you only my save CPU power
rsleevi: You won't be able to save CPU in all cases
<rsleevi> PROPOSAL: Close ISSUE-39?
virginie: It may be acceptable to remove this issue from scope
rbarnes: Who raised this issue
virginie: It is Wan-Teh
??vgb: Will the CryptoOperation still have an abort
rsleevi: I think so
... in the CryptoOperation will have multiple calls to the native API, so there might be a chance to stop calling the native API
<rsleevi> vgb: KeyOperation is atomic, cryptoOperation is not
<rsleevi> RESOLVED: ISSUE-39 to be closed with no action
<rsleevi> ISSUE-36?
<trackbot> ISSUE-36 -- Semantics for key generation versus key derivation -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/36
<rsleevi> ISSUE-43?
<trackbot> ISSUE-43 -- Separate method for key agreement -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/43
vgb: Recap: tension between derivations and protocol specific IPSec
<rsleevi> scribenick: rsleevi
vgb: There was a question of whether we could use generateKey with keys as generation params to yield Key objects
... and key derivation to yield byte streams
rbarnes: method names are cheap. It seems there are some conceptual differences
<nvdbleek> ?rbarnes: generate key has no input, derive does have input
vgb: A key derivation function doesn't necessarily give you a DES key with all of the parity bits
... Theres an argument where if I want to do that (where I start with a seed and do something), maybe there should be some easy way to do that
jimsch: Well, typically you derive keys for a specific algorithm
vgb: Well, if you're doing that, you'd typically derive some random bytes and use that for some input to generate a key
... generateKey just takes "here's the target algorithm", deriveKey typically takes a "here's a source algorithm to derive bytes, but doesn't tell you how to use those bytes"
... There's a third type though, that takes both a source and a target algorithm
<nvdbleek> vgb: you only provide the algorithm for generate key, in derive key you also have a source algorithm
<nvdbleek> virginie: What is the state in the spec
rbarnes: To be radical and blue sky about it, you could have an algorithm "here's a source of random bytes, derive me some keys"
... and conceptually, if you're drawing serially off a KDF stream, maybe you can do more interesting things
vgb: The challenges are like with IKEv2 where you're generating 4 keys
rbarnes: I was more talking about a stream object that you can read serially from
<nvdbleek> vgb: The question is does derive key give out a byte array or a key object
rsleevi: Where we ended up is that it outputs Key objects, which you could then export
jimsch: The real problem is sometimes I want to generate a key, sometimes I want to generate a blob
<nvdbleek> rsleevi: Currently it returns a Key object because it was better then a byte[]
vgb: The example is algorithms that generate a key and an IV, which take an output and splits it into a key and an IV
jimsch: And then you have interesting ones where you generate a key and a secret, then take that secret and derive a key and a secret, and continue chaining
<nvdbleek> vgb: Doesn't OAUTH generate multiple keys
vgb: Doesn't oauth generate multiple keys off the same Z value?
rbarnes: I don't know what the JWE specs coming out today say, but the currently published ones have a separate symmetric and mac key
<nvdbleek> rsleevi: You still need 2 keys
<nvdbleek> virginie: How do we going to progress those issues?
jimsch: One question - which way do you think is the more common case
<nvdbleek> jimsch: What is the most common case
jimsch: Could you generate a Key blob, export it, then split the bytes, then import it back as keys
vgb: I think Key and IV is a very common use case
jimsch: The question is which is more common. Does it make more sense to always just export bytes and then just reimport
vgb: My gut feel when reading algorithm specifications is they assume the KDF is some sort of PRF where you split stuff up and import it
rbarnes: One of the issues is you don't specify how many octets of the KDF you want
virginie: I don't see us solving or progressing on that issue
... One suggestion is to have a dedicated call to explore the scenario and perhaps draft a solution
<nvdbleek> virginie: We could have a dedicated call
virginie: Proposal is on our alternate weeks dedicate 1 hour for an ad-hoc call to discuss this issue and come to a proposal
<nvdbleek> scribenick: nvdbleek
rsleevi: What is the deliverable of those calls? Do we say the key derivation is a feature at risk
<rsleevi> ACTION: vgb, rbarnes, jimsch to discuss key generation/derivation/agreement [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action08]
<trackbot> Error finding 'vgb,'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
rsleevi: We have to agree on a time frame for the solution
virginie: On the 6th of May we have an extra call
<rsleevi> ACTION: rbarnes vgb and jimsch to discuss key generation/derivation/agreement [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action09]
<trackbot> Created ACTION-84 - Vgb and jimsch to discuss key generation/derivation/agreement [on Richard Barnes - due 2013-04-30].
virginie: The call will be at 20UTC on 6th May
... on the 13th we will decide how to progress
... issue stays open
rsleevi: The issues that we could discuss before the break are all discussed
rbarnes: Some of the symmetric cryptographic it is sufficient that you generate a random IV every time
<virginie> ISSUE-44?
<trackbot> ISSUE-44 -- Require creation of random IVs by default for CBC, CFB, GCM -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/44
...: This isn't obvious for the common web developer
... If it is omitted the UA could generate one
... This would be more secure
rsleevi: I see pro's and con's we need to see for what we want defaults
... In some cases the IV should be protected
...: So generating the IV might be more dangerous
vgb: Some people set the IV to 0 even if they know that it is dangerous
...: We might be better of with a special value or a helper function to generate the IV
... e.g.: iv:auto
rbarnes: most of the time you want auto
<rsleevi> rbarnes: There's an element of developer ergonomics where it's just hostile to make users specify
hhalpin: there is been a study, developers regardless of what they now use what is available, so it should be very simple
...: an IV helper function makes sense
rsleevi: protecting the IV you have to ???
<jimsch> jimsch: Protection of IV, you should only use an AEAD function
<rsleevi> jimsch: There will have to be additional things returned from output
...: There are already other things that we need to return for encrypt operations
<rsleevi> vgb: If I hear you correctly, you're arguing to let the caller omit the IV and return the IV
<rsleevi> jimsch: I don't really care if you use auto or omit - but basically you return it
vgb: You are proposing to let the caller omit the IV, and return the IV by the operation
rsleevi: developers need to protect the IV
...: We could return a dictionary
selfissued: you could use the API to implement authenticated
...: So the API should return the parameters
rsleevi: The safest bet is to add defaults later, if we now add incorrect defaults now we can't fix it later
...: if we add defaults we need to be sure that it are good defaults
<rsleevi> ACTION: rbarnes and vgb to propose a means for auto-generating IVs in 3 weeks [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action10]
<trackbot> Created ACTION-85 - And vgb to propose a means for auto-generating IVs in 3 weeks [on Richard Barnes - due 2013-04-30].
<scribe> ACTION: richard to make a proposal for an explicit auto generation token for IV [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action11]
<trackbot> Created ACTION-86 - Make a proposal for an explicit auto generation token for IV [on Richard Barnes - due 2013-04-30].
ACTION-85 due in 3 weeks
<trackbot> Set ACTION-85 And vgb to propose a means for auto-generating IVs in 3 weeks due date to 3 weeks.
ACTION-85 due in 4 weeks
<trackbot> Set ACTION-85 And vgb to propose a means for auto-generating IVs in 3 weeks due date to 4 weeks.
<hhalpin> https://www.w3.org/2012/webcrypto/track/actions/74
hhalpin: Is the API stable enough?
<rsleevi> ACTION-74?
<trackbot> ACTION-74 -- Harry Halpin to contact PING over privacy -- due 2013-01-28 -- OPEN
<trackbot> http://www.w3.org/2012/webcrypto/track/actions/74
rsleevi: We don't have any privacy concerns anymore, everything we can do now can be done in plain javascript
<rbarnes> yep
???: This isn't completely thru
<rbarnes> hhalpin: do we want a security review? boneh and others have expressed interest
rsleevi: Do we need a security review?
<rbarnes> rsleevi: if you want security review, you don't want cryptgraphers
<rbarnes> hhalpin: also have an action to ask other WGs for review
<rbarnes> rsleevi: propose that we address that after next public WD
<rbarnes> … have intentionally avoided filling in a lot of details while things get worked out
<rbarnes> … next public WD should have these holes filled in
rsleevi: I intentionally didn't fill in the wholes in the spec, because I didn't want to constantly want to change it
<rbarnes> drogersuk: agree that cryptographers != security review
<rbarnes> … when we had the joint meeting with webappsec at TPAC, we agreed that there was a dependency on the web security model
<rbarnes> … there was an action from that that I took to work on documenting the web security model
<rbarnes> … working on kicking off that work with brad hill, adam barth
virginie: There are 2 problems:
....: 1) review of the spec
... Would it be possible to have next public WD by the end of May
rsleevi: I can have something ready that the group can look at, and decide
virginie: Would that be something that is ready for review
rsleevi: I think so
virginie: 2) Documenting the Web Security Model
<rbarnes> scribenick: rbarnes
nvdbleek: i can, but it looked like you were doing it
i'll start back up
virginie: ready for LC in october or so?
hhalpin: ideally if we publish in june, want to go to LC in september / october
… so if most of our issues are closed by june, close that out by october, then one more round of review and it's over
rsleevi: the more important gating factor is going to be implementation experience
drogersuk: what about a test suite?
hhalpin: that's for tomorrow
virginie: that was for ACTION-74, keeping that open because we're not ready for reviews yet
… other actions we can close
?
hhalpin: most of the other actions are use case related
rsleevi: any that we can close out because they're stale? lots of over-due ones
hhalpin: building value proposition, higher level API, ...
… tlr added something about public communications
… add SEED, keeping that open
drogersuk: some considerations about jurisdictions where you can't do crypto stuff
<rsleevi> ACTION-67?
<trackbot> ACTION-67 -- Virginie GALINDO to legal aspects with respect to national directives -- due 2012-12-19 -- OPEN
<trackbot> http://www.w3.org/2012/webcrypto/track/actions/67
… considering export control laws, etc.
rsleevi: we have no mandatory to implement algorithms...
… if people are using chrome in iran, that's something the chrome team needs to deal with. ssl stacks already deal with these issues
… nothing here for the spec to address; implementors will
drogersuk: maybe put in a notice, ...
rbarnes: but what would the notice say?
drogersuk: more about what new entrants, what they need to consider
vgb: this is also very dependent on how the UA implements this
… could build a browser on CNG, not have any crypto in the browser
… nothing really generic you can say in the spec
virginie: closing the action with no text?
drogersuk: has jose discussed this?
jimsch: nope!
hhalpin: so, keeping "Add SEED", couple of others, everything else is from today
… think our action list is pretty well cleaned out
<ddahl> hhalpin:
<ddahl> https://www.w3.org/2012/webcrypto/track/issues/pendingreview
ddahl: two pending review issues
<rsleevi> ISSUE-2?
<trackbot> ISSUE-2 -- How to address pre-provisioned keys and managing ACLs -- pending review
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/2
<rsleevi> ISSUE-3?
<trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/3
<unanimous acclamation>: close them!
rbarnes: as a developer, how do i figure out if the algorithm i want is there?
… try it, and if it fails, it fails?
<rsleevi> ISSUE-38?
<trackbot> ISSUE-38 -- Key initialization and "finalization" -- postponed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
rsleevi: yes
vgb: is issue 38 really postponed, or should it be closed?
rsleevi: the idea would be something around key escrow, but the use case was really complicated, and there was not that much support
<rsleevi> ISSUE-2?
<trackbot> ISSUE-2 -- How to address pre-provisioned keys and managing ACLs -- pending review
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/2
PROPOSAL: Close ISSUE-2
karen: just to clarify for the main spec, there's no issues with pre-provisioned keys, but it is an issue for the WG at some point?
rsleevi: different topic than base spec, would need consensus to adopt
karen: so we close this issue for the main spec, but the issue is still around...
rsleevi: if there's not a spec to attach the issue to, you close the issue
karen: if we have a use case, it could be re-opened
hhalpin: this particular issue is poorly phrased. better to close this, write a new use cases, lead to a new issue
rsleevi: also a question of whether the use cases document is for the current API, whether the existence of a use case binds the WG to do something about it
virginie: use case document is living while spec is in development, clean it out as the spec matures
rsleevi: we have the ED of the use cases, you're saying when we go to WD, we remove the irrelevant use cases?
israel: it's a little confusing to take things out of the use cases document
karen: or else you have separate use cases documents
israel: exactly, v1 vs v2
hhalpin: as a start, mark use cases by version
rsleevi: or, have one document plus a wiki
hhalpin: wiki has lower visibility, so people might miss it and bring things to the WG
rsleevi: nobody is proposing adding major functionality at this point ...
virginie: so we have one use cases document which is aligned with the spec, then other use cases can go on the wiki or in a second document
… so karen, you are welcome to propose a use case within that framewrok
karen: two scenarios: asymmetric key and secret key
… (1) dr. smith has a key pair on her badge in the hospital, wants to sign a prescription, use the key to authenticate to e-prescription website
… (2) developer signs up for AWS, gets a secret key used for signing API requests
… key producer and consumer are different
rsleevi: you've mentioned these before, they need to be written down; might be ways to do them in the existing API
… should close this action because it's broadly written and unrelated to what you're saying
RESOLUTION: Close ISSUE-2
<rsleevi> ISSUE-3?
<trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/3
hhalpin: related to registry question?
vgb: no
rbarnes: seems like it could be useful; reason not to?
rsleevi: yes, lots. fingerprinting, complexity of expressing constraints, etc.
vgb: gets even complicated, because different keys have different capabilities as well
… CNG has an API for discovery, nobody uses it and nobody has expressed a desire to use it
PROPOSAL: Close ISSUE-3
RESOLUTION: Close ISSUE-3 with no action
<rsleevi> ACTION-54?
<trackbot> ACTION-54 -- Harry Halpin to blog post on w3.org about how the API fits into the larger Web platform -- due 2012-10-01 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2012/webcrypto/track/actions/54
ISSUE-38?
<trackbot> ISSUE-38 -- Key initialization and "finalization" -- postponed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
<rsleevi> ISSUE-38?
<trackbot> ISSUE-38 -- Key initialization and "finalization" -- postponed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
virginie: we discussed this and i forgot the outcome
rsleevi: close with no action
PROPOSED: Close ISSUE-38 with no action
RESOLUTION: Close ISSUE-38 with no action
ISSUE-34?
<trackbot> ISSUE-34 -- Representation of certificates -- postponed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/34
virginie: still working on ISSUE-34, so we'll keep it as postponed
ISSUE-15?
<trackbot> ISSUE-15 -- Discovering certificates associated with (private) keys -- postponed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/15
virginie: some redundancy with ISSUE-34
rsleevi: if you don't have a representation for certs, how do you discover them
vgb: there's two dimensions -- using certs to locate keys, and vice versa
virginie: postponed means that it's not a priority, ok to keep it that way? <no objection>
… on ACTION-54 ...
hhalpin: need to respond to some of the criticism, will do it when we release a public draft
rsleevi: propose we publish a WD, then see what criticism we get
hhalpin: we're still going to have critics that say "you shouldn't do this on the web", and "this is too complicated"
virginie: close for now, re-open when we have some feedback to address?
RESOLUTION: Close ACTION-54
<rsleevi> scribenick: rbarnes
<rsleevi> scribenick: drogersuk
Israel Hilerio presenting on array buffers
when using streams it gets a little bit more interesting
scribe: you can define a stream, it could be optional or could be null
you can enable all these operations (existing methods on subtlecrypto) to be streamable
scribe: (refers to email to the list on 23/04)
<rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0145.html
Israel walks through the steps
scribe: you can continuously process data and chain streams and arraybuffers together nicely
karen asks if you keep the same crypto operators
IH: yes, (shows processStream)
... you would also have your XHR which would let you know when you're done
for encrypting, decrypting, signing, verifying and the digest, they could also be ArrayBufferView
with the media source extensions, we do the same thing
scribe: this is a pattern we follow in existing specs.
... the proposal is to overload - there are different ways we can do this
karen asks if you can overload in JavaScript, ..(we are faking it essentially :-)
scribe: this allows you to expand it and do what you want to do (for example in the Stream examples shown
... one of the more interesting ones is - today arraybufferview is defined as a return type
ArrayBufferView is intended as a type
scribe: the only different thing we added here was the notion of getting the taglength but there is no way to get the tag
RS: Until you all finish you haven't got an authentication tag
... we ended up appending it
so when you finish you have the tag appended to it
RS: explains that you don't want 10MB blocks of text / cipher / plaintext
... (explains this was related to issue-18 - once you have read data you can drop it
... there is a potential spec issue about how we handle intermediate results
IH: Yes that's a good point
IH concludes by saying this is what we have been evaluating
<rsleevi> ISSUE-18?
<trackbot> ISSUE-18 -- Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics? -- closed
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/18
RH: This was previously in issue-18, a lot of these things make sense
... I realise that Microsoft have already implemented this in IE10
... the couple of concerns I raised were timing and deliverables
... another concern related to the whole thing about how we handle the progressive enc/decryption
... size of blocks etc
... the proposal for this will likely impact the proposals around the futures API (being discussed tomorrow)
... createobjecturl is complete hell and would be even worse with crypto
(changes JavaScript object into reference)
scribe: but you lose ability for garbage collection (pinning into memory), you're not sure when you're done
... lots of problems how to do that in File API
IH: With blobs, you're right there are all kinds of issues
... difference between blobs and streams
... to the extent that we have to solve how to deal with issues like stream to url
... hasn't really been dealt with
... long term we can deal with that
... in the short term we can get a lot of benefit from
RS: This was the huge appeal from ISSUE-18
... in this API model you're continuing to make round trips
... not sure how much data should be chunking
... streams does
... need to consider this all
... returning ArrayBuffer, could be just an oversight
... taking the input though - two bugs with File API, issues with XHR around ArrayBuffer / ArrayBufferView slicing
... probably can continue this discussion off-list
IH: internally it's not really immutable
... it's still the whole object is changing
... same construct
RS: historic issue is we wanted blobs and ArrayBuffers
... when you call slice it needs to make a copy
... and copies bytes and returns copies of bytes
... with an ArrayBuffer you have to copy the number of bytes you sliced
<scribe> ...(continued discussion on dealing with ArrayBuffer and ArrayBufferView as a whole, being the same)
RS: Seems reasonable syntactic sugar
<rsleevi> ACTION: rsleevi to update result to be ArrayBuffer than ArrayBufferView [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action12]
<trackbot> Created ACTION-87 - Update result to be ArrayBuffer than ArrayBufferView [on Ryan Sleevi - due 2013-04-30].
<rsleevi> ACTION: rsleevi to review syntactic sugar overloads for taking (ArrayBuffer and ArrayBufferView) [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action13]
<trackbot> Created ACTION-88 - Review syntactic sugar overloads for taking (ArrayBuffer and ArrayBufferView) [on Ryan Sleevi - due 2013-04-30].
<rsleevi> ACTION: rsleevi and israelh to work more on Streams API in joint with Futures API [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action14]
<trackbot> Created ACTION-89 - And israelh to work more on Streams API in joint with Futures API [on Ryan Sleevi - due 2013-04-30].
HH: proposes that we take Mark's discussion tomorrow
VG: Mark is on his way to the meeting now
..9-10: 30 will be use cases (Arun)
... then Robin Berjon is coming to talk about the testing framework
... then cert discussion
TLR asks if we wanted to discuss registry at some point
VG: There have been a lot of discussions, however there have been no agreed plans
HH: People have disagreed on the motivation
... I think we should discuss this for 30 minutes tomorrow
... this is more pressing than some of the further out use cases
... take the time from high level API or some other low level subject
Agreed this session will be 2:30-3:30 tomorrow
2: 30-3pm tomorrow (correction)
<markw> http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal
VG: we're also going to discuss the key discovery API
MW: I've just posted the link
... apologies for being in HTML etc.
... wrapping and unwrapping proposal is based on the email discussion
... using JSON web encryption - web key object
... RSA version and AES version
... wraps a content master key
... supports arbitrary lenght payload
... open issues have been discussed on email, we have proposals for now
... format
... compact or JSON serialisation or JavaScript object
... discusses crypto interface
... two new methods
... wrap and unwrap key
... algorithm identifier is where you'd put any operation parameters
... final one is enum JWE methods
method
scribe: two payload protection mechanisms
... unwrap key - ArrayBufferView provided
... algorithm identifier allows you to constrain the key to an algorithm
... key encryption key
... also attributes the web crypto key could have
... you may want to constrain the keys to be used for certain things
... the dictionaries show what it will look like
..VG: Objective here is to discuss the technical merits of this proprosal
RS: To re-iterate the concerns I have provided in the past..
... introduces dependencies on the user agent
... (wrap / unwrap)
... other concern is related to security model
... web crypto different to key discovery
in terms of security
scribe: web app could fully implement JOSE JavaScript side
... would lose key protection
... trust model is flawed
... the value-add of wrap / unwrap is closely tied to the security model
... it may or may not make sense
... and requires the UA to fully implement JOSE
<rbarnes> ack
RB: Dependency on JOSE isn't such a terrible thing
... if we're going to use JOSE we should just use it and not change a few things
<virginie> test
RB: we talked about the high level API being dependent on JOSE
<rsleevi> scribenick: drogersuk
karen discusses whether there is a security issue with exporting the key
mountie talks about the importance of protecting the key encryption key
vgb: I'm not as concerned as Ryan about the security model
... for now it might be sufficient to say that the unwrapped key gets the same security guarantee as the key encryption key
... trust model does delegate down to the unwrapped keys
... it would extend naturally (e.g. for smart card keys etc)
DD: I would consider the high level API as "frozen in time" for now
... it would be written in content JS
... I don't see Google implementing a high level API in the platform
HH: in general we could keep them separate
MW: (addressing responses)
... same rules for import / export apply for wrap / unwrap
... but still need possibility to add information on unwrap
... no intention to change anything in JWK
(misunderstanding)
MW: explaining why new proposal could not just be built on top of existing web crypto API
... an attacker could do a polyfill over the top of web crypto
... build confidence over the course of transactions..
... attacker has to get into initial exchange to be successful
(discussion on key encryption key usage and restrictions)
RS: collected some comments
... to address Richard's comments everything can be implemented once we have low level API
... we didn't agree that the high level API would be JOSE
... some things may not be appropriate
... don't see it as a foregone conclusion that browsers will implement
... to address security aspects (Mark)
... you fundamentally have no guarantee that you're secure
... key encryption key could be when you're being attacked
... but you can't assume anything - you could polyfill out right from the start as an attacker
... the continued question is how do address wrap / unwrap within the base specifcation and dependency on JWE
... no security guarantees on keys
(JWK dependency not JWE)
DD: I think that Microsoft, Mozilla and Google can have a shared github for a high level API (to be continued tomorrow...)
VG: explains security model / weaknesses need to be addressed
Jim (to MW): would you want to define a new type for export?
MW: yes (Jim notes it could affect base spec)
... issues around not being able to export unless wrapped
... gets a bit messy
... "a minefield of ancient unpleasantness"
scribe notes rathole discussion ongoing about wrap / unwrap
RS: talks about the issues around security and privacy aspects and issues around security of keys
... we see key discovery as separate which is why it is a separate spec
MW acknowledges that you don't always know what is going on
scribe: also says that you can have some confidence once boundaries are set
RS: JOSE is still open
discussion of breaching the security boundaries and lack of assurnace
rathole trust discussion...
<vgb> i think our scribe wants to go to dinner :)
<rsleevi> michaelh: Is there any way to distinguish whether or not a key was generated in JS vs the browser
<rsleevi> markw: No, because an attacker can polyfill
<tlr> +1 to early dinner
<rsleevi> markw: If you do it in the browser, then an attacker has to intercept the generation of a long-lived session key used to wrap subkeys
<rsleevi> hhalpin__: We need to make progress, but we're more or less where we're at the last telecon
<rsleevi> hhalpin__: straw poll: how many people think that wrapping should be a core primitive that should be a part of the low-level spec
<rsleevi> rbarnes: I can speak to one briefly we see in JOSE
<rsleevi> ... (describes use case of wanting to deliver code that doesn't have access to the keys)
RS: states that this does not give value-add security
... he is opposed
HH sums up - it is a lot more work for implementors, but the security gain is relatively low
scribe: needs a clear use case
<rsleevi> @hhalpin: Attempts to provide use cases that don't use pre-provisioned keys which NEED wrap/unwrap to get security benefit
<vgb> +1 to virginie
RS and HH propose to note this as a 'feature at risk'
scribe: this has a clear implementation by netflix
... it is in the wiki at the moment so it needs to be in one of the specs
RS: there is still some concern that we need to acknowledge, but yes it could go into the spec
... we will have an open issue for it
<hhalpin__> ACTION: rsleevi to add in wrap/unwrap as "feature at risk" to low-level [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action15]
<trackbot> Created ACTION-90 - Add in wrap/unwrap as "feature at risk" to low-level [on Ryan Sleevi - due 2013-05-01].
VG closes the meeting for the day
<wseltzer> trackbot, end meeting