18:53:18 RRSAgent has joined #crypto 18:53:18 logging to http://www.w3.org/2012/06/11-crypto-irc 18:54:04 wtc has joined #crypto 18:54:43 Chair: Virginie Galindo 18:55:00 Zakim, pick a scribe 18:55:00 sorry, hhalpin, I don't know what conference this is 18:55:05 Zakim, this is Crypto 18:55:05 sorry, hhalpin, I do not see a conference named 'Crypto' in progress or scheduled at this time 18:55:42 JimD has left #crypto 18:55:44 vgb has joined #crypto 18:56:32 emily has joined #crypto 18:56:49 Zakim, this is SEC_WebCryp 18:56:49 hhalpin, I see SEC_WebCryp()3:00PM in the schedule but not yet started. Perhaps you mean "this will be SEC_WebCryp". 18:56:56 Zakim, this will be SEC_WebCryp 18:56:56 ok, hhalpin; I see SEC_WebCryp()3:00PM scheduled to start in 4 minutes 18:57:32 SEC_WebCryp()3:00PM has now started 18:57:41 + +33.6.13.23.aaaa 18:58:00 agenda+ Welcome 18:58:06 agenda+ Survey about API 18:58:16 agenda+ Use-cases 18:58:20 agenda+ Technical Discussion 18:58:21 + +1.707.799.aabb 18:58:29 agenda+ Group Logistics 18:58:38 Zakim, pick a scribe 18:58:38 Not knowing who is chairing or who scribed recently, I propose virginie_galindo 18:58:41 Zakim, pick a scribe 18:58:41 Not knowing who is chairing or who scribed recently, I propose virginie_galindo 18:58:43 Zakim, pick a scribe 18:58:43 Not knowing who is chairing or who scribed recently, I propose virginie_galindo 18:58:58 +Wendy 18:58:58 + +1.773.939.aacc 18:59:37 JimD has joined #crypto 18:59:37 +John_Aberdeen 18:59:51 +[Microsoft] 19:00:05 Zakim, [Microsoft] is me 19:00:05 +vgb; got it 19:00:09 Zakim, what's the code? 19:00:09 the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin 19:00:19 + +1.650.214.aadd 19:00:44 zakim, aadd is Google 19:00:44 +Google; got it 19:01:58 +[Microsoft] 19:02:02 thanks wseltzer 19:02:14 + +1.408.540.aaee 19:02:15 + +1.512.257.aaff 19:02:24 MitchZ has joined #crypto 19:02:37 zakim, aabb is emily 19:02:38 +emily; got it 19:02:56 +??P13 19:02:58 Karen has joined #crypto 19:03:02 Zakim, ??P13 is hhalpin 19:03:08 +hhalpin; got it 19:03:14 Netflix on area code 408 19:03:23 +??P14 19:03:24 Zakim, who is on the phone? 19:03:24 On the phone I see virginie_galindo, emily, ddahl, Wendy, Jim_Davenport, vgb, Google, [Microsoft], +1.408.540.aaee, +1.512.257.aaff, hhalpin, ??P14 19:03:24 Google has rsleevi, wtc 19:03:24 [Microsoft] has Mike_Jones 19:03:30 Zakim, pick a scribe 19:03:30 Not knowing who is chairing or who scribed recently, I propose +1.512.257.aaff 19:04:41 zakim, Channy is channy_yun 19:04:41 sorry, Channy, I do not recognize a party named 'Channy' 19:04:47 Some good scribe instructions, for further reference: https://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html 19:04:50 zakim aaee is Netflix 19:04:52 scribe: Karen 19:05:12 Harry: help scribe 19:05:34 rsleevi has joined #crypto 19:05:48 Zakim, who is on the phone? 19:05:48 On the phone I see virginie_galindo, emily, ddahl, Wendy, Jim_Davenport, vgb, Google, [Microsoft], Netflix, Karen, hhalpin, ??P14 19:05:51 Google has rsleevi, wtc 19:05:51 [Microsoft] has Mike_Jones 19:05:51 Netflix has MitchZ 19:06:45 zakim, who is talking 19:06:45 I don't understand 'who is talking', JimD 19:06:55 there is some command to see who is talking 19:07:03 Zakim, who is making noise? 19:07:23 hhalpin, listening for 11 seconds I could not identify any sounds 19:07:35 sdurbha has joined #crypto 19:07:41 markw has joined #crypto 19:08:17 +??P18 19:08:29 Channy: are you on the phone? 19:08:30 Channy, are you on the phone or just IRC? 19:08:31 Zakim, scribenick Karen 19:08:31 I don't understand 'scribenick Karen', hhalpin 19:08:49 scribenick: Karen 19:09:05 p18 sdurbha 19:09:10 + +1.978.936.aagg 19:09:14 zakim, p18 is sdurbha 19:09:14 sorry, wseltzer, I do not recognize a party named 'p18' 19:09:19 zakim, ??p18 is sdurbha 19:09:19 +sdurbha; got it 19:09:22 Zakim, ??P18 is sdurbha 19:09:22 I already had ??P18 as sdurbha, hhalpin 19:09:30 ddahl, just IRC 19:09:32 zakim, aagg is pgladstone 19:09:32 +pgladstone; got it 19:09:38 Channy: thx 19:09:39 PhilipG has joined #crypto 19:10:04 agenda? 19:10:05 Virginie: agenda 19:10:20 -> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0043.html 19:10:57 Other topics? 19:11:20 Zakim, who's on the phone? 19:11:20 On the phone I see virginie_galindo, emily, ddahl, Wendy, Jim_Davenport, vgb, Google, [Microsoft], Netflix, Karen, hhalpin, ??P14, sdurbha, pgladstone 19:11:23 Google has rsleevi, wtc 19:11:23 [Microsoft] has Mike_Jones 19:11:23 Netflix has MitchZ 19:14:15 tl1 has joined #crypto 19:15:35 Present +David_Hooley 19:16:03 http://www.w3.org/2012/06/04-crypto-minutes.html 19:16:16 Virginie: previous minutes http://www.w3.org/2012/06/04-crypto-minutes.html 19:16:18 hooley has joined #crypto 19:16:42 PROPOSAL: accept http://www.w3.org/2012/06/04-crypto-minutes.html as minutes for the previous meeting, any objections? 19:16:44 Harry: as long as no one object, it is approved 19:16:55 RESOLVED: accepted http://www.w3.org/2012/06/04-crypto-minutes.html as minutes for the previous meeting. 19:17:16 Virginie: take way does not replace minutes 19:17:28 zakim, take up agendum 2 19:17:28 agendum 2. "Survey about API" taken up [from hhalpin] 19:17:42 http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis 19:17:42 http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis 19:17:53 topic: Survey about API 19:18:02 David presents summary 19:18:37 David: most want low level api 19:18:53 david: we will figure out what does that mean 19:19:10 david: one of question does not worded well - who will use api 19:19:40 david: main answer: web app users 19:20:10 david: main activities will be messaging, chatting, signature behind it 19:20:40 david: a good set of data. we can get more answers as we go alone. please read through raw data 19:20:51 virginie: thank you David for the efforts 19:20:59 s/alone/along/ 19:20:59 virginie: any comments? 19:21:04 q+ 19:21:07 q+ 19:21:15 q+ 19:21:53 sdurbha: emails seem to want high level api 19:22:24 david: there are still discussions on what that means high or low level api 19:22:49 david: I think low level is better so we can implement more func and follow standard 19:22:59 david: high level api can be built on top 19:23:45 harry: messaging and chatting on top is surprising. 19:23:47 q+ 19:24:17 q+ 19:24:24 vgb: what is not clear - how people think this api with relation to tls 19:24:38 vgb: an addition? 19:24:50 vgb: to implement tls in browser? 19:25:15 virginie: one feature - for web app to manage their security 19:25:30 I'm pretty sure we are NOT going to replace TLS :) 19:25:31 virginie: feature 2: tracking tls session 19:25:53 vgb: I don't think people want to be able to implement all of TLS, however, I think they do want to be able to secure and sign data before this data is pushed to the wire 19:26:05 wtc: rsleevi: got it! thanks! 19:26:07 p1: ryan and I will contact david later in design api 19:26:15 s/p1/wtc/ 19:26:23 david: use cases are not to replace tls 19:26:23 I imagine we are going to add some functions that let people sign and encrypt some parts of the DOM dynamically using a few cross-browser methods. 19:27:00 david: using secure messaging as an example - three persons involved 19:27:22 Karen: that is rsleevi :) 19:27:23 david: bob and alice may be two users using carol's service 19:27:49 sorry 19:28:03 rsleevi: tls is only suited for two people talking 19:28:10 rsleevi, you wanted to respond 19:28:45 virginie: to leverage what david said, we should focus on low level api first 19:29:00 virginie: allow developers to control the operations 19:29:00 -[Microsoft] 19:29:17 virginie: we can work on high level later 19:29:19 +1 19:29:20 +1 19:29:21 +1 19:29:23 +1 19:29:24 +1 19:29:26 +1 19:29:28 PROPOSAL: Start with low-level 19:29:28 +1 19:29:29 +1 19:29:33 +1 19:29:35 +1 19:29:49 RESOLUTION: Start with low-level API, then focus on high-level API 19:30:11 Virginie: a3 use cases 19:30:16 zakim, take up agendum 3 19:30:16 agendum 3. "Use-cases" taken up [from hhalpin] 19:30:17 Zakim, next agendum 19:30:17 agendum 3 was just opened, hhalpin 19:30:22 topic: Use-cases 19:30:38 -> http://www.w3.org/2012/webcrypto/wiki/Use_Cases 19:31:09 virginie: channy has updated the use cases http://www.w3.org/2012/webcrypto/wiki/Use_Cases 19:31:26 virginie: channy has updated use cases 19:31:32 Use-cases on wiki were gathered from mailinglist and commnutiy group. It was classified by charter goals. Please feel free to edit by anyone. 19:32:13 Any volunteers? 19:32:18 virginie_galindo: I can help you 19:32:33 virginie: make sure we don't put complicated use cases in the primary features 19:32:55 ACTION: Add use-cases from the survey to the wiki 19:33:07 I think it may be rearranged by low-level and high-level. 19:33:07 virginie: use case: validated document 19:33:59 http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0022.html 19:34:43 -hhalpin 19:34:45 document sent by ? 19:34:51 q+ 19:35:14 p1: tls proxy is a fact 19:35:30 PhilipG: Defense in depth, accepting that TLS proxies are a fact of life, and provide security in the face of those. 19:35:39 s/p1/PhilipG/ 19:36:20 philip: it is possible for a client to authenticate even if there is tls proxy 19:36:47 ryan: I am concerned that entire web security model is built on tls 19:37:24 harry has joined #crypto 19:37:25 ryan: don't know any browser can guarantee the security even with the defense in depth 19:37:50 Zakim, what's the code? 19:37:50 the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), harry 19:38:02 virginie: philip you can write down the use case 19:38:19 +??P10 19:38:22 philip: I am not sure it is relevant 19:38:24 Zakim, ??P10 is harry 19:38:24 +harry; got it 19:38:41 philip: I will write it down anyway 19:39:00 virginie: any suggestions on use cases? 19:39:05 q? 19:39:16 Jim: a lot of discussions on smart card 19:39:35 jim: we might want to create an abstraction on hardware devices 19:39:40 q+ 19:39:50 q- 19:40:00 jim: we want to make sure the api we create can support hardware devices 19:40:03 Zakim, agenda? 19:40:03 I see 5 items remaining on the agenda: 19:40:05 1. Welcome [from hhalpin] 19:40:05 2. Survey about API [from hhalpin] 19:40:05 3. Use-cases [from hhalpin] 19:40:05 4. Technical Discussion [from hhalpin] 19:40:05 5. Group Logistics [from hhalpin] 19:40:17 Zakim, next agendum 19:40:17 agendum 1. "Welcome" taken up [from hhalpin] 19:40:22 virginie:topics: draft api 19:40:32 topic: draft API 19:40:34 zakim, take up agendum 4 19:40:34 agendum 4. "Technical Discussion" taken up [from hhalpin] 19:41:09 virginie: 14min to discuss technical topics 19:41:37 David: latest update is section 7 19:41:53 http://www.w3.org/2012/webcrypto/WebCryptoAPI/ 19:41:54 david: added link to JWA (json algorithms) 19:42:12 david: we will benefit to use same identifiers as jwa 19:42:24 +1 re-using identifers from JOSE WG 19:42:24 david: updated examples in the strawman 19:42:32 s/14min/40min/ 19:42:43 http://www.w3.org/2012/webcrypto/WebCryptoAPI/#algorithms 19:42:50 +1 to the re-use 19:43:00 virginie: thank you for the work 19:43:36 david: try to begin proposal on key identifier 19:44:01 david: we might want to add some meta data on key identifier 19:44:38 virginie: proposal GUID from mitch 19:44:46 virginie: will we reuse? 19:44:56 http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0015.html 19:44:58 q+ 19:45:04 david: that's an ideal way to identity key 19:45:23 q+ 19:46:07 ryan: concern: will two users of two different sites have same or different GUID? if the same, it is possible to track user 19:46:30 ryan: I like the string id, which may not have this concern 19:47:10 ryan: example: netflex.p1 19:47:12 rsleevi: I think the JOSE WG has examples like that - origin + sequence number 19:47:39 p1: agree with ryan 19:47:50 s/p1/wtc/ 19:48:00 p1: the goal is to unique identify the key so that it can be revoked 19:48:06 q+ 19:48:42 wtc: hash of a secret key may accomplish the goal of identify the key without reveal the key 19:48:49 q+ 19:49:24 mitch: privacy concern is the one we share. 19:49:46 mitch: the uuid or hash may reveal too much 19:50:54 q- 19:51:12 mitch: we don't need to build all use cases but need to discuss the privacy concern 19:51:12 ack harry 19:51:35 i may be wrong, but the JOSE WG seems to not require any kind of specific id except that it is a string 19:52:56 harry: charter is very clear that we don't want to mandate a particular key identifier scheme 19:53:18 The question seems less to do with key identification, and more about key discovery 19:53:25 virginie: we need to name the key in order to handle it 19:53:28 Key identification serves as a means of key discovery, but is not the only one 19:53:31 i.e also the discovery of the properties of the key 19:53:47 which is different than sticking all the properties in its idenfication scheme 19:54:12 virginie: a need for the editors to come out a proposal 19:54:44 virginie: on key identifier. 19:55:00 david: Ryan and others have given feedback 19:55:21 david: enumeration of propertities 19:55:42 virginie_galindo: +1 19:55:44 +1 19:55:46 virginie: it is important and part of the design api 19:56:06 david: will share tomorrow or next day 19:56:42 virginie: next topic: discovery mechanism 19:57:23 virginie: netflex proposal? how to discovery key? 19:57:25 q+ 19:57:33 http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0030.html 19:57:34 david: no conclusion yet 19:57:45 ryan: do conclusion yet 19:58:14 ryan: need to consider mitch example where a particular key can only be used for a particular purpose case, mode etc 19:58:49 ryan: also need to consider more general use case that the key can be used in more cases 19:58:53 Just to throw one more oddball use case out there: we have seen one case of a single keytext block inside of hardware used as any of: DES, 3DES, 2DES (!), and AES-128 algorithms 19:58:57 I believe this is unusual, though 19:59:19 ryan: need to design api that can balance these cases 19:59:22 and could be handled by simply mapping the single keytext block to several different keys 19:59:30 also, I have been re-reading all of the latest JOSE JWK specs to help inform this discussion 19:59:40 but, cipher mode, padding, etc. may really be limited on a key-by-key basis 19:59:52 virginie: we need to build and write down the api 20:00:08 virginie: expect other participants to help 20:00:23 virginie: next topic: smart card discussion - lot of exchanges 20:00:44 virginie: our charter - we should not put anything specific to smart card 20:00:57 virginie: many use cases that need smart card 20:01:08 virginie: we need to find some ways to handle this 20:01:17 we don't want to bake in device-specific API features, but maybe we can do those use-cases with right level of abstraction. 20:01:26 q+ 20:01:29 use cases should not EXCLUDE smart cards explicitly; however, I agree that we may need to create an abstraction for the use of smart cards or other hardware-based devices 20:01:30 virginie: may be we can have a round table to discuss this 20:01:30 q+ 20:01:35 q+ 20:02:07 ryan: I have no objection to smart card, but have concern on security model 20:02:10 q+ 20:02:29 ryan: don't believe any website can benefit from know smart card 20:02:49 ryan: a client having keys stored in smart card is fine 20:02:57 q+ 20:03:23 ryan: we should not have anything specific to smart card 20:03:32 +1 keys stored in smart card 20:03:40 i.e. think of it as another container 20:04:06 Chan: I believe all use cases can be met by windows.cypto 20:04:20 Karen: s/Chan/wtc/ 20:04:48 a browser-specific solution doesn't seem to be a good answer 20:06:09 sdurbha: there are javascript api's that support crypto, but it is not possible to securely transfer keys. 20:06:10 sdurbha: As an alternative for/enhancement of , correct? 20:06:32 sdurbha: smart card support for keys is very appealing 20:06:45 rsleevi, correct 20:06:57 virginie: provisioning of the key is out of the scope 20:07:25 vgb: use case of key management 20:07:26 @JimD, a browser can use standard as like Firefox's impl. http://en.wikipedia.org/wiki/Federal_Information_Processing_Standard 20:08:30 vgb: where does key come from: local storage - not relevant to SC; key exchange; you have a key that is sent by a out of band way 20:08:55 vgb: the service knows it is in a smart card because it gives to the card. 20:09:06 well said, vgb 20:09:20 +1 20:09:20 +1 20:09:23 +1 20:09:27 +1 20:09:28 +1 20:09:28 vgb: +1. I think the matter of smart cards is a matter of key discovery, largely 20:09:31 vgb: we don't need smart card support, but need to know it comes from. e.g. smart card 20:09:34 +1 20:09:34 vgb: -1 to key provisioning within smart cards :) 20:10:07 +1, but would aim for a target where the "smart card keys" are used in a way consistent with the "runtime created keys" or "preprovisioned keys" 20:10:11 q+ 20:10:27 in other words, not necessarily "outside the sandbox" to get to the last part of your comment. 20:10:38 vgb: at the browser level - discover the key 20:11:22 MitchZ, I agree that the API should be consistent between the various types of keys 20:11:27 philip: provided that smart card portability of the key is a part of the use case 20:11:52 q+ 20:11:52 my point was that we should allow the possibility of accessing keys that were not created/initally received within the browser 20:12:17 philip: the easy of use is an important factor 20:12:31 hmmm...should we write a proposal/resolution here? 20:12:47 harry: wtc and I can take up an ACTION item to propose something 20:12:57 rsleevi - we're in violent agreement :) 20:13:04 :) 20:13:07 sorry, I didn't catch that 20:13:13 I have a half-composed email draft on this, will send out ot email list today 20:13:23 Thanks, vgb 20:14:19 VGB or Rsleevi, can you write *something* in IRC that captures in 1-3 sentences the precise proposal re the idea of accessing keys? 20:14:56 Virginie: vgb and ryan will propose something 20:14:58 harry: The browser should be agnostic as to the 'source' of the key - whether within the browser or outside 20:14:59 ACTION: VGB and RSleevi to write a proposal and send to mailing list for approval next meeting 20:15:23 Basic proposal on key access: there are 3 families of use cases 20:15:40 virginie: next topic: group life 20:15:47 1. Ephemeral / local-only use, as for local encrypted storage 20:15:51 zakim, take up agendum 5 20:15:51 agendum 5. "Group Logistics" taken up [from hhalpin] 20:15:59 2. Keys created through key exchange 20:16:07 virginie: f2f meeting - 24-25th of july 20:16:15 3. Keys that are distributed to parties and provisioned offline 20:16:19 maybe do a quick go through in IRC to see who can come to those dates? 20:16:27 virginie: who will be ready to attend the meeting? 20:16:28 PROPOSAL: F2F July 24-25. 20:16:30 +1 20:16:33 +1 20:16:35 +1 20:16:37 -1 20:16:40 +1 20:16:41 -1 on other travel that week 20:16:45 +1 (assuming no conflict with IETF) 20:16:51 -1 (unlikely to be able to attend any f2f) 20:17:01 The proposal is that while the API model should treat all these keys consistently as much as possible, it should also provide a discovery model for the 3rd class, since that is a special need for that class 20:17:10 +1 for Asad I guess 20:17:16 +1 20:17:17 +1 20:17:35 +1 for Mark Watson 20:17:37 +1 20:17:48 -1 (no sponsorship for travel :) 20:18:05 rsleevi: will you be available for phone calls those days? 20:18:33 ddahl: I wouldn't trust my phone where I'm going to be (Black Hat Briefings) ;-) 20:18:41 virginie: location? 20:18:45 rsleevi: ah, thanks 20:19:16 virginie: any problem moving to silicon valley? 20:20:18 David: we can accomodate at mountain view office 20:20:35 RESOLVED: Meeting 24-25th in Vancouver ala poll 20:20:41 virginie: thank you all. 20:20:57 Meeting Adjourned 20:21:06 Meeting: WebCrypto Working Group 20:21:07 RRSAgent, generate minutes 20:21:07 I have made the request to generate http://www.w3.org/2012/06/11-crypto-minutes.html harry 20:21:14 -vgb 20:21:14 you are welcome. Sorry for missing some points 20:21:15 -pgladstone 20:21:17 -emily 20:21:18 -sdurbha 20:21:18 -??P14 20:21:19 -Netflix 20:21:19