IRC log of crypto on 2012-11-12

Timestamps are in UTC.

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