00:32:49 RRSAgent has joined #crypto 00:32:49 logging to http://www.w3.org/2013/11/14-crypto-irc 00:32:51 RRSAgent, make logs public 00:32:51 Zakim has joined #crypto 00:32:53 Zakim, this will be CRYPT 00:32:53 I do not see a conference matching that name scheduled within the next hour, trackbot 00:32:54 Meeting: Web Cryptography Working Group Teleconference 00:32:54 Date: 14 November 2013 00:33:06 hello malaclyps 00:33:16 do you wanna join us on the teleconference ? 00:33:39 nope, i'm fine! i just hang out on the IRC channel 00:33:49 Zakim, dial Wuzhou_East 00:33:49 sorry, hhalpin, I don't know what conference this is 00:33:57 Zakim, this is CRYPT 00:33:57 sorry, hhalpin, I do not see a conference named 'CRYPT' in progress or scheduled at this time 00:34:02 oki, just tell us if there are special stuff you would like us to address 00:34:13 zakim, this meeting spans midnight 00:34:13 I don't understand 'this meeting spans midnight', wseltzer 00:34:20 zakim, call wuzhou_east 00:34:20 sorry, wseltzer, I don't know what conference this is 00:34:31 zakim, this is CRYPT 00:34:31 sorry, wseltzer, I do not see a conference named 'CRYPT' in progress or scheduled at this time 00:34:49 (by the way, good to see you have some interest in our work :)) 00:35:00 zakim, space for 20 00:35:00 I don't understand 'space for 20', wseltzer 00:35:03 zakim, space for 20 ? 00:35:04 ok, wseltzer; conference Team_(crypto)00:35Z scheduled with code 26633 (CONF3) for 60 minutes until 0135Z 00:35:14 zakim, call wuzhou_east 00:35:14 ok, wseltzer; the call is being made 00:35:15 Team_(crypto)00:35Z has now started 00:35:16 +Wuzhou_east 00:35:36 zakim, drop wuzhou_east 00:35:36 Wuzhou_east is being disconnected 00:35:38 Team_(crypto)00:35Z has ended 00:35:38 Attendees were Wuzhou_east 00:37:37 Agenda : http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda 00:41:37 Ralph_ has joined #crypto 00:41:38 jyates has joined #crypto 00:44:16 Ralph has joined #crypto 00:45:26 Ralph__ has joined #crypto 00:45:35 tobie has joined #crypto 00:45:50 Team_(crypto)00:35Z has now started 00:45:51 +Wuzhou_east 00:46:15 kodonog has joined #crypto 00:46:47 fan_ has joined #crypto 00:47:46 +JYates 00:47:49 -Wuzhou_east 00:47:51 +Wuzhou_east 00:47:58 Anders has joined #crypto 00:48:24 we can hear you 00:49:16 rsleevi has joined #crypto 00:50:25 -JYates 00:50:27 -Wuzhou_east 00:50:29 Team_(crypto)00:35Z has ended 00:50:30 Attendees were Wuzhou_east, JYates 00:50:50 hello Jyates, we will redial with other credentials 00:51:02 (as the call was wrongly scheduled for one hour) 00:51:28 Zakim, call wuzhou_east 00:51:28 ok, Ralph_; the call is being made 00:51:29 Team_(crypto)00:35Z has now started 00:51:30 +Wuzhou_east 00:51:33 +JYates 00:51:36 -Wuzhou_east 00:51:37 +Wuzhou_east 00:51:57 can u hear us joanne ? 00:52:20 rbarnes has joined #crypto 00:52:30 trying to dial in over Zakim 00:52:33 what's the passcode? 00:52:42 zakim, code? 00:52:42 the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), wseltzer 00:52:59 I can hear a bit, Should I try calling in again? 00:53:06 I used 26633 00:53:57 Ralph_ has left #crypto 00:53:59 to joanne : i think that is fine 00:54:03 +[Mozilla] 00:54:25 to remote attendees, please mute your phone, we hear you :) 00:54:30 rsleevi, zakim wants a ? 00:54:35 Ralph__ has joined #crypto 00:54:53 OK 00:55:04 -JYates 00:55:30 I'll call back in in 15 or 20 mins. 00:55:47 btw, it's lat-ish here, 5pm. obviously it will be pretty late by the time we're done for the day 00:55:48 mountie has joined #crypto 00:57:52 It is 8:00 pm here 00:58:21 really thnaks the motivated person attending remotely the call 00:58:22 I won't be able to listen for more than an hour or two. 00:58:34 that already something ! 01:00:51 +JYates 01:01:05 Ralph has joined #crypto 01:01:56 mete has joined #crypto 01:02:00 MichaelH has joined #crypto 01:02:47 secumania has joined #crypto 01:03:26 to all remote and present attendees, we will start in 5 minutes 01:04:26 annevk has joined #crypto 01:04:45 tony has joined #crypto 01:04:47 channy has joined #crypto 01:05:21 kotakagi has joined #crypto 01:05:50 markw__ has joined #crypto 01:06:21 israelh has joined #crypto 01:07:58 ekr has joined #crypto 01:08:01 csjung_ has joined #crypto 01:08:03 zakim, who is here? 01:08:03 On the phone I see Wuzhou_east, [Mozilla], JYates 01:08:04 On IRC I see csjung_, ekr, israelh, markw__, kotakagi, channy, tony, annevk, MichaelH, mete, Ralph, mountie, rbarnes, rsleevi, Anders, fan_, kodonog, tobie, jyates, Zakim, 01:08:04 ... RRSAgent, hhalpin, virginie, malaclyps, tantek, timeless, trackbot, slightlyoff 01:08:12 eke and i are in the room here 01:08:18 s/eke/ekr/ DYAC 01:08:20 jinsh has joined #crypto 01:08:26 ekr 01:09:14 audio is very fragmentary 01:09:21 and very echoey 01:09:24 sangrae has joined #crypto 01:09:35 +[Microsoft] 01:09:39 Scribenick: hhalpin 01:09:40 vgb has joined #crypto 01:09:52 agree--audio is echoey and fragmentary 01:09:53 topic: Intros 01:09:55 zakim, who is on the line? 01:09:55 I don't understand your question, vgb. 01:10:06 Samsung 01:10:06 zakim, who is on the call? 01:10:06 On the phone I see Wuzhou_east, [Mozilla], JYates, [Microsoft] 01:10:06 audio is truly useless 01:10:08 Tencent 01:10:15 zakim, [Microsoft] is me 01:10:15 +vgb; got it 01:10:21 Anders, PrimeKey 01:10:28 Karen, ISOC 01:10:33 Michael Hutchinson, Gemalto 01:10:44 LG Electronics 01:10:47 Israel, MS 01:10:53 ETRI 01:10:58 Kbit 01:11:03 Pozitron 01:11:32 Arun, Mozilla 01:11:38 s/Arun/Anne/ 01:11:47 hhalpin: can one of you try something in the voip area. 01:11:47 dsuwirya has joined #crypto 01:11:58 anders_ has joined #crypto 01:12:07 s/ETRI/sangrae, jin from ETRI/ 01:12:09 anders_ has left #crypto 01:12:14 better now 01:12:19 much better 01:12:34 much much better 01:12:59 virginie: 55 participants, 26 orgs, 1.5 years running 01:13:09 virginie: realistically, about 15 contributors on 3 specs 01:13:19 ... API, Use-cases, and Key Discovery 01:13:39 eroman has joined #crypto 01:13:47 slide link? 01:14:12 er, wrong copy/paste 01:14:17 http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda 01:14:22 q? 01:14:40 virginie: objective is to stabilize and go for Last Call after this meeting 01:15:09 q+ 01:15:43 note that I'm not suggesting, that's what the charter says 01:16:13 Once we got to Last Call, we'll be there till June and then CR 01:16:24 virginie: make sure we answer any comments and review 01:16:53 ack rbarnes 01:17:54 would like some time to talk about WebRTC and how they want to use WebCrypto 01:18:11 rbarnes: Time for how WebRTC will use WebCrypto 01:18:27 zakim: who is here? 01:18:30 max has joined #crypto 01:18:31 hhalpin has changed the topic to: WebCrypto TPAC f2f 01:18:35 MWF has joined #crypto 01:18:42 Zakim, who is on the phone? 01:18:42 On the phone I see Wuzhou_east, [Mozilla], JYates, vgb 01:19:00 Zakim, mute JYates 01:19:00 JYates should now be muted 01:19:04 seo has joined #crypto 01:19:11 Zakim, mute vgb 01:19:11 vgb should now be muted 01:19:32 rbarnes: Will send an email comparing the specs 01:20:54 q+ 01:20:55 q? 01:21:23 http://www.w3.org/2012/webcrypto/wiki/images/5/5c/W3C_Web_Crypto_WG_status_tpac2013.pdf 01:21:28 rsleevi: do we recharter to take on Web Certificate API, given that its on the milestones? 01:21:42 Ralph__ has joined #crypto 01:22:26 thinks that a Certificate API would likely require re-chartering 01:22:37 virginie: It's just a possible objective, we can discuss 01:22:37 max has joined #crypto 01:23:51 virginie: you don't need to *shout* :) 01:24:08 is certificate API included in Secondary API Features? 01:24:51 And test-suites, we have to do test-suites and interop report before exiting CR 01:25:02 It's after CR that things tend to slow down dramatically 01:25:19 virginie: Web Security breakout feedback 01:25:24 ... lots of people, more than 40 people in session 01:26:11 q? 01:26:44 virginie: AOB? 01:26:49 topic: Web Crypto API 01:27:04 tony_ has joined #crypto 01:27:18 gcapiel has joined #crypto 01:27:23 rsleevi: feedback from implementers 01:27:31 ... lots of new issues from implementing in WebKit 01:27:37 ... want to hear issues from MS who also implemented 01:27:48 ... hopefully no more design issues, more ambiguity in wording spec 01:27:58 ... hopefully next version can fit all these implementers in 01:28:06 ... in the bugs, things are moving well 01:28:15 https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=--- 01:28:21 there's the bug list for those following at home 01:29:23 virginie: any news on more implementers? 01:29:44 Ralph has joined #crypto 01:29:54 rsleevi: On Chromium and Blink side, which will bubble up to Opera 01:30:01 ... we are in process of implementing 01:30:03 LeckieWang has joined #crypto 01:30:25 JonathanJ has joined #crypto 01:30:33 Present+ Jonathan_Jeon 01:30:37 q? 01:30:43 http://msdn.microsoft.com/en-us/library/ie/dn265046(v=vs.85).aspx 01:30:48 can't hear 01:30:48 ^ MSFT implementation 01:31:04 israelh: We are implementing, Netflix uses our implementation 01:31:09 ... lots of internal people asking about it 01:31:16 ... polyfilling promises and catching up to the new version 01:31:52 ... based on events currently 01:33:00 q+ 01:34:33 PolyCrypt team is working on implementing in Firefox, including some variant that provides access to smart card functions 01:35:03 virginie: Mozilla? 01:35:07 Marcus_Altman___ has joined #crypto 01:35:25 Ralph__ has joined #crypto 01:35:30 israelh: lots of TPM requests 01:35:43 we also made a Firefox extension that uses some horrible hacks to do webcrypto using NSS https://addons.mozilla.org/en-US/firefox/addon/foxycrypt/ 01:35:57 (I don't know the details with respect to Mozilla's implementation.) 01:36:18 rsleevi: would like feedback from MS on Apple's comments 01:36:39 notes that INRIA is also doing a polyfill and is likely to do an analysis of the API 01:36:57 -vgb 01:37:15 http://www.w3.org/2012/webcrypto/track/issues/open 01:38:30 ISSUE-9? 01:38:30 ISSUE-9 -- what will be the mean to integrate in the API the fact that key usage may need user consent ? -- open 01:38:30 http://www.w3.org/2012/webcrypto/track/issues/9 01:39:23 rsleevi: in our very first f2f does our spec need to make any guidance? 01:39:50 +1 to closing 01:40:07 q? 01:40:12 ack rbarnes 01:40:29 israelh: do we need to keep track of this for v2.0? 01:40:54 i think we can re-open a new issue if/when we get around to key stores that will require it. the question will come up anyway 01:41:08 q+ 01:41:08 q+ 01:41:20 rsleevi: would prefer to close these issues 01:41:54 q? 01:42:04 israel is not audible 01:42:15 israelh: one suggestion to a link to a list of issues for future versions 01:43:19 q? 01:43:52 JonathanJ has joined #crypto 01:44:03 gcapiel1 has joined #crypto 01:44:06 we should just make a wiki page for v2.0 01:44:08 and then close the issues 01:44:11 ACTION: hhalpin to create wiki to track V2 next 01:44:11 Created ACTION-123 - Create wiki to track v2 next [on Harry Halpin - due 2013-11-21]. 01:44:34 q+ 01:44:35 also, note that in last call we might create new bugs/issues, the goal here is to close all issues/bugs brought up by the WG itself so far. 01:44:51 mountie: this is an implementers issue re UI 01:45:06 q+ 01:45:32 rsleevi: we are discussing v2.0 issues, we can just add those to future version issues 01:45:33 +1 01:45:38 wonsuk has joined #crypto 01:45:40 ack mountie 01:46:12 q+ 01:46:27 MichaelH: We need a mechanism for passing authentication through the API 01:46:58 ... i.e. something happens in a GUI so that an App or UA does it, but we need some way to pass it through 01:47:06 rsleevi: similar to MS smartcard implementation 01:47:12 ... none of that is covered in the spec right now 01:47:19 ... the smartcard issue is more in version 2 01:47:29 ... we will need to solve that for future forms of key storage 01:47:38 ... but we havne't heard from any UA implementers re providing this 01:48:28 virignie: we should close issue but address topic in version 2.0 01:48:32 byungjung has joined #crypto 01:48:48 gcapiel has joined #crypto 01:49:14 q? 01:49:25 queue= 01:49:36 israelh: do we have in current spec, a UA-defined UI? 01:49:42 ... doesn't seem to be? 01:50:07 ... unless we have very concrete use-case, I'd prefer to avoid UI/UA 01:50:07 q+ 01:50:28 israelh: we ask for consent in IndexedDB? 01:50:33 ... that's a UI from the UA? 01:50:42 ... we want to store key 01:50:53 ... we want to show a UI for accessing that key managed by the UA 01:50:58 ... not sure if I understand the scenarios 01:51:40 mete: I don't think spec should make UI recommendations 01:51:50 ... but we will need some kind of authentication to use the keys 01:52:11 ... not thinking of smartcards, I'm thinking of any kind of key storage like ordinary software keychains 01:52:19 q+ 01:52:23 q+ 01:52:30 ack mete 01:52:40 ... directly related to implementers role here, is there a way to securely enter something like a PIN? 01:53:35 q+ 01:53:37 ... this increases usability of API 01:55:07 rbarnes_ has joined #crypto 01:55:14 q- 01:55:17 q- 01:55:32 +1 to close ISSUE-9 01:55:34 1+ 01:55:36 +1 01:55:37 +1 01:55:39 PROPOSAL: Close ISSUE-9 01:55:40 +1 01:55:41 +1 to close ISSUE-9 01:55:44 +1 01:55:44 +1 01:55:47 +1 01:55:48 +1 01:55:51 +1 01:55:55 RESOLVED: ISSUE-9 to be closed 01:56:29 ACTION: MichaelH, mete, and Mountie to work on V2 use case wiki to discuss UI (and UA UI) for handling smart card authentication 01:56:29 Error finding 'MichaelH,'. You can review and register nicknames at . 01:56:36 ACTION: Michael, mete, and Mountie to work on V2 use case wiki to discuss UI (and UA UI) for handling smart card authentication 01:56:37 Error finding 'Michael,'. You can review and register nicknames at . 01:56:44 q? 01:57:14 israelh: There might be differing characteristics when discussing different types of key storage 01:57:23 ... that is, some keys may be long lived 01:57:43 ... need to keep in mind the lifetime of the key based on the mechanism used to store them 01:57:44 * At URL Michael Hutchinson MichaelH 01:58:02 ... ex: with IndexedDB, most UAs have the ability to clear these databases 01:58:15 ... If you reset the IndexedDB, you may find content is no longer available 01:58:16 q? 01:58:53 hhalpin: Users have different expectations with regards to private key material 01:59:09 ... developers may have different expectations 01:59:30 q? 01:59:35 q+ 02:00:10 israelh: there are different security boundaries based on where you create keys 02:01:02 ... we should document at the UA level when we expect different things to be obfuscated 02:01:11 ... this is likely to be per-UA specific, but there may be common patterns 02:01:12 q? 02:01:45 q+ 02:02:06 hhalpin: Some people may be coming to the application with the expectation that when you create a key, and then try to use the key, there should be UI 02:02:18 ... I think a lot of issues we have open right now are related to different mental models of how the API is working 02:02:22 q+ 02:03:48 i think i agree with ryan. the nature of key storage is currently out of scope, and adding guarantees as to how keys are stored would be a major scope increase 02:04:07 q? 02:04:29 hhalpin: ex: of Dr. Boneh's comment - if you say nothing about the storage of key material, there will be different expectations about how the key is stored 02:04:49 the keying material is available as defined in the specification -- pretty much available to the user, only available to the server/JS through the API 02:05:03 Ralph__ has left #crypto 02:05:04 virginie: on ISSUE-9, we are done 02:05:44 mountie: For key material, whether key material is accessible to user or server, both are correct 02:06:47 ... need some consideration from the server side about password policies, two factor, etc 02:07:13 comment: key material storage is not addressed by or "CertEnroll" either so this question goes beyond WebCrypto 02:07:14 ... need to also consider other security requirements for protecting key storage 02:07:40 +1 to mountie's comment in general 02:08:08 ISSUE-10? 02:08:08 ISSUE-10 -- Making sure our API is usable with pure js environement -- open 02:08:08 http://www.w3.org/2012/webcrypto/track/issues/10 02:08:50 leckie has joined #Crypto 02:10:15 rsleevi: This issue was originally raised with a concern over DOM events 02:10:31 q? 02:10:39 ... broadly speaking, the question is whether or deliverable must consider environments like node.js 02:10:48 PROPOSAL: Close ISSUE-10 02:10:55 +1 02:11:04 +1 02:11:10 +1 02:11:11 +1 02:11:12 +1 02:11:14 israelh: Agree that this issue can be closed; Promises should address this 02:11:15 +1 02:11:20 +1 02:11:23 +1 02:11:24 +1 02:11:41 RESOLVED: ISSUE-10 to be closed with no further changes to the spec 02:11:45 ISSUE-12? 02:11:45 ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open 02:11:45 http://www.w3.org/2012/webcrypto/track/issues/12 02:11:52 trackbot, close issue 10, no change 02:11:52 Sorry, wseltzer, I don't understand 'trackbot, close issue 10, no change'. Please refer to for help. 02:12:04 q+ 02:12:30 Closed issue-10. 02:12:36 Closed issue-9. 02:12:40 FYI, KeyUsage[] keyUsages = [] needs to be sequence keyUsages 02:13:01 q for rsleevi: the current spec does not require encrypt() to verify that key.algorithm matches algorithm (the method argument). is this deliberate 02:14:36 http://lists.w3.org/Archives/Public/public-webcrypto/2013Oct/0029.html 02:15:43 q? 02:16:16 this is related to ISSUE-12 02:16:21 if the comparison needs to happen... 02:16:26 then the dictionaries need to be comparable 02:16:33 q+ 02:16:35 currently key.algorithm is generation stuff 02:16:46 algorithm the argument is operation stuff 02:16:48 02:16:50 hhalpin has joined #crypto 02:16:52 danny_ has joined #crypto 02:17:05 gcapiel has joined #crypto 02:17:25 { name: "AES-CTR", length: 128 } 02:17:36 vs. { name: "AES-GCM", "iv": "...." } 02:18:00 yep, that's right 02:18:15 question: is the intent to allow a CTR key to be used for GCM? or to prevent this 02:18:39 good, i like that answer. nodding here 02:18:41 ingee has joined #crypto 02:18:50 q? 02:19:05 so then the spec needs to have a comparison of algorithms 02:19:07 Scribenick: hhalpin 02:19:22 and there needs to be a spec for how the algorithms are compared 02:19:24 virginie: Are you OK to close this issue? 02:19:27 hayato___ has joined #crypto 02:19:34 rsleevi: sounds like bugs to be opened against spec 02:19:52 ... these 1) operations need to check if the algorithm matches the key-type 02:20:10 ... 2) needs to be clarified if the name or parameters used for the key 02:20:28 ... RSA-PSS, generating a key with SHA-1 with intended hashing, but then using it to sign re SHA-256 02:20:36 right, (1) do the comparison (2) how to do the comaprison 02:20:40 that accurately captures my concern 02:20:46 i will open these bugs if you want me to 02:20:51 yep, will do 02:20:52 Marcus_Altman has joined #crypto 02:20:58 kotakagi has joined #crypto 02:21:00 q? 02:21:01 ACTION: rbarnes to file bugs following this discussion 02:21:01 Created ACTION-124 - File bugs following this discussion [on Richard Barnes - due 2013-11-21]. 02:21:08 q? 02:21:17 mete: I think I understand re parameters 02:21:48 leckie_ has joined #Crypto 02:21:54 q? 02:21:56 ... for me, I'd separate the keys and operations 02:22:21 ... even if it is the case for current algorithms that if we combine the params, it would be not that confusing, this may not hold for future algorithms 02:23:01 tony has joined #Crypto 02:24:04 rsleevi: let's say you are using AES encrypt 02:24:11 ... should we have IV in algorithm 02:24:28 ... is it current value or does the IV get dropped entirely so we make sure we get a new one when we start? 02:24:48 ... but we don't have that right now, we just have data and parameters 02:24:51 q+ 02:25:48 arunranga has joined #crypto 02:25:59 mete: it's still confusing but I think we get your point 02:27:24 rsleevi: with promises approach, we avoid lots of these problems 02:27:57 Time management --> note that we are 3 minutes away from the break 02:28:17 israelh: one of the fundamental concerns is that this is fine for one part, but not for multi-part. 02:29:35 q+ 02:30:09 israelh: I think promises addresses his concerns 02:30:52 tony_ has joined #Crypto 02:31:36 -Wuzhou_east 02:31:40 rsleevi: regardless of asymmetric or symmetric, we always get a key 02:31:59 Zakim, dial Wuzhou_east 02:31:59 ok, hhalpin; the call is being made 02:32:01 +Wuzhou_east 02:32:37 rsleevi: parameters like IV are not used for all forms of encryption, not all forms 02:33:04 ... like asymmetric doesn't use IV, so the IDL needs to represent signature for different algorithms 02:33:15 ... not different signatures per algorithm 02:33:44 the rationale ryan is citing is why i proposed separation out (1) parameters that define an algorithm (e.g., name, mgf) from (2) parameters that define an instance of the algorithm (e.g., iv) 02:33:55 +q 02:34:34 tony has joined #Crypto 02:35:16 rsleevi: all parameters are optional in WebIDL, that's historical 02:35:49 ironically, audio dropped out off and on while karen was relaying my comment ;) 02:35:58 encrypt(algorithm, params, key, data) 02:36:19 encrypt( { name: "AES-GCM" }, { iv: "..." }, key, data) 02:36:31 so i think it's workable to separate, but am willing to live with it together 02:36:45 every army runs on its stomach ;-) 02:37:10 proposed resolution : we keep the issue-12 open until we get feedback from vgb (microsoft) + resolve the 2 related bugs (having in mind we wanna adress it in the 2 coming weeks) 02:37:24 rbarnes: Right, that was the 'double dictionary' approach I was mentioning earlier; not very common (I can think of no API that does it), and the need for it is less so because of the CryptoOperation.algorithm 02:37:25 virginie: let's keep issue with vgb 02:37:50 +1 02:37:54 +1 02:37:54 +1 02:38:03 +1 02:38:04 +1 02:38:04 PROPOSA: Keep ISSUE-12 open. Resolve this in 2 weeks following feedback from rbarnes and vgb 02:38:05 +1 02:38:09 PROPOSAL: Keep ISSUE-12 open. Resolve this in 2 weeks following feedback from rbarnes and vgb 02:38:09 +1 02:38:10 +1 02:38:11 sangrae has joined #crypto 02:38:11 +1 02:38:15 +1 02:38:17 +1 02:38:20 rsleevi: not sure how CryptoOperation.algorithm addresses this/ 02:38:21 ? 02:38:31 gcapiel1 has joined #crypto 02:38:37 that's just the end of the line above :) 02:38:44 02:38:48 RESOLVED: ISSUE-12 to be kept open. 02:39:16 break; return in 40 minutes. 02:39:45 -JYates 02:40:33 csjung_ has joined #crypto 02:41:58 csjung_ has joined #crypto 02:51:29 -[Mozilla] 02:52:02 mountie has joined #crypto 02:55:08 +[Mozilla] 02:56:40 byungjung has joined #crypto 02:58:10 gcapiel has joined #crypto 03:05:07 seo has joined #crypto 03:13:47 mete has joined #crypto 03:14:26 csjung__ has joined #crypto 03:20:36 markw has joined #crypto 03:23:40 have we started back yet? 03:23:57 not yet 03:24:07 tantek has joined #crypto 03:24:29 tsk tsk, not very punctual 03:25:02 hhalpin has joined #crypto 03:25:06 q? 03:25:37 channy has joined #crypto 03:25:49 jin has joined #crypto 03:26:31 Nick is changed from jinsh to jin 03:28:55 hearing bits and pieces of audio 03:29:06 virginie has joined #crypto 03:30:33 q? 03:30:33 virginie has left #crypto 03:30:33 q? 03:30:42 leckie has joined #Crypto 03:30:58 ISSUE-28? 03:30:58 ISSUE-28 -- Short-names for algorithms -- open 03:30:58 http://www.w3.org/2012/webcrypto/track/issues/28 03:31:10 virginie has joined #crypto 03:31:12 scribenick: kodonog 03:31:35 tobie has joined #crypto 03:31:40 hey, go back to work ! 03:31:50 i'm here 03:31:56 and can hear you kind of ok 03:32:15 which issue are we talking about ? 03:32:41 Issue 28: came from jose, propose a mapping from JWA algorithms to webcrypto algorithm 03:33:00 came from jose, propose a mapping from JWA algorithms to webcrypto algorithm 03:33:02 tony has joined #crypto 03:33:54 kotakagi has joined #crypto 03:34:07 ryan suggests that there is an action for creating a mapping from JWA algorithms to web crypto algorithms, but not sure where this lands 03:34:22 so if we close this as wont fix, does the "or DOMString" go away? 03:34:29 no 03:34:44 but it would be limited to something that would go in the "name" field 03:34:52 technical mechanics are in place and more a procedural item to describe where 03:36:34 given that efforts to align WebCrypto and JOSE have pretty much been abandoned, i don't really see any value in standardizing a mapping table (it should be reasonably obvious) 03:36:47 +1 rbarnes 03:37:12 of course, we have no process here for managing WebCrypto algorithms once this WG goes away.... 03:38:22 mwf has joined #crypto 03:38:31 if someone wants a standard table, they could write a short RFC defining an IANA registry of mappings 03:38:35 if we are going to support JWK we are going to have to figure out what to do about JWA 03:39:25 <_M_> _M_ has joined #crypto 03:39:39 as long as there's no collision between "alg" parameters for JWE/JWS and "alg" parameters for WebCrypto, there's not an issue for JWK. of course, the question of how to ensure that is tied up in how the individual algorithm registries are maintained 03:40:18 audio is kind of lossy, but i'm managing to mostly follow along 03:40:26 ACTION: virginie to coordinate with W3C contacts and IETF/IANA about how this works 03:40:26 Created ACTION-125 - Coordinate with w3c contacts and ietf/iana about how this works [on Virginie GALINDO - due 2013-11-21]. 03:41:11 Possible actions: 03:41:16 rigo has joined #crypto 03:41:17 1) JOSE takes it as part of their JWA registry 03:41:26 2) WebCrypto takes it as part of their algorithm dictionary 03:41:48 3) new IANA registry to align the two - independent of the JWA registry or WebCrypto spec 03:41:53 4) Remove the feature 03:42:06 one possible solution: JOSE has a "places where this token may appear" column in their algorithm registry. we could register algorithms there with a note that they may only appear in WebCrypto 03:42:10 1-3 all seem preferable, but 4 is an option of last resort 03:42:13 (if we want to avoid conflict with JOSE) 03:42:21 but if we want to support JWK, we need to figure out what it means for import 03:43:43 ISSUE-28? 03:43:43 ISSUE-28 -- Short-names for algorithms -- open 03:43:43 http://www.w3.org/2012/webcrypto/track/issues/28 03:44:11 is the result of closing that there's no action w.r.t. the current spec? or is there a change? 03:44:56 ok, so it's pending the ACTION. we can close, then, pending that 03:46:34 proposal: keep #28 open until the action #125 is done 03:46:40 +1 03:46:43 +1 03:46:49 +1 03:46:53 +1 03:46:55 PROPOSAL: Keep ISSUE-28 open until ACTION-125 is resolved. 03:46:57 +1 03:47:10 +1 03:47:22 +1 03:47:27 ISSUE-32? 03:47:27 ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open 03:47:27 http://www.w3.org/2012/webcrypto/track/issues/32 03:49:20 q+ 03:49:32 ryan: recommends closing with no change 03:50:14 Israel: do we have anything in the spec that says this version of the spec doesn't apply to smart cards? 03:50:14 IMO, the secure element API is going to be a pretty separate piece of work 03:50:24 hhalpin_ has joined #crypto 03:50:39 rsleevi: yes, in a couple of places... 03:51:02 FWIW, the approach we're taking in our experiments is something like window.crypto.tokens[i]. 03:51:04 q+ 03:51:08 +q 03:51:31 Israel: make a statement that we don't support or guarantee the lifetime of the keys 03:51:46 q? 03:52:05 yes, is the WebCrypto spec 03:53:33 https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security-developers 03:54:20 rsleevi: last sentence of above reference is answer to Michael's question 03:55:10 ACTION: israelh to make text proposal to provide clarification that the API provides no guarantees regarding key lifetime 03:55:10 Error finding 'israelh'. You can review and register nicknames at . 03:55:12 Q: Does the extractability attribute cause a problem if the key material is stored in plain file system 03:55:40 -q 03:55:42 q? 03:57:07 PROPOSAL: Close ISSUE-32 with no further action 03:57:11 leckie_ has joined #Crypto 03:57:12 MichaelH: No, it doesn't. Extractability is just about visibility to JS, not to other things on the host. 03:57:26 Action: Israel Hilerio to make text proposal to provide clarification that the API provides no guarantees regarding key lifetime 03:57:26 Created ACTION-126 - Hilerio to make text proposal to provide clarification that the api provides no guarantees regarding key lifetime [on Israel Hilerio - due 2013-11-21]. 03:57:53 PROPOSAL: Close ISSUE-32 with no further action; postpone discussion of key storage to V2 03:58:00 +1 03:58:03 >>>PROTOCOL: I will prefix comments to be relayed with MIC. Everything else can be left as back-channel chatter 03:58:13 +1 03:58:15 +1 03:58:17 +1 03:58:18 +1 03:58:18 +1 03:58:19 +1 03:58:26 +1 03:58:30 +1 03:58:37 RESOLUTION: ISSUE-32 closed; 03:58:56 ISSUE-35? 03:58:56 ISSUE-35 -- Handling of wrap/unwrap operations -- open 03:58:56 http://www.w3.org/2012/webcrypto/track/issues/35 03:59:14 trackbot, close issue-35 03:59:14 Closed issue-35. 04:00:20 trackbot, reopen issue-35 04:00:20 Re-opened issue-35. 04:00:28 rsleevi: issue created by Mark after first F2F, 04:00:35 trackbot, close issue-32 04:00:36 Closed issue-32. 04:00:58 rsleevi: defer until Mark joins us, may want further discussion on the double wrapping case 04:01:42 ISSUE-36? 04:01:42 ISSUE-36 -- Semantics for key generation versus key derivation -- open 04:01:42 http://www.w3.org/2012/webcrypto/track/issues/36 04:01:43 q? 04:01:48 concrete steps to closing this issue, get Mark's feedback on the concrete steps, may be satisfied with current solution 04:01:58 issue-36? 04:01:58 issue-36 -- Semantics for key generation versus key derivation -- open 04:01:58 http://www.w3.org/2012/webcrypto/track/issues/36 04:02:29 Mohammed has joined #crypto 04:02:38 action for richard and vijay to come back with a proposal on how to resolve this, they did, a slightly different variant was incorporated into the current spec 04:02:38 Error finding 'for'. You can review and register nicknames at . 04:02:46 -Wuzhou_east 04:02:54 current solution is similar in spirit 04:02:58 lost you guys! 04:03:11 np 04:03:25 zakim, code? 04:03:25 the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), rigo 04:03:38 kotakagi has joined #crypto 04:03:44 zakim, who is here? 04:03:44 On the phone I see [Mozilla] 04:03:45 On IRC I see kotakagi, Mohammed, leckie_, hhalpin_, rigo, mwf, tony, tobie, virginie, jin, channy, markw, csjung__, mete, seo, gcapiel, mountie, sangrae, arunranga, hayato___, 04:03:45 ... rbarnes, eroman, dsuwirya, vgb, ekr, israelh, MichaelH, rsleevi, Anders 04:03:51 +Wuzhou_east 04:04:16 https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-SubtleCrypto-method-deriveBits 04:04:26 proposed solution is in the spec as referenced by the above link 04:05:03 if you want to use the raw bits from some secret agreement, derived keys and derived bits as distinct 04:05:28 MIC: i think that fixing this problem in general will require some fairly radical re-engineering, basically generalizing the concept of what can be inside the envelope beyond just keys to arbitrary octet sequences. keeping the current solution will cut off some use cases / protocols, but i would be ok with that for v1. it would be good if we could at least get a basic scenario to work, using pair-wise DH to get a symmetric key. 04:05:40 rsleevi: closer to mic? 04:05:50 thanks! 04:06:10 q? 04:06:43 zakim, Action: Richard Barnes and Vijay Bharadwaj to come back with a proposal on how to resolve ISSUE-36. Reference, they did a slightly different variant that was incorporated into the current Draft 04:06:43 I don't understand you, rigo 04:06:45 net of all that, i'm ok with what we've got :) 04:07:00 trackbot, Action: Richard Barnes and Vijay Bharadwaj to come back with a proposal on how to resolve ISSUE-36. Reference, they did a slightly different variant that was incorporated into the current Draft 04:07:18 ok 04:07:30 q+ 04:07:50 MIC: i need to review what's there. i think it's close enough that any deltas can be filed as minor new issues. 04:08:00 ... and thus we can close this one. vgb might disagree 04:08:35 q? 04:08:53 MichaelH: want to understand the security considerations 04:08:54 closer to mic please 04:10:00 q? 04:10:02 If a key that you are using for derivation supports both derived keys and derived bits, then derived bits will allow that... 04:10:13 virginie is pretty clear now 04:10:48 @rbarnes clear or loud? 04:11:11 Virginie: we could have a consensus to close ISSUE-36 pending review from vijay. Relative to derived bits, check that it is acceptable. 04:11:34 there are some codec/loss issues, but net of that i think they're ok. louder helps overcome some of that i think. 04:12:25 MIC: the one thing that's not immediately clear to me is how you would generate a long bit stream and slice parts into keys, IVs, nonces, etc 04:12:42 MIC: ryan, is there a plan for this that i'm missing? 04:13:22 ACTION: vgb to review proposal for deriveBits by Friday, November 15 04:13:23 Created ACTION-127 - Review proposal for derivebits by friday, november 15 [on Vijay Bharadwaj - due 2013-11-21]. 04:13:26 that's what derived bits does. derived bits has a parameter a length, 04:13:31 MIC: so if i wanted to get (key, iv, nonce) out of a derivation, i would deriveBits, slice, then re-import the key? 04:13:55 rsleevi: correct 04:14:05 makes me kind of sad that the key has to leave the boundary, but i can live with it 04:14:33 trackbot, associate action-127 with issue-36 04:14:33 action-127 (Review proposal for derivebits by friday, november 15) associated with issue-36. 04:14:39 up to the application to do whatever specific processing is required 04:15:05 ISSUE-41? 04:15:05 ISSUE-41 -- Clean up algorithm normalization and support checks -- open 04:15:05 http://www.w3.org/2012/webcrypto/track/issues/41 04:15:07 issue-41 04:15:07 issue-41 -- Clean up algorithm normalization and support checks -- open 04:15:07 http://www.w3.org/2012/webcrypto/track/issues/41 04:15:43 i need to swap in state on this. next issue? 04:15:56 markw has joined #crypto 04:15:59 ISSUE-43? 04:15:59 ISSUE-43 -- Separate method for key agreement -- open 04:15:59 http://www.w3.org/2012/webcrypto/track/issues/43 04:15:59 +[Microsoft] 04:16:23 hi this is vijay 04:16:32 zakim, [Microsoft] is me 04:16:32 +vgb; got it 04:16:45 noticed i now have new actions :) 04:17:30 Marcus_Altman__ has joined #crypto 04:17:42 sorry, audio is choppy so i will follow along but won't try to talk... 04:18:59 hhalpin has joined #crypto 04:19:18 rsleevi thinks derived bits should be the answer... 04:19:42 hhalpin_ has joined #crypto 04:20:32 ready for ISSUE-41 when you are 04:20:40 ISSUE-41? 04:20:40 ISSUE-41 -- Clean up algorithm normalization and support checks -- open 04:20:40 http://www.w3.org/2012/webcrypto/track/issues/41 04:20:45 MIC The current text conflates the notions of "registered" and "supported". That is, it doesn't allow implementations that supprot un-registered algorithms (e.g., experimental or local algorithms). The proposal is to decouple these to notions. 04:21:16 "If normalizedAlgorithm does not describe a registered algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm." <-- so if I support a non-registered algorithm, I can never execute it 04:21:42 ^^^ that's the current text 04:22:08 yes 04:22:32 registered and supported were meant to be equivalent terms 04:23:08 MIC so you're saying that UAs MUST NOT implement algorithms that are not registered in this spec? 04:23:28 then i'm confused :) 04:23:35 if the issue is we should use supported instead of registered that is fine, if registered then within the UAs implementation 04:24:04 SHOULD NOT is fine 04:24:11 i would like to see text 04:24:17 could we delete the word registered 04:24:27 +1 for SHOULD NOT 04:24:35 i think that's ok 04:24:52 there were a couple of other edits in the bug, but maybe we can hammer those out offline 04:25:32 goal of language what should a UA do if it encounters an algorithm that it doesn't support 04:26:07 any UA that did not support that algorithm who have a defined behavior 04:26:12 i would propose we keep this open for ryan to propose text 04:26:23 q+ 04:26:57 here's what's proposed in the bug: 04:26:57 If normalizedAlgorithm does not describe a recognized algorithm, throw an AlgorithmNotSupportedError exception and terminate the algorithm. 04:26:58 If normalizedAlgorithm does not describe an algorithm that supports encryption, throw an OperationNotSupportedError exception and terminate the algorithm. 04:27:17 MichaelH: If you don't have an operation to perform you regurn an error. 04:28:10 possible interpretations 1) no idea what AES-CBR means; 2) knows what AES-CBR is but doesn't support it; 3) knows and supports AES-CBR 04:28:25 for each case, need to have a defined behavior for what the UA will do 04:28:50 MIC: (1) and (2) are equivalent, AlgorithmNotSupportedError 04:29:33 Israel: can we not just follow the same pattern in the current spec. This is a natural equivalent ... 04:29:51 understood & supported == win! 04:30:00 understood and not supported along with not understood and not supported have consistent behavior 04:30:35 we could close right now if we just adopt the text in the bug :) 04:30:44 proposed text : "If normalizedAlgorithm does not describe an algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm." 04:30:57 +1 04:30:57 -Wuzhou_east 04:31:07 +Wuzhou_east 04:31:30 i can live with that, but note that it still conflates "i don't know this" with "that algorithm can't encrypt" 04:31:46 more of a DontWorkExcpetion 04:32:05 that's the reason for AlgorithmNotSupportedError vs. OperationNotSupportedError 04:32:11 but i'm hungry, so i don't care that much :) 04:32:42 at this point, i think we've got sufficient joint understanding that ryan can implement some text 04:32:54 rsleevi: but this is a perhaps a spec bug 04:33:49 issue-41:proposed text : "If normalizedAlgorithm does not describe an algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm." 04:33:49 Notes added to issue-41 Clean up algorithm normalization and support checks. 04:33:49 close issue with proposed text and open a spec bug 04:34:07 +1 04:34:09 +1 04:34:11 +1 04:34:11 +1 04:34:12 +1 04:34:13 +1 04:34:18 +` 04:34:20 +1 04:34:22 +1 04:34:28 +1 04:35:08 Mountie: one question before +1... are you willing to keep the list of algorithms in the spec 04:35:11 issue-41: closed with the proposed text from bug tracker 04:35:11 Sorry, but I think you meant to close issue-41. 04:35:13 +1 04:35:29 yep, i'll be here after lunch 04:35:38 Break for 90 minutes 04:35:41 issue-41: agreement on the proposed text from bug tracker 04:35:41 Notes added to issue-41 Clean up algorithm normalization and support checks. 04:35:42 ok, see you then 04:35:46 kotakagi_ has joined #crypto 04:35:48 sangrae has left #crypto 04:35:49 -[Mozilla] 04:35:52 exit 04:35:58 trackbot, close issue-41 04:35:59 Closed issue-41. 04:36:12 -Wuzhou_east 04:36:25 rsleevi: answer to mountie, that is a separate discussion 04:38:01 -vgb 04:38:02 Team_(crypto)00:35Z has ended 04:38:02 Attendees were Wuzhou_east, JYates, [Mozilla], vgb 04:38:47 rrsagent, please draft minutes 04:38:47 I have made the request to generate http://www.w3.org/2013/11/14-crypto-minutes.html virginie 04:39:26 rrsagent, set log public 04:39:33 rrsagent, please draft minutes 04:39:33 I have made the request to generate http://www.w3.org/2013/11/14-crypto-minutes.html virginie 04:39:41 kotakag__ has joined #crypto 04:46:38 tantek has joined #crypto 04:58:45 vgb has joined #crypto 05:06:56 nvdbleek has joined #crypto 05:07:10 zakim, code? 05:07:10 the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek 05:11:25 Team_(crypto)00:35Z has now started 05:11:33 +nvdbleek 05:11:45 hi 05:12:29 -nvdbleek 05:12:30 Team_(crypto)00:35Z has ended 05:12:30 Attendees were nvdbleek 05:14:56 mete has joined #crypto 05:34:22 byungjung has joined #crypto 05:41:14 kotakagi has joined #crypto 05:41:26 nvdbleek has joined #crypto 05:42:18 nvdbleek has joined #crypto 05:43:24 danny_ has joined #crypto 05:44:37 nvdbleek has joined #crypto 05:54:34 ekr has joined #crypto 05:55:04 kodonog has joined #crypto 05:56:22 rbarnes has joined #crypto 05:58:42 zakim, contact? 05:58:42 I don't understand your question, rbarnes. 05:58:47 nvdbleek has joined #crypto 05:58:59 csjung__ has joined #crypto 05:59:38 csjung___ has joined #crypto 05:59:49 zakim, what's the code? 05:59:49 the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), rbarnes 05:59:54 markw has joined #crypto 06:00:32 virginie has joined #crypto 06:01:14 mete has joined #crypto 06:02:17 Team_(crypto)00:35Z has now started 06:02:19 rbarnes_ has joined #crypto 06:02:25 +nvdbleek 06:02:27 Bert has joined #crypto 06:02:35 sangrae has joined #crypto 06:03:22 +Wuzhou_East 06:04:05 hhalpin has joined #crypto 06:04:05 JonathanJ has joined #crypto 06:04:35 + +1.425.836.aaaa 06:04:48 zakim, aaaa is me 06:04:48 +vgb; got it 06:06:31 tony has joined #Crypto 06:07:11 tobie has joined #crypto 06:07:21 leckie has joined #Crypto 06:07:52 israelh has joined #crypto 06:07:59 jin has joined #crypto 06:08:52 q? 06:09:14 dsuwirya has joined #crypto 06:09:14 mountie has joined #crypto 06:09:15 Scribe: Bert 06:09:27 Topic: Web Crypto API 06:09:32 working on connecting 06:09:32 issue-46? 06:09:32 issue-46 -- Optional algorithm parameters must have default values -- raised 06:09:32 http://www.w3.org/2012/webcrypto/track/issues/46 06:09:34 MichaelH has joined #crypto 06:09:46 it will be a couple of minutes, so maybe cover an issue that doesn't need me? 06:10:03 manu1 has joined #crypto 06:10:10 https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=--- 06:10:20 fan has joined #crypto 06:10:21 -vgb 06:10:23 virginie: Wait for input? 06:10:32 ryan: We got VG's 06:10:34 Present+: Manu_Sporny 06:10:36 ... Over to bug list: 06:10:42 + +1.434.941.aabb 06:11:00 ok, i'm on 06:11:05 ryan: File a bug against the spec! 06:11:07 zakim i am aabb 06:11:17 i have no shame, having filed several bugs :) 06:11:26 ... When you're reading something that isn't clear, best is to file a bug 06:11:27 +vgb 06:11:36 ... First bug: 06:11:38 Reminder to the new attendees : the agenda is http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda 06:11:52 israelh: all issue have been taken care of? 06:12:06 zakim, mute me 06:12:06 nvdbleek was already muted, nvdbleek 06:12:06 \me excellent 06:12:08 ryan: No, waiting for richrd to join phone 06:12:15 richard: I'm here 06:12:21 ISSUE-44? 06:12:21 ISSUE-44 -- Require creation of random IVs by default for CBC, CFB, GCM -- open 06:12:21 http://www.w3.org/2012/webcrypto/track/issues/44 06:12:22 Reminder to everyone if you wanna queue, talk, standup, walk to the mic and talk 06:12:27 israelh: And PJ's issues? 06:12:28 jmr has joined #crypto 06:12:41 s/PJ's/vdb's/ 06:12:48 danielkim has joined #crypto 06:12:51 ryan: ruchard filed issue 44 06:12:57 ... Context is: 06:13:03 ... 2 aspects, set of algos 06:13:12 ... Random generated 06:13:18 ... Make is eaiy for people 06:13:29 ... by automatically generating. 06:13:38 ... One argument is for better security. 06:13:54 ... Other is that some guidelines, such as 40-2, 06:14:15 ... require it. 06:14:22 ... Is that correct, Richard? 06:14:25 richard: yes 06:14:46 AndyF has joined #crypto 06:14:57 ryan: IV param, and any that requies random, also should accept a string "random" 06:15:04 ... That was a proposal. 06:15:19 ... When we discussed that, how to get IV out, 06:15:39 ... But in promises model we don't reflect that out. 06:15:46 ... So th eproposal needs further work, 06:15:55 ... Not saying it is impossible. 06:16:06 .... We can potentially find a solution, 06:16:13 ... But how important is it? 06:16:20 ... SO maybe no action to be taken. 06:16:20 q? 06:16:28 richard: I can update the proposal. 06:16:34 ... It is a bit stale. 06:16:44 ... I take an action? 06:17:01 virginie: When you say action, for V2 or for current spec? 06:17:07 q+ 06:17:09 rich:Current 06:17:21 ryan: or leave action as it is 06:17:30 @@: Need a vote? 06:17:34 JonathanJ has joined #crypto 06:17:48 ryan: There have been neither positive nor negative feedback. 06:17:59 ... fips 40-3 is revulating the requiremtn. 06:18:04 s/@@/MichaelH 06:18:15 richard: Encouraging fresh IDs 06:18:28 ack israelh 06:18:46 israelh: In old world, we had instaces that return compound values. 06:18:56 ... Sohave to resolve that anyway. 06:19:15 ryan: Say you ascpi operation, 06:19:26 ... If you give explicit ID, no need to reflect it back. 06:19:41 ... What would API look like when it doesn't require an ID. 06:20:03 richard: You can (scribe missed) 06:20:19 +q to ask if it could be better to handle these things in high level apis 06:20:21 ryan: We are currently handling dat ain general in the API. 06:20:39 ... How do you copy, do you neuter. How make sure data is not mutated. 06:20:50 ... We're getting to the point of always makin gcopies 06:20:51 s/ID/IV (initialization vector) 06:20:59 israelh: With keyword, that optimises the pb. 06:21:16 s/gcopies/copies/ 06:21:25 q? 06:21:33 ryan: You say if caller suplies IV, he gets data back; other wise he gets IV back. 06:21:45 ... Related pb: 06:21:58 ... Any authenticated data: 06:22:08 .... That's a case of multiple outpiuts returned. 06:22:28 israelh: generalizes the whol pb, gives us scale. 06:22:39 virginie: There is n action? 06:22:46 ryan: Restate the proposal: 06:23:05 ... In list of algos we talke about return values, araay bffer. 06:23:19 ... Return would be dictionary type key-value. 06:23:37 q+ 06:23:38 ... We may not need it for all algos, but for those that have IV. 06:24:06 .. If you specify "auto" (...) 06:24:24 gcapiel has joined #crypto 06:24:24 q? 06:24:28 virginie: Potential action to richard 06:24:45 ryan: Propose that richard write proposal. israelh suggested a way. 06:24:59 kotakagi has joined #crypto 06:25:03 ACTION: Richard to update proposal for auto-IV proposal 06:25:03 Created ACTION-128 - Update proposal for auto-iv proposal [on Richard Barnes - due 2013-11-21]. 06:25:10 mete: Understand generatibg IV randomly, but why in low-level API? 06:25:19 q+ 06:25:22 ... This shoul dbe handled in higher API. 06:25:36 +??P15 06:25:41 ... This is relted to topic of operational params that VJ sent e-mail about. 06:25:46 mete, you wanted to ask if it could be better to handle these things in high level apis 06:25:48 - +1.434.941.aabb 06:25:58 hello who is P15 ? 06:26:03 vj: API that a;llows API to cut and paste sample code. 06:26:12 ... And get secure program that way. 06:26:16 serious +1 to vijay on allowing cut/paste to be safe 06:26:28 cut/paste is never safe :) 06:26:34 use a high-level API ;) 06:26:35 ... 1) If we'r egoing to have this behavior that sometimes you return IV with ciphertext, 06:26:45 rsleevi: yeah, about that..... 06:26:48 ... I dob't want to clutte rup the value. 06:27:01 q? 06:27:07 ... We have effectively separated out operation params 06:27:21 ... Don't necessarily give (...) params to call. 06:27:53 israelh: You always get a value back, uou always get the same i/f back. 06:28:03 ... Q is if there is an IV in it. 06:28:14 { data: [...] } or {data: [...], iv: [...]} 06:28:15 ... If you pas this particular string, which is default, 06:28:22 so you always result.data, but may not result.iv 06:28:26 ... that the Promise would look it up for you. 06:28:36 vj: I sthere any benefit to be had? 06:28:44 ryan: yes. 06:28:55 ... The buffer input to webcrypto, 06:29:02 ... in v.1 we are requing, 06:29:17 ... either you freeze th einputs, 06:29:24 ... an dprevent futher mutation, 06:29:32 ... or requirte impl to always copy buffers. 06:29:59 ... We would require imple to aways allocate new object. 06:30:14 ... And even if that is just 16 bytes, it is a seriuous consideration. 06:30:27 q? 06:30:28 ... It is basically an optimization thing. And Webkit is interested in that. 06:30:39 vj: That is valid thing. 06:30:48 richard: What is arg agains neutering? 06:31:10 ryan: The freezing? That would be the first API that does this. Would require changes to WebIDL. 06:31:25 tony_ has joined #Crypto 06:31:29 ... Downsize with freezing is you force the caller to allways allcoate 06:31:40 ... Else would allow sharing. 06:31:53 israelh: They are asynch calls by nature, makes it hartd. 06:32:01 virginie: Richard, want to add anythinh? 06:32:10 q+ 06:32:14 richard: support vj on general principles. 06:32:42 virginie: So we already put action on richard. 06:32:47 ACTION-128? 06:32:47 ACTION-128 -- Richard Barnes to Update proposal for auto-iv proposal -- due 2013-11-21 -- OPEN 06:32:47 http://www.w3.org/2012/webcrypto/track/actions/128 06:32:53 ... It may req more discussion in WG 06:33:06 rsleevi: in principle cut-and-paste is never safe, in practice most code is cut-and-paste :) 06:33:07 ... Stays open issue. 06:33:35 eric: From convenince of user, auto string may not be worth it. 06:33:40 Zakim, associate ACTION-128 with ISSUE-44 06:33:40 I don't understand 'associate ACTION-128 with ISSUE-44', rsleevi 06:34:08 I am going to note the issue as regards randomized IVs is a well-known error that multiple reviewers have brought up 06:34:17 israelh: Question: is is possible to instead of passing a keyword, to just autmatically overload. 06:34:21 AndyF has joined #Crypto 06:34:24 in fact, that was my initial proposal! 06:34:31 ... So no need to pass anything. 06:34:33 q+ 06:34:42 cf. ISSUE-46 06:34:43 ryan: Gets a little weird. 06:34:47 israelh: OK 06:34:53 vj: Eric's comment: 06:35:10 ...."Why not just random values?" 06:35:30 ... pb is that naive programmer has to know how long the IV has to be. 06:35:43 q? 06:35:50 var alg = { name: "AES-CCM", iv: "random-data" } vs var alg = { name: "AES-CCM", iv: "auto" } 06:35:55 ... Theymay generate just x bits 06:36:04 ryan: Good argument! 06:36:30 virginie: OK, we'll come back to that later. 06:36:48 ryan: issue 12 06:37:00 ... Just to restate: 06:37:22 on the topic of safe parameter choice, there was a great paper at CCS a few weeks ago that found that roughly 10% of apps using crypto used static IVs 06:37:24 http://www.cs.ucsb.edu/~chris/research/doc/ccs13_cryptolint.pdf 06:37:39 ... Came from fact that crypto algo hd param that reflected back what algo was craeted with. 06:37:40 88% of apps studied made some sort of bad parameter / algorithm choice 06:37:50 ... Could reuse params that you should not reuse. 06:38:03 ... IN promises model, we are no longer reflecting algo back. 06:38:04 issue under discussion in ISSUE-12 : http://www.w3.org/2012/webcrypto/track/issues/12 06:38:22 ... I do' tknow what advantage is of splitting algo and operation params. 06:38:24 issue-12? 06:38:24 issue-12 -- Should the API distinguish between algorithm and operation parameters? -- open 06:38:24 http://www.w3.org/2012/webcrypto/track/issues/12 06:38:35 ... Promise does not expose params. 06:38:48 ... Programmers have to track the params anyway. 06:39:03 ... J, your thinking? 06:39:16 vj: th eonly justification is syntactic sugar. 06:39:19 issue-12: 88% of apps studied made some sort of bad parameter / algorithm choice 06:39:19 Notes added to issue-12 Should the API distinguish between algorithm and operation parameters?. 06:39:23 s/J/vgb/ 06:39:25 s/J/vgb 06:39:31 ... I'm sympathetic to that argument. 06:39:54 ... We have been trying for month, maybe just let it go. 06:40:16 ... There is no good way to do it, so maybe just forget it. 06:40:25 ryan: So no further action on issue-12? 06:40:41 virginie: This morning we had two bugs to be opened for issue-12. 06:40:47 ... For richard. 06:40:59 richard: other issues this morning... 06:41:05 ryan: 36 06:41:26 richard: Comparison 06:41:39 ... we may yet have to clarify. 06:41:45 vj: Algorithm object? 06:42:13 ... comparing normalized version. All that remians is finding normalized. 06:42:33 richard: "compare these and ignore the others" 06:42:44 gcapiel has left #crypto 06:42:52 ... The keys that you compars. 06:43:17 vj: Taxonomy defining comparison. Is that in separate dictionaries? That is issue-12. 06:43:30 ryan: Do we expose that to user, or is it implementation? 06:43:44 virginie: So keep issue open. 06:44:01 ... But we close issue and open bugs? Should it be other way round? 06:44:20 ryan: We agree what the reslution should look like. 06:44:31 hhalpin: Editor should (...) 06:44:46 israelh: vj said keep it as is. 06:44:58 ryan: spec bug 06:45:19 virginie: is everyone happy? 06:45:38 the later it gets, the punchier i get :) 06:45:44 ... So action is to open a bug in order to "..." 06:46:01 ... Any others on issue-12? 06:46:06 +1 06:46:11 ... Put 1 on IRC if you agree. 06:46:13 +1 06:46:22 +1 06:46:24 +1 06:46:25 +1 06:46:28 PROPOSAL: Close ISSUE-12 with no user-visible changes to the API; a spec bug regarding equality of algorithm dictionaries will be opened, if not already 06:46:28 +1 06:46:29 +1 06:46:30 +1 06:46:32 ... Editor is going ot asnwer the bug 06:46:32 +1 06:46:39 0 06:46:46 Bug is 23098 06:47:00 ISSUE-36? 06:47:00 ISSUE-36 -- Semantics for key generation versus key derivation -- open 06:47:00 http://www.w3.org/2012/webcrypto/track/issues/36 06:47:12 q? 06:47:24 vj: I misse dmost of that due to audio pb 06:47:45 ryan: You and jim should put forward proposal. 06:48:08 ... You added a new usage for secret agreement, that became derived bits. 06:48:32 ... So question for you and riuchard is are you happy with that, does it meet use case? 06:48:32 i'm still OK with this 06:49:12 vj; In MS crypto APIs is not possible to get out bits of value. 06:49:35 ... You can get one rerivation out of it. So it doesn't quite work. 06:50:05 ryan: What you described, sounds like do secret agreement and then get derived key out of that. 06:50:16 ... But then you can de derived key to get key object. 06:50:27 ... And then you can get derived bits. 06:50:37 vj: It is possible to represent the oepration that way. 06:50:43 ryan: but is it pretty... 06:50:59 vj: Can support it that way for DH. 06:51:07 virginie: Other comments? 06:51:17 vj: I sent a few in e-mail: 06:51:44 ... One was about including key material in (...) 06:51:51 ryan: Yes, that is weird. 06:52:04 ... Also is it an arry buffer or something else? 06:52:18 ... API is inconsistent maybe. 06:52:20 well, if it's an ArrayBuffer, then the application has to figure out what the text encoding is 06:52:24 jmr has joined #crypto 06:52:44 vj: (scribe didn't understand) 06:52:57 +1 for me too 06:53:02 ryan: We can figure out what it should lok like on th elist. 06:53:07 vj: Other thing: 06:53:32 ... Pseudo code for various methods that return an object don't say that it needs to construct an object. 06:53:46 ... Most people would say result is a bunch of bytes. 06:53:55 ... It doens't say you have to construct key object. 06:54:08 ryan: I take that as a spec bug. I need to inmprove the etxt. 06:54:16 list 06:54:18 ... There is the den of the algo for derive dkey. 06:54:28 leckie_ has joined #crypto 06:54:38 ... ECDH example says this is the derivation. 06:54:52 ... And says "here is the format." 06:55:02 q? 06:55:03 .. that was the intention. 06:55:14 ... It is a language bug in my mind. 06:55:39 ... Example of derived key returning something else than an obkect: 06:55:49 ... Discussion on list was that this was weird. 06:55:59 ... Need to keep keys within security boundary. 06:56:10 ... Get four key handles back. 06:56:22 btoews has joined #crypto 06:56:25 ... generateKey sometime return key pair sometimes key object. 06:56:43 Mohammed has joined #crypto 06:56:50 joshpeek_ has joined #crypto 06:56:51 ... If we do SSL case, we can return four key objects. Not saying that we should do that case. 06:57:04 ... What obj is returned is similr for every other algo. 06:57:27 ... Indiv algo says here is the result of signing th eobject. 06:57:34 vj: Fine with that. 06:57:48 ... We generally agree in spirit, some wording to work out. 06:58:15 virginie: issue-46 this morning we agreed, nor vj is fine, so just this bug. Can close isse? 06:58:33 ryan: We created action for you to review. Can then close on next call. 06:58:34 s/46/6 06:58:40 s/6/36 06:58:40 vj: OK close on next call. 06:58:50 I'm fine with this too, but a note or other clarification would be welcome, because a colleague of mine had the same problem (not knowing what is returned) 06:59:08 virginie: Everybody OK with 36 and 43 close at next call? 06:59:15 s/would be welcome/would indeed be welcome/ 06:59:16 ... Admin issue: 06:59:20 +1 06:59:29 ... Now we have two systems for tracking. 06:59:30 https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=--- 06:59:36 btw, the audio is working *very* well this session 06:59:39 ... Is everybdy following them? 06:59:56 ryan: Other groups have piblic list. 07:00:16 ... I distinction between bugs and issues. 07:00:28 q+ 07:00:46 israelh: We have talked in last telcon about promsies model. Do we make an isse so we can close it? 07:01:02 ryan: On eof those design issues. Not just a spec bug. 07:01:13 israelh: I put some example code. 07:01:28 ... Make an issue fo rthat? 07:01:36 virginie: Can you do that during the break? 07:01:38 israelh: OK 07:01:51 hhalpin: We have to close all issues for LC, but no need to close all bugs. 07:02:20 ryan: we are likely to open bugs and issues during LC. 07:02:34 ... Bugs are quicker than issues to solve. 07:02:43 q? 07:02:50 vj: I looked at doc in Mercurial: 07:03:11 ... Is (...) an open issue? 07:03:20 ryan: Largely an issue of typing to do. 07:03:31 ... Jwk 07:03:45 ... 90% is typing issues. No excuse :-) 07:03:50 s/(...)/importKey and exportKey/ 07:04:12 israelh: Other thing for vj: we also postponed wrap/unwrap to tomorrow morning. 07:04:28 vj: I should be availabel tomorrow whole day. 07:04:45 https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=--- 07:04:52 dsinger_ has joined #crypto 07:05:00 on importKey and exportKey we should also agree for jwk if the jwk object is provided as arraybufferview or an object, implementations currently disagree on this 07:05:21 ryan: We have an old bug: 07:05:30 ... back in Sep 2012 07:05:45 ... Basically hwo we handle algo security stuff. 07:05:52 jmr has left #crypto 07:05:54 ... What is a good building block? 07:06:06 ... We discussed previously a giant algo table. 07:06:17 ... With notes where to seek further input. 07:06:33 ... We don't wan tto mainain that and update as cryptographer discover more. 07:06:35 taocai has joined #crypto 07:06:37 q? 07:06:55 q+ 07:07:00 virginie: So you propose to add some text? 07:07:15 ryan: Yes, I'll go through those bugs. 07:07:35 ... One of the ongoing bugs withou rsoltion: 07:07:44 ... raised by mark, 07:07:58 ... support jwa algos that Jose does not want to support. 07:07:58 q+ 07:08:16 ... Marks' language to add registration procedure. 07:08:17 q- 07:08:37 ... Discussion ongoing and may become an issue. 07:09:04 ... Jose has usage Ink, all in a single param. 07:09:09 sorry, which bug number are we dealing with ask the sleepy chair ? 07:09:26 ... How does webcrypto interpret this value? Do we need a 2nd value? And what if the values are inconsistent? 07:09:47 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23796 07:09:48 ... If the value from caller is a subset, it succeeds, if in conflict, it fails. 07:10:23 ... Spec is not clear yet, people are welcome to jump it on m-list. 07:10:26 https://www.w3.org/Bugs/Public/buglist.cgi?list_id=29805®etlastlist=29805 07:10:57 markw has joined #crypto 07:11:03 virginie: What bug #? 07:11:04 https://www.w3.org/Bugs/Public/buglist.cgi?bug_id=18925%2C23796%2C20611%2C19416%2C21435%2C19705%2C22571%2C23013%2C23695%2C23096%2C23017%2C23779%2C23097%2C23159%2C23445%2C23499%2C23655%2C23051%2C23762%2C23729%2C23728%2C22992%2C23098%2C22598%2C23662%2C23660%2C23504%2C23503%2C23501%2C23500%2C23498%2C23496%2C23495%2C23242%2C23043%2C22546%2C22977%2C22860%2C22548% 07:11:04 2C22677%2C22639%2C22570%2C23786&list_id=29805&order=bug_id&query_based_on=&query_format=advanced 07:11:25 leckie has joined #crypto 07:11:47 ryan: next is 19416 07:12:06 ... Wrap oper should detect that key is allowed for wrap. 07:12:17 https://www.w3.org/Bugs/Public/buglist.cgi?list_id=29805®etlastlist=29805 07:12:50 ryan: spec has a bug that it doesn't say that. So text to write. 07:13:01 ... 19705: 07:13:18 ... Don't konw resolution. 07:13:36 ... Spupply a list of defaults? Can you suply a safe list of defaults? 07:13:49 ... If you suplly a usage that isn't supported, it should fail. 07:14:16 ... Or people jst have to specify key usage *always" That seem sensible to me. 07:14:41 ... I propose option b, key usage is moved aedad of other params and must be specified. 07:15:08 hhalpin: You can imagine distinguishing low-level and high-level API. 07:15:17 ... Defaults might be problematic. 07:15:22 +q 07:15:24 ryan: No that is not the issue here. 07:15:37 ... Default here wa sjust syntactic sugar, not safer. 07:15:52 hhalpin: Even insecure code? 07:15:57 ryan: No, not really. 07:16:04 q? 07:16:57 mountie: Extension has key usage with objective, is there consideration for when extension is aenabled for key usage? 07:17:05 ryan: Unrelated to this bug. 07:17:16 ... This is just API semantics. 07:17:33 jmr has joined #crypto 07:17:38 mountie: If reuse object ID... 07:17:46 ryan: Different discussion. 07:17:58 ... You should file a bug for that. 07:18:12 ... This bug is call-time semantics, no relation object ID. 07:18:49 virginie: is this going to be future-proff, certifcate. 07:19:16 ryan: Separate issue from what happens when you call (...) 07:19:26 q? 07:19:27 virginie: 19705: other comments? 07:19:44 ryan: Next 20611 07:20:01 ... Javascript side. 07:20:20 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20611 07:20:22 ... text encoding 07:20:43 ... Array buffer withg a sequenc eof bytes, how do you interpret that? 07:21:02 ... Should webcrypto interpet it as utf-8? 07:21:17 ... It is underspecifed in spec. 07:21:36 ... next is 21435 07:21:39 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21435 07:21:58 ... as* key length can be inferred from bytes. 07:22:13 .. When importing a key do you have to say the length? 07:22:24 ... I think it is similar to jwk. 07:22:36 ... Caller not required to specify length, because can be inferred. 07:22:50 ... In Jwk you can hopefully infer everythng. 07:23:02 vj: If caller specifiesa param and it conflicts? 07:23:17 ryan: Correct: then operation will fail. 07:23:39 vj: Agree. We should never ignore params. 07:24:31 ryan: 22545 was already fixed. 07:24:45 s/22545/22546/ 07:25:05 virginie: One more bug and then coffee break. 07:25:12 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22548 07:25:18 ryan: 22548: 07:25:37 ... Couple of issues in WebIDL. 07:25:39 leckie has left #crypto 07:26:16 ... Is "decrypt, decrupt, decrypt" same as "decrypt"? 07:26:27 .. Duplicates not preserved, is the proposal 07:26:35 virginie: Comments? 07:26:38 q+ 07:26:58 MichaelH: is "decrypt, decrupt" legal? 07:27:02 ryan: yes 07:27:04 ack michaelh 07:27:11 leckie has joined #Crypto 07:27:16 ... Spec eithe rhas to say it is invalid or what it means. 07:27:29 MichaelH: Seems overkill to put in 3 decrypts. 07:27:33 s/decrupt/decrypt 07:27:40 ryan: yes, but oit has no implications. 07:27:52 MichaelH: Sort them alphabetical and compare? 07:28:07 ryan: does the sortin gmatter? 07:28:21 eric: in JS you can do "in" text 07:28:42 (scribe missed) 07:29:04 ryan: I don't think you can compare arrays directly. 07:29:17 ... So have to do it with in-tests 07:29:32 .. But it may be sotrted, I don't have preference. 07:29:32 q? 07:29:45 virginie: break for 30 mins. 07:30:03 israelh: And go through the Promises issue? 07:30:10 Promises issue 59: https://www.w3.org/2012/webcrypto/track/issues/59 07:30:12 -vgb 07:30:17 I won't be able to attend the next session, tomorrow I will be on the call the complete afternoon 07:30:45 ok, thxs vgb 07:31:07 -nvdbleek 07:31:10 -Wuzhou_East 07:31:20 i'll be back, nick is leaving 07:43:55 ekr has joined #crypto 07:57:48 csjung____ has joined #crypto 07:57:57 we will resume the meeting in few minutes 08:01:27 +vgb 08:02:26 mete has joined #crypto 08:06:00 tantek has joined #crypto 08:06:16 +Wuzhou_East 08:06:20 lets chase bugs... 08:07:13 +Wuzhou_East 08:07:16 mountie has joined #crypto 08:07:56 nkic has joined #crypto 08:08:41 ISSUE-59? 08:08:41 ISSUE-59 -- Promises Programming Pattern Verification -- open 08:08:41 http://www.w3.org/2012/webcrypto/track/issues/59 08:09:19 scribenick: kodonog 08:09:27 tony has joined #Crypto 08:09:35 describing promises issue that was just created 08:09:50 Israel providing overview of the issue 08:10:03 we've released the crypto spec that deals with events 08:10:03 btoews has joined #crypto 08:10:09 in IE windows 7 and 8.1 08:10:17 sample code has been written 08:10:45 sample code retrieving a password that some enters 08:10:55 using different operations that someone enters 08:11:19 doing the basic promises model 08:11:25 in the first pass we are getting digest 08:11:29 passing the parameters 08:11:41 jin has joined #crypto 08:11:45 doing the import key and continue to get some random values 08:11:50 and ultimately encrypt 08:12:12 in this case, i've skipped the error handling part until the last 08:12:33 why do you care about the intermittent failures when you have the promises model 08:13:17 if the first digest failed, wouldn't you skip the exception. 08:13:25 Israel: no 08:14:00 commenting the http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/att-0023/CryptoPromises.sample.txt 08:14:24 rsleevi: promises is trying to encourage a more idomatic approach for example 2 08:14:30 AndyF has joined #crypto 08:14:52 rsleevi: what happens if promises 2 or 3 fail 08:15:02 israel: then promises 1 fails 08:15:22 all of the internal promises that fail are bubbled up to promise 1 08:15:36 rsleevi: the way that promises are supposed to work, you do a, then b, then 08:15:37 c 08:15:59 israel: there is a problem with that model, the first promise is the one you created by passing the parameters 08:16:33 markw has joined #crypto 08:17:11 how to pass parameters to the 2nd promise? 08:18:17 (discussion between ryan and israel on how promises work) 08:19:24 taocai has joined #crypto 08:19:49 digest.then(function (digestResult) { return importKey(... digestResult) }).then(function (importResult) { return encrypt(..., importResult) }).then(function (encryptResult) {}); 08:20:05 wc.digest(...).then( 08:20:06 function(digest) { return wc.importKey(...); } 08:20:07 ).then( 08:20:09 function(key) { return wc.encrypt(...); } 08:20:10 ).then( 08:20:11 function(ciphertext) { return wc.importKey(...); }, 08:20:12 functionToHandleErrors 08:20:13 ) 08:21:02 Israel's example: have to do for an event model 08:22:46 Israel: if you think about multipart versus one part, we've agreed not to do multipart for v1 08:23:07 does the model still hold, because in a multipart model, are we looking for the dents to be automatically created? 08:23:08 variant: 08:23:10 wc.digest(...).then( 08:23:11 function(digest) { return wc.importKey(...); }, 08:23:12 functionToHandleDigestErrors 08:23:14 ).then( 08:23:15 function(key) { return wc.encrypt(...); }, 08:23:16 functionToHandleEncryptErrors 08:23:17 ) 08:23:23 we can thing about multipart operation as a synthentic stream 08:23:32 tricky when you want to clone state 08:23:49 probably not address until v2 08:24:07 in the stream model, you may still hae to send out some events 08:24:19 webapps group is trying to figure out how they want streams to look 08:25:01 israel: i will retype my example for inclusion in Issue #59 08:25:35 Going back to the bug resolution discussion 08:25:54 https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&order=bug_id&product=Web%20Cryptography&query_based_on=&query_format=advanced&resolution=--- 08:26:37 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22571 08:26:45 rsleevi: we can add sorting (wrt bug 22548) 08:27:02 nvdbleek has joined #crypto 08:27:14 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22570 08:27:22 Bug 22570 08:27:40 relates to earlier conversation on random data 08:27:53 wonsuk has joined #crypto 08:28:33 array buffer cipher text, array buffer tag 08:29:04 +??P9 08:29:21 hi richard 08:30:02 rsleevi: personal preference do nothing 08:30:30 rbarnes has joined #crypto 08:30:39 zakim, who is on the phone? 08:30:39 On the phone I see Wuzhou_East, rbarnes, vgb, rbarnes.a 08:30:59 israel: i've talked to implementors as well and gotten different feedback 08:33:14 rsleevi: I don't have a clear 08:33:19 q? 08:33:28 vijay: unrap key takes the key format. 08:34:09 (vijay - can you enter your question... I missed it) 08:34:52 vgb: for importKey/exportKey we can just define the format to define a serialization, right? 08:35:03 Bijay: for decrypt it might be better to just add an option for that. otherwise the programmer has to create a weird object 08:35:14 rsleevi: Sure, but we have to solve the encrypt/decrypt data 08:35:19 Mark: you could say the last one in the sequence is the authentication tag. 08:36:14 rsleevi: pass some of the parameters in the algorithm, 08:36:21 there are alot of ways to do this 08:36:23 q? 08:37:10 do you supply tag as part of the input or the parameters (for the encrypt/decrypt operations) 08:37:31 How do you feel about this in terms of concatenation. 08:37:47 We'll just have to try to various options and see what the sample code looks like. 08:38:05 rsleevi will propose something in the next rev of the spec 08:38:28 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22571 08:39:05 rsleevi: can't have a dictionary that is an attribute, this is correct and will be fixed in the next version of the spec 08:39:13 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22598 08:40:11 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22639 08:40:18 a variation on a previous bug, will be fixed in the next version of the spec 08:40:48 for 22639, this is just a language issue, will be fixed 08:40:48 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22677 08:41:36 raised by jim, today wrapped key is defined to call encrypt, unwrap calls decrypt , language issue 08:41:46 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22860 08:42:56 22860, copy past error 08:43:07 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22977 08:43:26 22977, will be updated to say promise 08:43:28 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22992 08:43:55 22992, webIDL bug 08:44:28 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23013 08:45:06 dsinger has joined #crypto 08:45:15 dsinger has left #crypto 08:45:17 23013, there are a couple duplicates of this, assymetric key pair, what do usages mean, what do the extractable attributes mean 08:45:44 i would support saying extractable = true for public keys always 08:46:47 q? 08:47:00 +q 08:48:21 -q 08:51:59 when you are generating a key pair, you would give the key usage, the signature would go with the private key, the would go with the public key 08:52:43 the next version of the spec, we have a consensus of what it should say, it just needs to be reviewed to ensure that it does say that 08:53:20 this is a normative requirement (not a non-normative note to implementors) 08:54:35 can't do a generic boiler plate because it is specific for each case 08:55:14 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23017 08:55:23 Mohammed has left #crypto 08:55:28 23017, adding webIDL syntactic sugar 08:55:47 Vijay: why does this bug matter? 08:55:58 vgb sounds fine to me 08:56:05 vijay... type in the irc 08:56:08 must be great firewall 08:56:18 tony has joined #Crypto 08:56:38 why does this bug matter? 08:56:49 any implementation supports maybe 2-3 RSA key sizes 08:57:01 if you can express a valid key size as a -ve number more power to you 08:57:16 webIDL says if you provide a negative number, convert to a positive 08:57:33 no, i'm saying that it's hard to define a rule in the spec that works for all implementations 08:58:20 goal is to add to webIDL or to the prose the explicit typed system 08:58:26 ok 08:59:16 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23043 08:59:50 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23051 08:59:53 23043, derived key type... some steps missing 09:00:10 23051, missing webIDL sugar 09:00:17 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23096 09:00:28 23096, dup of 23013, 09:00:37 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23097 09:01:21 23097, handling truncated signatures, HMAC-96, either API needs to specify how we support trunctation or say that we don't support truncation 09:01:42 plan is to specify how we support truncation 09:02:04 vijay: truncation causes security bugs, is anyone actually asking for this 09:02:50 rsleevi: there has been a request, people will do truncation either with or without API support 09:03:11 vijay: this is only relevant for operations that support truncation (HMAC) 09:03:22 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23098 09:03:54 23098, general issue, operation parameters and algorithm parameters 09:04:31 eric has put together a couple of proposals, 09:04:44 we will pick one of the options and go with it 09:05:07 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23159 09:05:33 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23242 09:05:36 23159, some parameters are bits and some are bytes, need to pick one 09:06:01 23242, no operation/algorithm support wrap/unwrap 09:06:28 next version will make it clear which operations/algorithms support wrap 09:06:32 which should? 09:07:07 RSA, RSA-ES, RSA-OAEP, are examples 09:07:15 why not AES-GCM? 09:08:03 if we define wrap/unwrap in terms of encrypt/decrypt why wouldn't any of the algorithms 09:08:11 vijay and rsleevi both shrug 09:08:26 put wrap/unwrap on them all and people can argue ones that shouldn't 09:08:28 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23445 09:08:30 israelh has joined #crypto 09:09:02 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23495 09:09:17 mountielee has joined #crypto 09:09:25 23445, depending on whether the bug is correct or incorrect the spec will be changed 09:09:54 23495, measuring entropy is not relevant on desktop computers 09:10:37 if we are at a place of lacking entropy you are at a point of SSL breaking down as well... 09:10:59 hhalpin: process, we need to get Dr. Boneh's call 09:11:18 q+ 09:11:19 correction... get Dr. Boneh on a call 09:11:40 we shouldn't remove it from bugzilla until last call closes or he responds 09:11:50 nvdbleek has joined #crypto 09:12:14 next step: Harry will reping him regarding attendance on next call, resend Ryan's answers, 09:12:44 rsleevi: want to consider this issue closed unless we hear back. 09:14:01 are we going to separate the existing bugs from the new ones generated during last call? 09:14:50 Rigo: last call is a notice to other groups that we believe that we are done, shouldn't go to LC with open bugs 09:16:03 Rigo: further explanation of the LC process 09:18:33 two classes of bugs, spec is ambiguous or incomplete, feedback we get from the community (we may leave these open, include our response) 09:20:10 Mete: are we happy about the random number stuff or is this a version 2 topic 09:20:20 kotakagi has joined #crypto 09:21:21 rsleevi: two aspects; get random values and ### 09:22:00 also, getrandomvalues is sync, generateKey is async 09:22:10 async methods can take as long as they want to return 09:23:03 vgb: in windows 8 we are constantly reseeding... 09:23:40 Windows doesn't expose the amount of entropy available, correct? 09:23:55 vgb: internally we have an entropy estimate but we never surface it 09:24:41 rsleevi: this notion of entropy has a deep cryptographic challenge associated with it, there is no good cross platform way to say "do i have entropy or not?" 09:25:20 q? 09:25:25 ack mete 09:26:18 why would an api have a switch that says I'm ok with insecurity. 09:26:36 you don't want a webpage to drain your entroyp pool 09:26:50 point of entropy doesn't really make sense in this context. 09:27:16 Mete: regarding email I sent yesterday, HMAC-SHA1 09:27:27 rsleevi: I thought it was in the spec, 09:27:41 universally implemented 09:27:59 a bug will be filed by Mete 09:28:33 tobie has joined #crypto 09:28:35 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23655 09:29:02 i would be fine with [] == 0x00 09:29:51 23655, spec will be updated to make clear 09:31:16 meet 9am (local), 5 pm pacific 09:31:31 -rbarnes.a 09:31:35 -vgb 09:31:56 rrsagent, please draft minutes 09:31:56 I have made the request to generate http://www.w3.org/2013/11/14-crypto-minutes.html rigo 09:32:00 -Wuzhou_East 09:32:15 zakim, who is here? 09:32:15 On the phone I see rbarnes 09:32:16 On IRC I see tobie, kotakagi, nvdbleek, mountielee, tony, taocai, markw, AndyF, jin, nkic, tantek, mete, csjung____, MichaelH, sangrae, Bert, virginie, kodonog, vgb, rigo, channy, 09:32:16 ... hayato___, eroman, rsleevi, Zakim, RRSAgent, timeless, trackbot 09:32:20 wrapping up for the day 09:34:25 manu1 has joined #crypto 09:48:43 csjung____ has joined #crypto 10:04:07 Bert has left #crypto 10:19:36 jyates has joined #crypto 10:40:00 disconnecting the lone participant, rbarnes, in Team_(crypto)00:35Z 10:40:02 Team_(crypto)00:35Z has ended 10:40:02 Attendees were nvdbleek, Wuzhou_East, +1.425.836.aaaa, vgb, +1.434.941.aabb, rbarnes 11:32:49 Zakim has left #crypto 12:25:33 nvdbleek has joined #crypto 12:34:09 nvdbleek has joined #crypto 12:36:08 csjung____ has joined #crypto 12:49:02 mete has joined #crypto 12:51:54 nvdbleek has joined #crypto 14:01:30 nvdbleek has joined #crypto 14:50:57 ekr has joined #crypto 15:16:20 tantek has joined #crypto 15:34:55 tantek has joined #crypto 16:08:40 csjung____ has joined #crypto 16:19:52 tantek_ has joined #crypto 17:15:01 ekr_ has joined #crypto 18:01:42 danny_ has joined #crypto 18:37:38 tobie has joined #crypto 19:27:14 ekr has joined #crypto 21:00:35 ekr has joined #crypto 21:01:50 danny_ has joined #crypto 21:30:10 tantek has joined #crypto 21:41:29 ekr has joined #crypto 23:18:07 ale has joined #crypto 23:29:31 ekr has joined #crypto