W3C

- DRAFT -

Web Cryptography Working Group Teleconference

23 Apr 2013

See also: IRC log

Attendees

Present
Ryan, Sleevi, Wendy_Seltzer, Nick_Van_Den_Bleeken, Sangrae_Cho, Seung-Hun_Jin, Mountie_Lee, Harry_Halpin, Karen_O'Donoghue, Karen_Lu, Thomas_Roessler, Jason_Mackay, SooHyung, Kim, Israel
Regrets
Chair
Virginie
Scribe
nvdbleek, hhalpin, rbarnes, drogersuk

Contents


<trackbot> Date: 23 April 2013

Introductions

<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

welcome

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

status of all deliverables

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

Web Crypto API status

Open issues

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

Outstanding Issues

<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

Handling of block encryption modes and padding

<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

Add abort() to the KeyOperation interface

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

Semantics for key generation versus key derivation AND Separate method for key agreement

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

Require creation of random IVs by default for CBC, CFB, GCM

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.

Ask for a formal review of WebApps and HTML

<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

Microsoft Streams & Overloads Proposal

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

Wrap/Unwrap

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

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: rbarnes vgb and jimsch to discuss key generation/derivation/agreement [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action09]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: rsleevi to update result to be ArrayBuffer than ArrayBufferView [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action12]
[NEW] 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]
[NEW] ACTION: sleevi to write informative text recommending CSP [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action01]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: vgb, rbarnes, jimsch to discuss key generation/derivation/agreement [recorded in http://www.w3.org/2013/04/23-crypto-minutes.html#action08]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2013-04-24 19:21:49 $