IRC log of crypto on 2013-04-23

Timestamps are in UTC.

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