18:56:52 RRSAgent has joined #crypto 18:56:52 logging to http://www.w3.org/2012/05/14-crypto-irc 18:56:55 zakim, who is here? 18:56:55 sorry, ekr, I don't know what conference this is 18:56:55 zakim, this will by CRYPT 18:56:56 On IRC I see RRSAgent, Zakim, emily, wtc, ekr, mcdondan, rbarnes, kaepora, Channy, tjr, tl1, ddahl, timeless, davidsarah, wseltzer 18:56:56 I don't understand 'this will by CRYPT', wseltzer 18:57:53 zakim, this will be CRYPT 18:57:53 ok, wseltzer; I see SEC_WebCryp()3:00PM scheduled to start in 3 minutes 18:58:04 smc has joined #crypto 18:58:12 virginie_galindo has joined #crypto 18:59:52 zakim, who's on the phone? 18:59:52 SEC_WebCryp()3:00PM has not yet started, rbarnes 18:59:54 On IRC I see virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, rbarnes, kaepora, Channy, tjr, tl1, ddahl, timeless, davidsarah, wseltzer 19:00:54 PhilipG has joined #crypto 19:00:57 Hi, all. I'm only on IRC because it's 4am in Korea :) 19:01:21 hi Channy - thanks for waking up! 19:01:27 fluffy has joined #crypto 19:01:52 zakim, who's on the phone? 19:01:52 SEC_WebCryp()3:00PM has not yet started, rbarnes 19:01:53 On IRC I see fluffy, PhilipG, virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, rbarnes, kaepora, Channy, tjr, tl1, ddahl, timeless, davidsarah, wseltzer 19:02:11 hhalpin has joined #crypto 19:02:32 christopherkula has joined #crypto 19:02:56 Zakim, what's the code? 19:02:56 the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin 19:03:16 rsleevi has joined #crypto 19:03:17 calling from 510-387-xxxx 19:04:16 MitchZ has joined #crypto 19:04:21 rbarnes has joined #crypto 19:04:23 hi all, solving few problems of connection with wendy. will be there in a minute 19:04:29 Zakim, who's on the phone? 19:04:29 SEC_WebCryp()3:00PM has not yet started, ddahl 19:04:30 On IRC I see rbarnes, MitchZ, rsleevi, christopherkula, hhalpin, fluffy, PhilipG, virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, kaepora, Channy, tjr, tl1, 19:04:30 ... ddahl, timeless, davidsarah, wseltzer 19:04:51 Zakim, who's on the phone? 19:04:51 SEC_WebCryp()3:00PM has not yet started, hhalpin 19:04:52 On IRC I see rbarnes, MitchZ, rsleevi, christopherkula, hhalpin, fluffy, PhilipG, virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, kaepora, Channy, tjr, tl1, 19:04:52 ... ddahl, timeless, davidsarah, wseltzer 19:04:59 Zakim, who's on the phone? 19:04:59 SEC_WebCryp()3:00PM has not yet started, hhalpin 19:05:00 On IRC I see rbarnes, MitchZ, rsleevi, christopherkula, hhalpin, fluffy, PhilipG, virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, kaepora, Channy, tjr, tl1, 19:05:02 ... ddahl, timeless, davidsarah, wseltzer 19:05:47 Karen has joined #crypto 19:05:51 Zakim, who's on the phone? 19:05:51 SEC_WebCryp()3:00PM has not yet started, hhalpin 19:05:52 On IRC I see Karen, rbarnes, MitchZ, rsleevi, christopherkula, hhalpin, fluffy, PhilipG, virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, kaepora, Channy, tjr, 19:05:52 ... tl1, ddahl, timeless, davidsarah, wseltzer 19:05:55 sdurbha has joined #crypto 19:05:58 zakim has been having trouble lately 19:07:22 Asad has joined #crypto 19:08:31 Web Cryptography Meeting Convened 19:08:37 chair: virginie_galindo 19:08:40 scribe: hhalpin 19:08:46 Zakim, agenda? 19:08:46 I see nothing on the agenda 19:08:56 agenda+ Introduction 19:09:04 agenda+ "Virtual round table" of delegates 19:09:04 topic: Introduction 19:09:14 agenda+ Brief reminder of usecases for primary features 19:09:23 agenda+ Brief presentation of editor's draft API (by editors) 19:09:29 virginie: let's have a quick overview of all the topics we need to address 19:09:34 agenda+ Review of comments on draft Web Crypto API 19:09:47 agenda+ Web Cryptography Usecases and Requirements related to secondary features 19:09:53 ... and then go over some of the logistics to make sure we are all at the same place. 19:09:59 agenda+ Test Suite for Web Crypto API 19:10:08 agenda+ Feedback from public conf call 19:10:17 agenda+ Group life 19:10:22 Zakim, who's on the phone? 19:10:22 SEC_WebCryp()3:00PM has not yet started, hhalpin 19:10:23 On IRC I see Asad, sdurbha, Karen, rbarnes, MitchZ, rsleevi, christopherkula, hhalpin, fluffy, PhilipG, virginie_galindo, smc, RRSAgent, Zakim, emily, wtc, ekr, mcdondan, kaepora, 19:10:23 ... Channy, tjr, tl1, ddahl, timeless, davidsarah, wseltzer 19:10:28 agenda+ Liaisons with other groups 19:11:34 Harry, I'm here! -MitchZ 19:12:22 tjr - Tom Ritter, iSEC Partners. I'm on the phone. 19:13:03 kaepora: is that Nadim? 19:13:08 Yes 19:13:21 sdurbha: Seetharama Durbha, CableLabs 19:14:02 Asad from Gelmato, SDurbha from Cabelalbs, Karen from Gemalto, Richard Barnes (BBN), Ryan Sleevi (Google), Christopher Kula (indepdnent), Fluffy (Cisco), PhilipG (Cisco), Virginie (Gemlato), SMC (Shawn McGregor - Oregon State University) ,m Emily Stark (MIT), , Wan-Teh Changg (Google, Eric (RRTM), McDondan (?? - may not on phone), Kaepora (?? - maybe not on phone), Tom Ritter (iSec partners - IEs), Channy (?? maybe) , tl1 (Tom Lowenthal David (Phone), David 19:14:25 agenda? 19:14:25 s/RTRM/RTFM/ 19:14:37 Hey guys 19:14:39 Sorry I'm late 19:14:45 http://www.w3.org/2004/02/Process-20040205/groups.html#good-standing 19:17:12 emily has joined #crypto 19:17:17 http://www.w3.org/2004/02/Process-20040205/policies.html#coi 19:18:46 JimD has joined #crypto 19:18:50 David Hooley (Cablelabs Gate) 19:18:57 Jim Davenport (MITRE) here 19:19:23 Jim Davenport (MITRE) 19:20:08 public-webcrytpo@w3.org 19:20:13 https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebCryptoWG&component=Crypto%20API 19:20:19 (bugzilla) 19:21:41 we'll have a separate public-webcrypto-comments list 19:22:20 Topic: use-cases 19:22:49 zakim, take up agendum 3 19:22:49 agendum 3. "Brief reminder of usecases for primary features" taken up [from wseltzer] 19:23:16 virginie: what we have seen is that the use-cases behind the primary features are under debate last week 19:23:50 ... I propose we have a wiki-page where we store the use-cases 19:23:57 ekr: the primary use-cases are too vague 19:24:28 I just summarized some of features in community wiki. http://www.w3.org/community/webcryptoapi/wiki/Use_Cases It's very starting page. 19:24:30 ekr: we need to be a lot more detailed than the list of things, largely because of the requirement of key isolation 19:24:35 RRSAgent, draft minutes 19:24:35 I have made the request to generate http://www.w3.org/2012/05/14-crypto-minutes.html timeless 19:24:45 ... we hvae to list them excruciating detail 19:24:58 richard: if we have a requirement that the javascript layer can't handle the key 19:25:08 ... then we need to have explicit functions for derived key 19:25:28 ekr: every single protocol, as there's a azillion different key derivation functions 19:25:29 q+ 19:26:06 karen: I also think we define the scope and the level 19:26:19 ... most of the messages do not seem aimed at high-value use-cases 19:26:27 Particularly, it needs to say stuff like JOSE, FIPS 800-108, etc. 19:26:39 Hey guys, I'm in the conference call (I'm Nadim Kobeissi) 19:26:40 s/azillion/zillion/ 19:26:45 wtc: I suggest that we need to sharpen the editors draft in the use-case 19:26:54 ack hhalpin 19:27:02 I proposed some use cases way back in December: http://lists.w3.org/Archives/Public/public-identity/2011Dec/0058.html I can revisit those and flesh them out if desired. 19:27:16 (Some of those are clearly outside the scope now.) 19:27:28 tjr: probably would be helpful 19:27:41 tjr: these seem like the right kind of thing. 19:27:52 (not necessarily saying I agree that they are exactly right) 19:29:29 q+ 19:30:00 I think it's definitely to be interpreted as key isolation 19:30:30 What else would you do with secret key material? 19:30:58 How can I put myself on the speaker queue? 19:31:23 ddahl: let's consider key material still open at this point 19:31:28 ... in some cases we'll need it 19:31:33 q+ 19:31:40 RRSAgent, draft minutes 19:31:40 I have made the request to generate http://www.w3.org/2012/05/14-crypto-minutes.html timeless 19:31:44 good Zakim guide here: http://www.w3.org/2001/12/zakim-irc-bot 19:31:47 q- ddhal 19:31:49 Isn't the complexity around key isolation really two things: (1) how you derive / access the key or (2) how may crypto APIs you want in the generic case, whether you support key isolation or not? 19:31:53 q- 19:32:10 q+ 19:32:26 We don't need to add all crypto algorithms under the sun in version 1 of the APIs, do we? 19:32:29 s|s/RTRM/RTFM/|| 19:32:34 s/Hey guys// 19:32:38 s/Sorry I'm late// 19:32:49 s/webcrytpo/webcrypto/ 19:32:52 MitchZ: no, we should not 19:32:55 kaepora: the charter should be interpreted as key isolation 19:32:59 s/(bugzilla)// 19:33:05 ... no other thing that is actually helpful 19:33:09 s|https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebCryptoWG&component=Crypto%20API|-> https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebCryptoWG&component=Crypto%20API Bugzilla| 19:33:23 RRSAgent, draft minutes 19:33:23 I have made the request to generate http://www.w3.org/2012/05/14-crypto-minutes.html timeless 19:33:26 can the speaker please introduce himself? 19:33:31 ekr: I'm not sure why this a surprise for people, its important to distinguish between two different kinds of key isolation 19:34:01 ... one form that I effectively trust JS with Key 0, but I'm worried about key theft at a later point 19:34:15 zakim, who's talking? 19:34:15 sorry, JimD, I don't know what conference this is 19:34:19 ... the other case is where you consider the browser is a trusted platform, and I'm not even allowed the access the keys 19:34:26 q- 19:34:31 JimD: ekr is talking 19:34:52 ekr: we should distinguish them, most of security rationales are about the first, not the second 19:35:09 q? 19:35:11 q+ 19:35:14 q- ekr 19:35:44 MitchZ: Our concerns around key protection have to be about writing more and more web applicaitons in HTML5, XSS attacks 19:36:12 ... what is we are pulling down stuff from location we though we were (ala TLS) that may work in some cases 19:36:22 q+ 19:36:32 ... as applications being arbitrarily deployed, our concern is concern is for the user 19:36:36 zakim, this is SEC_WebCryp 19:36:36 ok, JimD; that matches SEC_WebCryp()3:00PM 19:36:54 ... if they want to take the keys to different application or a browser, we are worried about rogue attacks and non-renewable firmware 19:37:35 ekr: I'll be honest if we have XSS attacks, then we a problem and you need to figure out reseed their applications 19:37:49 Good distinction: browser/devices 19:38:35 MitchZ: that may be true in browser world, but things may be very different in devices where the keys are hidden from anything but secure OS 19:38:47 ... usually the keys are hidden in HSM is becoming more common and necki 19:38:51 agenda? 19:39:04 s|good Zakim guide here: http://www.w3.org/2001/12/zakim-irc-bot|| 19:39:14 I keep hearing "Eckert" 19:39:20 Are people referring to "ekr"? 19:39:23 Yes 19:39:25 If so, apologies, Eric. 19:39:30 Of course I know you ;) 19:39:36 We need to do lunch again soon... 19:39:51 s/m Emily/Emily/ 19:39:54 s/, ,/,/ 19:40:00 ekr: in exactly the case in MitchZ is talking about exposure of ephermeral keys is not so bad, but exposure of permanent keys is terrible 19:40:12 ... a design where every key has to be hidden may be impossible 19:40:18 ... not an all or nothing issue 19:40:23 hhalpin: i think this is an open issue that cannot be viewed as an all or nothing situation. I can see some API methods that allow you to create accessible key material, but the default main usage will be via keyID 19:40:56 q+ 19:41:18 q+ 19:41:27 ack MitchZ 19:41:29 so, for instance, if you said that you couldn't access certain long-term keys, but you could export symmetric keying material, the whole KDF problem goes away 19:41:51 MitchZ: it is true that in many cases session keys can be revoked and renewed, so maybe XSS isn't a huge issue 19:42:13 ekr: we should create some psuedo-code examples that better explain when we might want have access to the secret key material 19:42:17 ... we have examples of how third parties take those keys and abuse them in interesting ways, and we have internally implemented things were session keys are inaccessible 19:42:23 I'm not suggesting that there is *no* benefit to protecting keys ever. 19:42:24 ... its not a religious standpoint 19:42:31 ... should have a either-or design 19:42:34 q- MitchZ 19:42:37 q- ekr 19:42:40 q+ 19:43:11 rsleevi: lets look at high level, low level, normal 19:43:22 ... PCKS11 gives you option, and you see thats common with other API 19:43:42 rsleevi: +1 to this approach 19:43:49 .. look at the "refer to by handle" but you can export it potentially in Crypto API and Next Gen Crypto API from Microsoft 19:43:53 ... you have things and consistently refer to them by handles 19:44:02 Where things get really messy is whether the application of a key to a piece of data taints the output of that operation. 19:44:12 ... but as some of this is implenmtatnion dependent, we can get them 19:44:18 q+ 19:44:31 So, say I have an RSA key and I do X=RSA_decrypt(K, msg) 19:44:36 ... but if we go low-level like PKS11 for JS we're going to have a very trickty time 19:44:38 Should I be able to see the output of X? 19:44:43 ... padding schemes, encrpytion modes, 19:44:46 q+ 19:45:02 kaepora has joined #crypto 19:45:23 ... we should allow implemention dpeendent 19:46:03 ... import/export out of key material 19:46:06 rbarnes: I'd like more info on use-caes before making decision on use-cases 19:46:07 This becomes especially difficult if some of the operations reveal information about the keys. 19:46:13 q- 19:46:53 Virginie: A need for us to write the use-cases down and transform them into functional requirements 19:46:57 So, for instance, it's generally safe to operate an RSA decryption oracle as long as I'm not allowed to do raw output of PKCS#1 non-compliant data 19:47:03 kaepora has joined #crypto 19:47:14 but it's *not* necessarily safe to output the results of DH key agreement compuations 19:47:14 ... the multiple levels approach is a proposal 19:47:18 Someone mentioned earlier that W3Crypto would be used on Bluray devices – could someone expand on that? Examples? 19:47:18 I'm having a hard time hearing Virginie 19:47:29 New idea to me 19:48:04 kaepora: There is a netflix use case for this... http://www.w3.org/wiki/NetflixWebCryptoUseCase 19:48:55 to fluffy : hearing of understanding my frenc accent ? ;-) 19:48:58 *Crickets* 19:49:02 hhalpin: i will if no one else does 19:49:13 so, I don't generally understand the problem that people think they are trying to solve. I know how I would design a system :) 19:49:18 ddahl: i can help 19:49:22 i'll volunteer to work with ddahl 19:49:24 rbarnes++ 19:49:33 MitchZ++ 19:49:35 ACTION: ddahl amd MtichZ to help collect use-cases around key isolation 19:49:50 hhalpin: don't forget rbarnes 19:50:02 agenda? 19:50:16 zakim, drop agendum 2 19:50:16 agendum 2, "Virtual round table" of delegates, dropped 19:50:30 zakim, take up agendum 4 19:50:30 agendum 4. "Brief presentation of editor's draft API (by editors)" taken up [from wseltzer] 19:50:42 s/and MitchZ/ and MitchZ and rbarnes 19:50:54 topic: Brief presentation of editor's draft API 19:51:00 -> http://www.w3.org/2012/webcrypto/WebCryptoAPI/ 19:51:10 ddahl: This is just a starting point for conversation on the API 19:51:22 http://www.w3.org/2012/webcrypto/WebCryptoAPI/ 19:51:24 ... I've expanded on DomCrypt work 19:52:03 w.r.t. to ekr's question on the RSA decrypt, i believe that what is described does not work b/c... the initial message from client -> server does not contain any sort of acknowledgement that the exchange has the eventual purpose of key exchange with key hiding 19:52:23 ... the big change is we've moved to event driven model 19:52:30 sorry, I don't understand your point. 19:52:30 ... that's the largest change from DomCrypt 19:52:40 ... I'd like to see if this event-driven model makes more sense 19:52:40 DH has the benefit of the SS creation happening under the covers, so it's obvious how this would work w/ DH 19:53:00 ... no such thing as call-back driven DOM interface as event-driven is cleaner, allows multiple listeners 19:53:06 ... seems to be "what the web expects" 19:53:10 but an RSA "for hidden key exchange" could certainly be possible, but it isn't regular RSA encrypt/decrypt 19:53:15 q+ 19:53:20 q+ 19:53:27 ... as far as key isolation, everything is what I think of as "high-leveL' 19:53:37 ... what appears to be high-level could be low-layer from a different layer 19:53:40 q- 19:53:57 Mitch: well, as I said, I'd like to see a threat analysis that explains why it's desirable to hide the RSA output. 19:54:08 ddahl: I'm a browser engineer, not a cryptographer 19:54:22 I don't understand how this API works if I have concurrent key generations. 19:54:25 ... the main other things that have changed is hashing and MAC 19:54:28 ... other folks want CMAC 19:54:32 how do I distinguish them? 19:54:36 ... so some other things have came up 19:54:41 ... this is a starting point 19:54:49 ... I have tried to add as much example code as possible 19:55:06 can't we use hg? 19:55:16 That's what WebApSec is using. 19:55:51 perhaps the hub of git. :) 19:56:19 The question I'm planning to ask: will adding DRM a-la-Netflix be worth modifying our spec, or is it not enough of a priority? 19:56:51 ? Netflix' involvement in this has nothing to do with DRM? 19:57:06 So, I'll be curious to hear your question. 19:57:08 virginie: we want to address as much as we have 19:57:26 ... so let's stick to discussion on mailing list rather than raising new version 19:57:29 ddahl: how do you handle concurrent async operations? 19:57:40 q? 19:57:42 q? 19:57:42 MitchZ: http://www.w3.org/wiki/NetflixWebCryptoUseCase specifies "DRM license exchanges" 19:57:43 q- 19:57:50 q- ekr 19:58:05 q- 19:58:10 ddahl: we will try to create constructors 19:58:15 ekr: I'm not have callback vs events 19:58:21 ... but we need to have concurrent operations 19:58:35 ddahl: what will happen is that you'll create a constructor and isolate it via constructor 19:58:44 ddahl: That was the motivation for the object-based approach discussed on the mailing list - so that different objects may have different callbacks, and for the use via Workers 19:58:53 s/callbacks/events/ 19:59:07 q+ 19:59:30 kaepora: API to grant license exchange, we would modify the charter 19:59:35 rsleevi: indeed, that was another thing that Mozilla platform engineers recommended - a synchronous API in parallel that only runs in Workers 19:59:41 Whew, great news 19:59:47 MitchZ: I'll remove the DRM acronym from use-case document now, our protocol has to do with device and user-authentication 19:59:55 MitchZ: That's wonderful news, thanks. 19:59:58 ... the DRM question confuses 20:00:02 q+ 20:00:04 -??P21 20:00:11 Yeah, I was a bit frazzled by the mention of DRM ;-) 20:00:13 q- 20:00:24 PhilipG: I wonder about higher level stuff 20:00:27 q+ 20:00:34 JimmyD0nut has joined #crypto 20:00:48 q- 20:00:49 agenda? 20:00:54 kaepora: thanks for input on use case doc. 20:01:09 topic: secondary use-cases 20:01:11 hhalpin: i think there might be a question from karen 20:01:12 MitchZ: Thanks for the reassuring answer, I'd hate this spec to be DRM-oriented. 20:01:35 me too :) 20:01:55 karen: for the API itself I don't quite understand where is the ciphertext is 20:02:17 ddahl: the ciphertext shows inside of the function handler that is run after things are encrypted 20:02:33 wtc: a few minor typos 20:02:48 karen: keystore of cryptoprovider 20:02:52 ... is that in-scope? 20:03:30 q+ 20:03:30 browser could provide key operations 20:03:31 ... but could smartcard? 20:03:36 q- Karen 20:04:05 rsleevi: looking at different levels of keys, looking at persistent keys on smartcards 20:04:06 ... some of its contigent on use-cases that come in 20:04:13 Is this meeting capped at ending in 30 minutes, or is expected to run indefinetly? 20:05:13 zakim, JimD is temporarily JimmyD0nut 20:05:13 sorry, JimD, I do not recognize a party named 'JimD' 20:05:14 q- 20:05:36 timeless has joined #crypto 20:06:04 - +1.403.244.aagg 20:06:08 RRSAgent, draft minutes 20:06:08 I have made the request to generate http://www.w3.org/2012/05/14-crypto-minutes.html timeless 20:06:12 Zakim, where is +1403? 20:06:12 North American dialing code 1.403 is Alberta 20:06:25 q+ 20:06:35 meeting: Web Cryptography Working Group 20:07:01 - +33.6.13.23.aall 20:07:28 wtc: what I have in mind is that the website use very high-level criteria, similar to TLS 20:07:35 RRSAgent, draft minutes 20:07:35 I have made the request to generate http://www.w3.org/2012/05/14-crypto-minutes.html timeless 20:07:41 ... specifying the set of acceptable criteria to find key in right key container 20:07:51 q? 20:07:55 q- 20:08:16 topic: gathering secondary feature use-cases 20:08:23 q+ 20:08:30 phone troubles here for virginie and wendy 20:08:44 I have a pretty elaborate use-case 20:09:10 q+ 20:09:41 nadim: I might want to volunteer for that document if no-one else does 20:09:46 ... I'd need to be briefed 20:10:04 ... I have an elaborate use-case for encrypted IM using HTML5 20:10:16 ... porting to Android to iOS using PhoneGap 20:10:22 ... it would benefit from such an API 20:10:47 ... secret key storage would be very useful 20:11:07 ... the project is already running so we can use it for a testbed 20:11:25 + +33.6.13.23.aapp 20:11:47 There is secondary feature use-cases from Korea too. http://www.w3.org/wiki/KoreaWebCryptoUseCase 20:11:55 I'll volunteer to assist nadim with secondary use-cases 20:12:09 Link to my project (Cryptocat) 20:12:11 ... move from Stanford Library to W3C library 20:12:13 https://project.crypto.cat 20:12:22 https://crypto.cat 20:12:36 rsleevi: do you mean just erasing it on the client or a message to the server? 20:12:43 ryan: we really want to fix the TLS session stuff, but as its in charter, that's one we are very interested in Google, could be done independently but could happen here 20:12:52 ... browsers each do it differenty 20:12:56 ... we will put together a strawman 20:13:28 ekr: API for the client to 'forget' its session ID 20:13:42 ekr: invaliding the (client) session ID cache 20:13:46 rsleevi: why doesn't the server do it 20:13:47 ? 20:14:00 ACTION: JimD and Nadim to start a wikipage to start collecting the use-cases for secondary features 20:14:21 Isn't it kind of a problem to have the session cache hanging around on the server? 20:14:25 JimD: Please email me so we can get started: nadim@nadim.cc 20:14:29 Topic: Test Suite 20:14:40 virginie: We will want to address test suite 20:14:53 Interested in possibly helping Nadim on secondary use cases 20:14:56 ekr: Browser behaviours actively thwart effectively managing it at the server. I can provide more details on the list of previous discussions where this has arrived (eg: the W3C CG for WebID catalogued these pretty well) 20:15:03 topic: feedback from public call 20:15:31 I'm not disagreeing with that, but it seems like a security problem to have it exist on the server 20:15:32 the definition of use-cases of primary features 20:15:47 q- 20:15:53 topic: Group life 20:16:03 ekr: The expressed desire for log out has less to be about security issues, and more about the general usability of SSL client certs within browsers 20:16:12 rsleevi: ah 20:16:22 lets have a face-to-face meeting during the summer 20:16:27 can't have something earlier than 8 weeks 20:16:29 That's a great idea 20:16:36 - +1.510.387.aaii 20:16:37 end of july would be earliest 20:16:49 we could do near the IETF meeting in Vancounver 20:16:59 what is the proposed time? 20:17:05 @hhalpin I want to join job of secondary feature use-cases 20:17:06 IETF is already *really* long 20:17:18 hhalpin: +1 to IETF colo 20:17:41 IETF is July 20-Aug 3 in Vancouver 20:17:44 Vancouver would be cool 20:17:52 wseltzer: July 29, you mean, right? 20:17:53 s/20/29/ 20:18:12 https://www.ietf.org/meeting/upcoming.html 20:18:26 q+ 20:18:35 wtc has joined #crypto 20:18:37 That overlaps with Black Hat July 23-26 20:18:40 ekr: its a problem to schedule stuff right before IETF 20:18:45