19:54:11 <RRSAgent> RRSAgent has joined #crypto
19:54:11 <RRSAgent> logging to http://www.w3.org/2012/11/12-crypto-irc
19:54:13 <trackbot> RRSAgent, make logs public
19:54:13 <Zakim> Zakim has joined #crypto
19:54:15 <trackbot> Zakim, this will be SEC_WebCryp
19:54:15 <Zakim> ok, trackbot; I see SEC_WebCryp()3:00PM scheduled to start in 6 minutes
19:54:16 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:54:16 <trackbot> Date: 12 November 2012
19:54:29 <wseltzer> Chair: Virginie_Galindo
19:54:30 <virginie> agenda ?
19:54:41 <virginie> agenda+ welcome
19:55:21 <virginie> agenda+ debrief F2F (optional)
19:55:40 <virginie> agenda+ use cases
19:56:00 <virginie> agenda+ action review
19:56:28 <virginie> agenda+ mailing list discussion (summary)
19:56:57 <virginie> agenda+ group life (calls, next F2F)
19:59:19 <wseltzer> wseltzer has changed the topic to: WebCrypto call: Monday, Nov. 12, 1900 UTC+1
19:59:37 <Zakim> SEC_WebCryp()3:00PM has now started
19:59:44 <Zakim> +??P0
20:00:34 <Zakim> +??P2
20:00:45 <wseltzer> zakim, ??P2 is me
20:00:45 <Zakim> +wseltzer; got it
20:00:52 <Zakim> +ddahl
20:01:07 <Zakim> + +1.303.661.aaaa
20:01:09 <Zakim> +??P5
20:01:25 <sdurbha> sdurbha has joined #crypto
20:01:26 <markw> markw has joined #crypto
20:01:28 <wseltzer> zakim, ??p0 is rsleevi
20:01:28 <Zakim> +rsleevi; got it
20:01:42 <virginie> ??p5 is virginie
20:01:52 <wseltzer> zakim, ??p5 is virginie
20:01:52 <Zakim> +virginie; got it
20:02:10 <Zakim> + +1.415.867.aabb
20:02:17 <wseltzer> zakim, aaaa is sdurbha
20:02:17 <Zakim> +sdurbha; got it
20:02:29 <markw> Zakim, aabb is markw
20:02:29 <Zakim> +markw; got it
20:03:31 <emily> emily has joined #crypto
20:03:36 <rsleevi> rsleevi has joined #crypto
20:03:45 <arunranga> arunranga has joined #crypto
20:04:01 <Zakim> + +1.707.799.aacc
20:04:05 <wtc> wtc has joined #crypto
20:04:06 <emily> zakim, aacc is me
20:04:06 <Zakim> +emily; got it
20:04:33 <Zakim> + +1.415.294.aadd
20:04:42 <arunranga> zakim, aadd is me
20:04:42 <Zakim> +arunranga; got it
20:05:15 <ddahl> ddahl has joined #crypto
20:05:25 <virginie> zakim, who is onthe phone ?
20:05:25 <Zakim> I don't understand your question, virginie.
20:05:25 <hhalpin> Zakim, what's the code?
20:05:26 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
20:05:35 <virginie> zakim, who is on the phone ?
20:05:35 <Zakim> On the phone I see Google, wseltzer, ddahl, virginie, sdurbha, markw, emily, arunranga
20:05:38 <Zakim> Google has rsleevi, wtc
20:06:05 <Zakim> +[IPcaller]
20:06:06 <virginie> agenda?
20:06:11 <hhalpin> Zakim, [IPCaller] is hhalpin
20:06:11 <Zakim> +hhalpin; got it
20:06:25 <arunranga> zakim, who is noisy?
20:06:39 <Zakim> arunranga, listening for 11 seconds I heard sound from the following: wseltzer (3%), virginie (92%)
20:07:30 <hhalpin> yes
20:07:39 <hhalpin> chair: virginie
20:07:43 <hhalpin> scribe: hhalpin
20:07:49 <hhalpin> scribenick: hhalpin
20:08:36 <hhalpin> agenda?
20:08:45 <hhalpin> agenda+
20:08:56 <hhalpin> Zakim, next agendum
20:08:56 <Zakim> agendum 1. "welcome" taken up [from virginie]
20:09:21 <hhalpin> The main topic of discussion will be ISSUE-5, the "Rethinking KeyStorage Issue"
20:10:02 <hhalpin> PROPOSAL: Approve minutes of Oct 20th meeting and TPAC minutes?
20:10:16 <hhalpin> RESOLVED: Approved minutes of Oct 20th meeting and TPAC minutes
20:10:19 <Chris> Chris has joined #crypto
20:10:22 <hhalpin> Zakim, next agendum
20:10:22 <Zakim> agendum 2. "debrief F2F (optional)" taken up [from virginie]
20:11:08 <Zakim> + +1.650.228.aaee
20:11:21 <Chris> Zakim aaee is Chris
20:11:29 <hhalpin> Folks are OK with skipping this and getting straight to issues
20:12:50 <wseltzer> [Minutes and slides linked from www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012]
20:13:02 <hhalpin> Discussion of keystorage by Ryan Sleevi, security concerns (defining value of API) work led by David Rogers/WebAppSec
20:13:22 <hhalpin> A few new issues and actions, including discussion of formats
20:13:47 <hhalpin> Also, use-case document and Korean banking use-case was highly discussed.
20:13:51 <hhalpin> Zakim, next agendum
20:13:51 <Zakim> agendum 3. "use cases" taken up [from virginie]
20:14:32 <hhalpin> Arun: not much progress since last call
20:14:44 <hhalpin> ... had some one off conversations about Korean use-case
20:14:50 <hhalpin> ... clear it can't be solved on its own
20:14:53 <hhalpin> ... by our API
20:14:59 <hhalpin> ... likely needs our API+SysApps
20:15:39 <hhalpin> ... even so, would require some substantial retooling of the use-case
20:15:41 <sdurbha> Virginie: Thanks for the recap, appreciate it
20:15:53 <hhalpin> ... so in our document, we need to document what subset of the Korean  banking use-case we can solve
20:16:02 <Chris> q+
20:16:17 <hhalpin> arun: some recap of pgp key exchange and kerberos use-case
20:16:46 <hhalpin> +1 gatekeeping, as said on mailing list, kerberos is pretty far out
20:17:05 <hhalpin> arun: I think we should keep kerberos to more future work
20:18:56 <virginie> q?
20:20:21 <hhalpin> That particular ticket is in SysTeam's Alexandre's hands, will keep pinging
20:20:39 <hhalpin> Chris: Kept following up with the Facebook signed use of local storage use-case
20:21:15 <hhalpin> Chris: Is crypto-hashing good enough or do we need to get to certs?
20:21:34 <hhalpin> Arun: Hashing plus signing might be even more!
20:21:36 <hhalpin> q+
20:21:48 <virginie> ack Chris
20:22:02 <hhalpin> Chris: I think maybe that could be handy
20:22:04 <emily> Somewhat tangential since it sounds like we're not considering Kerberos to be realistic, but here's a JS kerberos client that someone I know is working on: https://github.com/davidben/webathena
20:22:21 <hhalpin> ack hhalpin
20:23:01 <virginie> http://www.w3.org/2012/webcrypto/track/actions/open
20:23:28 <hhalpin> anyways, if Facebook doesnt need signed hashing, quite a few other folks claim they need it for reasons that I haven't had time to contemplate: Martus, Crypto.Cat, etc.
20:23:36 <pal> pal has joined #crypto
20:23:37 <wtc> emily: yes, rsleevi and I know davidben, too. He told us about his JS Kerberos client when we saw him last month.
20:24:07 <Zakim> + +1.650.458.aaff
20:24:18 <virginie> http://www.w3.org/2012/webcrypto/track/actions/67
20:24:26 <rsleevi> ACTION-67?
20:24:26 <trackbot> ACTION-67 -- Virginie GALINDO to legal aspects with respect to national directives -- due 2012-12-19 -- OPEN
20:24:26 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/67
20:24:59 <hhalpin> Zakim, next agendum
20:24:59 <Zakim> agendum 4. "action review" taken up [from virginie]
20:25:14 <rsleevi> q+ to ask about ACTION-67
20:25:15 <hhalpin> Virginie: not completed actions there
20:25:46 <hhalpin> ack rsleevi
20:25:46 <Zakim> rsleevi, you wanted to ask about ACTION-67
20:26:11 <hhalpin> Virginie: lets make sure we label things correctly re some of the reqirements
20:26:22 <hhalpin> rsleevi: I'm hoping to keep out of legal requirements
20:26:37 <hhalpin> ... other than state vaguely why one may not have some algorithms on same place
20:26:39 <wseltzer> q+
20:26:49 <wseltzer> ack wseltzer
20:27:52 <hhalpin> wselzter: we may want to have this legal conversation offline
20:28:17 <hhalpin> Virginie: I just want it noted that some crypto is not allowed in certain countries, but should not disturb our work
20:28:36 <hhalpin> Zakim, next agendum
20:28:36 <Zakim> agendum 5. "mailing list discussion (summary)" taken up [from virginie]
20:29:10 <rsleevi> q+
20:29:36 <markw> q+
20:29:56 <hhalpin> rsleevi: the sum of our face to face was keystorage
20:30:02 <hhalpin> ... proposal was to remove new types of storage
20:30:11 <hhalpin> ... so that we assume whatever best of breed storage in WebApps is the best
20:30:44 <hhalpin> ... thus we will just define a structured clone for key objects
20:30:46 <hhalpin> ... thats it!
20:31:08 <hhalpin> ... markw said this gets rid of pre-provisioned keys
20:31:28 <hhalpin> ... can we support them in the spec, then we need to have a consideration for pre-provisioned keys
20:31:37 <hhalpin> q+
20:32:36 <hhalpin> ... my goal is to carefully scope features and try to keep spec thin
20:33:38 <hhalpin> Virginie: so what is your take on pre-provisioned keys?
20:34:13 <arunranga> I am worried about storage in general; and I'm worried that the "best of breed" storage recommendation from WebApps WG will put us in a straightjacket.
20:34:22 <hhalpin> rsleevi: both Google and Mozilla expressed concerns on implementation
20:34:30 <hhalpin> ... just a whole new host of pre-provisioned keys
20:34:35 <sdurbha> q+
20:34:38 <pal> q+
20:34:44 <hhalpin> ... that extends lifetime of localstorage etc.
20:35:40 <rsleevi> ack rsleevi
20:36:21 <hhalpin> markw: it wasn't clear that removing keystorage removed the pre-provisioned key ideas
20:36:37 <hhalpin> ... I think its a good idea of using a structured clone algorithms
20:36:45 <hhalpin> ... its been there since the workshop and beginning for us
20:38:07 <hhalpin> ... we have some implementations where the implementers are not the one's that the W3C are usually used to, i.e. browsers!
20:38:15 <virginie> q?
20:38:20 <hhalpin> ... but other implementers are using things
20:38:30 <hhalpin> ... and will want them in the spec
20:38:40 <rsleevi> This is not at all uncommon that capabilities are limited to particular device types - see for example vibration events, geolocation, or touch events. However, they're traditionally split from device-agnostic bits to device-specific bits
20:40:01 <hhalpin> ... we want privacy concerns, I think its fine that users can remove pre-provisioned keys if they know some particular kind of service will stop operating
20:40:15 <hhalpin> ... i.e. if I remove the "Fox TV" key, then I can't watch Fox.
20:40:18 <hhalpin> q?
20:40:20 <hhalpin> ack markw
20:40:23 <hhalpin> ack hhalpin
20:41:34 <markw> we don't need a separate key storage for pre-provisioned keys - we just need a way to find them and KeyStorage is the only way right now
20:42:50 <Zakim> -hhalpin
20:43:11 <hhalpin> weird
20:44:04 <Zakim> +??P11
20:44:12 <hhalpin> q+
20:44:17 <hhalpin> Zakim, ??P11 is hhalpin
20:44:17 <Zakim> +hhalpin; got it
20:44:38 <wseltzer> sdurbha: @@. If our goal is provide a library for basic crypto operations, who's waiting to use that?
20:45:11 <wseltzer> ... privacy. I don't see this as worse than cookie usage today.
20:45:28 <rsleevi> q+ to respond to sdurbha
20:45:29 <wseltzer> ... keys unique per application running on the device is not device ID.
20:45:37 <wseltzer> ack sdurbha
20:45:40 <wseltzer> ack pal
20:46:10 <wseltzer> pal: Can we separate: structures and calls described by API; what happens behind the scenes (privacy, storage)
20:46:30 <hhalpin> pal: what is the downside with connecting guid to a key?
20:46:38 <hhalpin> ... re privacy/storage
20:47:13 <hhalpin> q?
20:47:42 <markw> q+
20:47:46 <pal> q+
20:47:56 <wseltzer> ack hhalpin
20:48:03 <virginie> q+
20:49:28 <hhalpin> hhalpin: so quick note, we can go forward with ryan's keystorage issue in the next draft, and then in secondary features go after the multiple key container feature
20:49:44 <hhalpin> ... then last, wanted to point out that we need at least 2 implementers per feature
20:50:08 <hhalpin> ... so another implementer besides Netflix needs to implement and be part of our test-cases, and thus our WG
20:50:13 <hhalpin> ... I think that won't be a problem
20:50:50 <hhalpin> rsleevi: in order to be comparable as regards privacy for another storage mechanism, then it has to have same lifetime as cookies+localstorage
20:51:04 <hhalpin> ... and thus if it was meant to be comparable, then you should just use localstorage
20:51:21 <hhalpin> ... if it isn't and has a longer lifetime, you effect the entire web platform
20:51:24 <sdurbha> q+
20:51:26 <hhalpin> ... so that's a reasonable concern
20:52:08 <hhalpin> ... if we go forward with pre-provisioned keys, it seems they should not have a separate storage than smartcards etc.
20:52:33 <hhalpin> ... we're talking about a lifetime that's different
20:53:17 <rsleevi> ack rsleevi
20:53:17 <Zakim> rsleevi, you wanted to respond to sdurbha
20:53:34 <virginie> zakim, close the queue
20:53:34 <Zakim> ok, virginie, the speaker queue is closed
20:54:06 <hhalpin> markw: I'm not happy to put this in secondary features, but I'd like to retain finding pre-provisioned keys
20:54:29 <hhalpin> ... and we have proposed more text on the privacy issues
20:54:29 <rsleevi> Note: It wasn't there from the beginning. I proposed and added it during the two weeks leading to FPWD
20:54:41 <rsleevi> As a simple placeholder for how we thought storage would work
20:54:59 <hhalpin> ... so let's go forward, but have a read-only keystorage
20:55:06 <hhalpin> ... and do structured cline
20:55:10 <hhalpin> s/cline/clone
20:55:18 <hhalpin> q+
20:55:31 <wseltzer> ack pal
20:55:32 <hhalpin> pal: why is guid for keyid a big deal?
20:55:34 <wseltzer> ack markw
20:55:49 <rsleevi> pal: The conversation is right now focused on a different aspect, which is pre-provisioned keys in general
20:55:57 <markw> the unique id is a separate issue
20:55:58 <rsleevi> pal: we've not yet talked about GUID
20:56:02 <hhalpin> virginie: if its optional, how is it dangerous?
20:56:25 <hhalpin> the point is why have an optional feature in an API, why not use a custom attribute?
20:56:37 <wseltzer> ack virginie
20:56:38 <wseltzer> ack sdurbha
20:56:43 <hhalpin> if its not optional, then we need to have multiple implenters actually do it.
20:56:54 <pal> introducing an optional id field that can be associated with a key does not necessarily introduces privacy issues
20:57:12 <hhalpin> sdurbha: the key is access-controled by origin, the user consents for key to be used by application, and thus I don't see how this causes privacy concerns
20:57:37 <hhalpin> thinks we need to take at least a straw poll on this!
20:57:53 <markw> @rsleevi: KeyStorage specifically was added when you say, but the idea of pre-provisioned keys has been part of our work from the first workshop
20:58:49 <hhalpin> virginie: I would like to have more time since I see problems communicating
20:59:14 <hhalpin> I might add we might just have fundamental disagreement in the WG, in which case we need to actually see how large disagreement is?
20:59:21 <markw> one point I missed: origin-specific pre-provisioned keys are much simpler than smart-card based keys, which are not necessarily origin-specific
20:59:53 <hhalpin> I also don't think 2 hours of discussion between folks that fundamentally disagree will help, what is necessary is moving forward on consensus
21:00:03 <pal> @rsleevi: I guess I am wondering if the group can address the interoperability needs of pre-provisioned key users (thorugh the addition of an optional key id) separately from storage, privacy, etc.
21:00:08 <hhalpin> but disagreement is a fact of life, and we can always vote as needed.
21:00:52 <hhalpin> Its much preferable to get consensus, so perhaps people could make concrete proposals they think will be acceptable over the mailing list ASAP?
21:01:01 <wseltzer> [Doodle re: call time http://www.doodle.com/nnekkq62drchupts ]
21:01:32 <Zakim> -Pierre
21:01:33 <Zakim> -sdurbha
21:01:35 <Zakim> -Google
21:01:36 <hhalpin> Meeting adjourned
21:01:36 <Zakim> -emily
21:01:37 <Zakim> -virginie
21:01:38 <Chris> Chris has left #crypto
21:01:38 <Zakim> -markw
21:01:41 <hhalpin> trackbot, end meeting
21:01:41 <trackbot> Zakim, list attendees
21:01:41 <Zakim> As of this point the attendees have been wseltzer, ddahl, +1.303.661.aaaa, virginie, +1.415.867.aabb, sdurbha, markw, rsleevi, wtc, +1.707.799.aacc, emily, +1.415.294.aadd,
21:01:44 <Zakim> ... arunranga, hhalpin, +1.650.228.aaee, +1.650.458.aaff, Pierre
21:01:45 <Zakim> -wseltzer
21:01:49 <trackbot> RRSAgent, please draft minutes
21:01:49 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/12-crypto-minutes.html trackbot
21:01:50 <trackbot> RRSAgent, bye
21:01:50 <RRSAgent> I see no action items
21:01:50 <Zakim> -ddahl