00:00:07 TLR asks if we wanted to discuss registry at some point 00:00:38 VG: There have been a lot of discussions, however there have been no agreed plans 00:00:46 HH: People have disagreed on the motivation 00:00:55 ...I think we should discuss this for 30 minutes tomorrow 00:01:05 ..this is more pressing than some of the further out use cases 00:01:18 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html rsleevi 00:01:22 .. take the time from high level API or some other low level subject 00:02:03 Agreed this session will be 2:30-3:30 tomorrow 00:03:46 2:30-3pm tomorrow (correction) 00:05:36 jmackay has joined #crypto 00:06:07 markw has joined #crypto 00:06:40 http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal 00:06:41 Topic: Wrap/Unwrap 00:07:05 VG: we're also going to discuss the key discovery API 00:07:12 MW: I've just posted the link 00:07:22 ..apologies for being in HTML etc. 00:07:42 ..wrapping and unwrapping proposal is based on the email discussion 00:07:44 Israelh has joined #Crypto 00:07:50 q? 00:07:51 ..using JSON web encryption - web key object 00:08:01 ..RSA version and AES version 00:08:08 ..wraps a content master key 00:08:18 ..supports arbitrary lenght payload 00:08:53 ..open issues have been discussed on email, we have proposals for now 00:09:05 ..format 00:09:26 ..compact or JSON serialisation or JavaScript object 00:09:41 ..discusses crypto interface 00:09:47 ...two new methods 00:09:52 ..wrap and unwrap key 00:09:59 vgb has joined #crypto 00:10:10 ..algorithm identifier is where you'd put any operation parameters 00:10:20 ..final one is enum JWE methods 00:10:22 method 00:10:35 ..two payload protection mechanisms 00:10:59 q+ 00:11:01 q? 00:11:53 q+ 00:12:03 q+ 00:12:27 ..unwrap key - ArrayBufferView provided 00:12:46 ..algorithm identifier allows you to constrain the key to an algorithm 00:13:03 tantek has joined #crypto 00:13:10 ..key encryption key 00:13:20 ..also attributes the web crypto key could have 00:13:47 ..you may want to constrain the keys to be used for certain things 00:14:10 q+ 00:14:18 ..the dictionaries show what it will look like 00:14:28 q? 00:14:36 q+ 00:14:55 ..VG: Objective here is to discuss the technical merits of this proprosal 00:15:01 ack next 00:15:20 RS: To re-iterate the concerns I have provided in the past.. 00:15:55 ..introduces dependencies on the user agent 00:16:00 ..(wrap / unwrap) 00:16:10 ..other concern is related to security model 00:16:40 ..web crypto different to key discovery 00:16:44 in terms of security 00:16:57 ..web app could fully implement JOSE JavaScript side 00:17:02 ...would lose key protection 00:17:12 ..trust model is flawed 00:18:01 ...the value-add of wrap / unwrap is closely tied to the security model 00:18:04 q+ 00:18:10 .. it may or may not make sense 00:18:22 ..and requires the UA to fully implement JOSE 00:18:28 q+ 00:18:42 q+ 00:18:49 ack 00:18:52 ack next 00:18:52 ack rbarnes 00:18:56 RB: Dependency on JOSE isn't such a terrible thing 00:18:57 ack next 00:19:35 ..if we're going to use JOSE we should just use it and not change a few things 00:19:55 jin has joined #crypto 00:21:03 test 00:21:06 drogersuk has joined #crypto 00:22:00 ..we talked about the high level API being dependent on JOSE 00:22:02 scribenick: drogersuk 00:22:02 q? 00:22:08 ack next 00:22:39 q+ 00:23:33 drogersuk_ has joined #crypto 00:24:09 karen discusses whether there is a security issue with exporting the key 00:25:05 ack next 00:25:06 q? 00:26:01 mountie talks about the importance of protecting the key encryption key 00:26:16 ack next 00:26:34 vgb: I'm not as concerned as Ryan about the security model 00:27:05 ..for now it might be sufficient to say that the unwrapped key gets the same security guarantee as the key encryption key 00:27:26 ..trust model does delegate down to the unwrapped keys 00:27:43 ack next 00:27:45 ..it would extend naturally (e.g. for smart card keys etc) 00:28:25 DD: I would consider the high level API as "frozen in time" for now 00:28:32 ..it would be written in content JS 00:29:04 ..I don't see Google implementing a high level API in the platform 00:29:16 HH: in general we could keep them separate 00:29:34 MW: (addressing responses) 00:29:38 q+ 00:29:43 q- 00:30:07 ..same rules for import / export apply for wrap / unwrap 00:30:36 ..but still need possibility to add information on unwrap 00:31:06 ..no intention to change anything in JWK 00:31:12 (misunderstanding) 00:32:09 MW: explaining why new proposal could not just be built on top of existing web crypto API 00:32:46 ..an attacker could do a polyfill over the top of web crypto 00:33:12 ..build confidence over the course of transactions.. 00:33:32 ..attacker has to get into initial exchange to be successful 00:34:55 q? 00:34:57 q? 00:35:22 ack next 00:35:24 (discussion on key encryption key usage and restrictions) 00:35:36 jmackay has joined #crypto 00:35:38 RS: collected some comments 00:35:42 vgb has joined #crypto 00:35:56 q+ 00:36:19 ...tlo address Richard's comments everything can be implemented once we have low level API 00:36:31 s/tlo/to/ 00:36:43 ..we didn't agree that the high level API would be JOSE 00:36:50 ..some things may not be appropriate 00:37:11 ..don't see it as a foregone conclusion that browsers will implement 00:37:29 ..to address security aspects (Mark) 00:37:42 ..you fundamentally have no guarantee that you're secure 00:37:58 ..key encryption key could be when you're being attacked 00:38:27 ..but you can't assume anything - you could polyfill out right from the start as an attacker 00:38:56 q- 00:38:57 ..the continued question is how do address wrap / unwrap within the base specifcation and dependency on JWE 00:39:21 ..no security guarantees on keys 00:39:36 q? 00:39:46 (JWK dependency not JWE) 00:41:02 q? 00:41:39 ack selfissued 00:41:58 DD: I think that Microsoft, Mozilla and Google can have a shared github for a high level API (to be continued tomorrow...) 00:42:43 VG: explains security model / weaknesses need to be addressed 00:43:01 q? 00:44:01 Jim (to MW): would you want to define a new type for export? 00:44:24 MW: yes (Jim notes it could affect base spec) 00:44:52 ...issues around not being able to export unless wrapped 00:45:03 ...gets a bit messy 00:45:19 .."a minefield of ancient unpleasantness" 00:47:46 scribe notes rathole discussion ongoing about wrap / unwrap 00:48:03 q? 00:50:27 q+ 00:51:00 q+ 00:51:28 RS: talks about the issues around security and privacy aspects and issues around security of keys 00:52:19 ..we see key discovery as separate which is why it is a separate spec 00:52:49 q? 00:53:07 ack rsleevi 00:53:09 ack next 00:53:59 drogersuk has joined #crypto 00:54:15 MW acknowledges that you don't always know what is going on 00:54:33 ..also says that you can have some confidence once boundaries are set 00:54:49 RS: JOSE is still open 00:55:05 q+ 00:55:41 q? 00:55:46 q+ 00:56:12 discussion of breaching the security boundaries and lack of assurnace 00:56:31 q? 00:56:55 q+ 00:57:03 rathole trust discussion... 00:57:54 q? 00:57:54 ack ddahl 00:57:56 q? 00:57:59 ack next 00:58:00 i think our scribe wants to go to dinner :) 00:58:25 michaelh: Is there any way to distinguish whether or not a key was generated in JS vs the browser 00:58:35 markw: No, because an attacker can polyfill 00:58:38 +1 to early dinner 00:59:16 q+ 00:59:17 q? 00:59:18 markw: If you do it in the browser, then an attacker has to intercept the generation of a long-lived session key used to wrap subkeys 00:59:20 ack hhalpin__ 00:59:43 hhalpin__: We need to make progress, but we're more or less where we're at the last telecon 01:00:00 hhalpin__: straw poll: how many people think that wrapping should be a core primitive that should be a part of the low-level spec 01:00:12 rbarnes: I can speak to one briefly we see in JOSE 01:01:02 ... (describes use case of wanting to deliver code that doesn't have access to the keys) 01:02:35 RS: states that this does not give value-add security 01:02:40 ..he is opposed 01:03:45 HH sums up - it is a lot more work for implementors, but the security gain is relatively low 01:05:10 ...needs a clear use case 01:05:12 @hhalpin: Attempts to provide use cases that don't use pre-provisioned keys which NEED wrap/unwrap to get security benefit 01:06:34 +1 to virginie 01:07:39 RS and HH propose to note this as a 'feature at risk' 01:07:52 ..this has a clear implementation by netflix 01:08:07 ..it is in the wiki at the moment so it needs to be in one of the specs 01:08:37 RS: there is still some concern that we need to acknowledge, but yes it could go into the spec 01:08:45 ..we will have an open issue for it 01:09:24 ACTION: rsleevi to add in wrap/unwrap as "feature at risk" to low-level 01:09:24 Created ACTION-90 - Add in wrap/unwrap as "feature at risk" to low-level [on Ryan Sleevi - due 2013-05-01]. 01:09:41 VG closes the meeting for the day 01:10:13 RRSAgent, make minutes 01:10:13 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html wseltzer 01:10:55 trackbot, end meeting 01:10:55 Zakim, list attendees 01:10:55 sorry, trackbot, I don't know what conference this is 01:11:03 RRSAgent, please draft minutes 01:11:03 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html trackbot 01:11:04 RRSAgent, bye 01:11:04 I see 15 open action items saved in http://www.w3.org/2013/04/23-crypto-actions.rdf : 01:11:04 ACTION: sleevi to write informative text recommending CSP [1] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T18-26-43 01:11:04 ACTION: karen to write up use case for the pre-provisioned key discovery use case [2] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T18-51-59 01:11:04 ACTION: mountie to write up a use case for the origin sharing [3] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T18-52-10 01:11:04 ACTION: klu to write up use case for the pre-provisioned key discovery use case [4] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T18-52-19 01:11:04 ACTION: sleevi to describe we're not storing key material itself in IDB [5] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T19-08-46 01:11:04 ACTION: vgb to write sentence about how structured clone relates to different types of key storage and that that key storage may have high-security implications (not in our spec!) [6] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T19-15-06 01:11:04 ACTION: vgb and rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition [7] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T20-31-54 01:11:04 ACTION: vgb, rbarnes, jimsch to discuss key generation/derivation/agreement [8] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T21-06-05 01:11:04 ACTION: rbarnes vgb and jimsch to discuss key generation/derivation/agreement [9] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T21-07-24 01:11:04 ACTION: rbarnes and vgb to propose a means for auto-generating IVs in 3 weeks [10] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T21-28-01 01:11:04 ACTION: richard to make a proposal for an explicit auto generation token for IV [11] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T21-28-05 01:11:04 ACTION: rsleevi to update result to be ArrayBuffer than ArrayBufferView [12] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T23-57-07 01:11:04 ACTION: rsleevi to review syntactic sugar overloads for taking (ArrayBuffer and ArrayBufferView) [13] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T23-57-22 01:11:04 ACTION: rsleevi and israelh to work more on Streams API in joint with Futures API [14] 01:11:04 recorded in http://www.w3.org/2013/04/23-crypto-irc#T23-57-58 01:11:04 ACTION: rsleevi to add in wrap/unwrap as "feature at risk" to low-level [15] 01:11:04 recorded in http://www.w3.org/2013/04/24-crypto-irc#T01-09-24 15:49:58 RRSAgent has joined #crypto 15:49:58 logging to http://www.w3.org/2013/04/24-crypto-irc 15:50:00 RRSAgent, make logs public 15:50:02 Zakim, this will be SEC_WebCryp 15:50:02 I do not see a conference matching that name scheduled within the next hour, trackbot 15:50:03 Meeting: Web Cryptography Working Group Teleconference 15:50:03 Date: 24 April 2013 15:50:10 Topic: Agenda review 15:50:11 Chair: Virginie_Galindo 15:50:19 agenda? 15:50:31 scribenick: rsleevi 15:50:39 scottk has joined #crypto 15:50:42 hhalpin has joined #crypto 15:50:45 sangrae has joined #crypto 15:50:59 Zakim, take up next agendu 15:50:59 I don't understand 'take up next agendu', rsleevi 15:51:00 Zakim, take up next agendum 15:51:01 I see a speaker queue remaining and respectfully decline to close this agendum, rsleevi 15:51:05 q? 15:51:16 ack karen 15:51:18 Zakim, take up next agendum 15:51:19 agendum 3. "key discovery" taken up [from hhalpin] 15:51:33 markw: Key Discovery API focuses specifically on named, pre-provisioned keys 15:51:46 jyates has joined #crypto 15:51:47 kodonog has joined #crypto 15:51:47 ... keys were placed there by somebody else - not the web crypto API / origin 15:51:59 ... origin-specific and were placed there for a specific origin 15:52:29 ... Use case is CE devices / TVs 15:52:40 Web Crypto Key Discovery API editors draft https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html 15:52:52 ... draft is trying to be generic as possible, staying within the scope of named, origin-specific, pre-provisioned keys 15:52:53 karen_ has joined #crypto 15:53:07 ... keeping origin-specific is important as a way to address the many security concerns that might otherwise arise 15:53:08 rbarnes has joined #crypto 15:53:22 ... privacy considerations are largely adapted from web storage 15:53:38 ... couple comments from the list, response is "If it's good enough for web storage, it should be good enough for us" 15:53:55 ... very similar to cookies, except someone else put them there 15:54:23 ... Define a subclass of Key - NamedKey - with two attributes - name and ID 15:54:38 ... name identifies key within the same origin/device 15:54:57 ... id uniquely identifies keys among all key sets. Essentially can be a device ID 15:55:15 ... This is part of the use case. Netflix's use case has business rules that rely on knowing exactly what device is accessing the service 15:55:37 vgb: Do you only care about symmetric keys? 15:55:51 markw: There's no assumption about the type of key here. Should work for both 15:56:15 vgb: So does that mean if I have a key pair, I would have to look up both the public and private key pair separately 15:56:17 markw: yes 15:56:21 q+ 15:56:32 mountie: Is this only applicable to pre-provisioned keys? Is this available to all UAs 15:56:38 q? 15:56:49 markw: It's only applicable to pre-provisioned keys 15:57:01 drogersuk has joined #crypto 15:57:02 rbarnes: Pre-provisioned doesn't necessarily mean device keys 15:57:21 markw: Correct. It might have been provisioned by other means. eg: each time an origin asks for a key, a new key is provisioned for that origin using some key generation 15:57:53 mountie: The possibility of device IDs are being looked at in sysapps 15:58:14 ... when users look at whether this API is useful for them, if there isn't coverage in UAs, then it's not really useful for them 15:59:08 ...(discussions trying to clarify Mountie's point) 16:00:28 q+ 16:00:30 markw has joined #crypto 16:00:44 vgb: I think mountie's question is basically if I have a new application that wishes to use such pre-provisioned keys, how does it go about provisioning keys on existing devices 16:00:54 markw: That's a problem for applications to solve independent of this API 16:00:58 q? 16:01:18 ack next 16:01:18 q+ 16:01:32 q+ 16:01:46 michaelh: Presumably the same name would be used for public / private 16:01:51 markw: that is something that's vague in the spec that we need to make a decision about 16:02:43 tobie has joined #crypto 16:02:45 ACTION: markw to clarify how public/private key pairs are retrieved with respect to naming 16:02:45 Error finding 'markw'. You can review and register nicknames at . 16:02:49 ack next 16:02:57 ACTION: watsonm to clarify how public/private key pairs are retrieved with respect to naming 16:02:57 Error finding 'watsonm'. You can review and register nicknames at . 16:03:16 ACTION: mark to clarify how public/private key pairs are retrieved with respect to naming 16:03:17 Created ACTION-91 - Clarify how public/private key pairs are retrieved with respect to naming [on Mark Watson - due 2013-05-01]. 16:04:20 karen: Why is the name important? If we restrict to the same origin, and we just say "getKeys", and specify some other attributes (like usage or type), why not just do that as a general API 16:04:56 markw: There are not that many attributes on keys, our assumption was you could just get those keys back by name and iterate 16:05:29 karen: So that means you need to have a way to define the uniqueness of names 16:05:48 q? 16:06:32 mountie: origin specific keys can be exposed via DNS attacks 16:06:38 q+ 16:06:57 markw: This is no different than cookies or localStorage, if you're doing over HTTP. HTTPS origins are harder, but surely possible 16:07:11 virginie: Did we finish the previous point? 16:07:26 q- 16:07:30 markw: No, the assumption is there's some unspecified method to pre-provisioned keys, and it's no stretch to say there's some assumption that it's also capable of provisioning names 16:07:42 ... the person who wants to use the keys has to know about the pre-provisioning method 16:07:55 ... in the specific example of TVs, we say put the key in the TV, and give it this name 16:08:21 ... in the example of some generic provisioning method, the provisioner would say we provision keys "A", "B", and "C", and thats what you use 16:08:28 karen: I'm wondering why we can't have a more generic API 16:08:52 ... so you provision your key, a secret key, which you know is specific for use by Netflix (or some other provider) 16:08:54 arun has joined #crypto 16:09:11 ... and when the Netflix UA & application and is running, just says getKeys() and searches by some attribute 16:09:12 q+ 16:09:15 q+ to respond to Karen 16:09:25 q+ 16:09:30 markw: In general, theres no reason we can't add things to the API 16:09:35 q? 16:09:38 ... but I'd be reluctant to add things to the API without a use case 16:09:51 ... if there is a use case, I'd like to see a use case 16:10:00 q? 16:10:08 ... in your example, you have multiple keys that may match the properties, so you still need a way to distinguish them 16:10:18 karen: But isn't that the usage 16:10:29 markw: we have at least those two - but in principle, you could have multiple keys with all the same properties 16:10:39 karen: Ok, so you have a name, so you can say getKeys and say name as a generic attribute 16:10:52 q+ 16:11:22 markw: The question is why don't have have a "getKeys" and then you have to search them all 16:11:46 michaelh: why don't you have a SQL query where you just say get keys with some query 16:11:49 ack next 16:12:03 q- 16:12:14 hhalpin: There's been very little discussion of key discovery on the mailing list 16:12:18 ... even less outside review 16:12:27 ... as a process point, we should just devote a day to key discovery 16:12:48 ... so we have this potential problem where every telecon someone brings up smart cards 16:12:58 ... I would suggest we do an ACTION to just handle a key discovery telecon 16:12:58 ack next 16:13:17 i.e. we may not have time to do a thorough key discovery discussion 16:13:23 jimsch: I'm a little bit worried about potentially the process for key tainting 16:13:30 ... it's not a particular issue for you because you're in hardware 16:13:31 had a close look at the spec hoping it would solve our use case, but it turned out not to be useful for our use case 16:13:37 also we have lots of possible privacy issues, matching to smartcards and other use-cases, etc. 16:13:43 ... but in software, you may want to change the modes at some later point 16:13:45 you could easily go for a whole day on just key discovery :) 16:13:48 ... so we potentially need some way to modify that 16:13:51 q- 16:14:04 ack rs 16:14:04 rsleevi, you wanted to respond to Karen 16:15:49 q+ 16:15:49 q? 16:15:53 ack mountie 16:15:54 rsleevi: Wholly support Mark's specific narrowing of scope to just this 16:16:06 ... think that any other use cases like hhalpin was suggesting should also be accompanied by spec proposals 16:16:25 ... attempts to describe generic query APIs in the web has generally been a big failure and overly complex (CSS media queries, IDB) 16:16:46 mountie: Raises the social issue that UAs may deny applications this API, it's not a technical issue 16:16:58 ack next 16:17:16 vgb: I'm gonna do a sort of +1 to Mark and Ryan here. I would much rather see a simpler API that meets the use case that we have today 16:17:22 ... which is searching a small set of pre-provisioned keys 16:17:22 selfissued has joined #crypto 16:17:31 ... I think it's OK to say we don't solve everyones problem, but we solve some of the peoples problems 16:17:48 ... I'd be very uncomfortable complicating this API at this point 16:18:01 ... One thing might be making name optional, so that you can get all the keys when you don't specify the name 16:18:10 ack karen_ 16:18:25 karen: I think we need to separate the definition of the API versus the implementation of it 16:18:26 @mountie: UAs/devices could support a generic online provisioning system that would provide a key or keys for any origin - this would make this API useful for any site, not just the big players 16:18:38 ... if we agree we have getKeysByName, and then somebody else comes out with a use case 16:18:49 ... then we'll have getKeysByKeyUsage, getKeysByAlgorithm, getKeysByKeyType 16:18:57 ... so for each attribute we end up with a specific attribute 16:18:59 q+ 16:19:04 markw: Why? What for? 16:19:27 karen: You have a use case for name. get key by attribute 16:19:43 markw: A use case isn't that someone wants a key by attribute. A use case is why they want to do so 16:19:59 q+ 16:20:31 karen describes a situation where you want to use a signing key, and the application wants to say get signing key 16:20:52 q? 16:20:58 q+ 16:21:07 q- 16:21:14 virginie: It sounds like you still need to convince the group, and write down a use case 16:21:43 ACTION: karen to write use case description describing the use case 16:21:43 'karen' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., klu, kodonog). 16:21:47 @karen: what if two keys with usage = sign come back ? Which do I use ? How do I know which one is the one to be used for the tax return and which one should be used for the medical document ? 16:21:54 @karen i think these considerations matter if there are hundreds of pre-provisioned keys per origin - not clear when that would be. otherwise get all keys is fine. 16:22:14 note that Key Discovery puts origin restrictions, too, karen_, I'm not sure your use case is origin-constrained. 16:22:42 action-80? 16:22:42 ACTION-80 -- Karen Lu to write up use case for the pre-provisioned key discovery use case -- due 2013-04-30 -- OPEN 16:22:42 http://www.w3.org/2012/webcrypto/track/actions/80 16:22:44 q+ 16:22:54 Zakim, close the queue 16:22:54 ok, rsleevi, the speaker queue is closed 16:22:58 ack next 16:22:59 q- 16:23:21 q? 16:23:30 q- 16:23:33 q- 16:23:37 zakim, open the queue 16:23:37 ok, rsleevi, the speaker queue is open 16:23:55 @karen_, @vgm I expect there to be just a handful of keys per origin 16:24:00 TOPIC: Use case document 16:24:08 @markw: then let's just expose one big dictionary of them 16:24:10 zakim, take up next agendum 16:24:10 agendum 4. "testing" taken up [from hhalpin] 16:24:17 zakim, agendum? 16:24:18 I don't understand your question, rsleevi. 16:24:22 s/@vgm/@vgb/ 16:24:33 i/TOPIC/[Next steps, dedicated call on Key Discovery, action-80 to develop use cases] 16:24:50 @markw i agree 16:24:57 Notes that testing will be 10:30-11:30 with Robin from HTML WG 16:25:17 @rbarnes - this was my motivation for suggesting making the name optional 16:25:37 arun: I think it's a good thing when the WG says "please provide a use case" 16:25:51 @vgb - right. i would be even more extreme, and just skip the method call -- window.crypto.keys[name] 16:26:04 ... That the current use cases document which has key discovery and the api in the same documents was at first a bit awkward 16:26:17 ... because as a browser vendor, pre-provisioned keys can be a bit hard to swallow 16:26:19 Web Crypto WG use cases https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html 16:26:37 ... the current use cases were largely taken up from the use cases wiki, not necessarily the spec 16:26:57 ... including use case from tobie at Facebook, which in retrospect, may not be an appropriate security model 16:27:05 ... another use case is browser ID 16:27:13 q+ 16:27:13 q+ 16:27:24 ... another use case is OTR, if we actually want to take that seriously. Following up with nadim to discuss this 16:27:42 ... other use cases that we extracted from the wiki included encrypted communications 16:28:14 ... this came from a discussion with tantek over IRC, which is the extraction of whatever-you-might-use in your PGP key and then using it in a webmail application 16:28:19 ... since it was given, it was documented 16:28:35 ... It's worth noting that there are actively bad use cases, that we should try to block 16:28:40 jmackay has joined #crypto 16:28:42 selfissued: bad in what sense? 16:29:04 arun: we've seen back and forth discussions on the listserv of things you should or shouldn't do. You CAN do it, but that doesn't necessarily mean you should do it 16:29:12 ... eg: supercookie 16:29:27 ... or implementing TLS atop ws:// instead of using wss:// 16:29:37 Could we consider https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/UseCases#document-signing as a use case for a future version of the spec? 16:29:44 ... I wouldn't want to be a person who fabricates use cases in a glass house and say "Hey, this is a use case" 16:29:51 ... want actual real world use cases 16:29:57 q+ 16:29:59 ... questions about whether a high-level API is actually a use case 16:30:09 ... we should get back to really good crypto use cases 16:30:22 ... some of this is just cleaning up 16:30:49 ... still kept the model of checking code sanity, but removed some of the threat model 16:31:02 ... there's been some back and forth with mountie about the banking use case 16:31:22 ... I think you're considering what actually happens in Korea today, but that doesn't necessarily 1:1 match what we're doing here 16:31:40 ... but I think we may be able to come up with a credible scenario that doesn't exactly match what's done today, but that can address the use case 16:31:53 q- 16:31:54 arun: I intend to add the BrowserID use case 16:31:57 q+ 16:32:02 ... if there are any other additions, like to ask the group to submit them 16:32:12 q? 16:32:28 q+ 16:32:31 karen: I will write a use case. How would you like me to write it 16:32:51 q+ 16:32:53 @vgb: we need the getKeys ... method to be asyncronous, so window.crypto.keys[name] doesn't work 16:32:55 q+ 16:33:00 q? 16:33:14 (arun and karen discuss how to submit use cases) 16:33:26 virginie has joined #crypto 16:33:30 q? 16:33:34 ack next 16:33:34 arun: It's not that I have generated use cases out of the void. They're based on real world 16:33:44 Here is the document as it stands: https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html 16:33:48 rbarnes: arun, you mentioned OTR, I'd like to suggest we instead focus on XMPP 16:34:15 q? 16:34:17 ... I've got some additional use cases for demo apps that I've been playing with polycrypt 16:34:19 arun: I would argue that the simple, tangible use cases are the good ones 16:34:20 ack selfissued 16:34:25 q- 16:34:34 selfissued: Is the ability to build the JOSE implementation one of the existing use cases 16:34:55 polycrypt hello world example: http://demo.polycrypt.net/hello 16:35:04 rsleevi: It's not in the use cases doc, but IS in the main document. Need to align those 16:35:09 polycrypt self-signed certificate generator: http://demo.polycrypt.net/x509 16:35:36 nvdbleek: Yesterday we were discussing use cases for future versions. Is that something we want to document, or just focus on what we have today 16:35:41 (and it wouldn't be hard to build a CA from the self-signed cert generator) 16:36:09 arun: I would prefer we focus on use cases that are enabled by the API or that can be accomplished by smaller changes. Can you provide an example? 16:36:10 jimsch has joined #crypto 16:36:14 q? 16:36:17 nvdbleek: Example of using smart card signatures 16:36:48 do we need to determine if use-cases that are *only* partially addressed should be included? I'm still not sure what the edges are. 16:36:55 virginie: Process clarification - since you're going to be getting use cases that may be about new features, what do we do with them 16:37:05 ... can we park use cases in the wiki, and then keep the use cases document aligned 16:37:19 q? 16:37:32 ack nvd 16:37:52 arun: Sounds like a good idea 16:38:07 mountie: will you prepare use cases with other WGs in combination 16:38:10 arun: Can you give an example 16:38:26 mountie: Working with WebAppSec for using/enhancing CSP 16:38:48 arun: Is your question will I combine webcrypto API with best security practice on the web? 16:38:53 mountie: Not just focusing on security 16:39:05 ... for example, your previous use case is trying to protect JS source 16:39:21 q? 16:39:32 arun: (refers to email) I think I've updated the spec to reflect your mail 16:39:53 arun: it seems like useful practice to provide sample code to go with the use cases. It's something I just did to show how you might use the API 16:40:00 ... it should also of course not show bad things 16:40:11 ... in the context of the use case of the code Tobie gave me, it did use eval() 16:40:16 ... which isn't all that good 16:40:31 hhalpin: Clarifying point: There are use cases that are only partially addressed by webcrypto 16:40:44 https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html#banking 16:40:47 ... what's the status on those? eg: the banking use case 16:40:50 ... do those stay? 16:41:05 arun: But the banking use case makes no pretense of addressing the specific Korean use case 16:41:24 hhalpin raises points of secure remote password and eid, bits that may not be addressed entirely 16:42:03 hhalpin: Possibility of including primitives *not* included by webcrypto, but meant to be addressed elsewhere 16:42:03 arun: I think that'd be a distraction to include that stuff 16:42:29 arun: Do you think it'd be helpful to include a note at the end of the use cases to the wiki 16:42:34 israelh has joined #crypto 16:42:47 q+ 16:42:50 hhalpin: We keep getting use cases to the list that we go back and forth where we're not trying to cover all use cases 16:42:58 ack mountie 16:43:01 arun: I guess the question is how do we make clear what we're not doing as a WG 16:43:10 q+ 16:43:17 ack hhalpin 16:43:34 virginie: action for arun to clarify what is and isn't covered in the spec? 16:43:47 arun: Well, we already do that. 16:44:02 q+ 16:44:53 call out in a "red" font or "blue" font about primitives in use-cases that we can't cover, and then note for those use-cases we can't provide full JS examples obviously 16:44:55 ack karen_ 16:44:56 karen: to echo what harry was saying, we need to clarify 16:45:10 ... for example, the banking use case. In Europe, you have a banking card which is a smart card 16:45:26 knowing what primitives we don't cover could be useful for future W3C and IETF WGs 16:45:26 ... the keys aren't generated the first time you sign in, the keys are on the smart card 16:45:32 ... a lot of the banking use case is pre-provisioned key 16:45:39 and also explicitly redirect people away from keeping requesting these 16:46:03 ... perhaps you can state we don't have a pre-provisioned key support within the spec 16:46:13 use case for eID http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0177.html 16:46:16 q+ 16:46:25 arun asks for clarification on pre-provisioned keys. smart cards are pre-provisioned, but not necessarily origin-constrained 16:47:02 karen: If you want to use your banking ID to address the banking use case, you can't 16:47:04 q- 16:47:08 ack next 16:47:29 israelh: One question I had from the use cases providing real code - is it real code we're trying to provide, or the pseudo-code? 16:47:46 ... some of the comments you have are as useful or more useful than the code itself 16:47:54 arun: I agree. It would be nice to find a better way to proceed 16:48:05 israelh: I don't think you want to update the document every time the API changes 16:48:07 q? 16:48:08 arun: I agree 16:48:11 ack next 16:48:12 q+ 16:49:21 q+ 16:51:06 rsleevi: I have to disagree with hhalpin about decomposing into primitives such as those we won't address 16:51:20 ... seems like committing to a set of design choices that may not be appropriate or fully understood at the time we're documenting 16:51:30 q+ 16:51:33 ... would prefer to see the use cases doc cover the cases we do, and leave to the wiki the partial cases 16:51:46 Looking at charter, I'm trying to figure out the process for clarification on "secondary" features: http://www.w3.org/2011/11/webcryptography-charter.html 16:51:56 Just say it cannot be met by the current API; but not why 16:52:08 arun: I'm not sure the best way to match the way to say No to the use cases we won't be addressing 16:52:11 ack nvdbleek 16:52:39 nvdbleek: I think the test cases should reflect the use cases - that means a more concrete set of use cases 16:52:39 ack hhalpin 16:52:56 hhalpin: to be clear, the reason why I said we want to document the stuff we're not doing 16:53:02 control of TLS session login/logout, derivation of keys from TLS sessions, a simplified data protection function, multiple key containers, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption. 16:53:05 ... for example, the secondary features from our charter 16:53:15 ... one way to be clear about that is to say in the use cases document that we're not covering it 16:53:30 ... for example, use cases that rely on those secondary features aren't addressed 16:53:38 ... one way is to not include them in the use cases doc, and leave em in the wiki 16:53:50 ... another way is to include them in the doc, but then say why we're not including them 16:54:04 q? 16:54:24 SooHyung has joined #crypto 16:54:35 hhalpin: Want to avoid polluting the main spec of saying all the things we're not doing 16:54:36 ACTION: arun to add JOSE use case 16:54:36 Created ACTION-92 - Add JOSE use case [on Arun Ranganathan - due 2013-05-01]. 16:54:50 ack israelh 16:55:19 Route 1): All use-cases that aren't completely covered we don't let in use-case document, we cover in wiki. Then we add some text in use case document that clarifies what secondary features we aren't covering as a WG 16:55:28 ACTION: arun to add caveats showing that web crypto WG is only addressing a subset of some use cases 16:55:28 Created ACTION-93 - Add caveats showing that web crypto WG is only addressing a subset of some use cases [on Arun Ranganathan - due 2013-05-01]. 16:55:45 israelh: a possible solution would be to add a note to a use case (eg: banking use case) is to state that we're not trying to cover the entire use case (such as the Korean banking use case), only a subset 16:55:49 q? 16:56:00 Route 2): Use-cases are allowed in use-case document that have bits we don't cover, but we explicitly mark those bits in some fashion and map those to things that are out of scope or in non-covered secondary features 16:56:07 Either is fine I think! 16:56:42 sangrae has joined #crypto 16:57:04 arun: I've treated wrap/unwrap with great optimism that we will accomplish within the API 16:57:27 ACTION: arun to add BrowserID use case to use cases document 16:57:27 Created ACTION-94 - Add BrowserID use case to use cases document [on Arun Ranganathan - due 2013-05-01]. 16:57:42 q? 16:57:50 20 minute break 16:57:57 next up: testing framework 17:00:21 tobie has joined #crypto 17:24:07 virginie has joined #crypto 17:36:06 I'm giving myself another action, namely to document a robust crosss-origin use case. 17:36:25 Topic: Testing infrastructure 17:36:32 rberjon presenting 17:36:40 ACTION: arun to document a cross-origin use case for webcrypto 17:36:41 Created ACTION-95 - Document a cross-origin use case for webcrypto [on Arun Ranganathan - due 2013-05-01]. 17:36:53 SooHyung has joined #crypto 17:37:05 rberjon: Testing is important 17:37:08 ... especially for interop 17:37:24 jin has joined #crypto 17:37:24 ... a growing collection of tests on the github repository 17:37:40 ... repository is meant to be the centralized testing repository for all the web platform technologies going in to browsers 17:38:17 ... once CSS is incorporated, close to 0.5GB of tests 17:38:22 ... all tests use the same test harness 17:39:00 ... If you want to ship your specs, write tests. 17:39:14 ... Fairly easy to add tests. Fork the repository. Add new tests. Submit a pull request. 17:39:30 ... Standard github workflow. If you're familiar with github, easy. If you're not, there are thousands of tutorials to help you, and we can too 17:39:52 ... tests published to github are made available via the W3C test page 17:40:08 q+ 17:40:23 ... adding infrastructure to run specific tests, all tests, etc. Similar to caniuse, browser support, etc 17:40:33 ... in order to add tests, simple review process 17:40:54 ... when a pull request is submitted, we want it reviewed by someone who isn't the person who submitted the test 17:41:03 ... doesn't matter same company, same team, as long as they're different people. 17:41:31 virginie: What are the best practices for the WG in writing tests. Should we have one test leader, everyone else contributes? 17:41:42 rberjon: Depends on how your WG wants to work 17:42:04 israelh: How does this compare to other testing efforts? MSFT has submitted a lot of tests in the past through different means. Does that mean we go through github now? 17:42:08 rberjon: Yes. 17:42:42 rberjon provides context and limitations of the old way of handling tests in the W3C 17:43:08 ... ex: when looking for duplicated tests (between submitted & approved), found ~2000 duplicated files from people forgetting to move stuff from submitted -> approved 17:43:23 q? 17:43:23 ... in this system, the repo contains all/only approved tests. pull requests handle the submitted 17:43:27 ack israelh 17:43:46 ... In other WGs, we've handled it where we're all test writers and test reviewers 17:45:25 ddahl: How does the test handle inter-origin pieces? 17:45:49 rberjon: w3c-tests.org has multiple open ports and domains, if you need to deal with inter-origin bits 17:46:26 ... but does webcrypto need multiple origins? 17:46:45 israelh: Interesting to think about tests. Would we have a test encrypt then decrypt something, and make sure it gets the same output? 17:47:09 ... or would we need to have inter-origin where someone sends you a key and then tells you what to expect? 17:47:32 rberjon: It depends on what your spec says normatively 17:47:52 ... there's a difference in publishing a really really good test suite that you need to test interoperability 17:48:02 ... and a test suite that you need to exit CR, which may be of a lower quality 17:48:23 ... if you're confident that you can ship something that is (roughly) interoperable, then ship it, and continue to working on tests 17:48:35 arun: Is there any test suite that you think is particularly exemplary that you think we should emulate? 17:48:39 rberjon: interesting question 17:48:42 arun: Or at least more mature 17:49:25 (rberjon and arun discussing IndexedDB - turns out a bad pull/merge) 17:50:12 rberjon: Each HTML file is not necessarily a single test 17:50:21 vgb has joined #crypto 17:50:27 ... you may wish to group a series of logically related tests together into a single file 17:50:50 ... you may wish to also split up tests (eg: for mobile, running 20,000 tests might run out the battery) 17:51:03 virginie: Question - how much support can we expect from you? Do you have a special line (laughter) 17:51:40 rberjon: If it's at a decent time... there's also a mailing lists called public-tests-infra@ - that's the right place to go for support in general 17:52:08 ... that's the right place to ask questions. It'll probably be me answering, maybe tobie or ms2ger 17:52:44 hhalpin: Anyone else have github IDs that wish to be added to the repo? 17:52:58 https://github.com/nvdbleek 17:53:09 virginie: How much time does it take to develop tests? 17:53:11 I'll add folks *now* if you put your Github nick i IRC 17:53:22 rberjon: It depends. For some simple specifications, we were done in a day or two 17:53:39 ... beyond that, it depends on two things - the quality of the spec writing. A well written spec is easily tested 17:53:47 ... it also depends on how things interact together 17:54:12 ... eg: if you have user interaction or some other hardware/device 17:54:22 ... If you want to write tests fast, you need to be in a sort of translation mode 17:54:33 ... A user agent MUST do this... then translate that into a test to test that 17:54:56 nvdbleek: Isn't there a document that is meant to help specification writers write good specs for testing 17:55:05 also, using test harness: http://darobin.github.io/test-harness-tutorial/docs/using-testharness.html 17:55:11 http://www.w3.org/TR/test-methodology/ 17:55:27 rbjeron: Yes, there's a test methodology doc that explains how to write good testable assertions and how to encode testing pieces within your specification 17:55:47 ... very important for specification writers to read the advice in that specification, because it's very precise in how it describes writing a conformance assertion 17:55:58 jyates has joined #crypto 17:56:10 ... when specs are written that way, you can sort of translate them mentally into tests very easily 17:56:17 q? 17:56:43 kodonog has joined #crypto 17:56:44 israelh: Is it fair to say you're reliant on submissions of tests - you're not going to write the tests yourselves, right? 17:57:16 rberjon: Yes, based on funding and priorities 17:58:06 ... you don't necessarily have to be amember of the W3C to make test submissions. You do have to agree to the license 17:59:27 For movement to CR, we will write something like this: 17:59:31 based on the test-suite 17:59:39 israelh: Still not seeing movement for some of the older submissions from MSFT 17:59:51 rberjon: Yes, we're still catching up. New submissions are making it through quicker 17:59:58 http://www.w3.org/2001/XKMS/Drafts/test-suite/CR-XKMS-Summary.html 18:01:16 http://www.w3.org/MarkUp/Forms/2008/XForms11ImplReports/results.htm ;) 18:01:19 Aha, much nicer interop report: 18:01:20 http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/ 18:01:41 israelh: Just because the tests aren't needed until exiting CR, doesn't mean you shouldn't write tests early 18:01:57 q? 18:02:52 rberjon: Also notes about Test the Web Forward events to get involved with the community to help write tests 18:03:45 tantek has joined #crypto 18:03:59 URL is http://testthewebforward.org/ 18:05:25 q+ 18:05:28 q+ 18:06:54 karen_ has joined #crypto 18:07:24 virginie has joined #crypto 18:07:30 q? 18:07:45 jmackay_ has joined #crypto 18:08:00 hhalpin_ has joined #crypto 18:08:23 RRSAgent, draft minutes 18:08:23 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html hhalpin_ 18:08:26 vgb has joined #crypto 18:08:51 RRSAgent, draft minutes 18:08:51 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html hhalpin_ 18:08:55 jin has joined #crypto 18:08:56 q+ 18:09:01 q- 18:09:13 sangrae has joined #crypto 18:09:16 rsleevi: Would postpone writing tests until the next public working draft 18:09:22 jyates_ has joined #crypto 18:09:38 ... the API should stablize there 18:09:48 ... lots of algorithm specifications needed in order to be able to use algorithm KATs 18:10:00 ... wrap/unwrap also brings in a dependency on JOSE test suites 18:10:01 SooHyung has joined #crypto 18:10:05 markw: Just on JWE wrapped JWKs 18:10:13 rsleevi: But that's still a large set of tests, MTI algorithms, etc 18:10:22 big set of test vectors: http://demo.polycrypt.net/ 18:10:22 markw: But you'd have that regardless of the wrapping format 18:10:31 ddahl: +1 to waiting until we have a Futures API 18:10:32 q? 18:10:42 ack ddahl 18:11:18 israelh: while we can't say anything, naturally, when we look at implementation details and implementing specs, we like to have a test suite to go with it to show our conformance 18:11:44 ddahl: question for rbarnes, do you see polycrypt evolving with the spec changes 18:11:54 rbarnes: Yes. We try to match the API 18:12:27 Zakim, drop agendum 4 18:12:27 agendum 4, testing, dropped 18:13:10 Topic: Brief discussion of Futures from following up the points raised yesterday 18:13:34 israelh: Discussed with rsleevi briefly, worked on a proposal last night for a way to decouple the DOM dependency for server-side approaches 18:14:16 ... so that we can discuss futures for their own merits, independent of the server side concerns 18:14:22 Topic: Futures 18:14:34 (israelh prepping slides to present) 18:15:08 gist of IDL modifications is to make CryptoOperation no longer derive from EventTarget 18:15:22 israelh: ... in the context of a server environment 18:15:39 ... also replace the event functions with VoidFunction?, so there isn't a need to dispatch events 18:16:05 ... ex: "attribute VoidFunction? onabort" 18:16:22 ... thinking is that this sort of IDL can go into a non-normative section for the server environment 18:16:49 ... from a programatic perspective, your code is more or less the same 18:17:03 ... ex: operation.encrypt(...).oncomplete = function() { var myResult = this.result; } 18:17:08 drogersuk has joined #crypto 18:17:43 ... this sort of behaviour independent of new capabilities/new language approaches, gives you a way of expressing/dealing with constraints for the server environment 18:18:10 ... gets you the same value (re-usage of code patterns) without having to bring in elements like capturing, bubbling, etc 18:18:42 arun: This seems to simplify things for your implementation (in the server), it doesn't really change the shape of the API 18:19:08 israelh: Right. That's the goal - we can just fit this in without going too radical 18:19:13 arun: Futures is pretty radical 18:19:29 israelh: One of our concerns is on the dependency on futures and the stability of it 18:19:37 ... at least this is a programming model understood by developers 18:19:48 ... it's unclear about what the powers may be may have 18:20:20 ... at least wanted to separate out the server dependency from the discussion 18:21:06 rbarnes: Does this require changing anything in the base specification? Would this code actually work against the base spec? Don't you have to say event.target.result 18:21:36 israelh: No, you can still write this code 18:21:45 virginie: What's the action here? 18:22:01 israelh: I think we need to know the path forward - if we're going to go Futures, when do we say go / no go 18:22:01 q? 18:22:21 arun has joined #crypto 18:22:22 vgb: I think the point is if we're not going to go futures, this piece of non-normative text would be sufficient to address the use case 18:22:44 arun: I actually think Futures are eating APIs and consuming them one by one 18:23:01 ... i expect it won't be long before people approach me for File API and suggest we divorce it from eventtarget 18:23:21 ... i think futures is taking over the web APIs. If we're going to divorce ourselves from EventTarget, futures are probably going to be it 18:23:43 ... I don't think futures is too much heavy lifting. We should reconcile ourselves with it 18:23:54 israelh: If I look at TPAC 2 years ago, promises was the thing 18:24:01 arun: So you're afraid it's a fad? 18:24:21 israelh: Yes. That's our fear. We embraced promises in our Win8 Web APIs, and now we're here talking about Futures 18:24:41 ... we've seen the conversation change over time, but we still have EventTarget and DOMEvents 18:25:04 ... as we look at an implementation side, and getting stuff out in our release cycles, the less churn we have, the easier it is to get these things and push them through 18:25:41 virginie: Once Ryan come back with a Futures API, what's going to be the discussion within the WG to go forward with it? 18:27:14 rsleevi: I would suggest the decision will be coming from script-coord and TAG 18:27:27 ... which is where I'm getting push for this 18:27:31 mountie has joined #crypto 18:27:36 arun: To be fair, your TAG rep is the progenitor of Futures 18:27:45 rsleevi: True, but we are seeing the push for this from others. 18:28:15 virginie: So when we discuss futures. we'll need to get the input from everyone 18:28:19 Topic: Certificate Management 18:28:47 israelh has joined #crypto 18:29:03 jin has joined #crypto 18:29:24 mountie: The proposal looks at performing certificate management operations - issuing, updating, revoking, and validating certificates 18:29:33 Freshly spueezed spec on Certifiate management http://mountielee.github.io/webcertapi/webcertapi_draft.html 18:29:56 ... certificate management API based on RFC 4210 18:30:14 (mountie discussing use case from draft) 18:30:26 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html rsleevi 18:32:45 q+ 18:33:39 sangrae: in charge of project to replace ActiveX control 18:34:20 (sangrae demonstrates how Korean banking works today) 18:34:59 sangrae: demo of integrating a CMP library into Firefox 18:35:27 israelh_ has joined #Crypto 18:36:12 arun: Is that using 18:36:19 sangrae: No, this is using our CMP library 18:37:00 jyates has joined #crypto 18:38:42 sangrae: requestCert API generates a CMP CertMessage request 18:38:50 ... which you send to the CA server, which then processes it 18:39:18 ... and sends back a CertMessage, which the UA calls handleResponse 18:39:34 ... handleResponse returns a certResult message 18:39:52 ... finally, UA then calls genConfirm to send a final confirmation to CA server that the operation is complete 18:40:10 vgb has joined #crypto 18:41:05 michaelh: shouldn't your second arrow be a CertResult? 18:41:22 sangrae: No, its a CertMessage 18:41:47 sangrae: We have a RequestType to support alternative request messages - cmp, cms, pkcs10 18:42:03 sangre: requestCert, updateCert, handleResp, genConfirm 18:42:11 s/sangre/sangrae/ 18:42:41 ... genConfirm is only used for CMP - if you're using PKCS#10, it's not necessary 18:42:57 vgb: Am I understanding correctly that requestCert is really generateCertRequest? 18:43:15 mountie: Yes, it generates the cert itself 18:43:34 vgb: And revoke is the same way, right? it's really generateRevocationRequest? 18:43:39 sangrae: Yes 18:44:08 karen: What about validation? Normally if you're doing revocation, it's because you're validating 18:44:17 jimsch: This is self-report - reporting your certificate should be revoked 18:44:57 mountie: discussing validation API 18:45:13 ... security considerations: would like to disable the same origin policy for some aspects 18:45:28 ... private keys, certificates, CAs 18:45:42 ... want exceptions without user consent or UI 18:46:46 ... certificate key storage should be interoperable with existing TLS key storage (not sure what it's called) 18:47:15 (mountie reads section 5.2 of draft) 18:47:43 ... if you're using TLS key storage, you can potentially use PKCS#11 18:47:50 q? 18:48:02 vgb: The same origin exception sounds to me like you're saying let's just not do same origin 18:48:16 ... the three bullet points I see applies to basically any certificate issued by any public CA 18:48:34 ... this isn't a narrowly scoped exception, it seems like if you have any key for a certificate, lets just not do same origin 18:48:43 ... which is a ... departure... from our existing security model 18:49:01 sangrae: If you have a certificate that's "trusted" from some CA, then you can use that key with any webpage 18:49:15 vgb: Without getting into a definition of what "trusted" means, you're really talking about all of them 18:49:30 mountie: let me get into the use cases 18:49:40 vgb: No no, I agree that you can do good things with this API 18:49:46 ... but you can also do a lot of bad things with the API 18:49:56 ... and our goal when designing a security API, you should not be able to do bad things 18:50:05 rbarnes: What are the bad things you can see? 18:50:16 vgb: If you take away same origin, a lot of bad things 18:51:01 ... you're basically saying any origin has access to keys 18:51:07 mountie: But isn't that true for TLS key storage? 18:51:28 rsleevi: No. In those cases you have a trusted application (user agent) doing very specific things and performing a very specific operation 18:51:33 q+ 18:51:34 ... your proposal gives full access to the key 18:51:48 jimsch: There is no reason that I know of that the protocol can't provide a list of origins as part of the protocol 18:51:54 ... ex: you could send back a list of origins as part of CMP 18:52:29 q? 18:52:32 q+ 18:53:14 mountie: TLS login and logout as a way of dealing with certificate auth 18:54:19 vgb: I think when the charter talks about TLS session disconnect, we're talking about a clearing TLS state 18:54:40 q? 18:54:52 mountie: But what about TLS login 18:55:01 vgb: ... I think this was a different discussion 18:55:09 ... I think we need to be careful with certificates and around the trust model 18:55:20 ... For example, if you take the three bullet points [scribe note: From section 5.1] 18:55:42 ... When I get a TLS private key, all I get is a statement that the holder of this private key has these statements 18:55:50 ... I don't get the ability to use it silently 18:55:59 q+ 18:56:04 mountie: let me answer that - I didn't say silently 18:56:19 ... to access private key, we need some sort of UI 18:56:24 ... that is dependent on the user agent 18:56:30 vgb has joined #crypto 18:56:34 q? 18:56:46 ... have the UI let the user choose what certificate they want to use and then enter some pin 18:56:52 q? 18:56:57 ack rsleevi 18:57:00 q+ 18:58:13 rsleevi: i'm struggling to separate the API proposal from the underlying requrement 18:58:39 ... implementing CMP in a browser is a lot to bite off. 18:58:40 karen_ has joined #crypto 18:58:52 mountie has joined #crypto 18:58:55 jyates has joined #crypto 18:59:07 q+ to ask about certs via JavaScript 18:59:31 ... also reiterate security concerns - this api would permit supercookies, do bad things with TLSnkeys, etc. 19:00:05 q? 19:00:09 ... Speaking for Chrome and Mozilla, CRLs and OCSP are not supported to the extent you need here. 19:00:44 ... Need to distill this down to a small kernel of browser capabilities, and polyfill the rest 19:01:00 mountie: I think we need to open the certificate pandora's box. Many people are waiting for something with certificates 19:01:11 ... generating PKCS#7 formatted messages, ASN.1 encoding/decoding, certificate validating/issuing 19:01:20 jmackay has joined #crypto 19:01:23 ... our requirements up to CMP, and then PKCS#7 formatted signatures 19:01:28 ... and how we verify certificates 19:01:36 ... it would be beneficial for many users who have experience with certificates 19:01:58 sangrae: in Korea we currently use ActiveX controls, but there are many security problems with this 19:02:01 virginie has joined #crypto 19:02:09 ... certificates and private keys are normally stored in the OS store that we can use 19:02:17 q? 19:02:42 ... but if we had certificate management functions, we could resolve many of those security problems 19:03:43 mountie: if we had web standards, we could resolve those security concerns for those users 19:03:46 Zakim, close the queue 19:03:46 ok, rsleevi, the speaker queue is closed 19:03:56 ack MichaelH 19:03:57 MichaelH: First of all, I like it, trying to support certificates 19:04:08 ... to mitigate the security concerns, can we have some sort of registration 19:04:20 ... where the provider registers an origin, exports the key, then brings it in 19:04:27 ... so we still have same origin protection 19:04:38 ... on the security issues, you're not really mitigating the issues 19:04:43 ... you're just moving them from the plugin into the browser 19:04:55 ... but they're still ultimately there 19:05:11 ack next 19:05:33 karen: your use case is similar to the use cases I've been talking about 19:05:38 ... such as the eid use case 19:06:13 (discussing government issued ID) 19:06:43 ... with the proposal itself, I think if we want to have this kind of management 19:06:50 ... we'll have to address the sort of access control 19:07:04 ... for example, when you issue a certificate, it might not be the users decision, it might also be the issuer's decision 19:07:24 drogersuk has joined #crypto 19:07:24 ... for example, mobile device using something like ISIS 19:08:06 hhalpin has joined #crypto 19:08:20 ... ISIS is an example of who has control over the keys. the UCIC has controls over who has access to the keys 19:09:04 sangrae: In the Korea case, every private key is protected by password 19:09:12 q? 19:09:57 ack next 19:10:18 ddahl: A little bit of background on this would be helpful 19:10:31 ... has the Korean government actually looked at the same origin policy 19:10:36 ... and decided this wasn't acceptable? 19:10:49 ack rbarnes 19:10:54 ... it seems like you're driving in the wrong direction for years with this 19:11:11 rbarnes: In agreement with rsleevi here - what are the things you cannot do in the browser 19:11:25 ... certificate management protocols are almost certainly not in that domain 19:11:33 q? 19:11:39 ... it seems to me that the critical thing is being able to control what certificate and private key can be associated with a TLS connection 19:12:03 ... dealing with that might be much better than trying to figure out how to address all of the legacy stuff 19:12:28 arun: The more I think about this, it seems useful to have a hallway conversation with rsleevi on how to address this with cross-origin communication 19:12:33 ... two flies in the ointment 19:12:39 ... how to deal with key storage 19:12:48 ... and in a way that's disconnected from TLS 19:12:50 notes that if its just associating keys with TLS sessions is similar to Steve Farrell's key derivation from TLS session ideas way back at origin of WG 19:13:09 @hhalpin: No. Entirely different thing. 19:13:11 q+ 19:13:34 nvdbleek: It seems that the issue is the need to access keys outside of the scope of the origin (eg: on smart cards or other devices) 19:13:46 q? 19:13:50 ack arun 19:13:50 arun, you wanted to ask about certs via JavaScript 19:13:50 ack arun 19:14:34 michaelh: it seems like what's missing is the "client side user" case - the current keys only deal with "web app" keys 19:15:26 Break for lunch. Following lunch, high level API discussion 19:15:32 and key agreement 19:15:37 registry of algorithms 19:15:41 bignum 19:15:42 and wrapup 20:05:57 zakim, this is crypto 20:05:57 sorry, wseltzer, I do not see a conference named 'crypto' in progress or scheduled at this time 20:06:31 israelh has joined #Crypto 20:06:32 vgb has joined #crypto 20:06:35 ScribeNick: arun 20:06:48 Topic: High Level API 20:06:56 SooHyung has joined #crypto 20:07:17 q+ 20:07:28 Virginie: the Web Crypto API generated some comments such as "this is too technical, difficult to use, etc." 20:07:42 Virginie: High Level API seemed to generate some interest. 20:07:56 sangrae has joined #crypto 20:08:15 jin has joined #crypto 20:08:21 Virginie: some developers expressed a mitigation of their criticism if there's a High Level API 20:08:39 Virginie shows some slides and examples of Twitter commentary about the existing WebCrypto API 20:09:09 Virginie shows slide illustrating notions discussed on the WG regarding High Level API. 20:09:19 karen_ has joined #crypto 20:09:25 drogersuk has joined #crypto 20:09:26 Virginie: should we put this on the REC track? 20:09:28 q+ 20:09:31 q? 20:09:33 q+ 20:09:44 HHalpin: my take on it is that it is a myth that a High Level API will be easy to use. 20:09:50 mountie has joined #crypto 20:09:59 HHalpin: given that, it does make sense that higher level shims will be developed. 20:10:13 HHalpin: shims happen. Should the market develop it, or us? 20:10:28 HHalpin: if we do push out a High Level API, it might be rushed. 20:10:43 HHalpin: market might develop a better High Level API 20:11:08 jmackay has joined #crypto 20:11:24 HHalpin: we might present something like a shim. If there was some sort of a useful API that's high level, should it be normative or informative? 20:11:35 HHalpin: right now we can't do either. We don't have enough person power. 20:11:44 selfissued has joined #crypto 20:11:48 q+ 20:12:05 q+ 20:12:25 jyates_ has joined #crypto 20:12:52 HHalpin cites Keyzsar and NaCl 20:13:18 HHalpin: Keyzsar looks fairly sane; NaCl aims for Box/Unbox simplicity 20:13:34 q+ 20:13:39 HHalpin: NaCl's focus is clearly public-key authenticated encryption 20:13:43 MichaelH has joined #CRYPTO 20:14:02 HHalpin shows a slide illustrating code snippet 20:14:14 jimsch has joined #crypto 20:14:35 keyczar has defualts! 20:14:40 HHalpin: KeyCzar has a JSON/JOSE-ish format that they use. 20:14:48 HHalpin: they hide the raw key format. 20:15:07 HHalpin: on some level, since there's more key management built in, KeyCzar may be more complex than WebCrypto API. 20:15:16 HHalpin: and then there's ddahl's draft... 20:15:24 .... which is more simple than NaCl and KeyCzar 20:15:30 q? 20:15:35 ... not a lot of scrutiny on it, which may mean it's perfect. 20:15:44 ... then there's rbarnes' work. 20:16:01 hhalpin has joined #crypto 20:16:07 q+ 20:16:22 israelh has joined #crypto 20:16:44 q+ 20:16:51 Virginie: there are several directions -- an informative document, limited High Level API, or solicit web dev needs. 20:16:59 ... I would like to hear the prefered options. 20:17:02 q? 20:17:19 Virginie: I would like comments on how to treat this topic in the WG. 20:17:28 ... I'm not looking for one API being better than the other. 20:17:48 ... e.g. comparing KeyCzar vs. NaCl 20:18:00 q? 20:18:05 ack drogersuk 20:18:23 virginie has joined #crypto 20:18:25 DR: I mentioned at TPAC that developers didn't know what they were doing, e.g. breaking SSL libraries, etc. 20:18:33 q? 20:18:50 ... your average developer knows about some of the properties of what they want to secure, but .... [not much]. 20:19:03 ... if there's a high level abstraction, that might be a good thing. 20:19:23 ... I kind of agree with Harry. This is predicated on having the low level API in the first place. 20:19:50 ... The question about use cases, I'm not sure whether we can specifically define use cases. All we're trying to do is enable developers to create whatever use case they want. 20:20:00 ... e.g. I want to send something to someone confidentially. 20:20:18 .... Box/Unbox is nice. However, you can get into trouble. Suddenly you end up with a complex high level API. O 20:20:31 ... Or you're making recommendations. Because we consider them to be secure. 20:20:59 ack next 20:20:59 ... I think we already have collected developer needs. Whether W3C is the right place has a question mark on it. 20:21:16 DDahl: I echo drogersuk 20:21:24 nvdbleek has joined #crypto 20:21:33 ... my naive use case was 'zero knowledge' on servers, etc. 20:22:04 ... I've learned a lot. The implementation of a high level API, howsoever imperfect, is still going to require 60-80% of the engineering effort, comparable to the low level API. 20:22:29 ... What do other browser vendors thing? I'm not sure what MSFT thinks. I'd like to learn more. Are you willing to put forth a statement? 20:22:36 q+ 20:23:00 .... I think that when you come up with a high level API, you're going to need more than one shim. I can see a shim for safe defaults, for messaging, signing, etc. 20:23:08 ... a shim for OTR, for example. 20:23:25 ... What I want to do, in parallel with test driving, is set up a Git hub for use cases and shims. 20:23:44 ... Let's get the players involved, and put together a nice project, get wide review. 20:24:01 ... We might have a grass routes collection of shims. 20:24:35 Mike: I think it's important for a lot of reasons to work in high level API. Both as drogersuk was saying, to help devs make better choices, and solve actual use cases. 20:24:50 Mike: I was puzzled by hhalpin's comment about it potentially being rushed. 20:25:08 HH: doubtful about it being on the same timeline. 20:25:37 HH: another timeline, OR not make it REC track. 20:26:05 Mike: Process aside, coming to it from an eng perspective, work on a high level API that outputs the JOSE format, and consumes it, would be a value to the community. 20:26:26 ... it becomes a test case that the low level stuff willl do the job, and the high level stuff is validation for the low level implementations. 20:26:34 ... this is a resource question, not an interest question 20:26:50 q? 20:26:52 ... I'll have to go back to Redmond to find a JS expert to do this. 20:26:58 ack selfissued 20:26:59 ack next 20:27:23 arun: it should become 20:27:25 arun: I was wondering whether it was a good idea to treat the high-level API as a use case of the low-level API 20:27:36 arun: treat a high level api as a use case of a low level api 20:27:48 ... this means that the highlevel API is not a WG deliverable, but is secondary hack work on top of the low-level API 20:27:52 q? 20:27:58 ... as a secondary work 20:28:00 selfissued: Not sure if it fills the need, or a step towards filling the need 20:28:06 ack next 20:28:20 arun: ben adida was saying this too - he would like to see a set of shims built 20:28:48 rsleevi: The issue with NaCl and with KeyCzar... is.... to be clear, the Twitter critics are the same 5 critics, and they are opinionated, but we should be careful. 20:28:49 I think that's a proposal to add a "use-case: high-level API and see if we can built it" 20:28:51 q+ 20:29:01 ... there's lots of ppl with strong opinions on crypto, etc. We need to balance opinions. 20:29:16 ... WHen I met with some of these critics, I could [assuage their worries]. 20:29:38 .... NaCl is not as simple as HHalpin described it. David was saying it exposes different functions, depending on what you're trying to do. 20:30:03 tantek has joined #crypto 20:30:03 I was pointing out the main difference is NaCl does have strong defaults 20:30:09 .... When you start thinking about High Level APIs, there are all sorts of different needs. Privacy vs. integrity are composable things that are essentially protocols. 20:30:44 ... Nadim, for OTR, wants different guarantees than JOSE. And we just talked about XMPP. I echo Arun's comments that we don't have use cases that spell out "what I want." 20:31:06 ... Let's not take it on as a WG item. Let's ask: what does doing it in the browser gain? 20:31:41 ... if we talk about the average web developer not getting Crypto, well [yes there's the rub]. The average web developer doesn't do secure things, e.g. mixed content over TLS. 20:31:50 q? 20:31:53 ack next 20:32:23 VGB: I'm going to take a different tack on the question. At the native level, we build high level APIs. But let's first define what High Level means. 20:32:50 VGB: for those devs that just want to build out a private convo, ask them integrity protection needed? Might not know. 20:33:31 q- 20:33:40 VGB: I support doing this as a use case. But... it doesn't solve your problem. What you will have is a magic API that given data and a key, will spit out an encrypted chunk. That will lead to bad practice, e.g. hard-coded passwords. 20:33:55 VGB: hardest thing about Crypto isn't Crypto. It's key mgmt. 20:34:13 VGB: Hardest part isn't protect a piece of data. It's "to that recipient." 20:34:35 drogersuk has joined #crypto 20:34:37 ... I think if you take the view that I just want to cater to the naive developer, you're setting yourself up for failure. 20:35:09 q? 20:35:33 key management is hard: http://www.w3.org/TR/xkms/ 20:35:38 ... The helper function might help, but it won't solve the problem. The "other question" is almost another WG in itself. The XKMS was [not as successful as originally anticipated] [given the intractibility of the problem]. 20:36:11 ack next 20:36:14 VGB: many WGs tasked with a high level API haven't gone anywhere. 20:36:28 IH: I think from the IE perspective, we have the same constraints as any other UA project. 20:36:37 IH: we're definitely going ahead with implementing the low level API first. 20:36:44 vgb has joined #crypto 20:36:57 IH: Based on that, we'll look at the v2, and see what's next. We did this for IndexedDB, WebGL, etc. 20:37:07 IH: A lot of people are writing frameworks based on what they want to do. 20:37:18 IH: logically, this belongs in the community. NOT in a WG. 20:37:32 IH: There are many commonalities, maybe we take some of that into the WG. 20:37:42 q? 20:37:43 ex: Futures (promises) or Query Selectors (CSS) 20:37:59 IH: I think the pragmatic approach is to start with low level, and see if libraries emerge. A test case around this might be interesting. 20:38:13 IH: e.g. for IndexedDB, we coined an abstraction layer as proof of concept. 20:38:22 IH: we do have people that have built polyfills. 20:38:25 ack next 20:38:26 q+ 20:38:57 q? 20:38:58 DR: We've heard from a few folks that that average web developer doesn't do things securely. This comes down to education piece. We might need developer guidelines. 20:39:23 DR: We're going to do some work on these pieces, talked to dschepers. 20:39:43 ... there's a knowledge gap. Developers are being told to develop things securely, but aren't being given the help. 20:39:52 q? 20:39:55 q+ 20:39:56 .... I am hearing from the average developer that we want to do this more easily, but Crypto is hard. 20:40:13 ... What they're actually doing is actually no security. 20:40:45 jmackay has joined #crypto 20:40:49 q+ 20:40:49 ... Shims will ALSO be implemented insecurely. Maybe taking ownership on GitHub would be good, rather than let BAD SHIMS blossom. 20:40:55 ack next 20:41:06 arun: Just looking through this and how default understanding even defaults are 20:41:09 ... this is a hard problem 20:41:15 ... I think we should double down on the low-level API 20:41:32 ... eg: futures might make the API easier 20:41:35 q+ 20:42:03 ... on use cases , I'm not sure if it makes sense for to separate out use cases for low level and high level API 20:42:10 ... the sample code might differ, but the use cases are the same 20:42:12 ack next 20:42:15 ack hhalpin 20:42:35 HHalpin: again, of all the options on the board, it seems like the option that has the most support, is can't build High without Low. 20:42:46 HHalpin: I'm not hearing anyone saying we should do active charter changes. 20:43:12 HHalpin: I'm not hearing that, but on the other hand I do hear that it would be an interesting use case of the low level if we can build a shim on top of it. 20:43:21 ... we probably want a shim before we hit rec. 20:43:28 ... we should definitely see if that's possible. 20:43:48 ... after the next public draft of web crypto is out, the question is can a high level shim be built on top. 20:44:14 ... seeing if the shim can fit on some use cases? Or all? That would be interesting to determine. 20:44:53 q+ 20:44:53 ack next 20:45:01 q? 20:45:02 we should put a mention in the spec to the web platform site too 20:45:35 DR: I'm nervous about seeing this WG deliver a shim. Beyond all the political aspects of use cases, my concern is that you don't deliver shims. You deliver libraries people use. 20:45:48 rsleevi said the above ^^^ 20:46:01 rsleevi: I'm nervous about this WG delivering a shim. 20:46:25 rsleevi: I'm nervous about a formal engagement at the W3C level as a work item with making shims. 20:47:08 rsleevi: I'm nervous about the harm this will do. Throwing code over the wall has the risk of being dangerous. 20:47:09 q? 20:47:12 q? 20:47:13 ack next 20:47:52 IH: I think that one thing that might prove useful is a set of patterns, that we can point people to. Here's the webcrypto set of commands that does specific task, usable for particular things. 20:48:09 DR: if you go to the web platform site, it's guidance and patterns. 20:48:27 http://www.webplatform.org/ 20:48:33 which is a W3C effort 20:48:39 Link to web platform: http://docs.webplatform.org/wiki/Main_Page 20:48:43 ;-) 20:48:52 IH: we need to make sure we don't oversell things, including Futures. 20:49:04 IH: Let's not undersell what's in use today. 20:49:11 ack next 20:49:29 q+ 20:49:47 Mountie: My opinion is we don't need a High Level API. 20:50:53 MH: The low level API could use more code snippets. 20:51:03 q? 20:51:34 ack MichaelH 20:51:58 q+ 20:52:56 q? 20:53:01 hhalpin has joined #crypto 20:53:23 drogersuk has joined #crypto 20:53:38 q+ 20:53:54 q? 20:54:01 q+ 20:54:22 arun: The need for a high-level API can more or less be said for any API from the web 20:54:35 arun: People always want something simpler 20:54:46 ... we've successfully punted these issues in the past to libraries like jQuery 20:54:55 ... not sure we need an explicit use case in the doc for high level 20:55:10 ack next 20:55:20 HHalpin: Depending on how much energy develops around the shim, pointing out to the best of breed might be a good activity for the WG. 20:55:42 MJ: when we met at Mozilla a while back, we proposed a high level API. I don't think the High Level API should be rec trac. 20:55:51 MJ: Issues seem to be resourcing issues. 20:56:19 (israelh and rsleevi shaking heads at that) 20:57:17 ? 20:57:18 MJ: Ideally, I'd like to see a high level API, that calls the low level API And then decide whether to make a spec. 20:57:20 q? 20:57:26 ack next 20:58:22 DR: Web Crypto is a special case. That aside, the proposal might be to put something in the spec that links to web platform, and then once we've got that note in the spec, proceed zealously with education. 20:58:31 ack next 20:59:01 IH: it sounds to me like the whole goal is that Web Crypto is built so that further absractions on top of it. 20:59:33 q? 21:00:12 s/absractions/abstractions 21:00:34 q+ 21:00:44 s/further abstractions/further abstractions can be built on top of it. 21:01:32 q+ 21:01:36 ack hhalpin 21:01:46 q+ 21:01:47 HHalpin: could open an issue to see if shims blossom. 21:01:48 q- 21:01:56 ack hhalpin 21:01:59 q+ 21:03:09 q+ 21:03:12 q+ 21:03:13 q+ 21:03:15 DDahl: I'd like to do a library, that does stuff with JOSE. I'm not sure that's WG items, or work that Mozilla, Google, MSFT, BBN, and others do. 21:03:21 DDahl: hopefully, like jQuery, it could take a life of its own. 21:03:51 DDahl: it's not just one shim. It could be a series of these. 21:03:51 ack next 21:03:55 q? 21:03:57 ack next 21:03:58 q+ 21:04:14 IH: we should definitely try and partner with library folks. 21:04:19 IH: even talk to the jQuery guys. 21:04:29 IH: there are things we can close today. 21:04:54 ... one that's not controversial. Let's put a goal in the spec., saying layering abstraction is a goal. 21:05:11 ... We need Low Level first, and then evaluate that again. 21:05:25 ... The only thing is that we can work on libraries, even within Microsoft, and bring those back to the WG. 21:05:49 I actually think the ACTION would be "Build at least one working sample shim(s)/library that addresses one common use-case". If it does exist we point at it from the WG deliverable use-case and Web Platform docs, great. 21:05:51 My concern would be if we have to modify the charter. 21:05:51 ... All of those are not controversial. We can close those. 21:05:52 ack next 21:05:59 scottk has joined #crypto 21:06:03 That is what we need to give W3C head's up on ASAP. 21:06:35 rsleevi: Rather than open an issue, let's close stuff. I want to make sure we have a response. And that we can give it to the community at large. 21:06:44 rsleevi: so, huge +1 to IH 21:06:50 ack next 21:06:52 ... and let's get back to work on the low level API> 21:07:29 Mountie: after 10 years labor, we're not sure about SHA-256, etc. If we give high level API, or use cases, that can cause a misreading. 21:07:40 Mountie: maybe people will start thinking SHA-256 is secure. 21:07:47 q+ 21:08:05 Mountie: a guide document, given the evanescence and tendency to obsolescence within Crypto, can be dangerous. 21:08:20 ack next 21:08:24 zakim, close the queue 21:08:24 ok, rsleevi, the speaker queue is closed 21:08:56 MJ: I mostly agree with what Israel H. said. 21:09:13 MJ: as possible input to decide what next steps are, I'll search for a dev to help. 21:09:24 MJ: This is inter-related with Key Wrapping. 21:09:49 ... JWE to JWK might be a part of the use cases, and thus a party for consideration in high level API. 21:10:53 Virginie: I suggest we put as a goal to write down small use cases we want to address, if we go for a high level API. 21:11:02 +1 21:11:26 -1 21:13:05 q+ 21:14:36 HHalpin: I would be concerned if there wasn't a working shim by the time we hit rec. 21:15:10 q? 21:15:14 which made it back into the browser later 21:15:30 q? 21:15:31 Here is further example of IndexedDB causing problems with developers: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ 21:15:31 ack virginie 21:15:36 ack drogersuk 21:15:36 (view the comments) 21:15:48 DR: I don't see the dveloper docs as a mutually exclusive option. 21:16:04 DR: if we get an agreement that we'll do that, and put a note in it, we may be offset our detractors. 21:16:48 DR: by not saying anything to developers, well, that's an example of CRYPTO SNOBBERY 21:17:09 DR: the action here is to call out WebPlatform in the spec 21:17:23 Getting Web Platform docs should be high priority as soon as we get next Public Working Draft 21:17:29 ACTION: israelh to draft goal statement explaining a bit about the goals of being wrappable specific to use case 21:17:29 Error finding 'israelh'. You can review and register nicknames at . 21:17:45 ACTION: sleevi to include statement about web platform in the doc 21:17:46 Created ACTION-96 - Include statement about web platform in the doc [on Ryan Sleevi - due 2013-05-01]. 21:18:04 ACTION: david rogers to add docs to webplatform 21:18:04 'david' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ddahl3, dmcgrew, drogers2, dhooley). 21:18:14 i am ddahl3 21:18:16 ACTION: drogers2 to add docs to webplatform 21:18:16 Created ACTION-97 - Add docs to webplatform [on David Rogers - due 2013-05-01]. 21:18:56 change that due date by 2014 ;-) ? 21:19:07 Virginie: on the shim aspect, any volunteers? 21:20:02 +1 21:20:09 +1 21:20:17 future +1 21:20:28 +1 21:20:29 The proposal is that Mike Jones, David Dahl, and Richard Barnes will work on a shim. 21:20:34 Virginie:call for volunteers for a special task force. 21:20:53 Virginie: this task force will focus on shims generated on top of the low level API 21:21:09 virginie: will we be issue uniforms? 21:21:13 virginie has joined #crypto 21:21:21 q? 21:21:45 +1 21:21:52 +1 21:21:59 ACTION: ddahl, selfissued, and rbarnes to develop a higher-level shim 21:21:59 Error finding 'ddahl,'. You can review and register nicknames at . 21:22:22 -1 21:22:41 Now on break 21:23:01 My future +1 was for The proposal is that Mike Jones, David Dahl, and Richard Barnes will work on a shim. not volunteer 21:24:31 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html rsleevi 21:31:50 virginie has joined #crypto 21:44:52 drogersuk_ has joined #crypto 21:46:02 mountie has joined #crypto 21:46:16 jmackay has joined #crypto 21:46:20 SooHyung has joined #crypto 21:46:40 http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/att-0029/CryptoAPI.j_ 21:46:45 Topic: Big Num 21:46:53 karen_ has joined #crypto 21:47:31 q? 21:47:54 I am scribing 21:47:57 ScribeNick; arun 21:48:03 Topic: BigNum 21:48:11 israelh has joined #crypto 21:48:20 vgb has joined #crypto 21:48:26 ??: For better or worse, JavaScript is the language moving forward. 21:48:32 jin has joined #crypto 21:48:58 ??: While what you've done to date solves the 90% use case e.g. RSA, encryption, signing, we work on pushing the cutting edge of crypto tech 21:49:04 s/??/jmackay/ 21:49:10 ??: We'd like to really push the boundaries of what we can do. 21:49:22 hhalpin has joined #crypto 21:49:30 jmackay: we need fast math in order to push the boundary: groups, rings, fields. JS is not ideal for that. 21:49:45 ... the proposal submitted to the listserv is a strawman 21:50:01 ... First, use cases from our perspective. 21:50:40 .... UProve, which is a selective disclosure protocol. For example, if I have a driver's license, I can only show you my age, or only proof that I'm 21+, without revealing my age. 21:50:43 hhalpin_ has joined #crypto 21:50:47 ... Unfortunately, it requires client crypto 21:51:11 .... It's worth nothing that the EU is looking at UProve in the ABC4Trust project. 21:51:20 JM: This has real application for the EU's potential standards. 21:51:38 ..... Other interesting things: Helios, and other voting protocols, using the browser as the client. 21:51:49 ... You can develop pairing libraries on top of elliptic curves. 21:52:02 ... Attribute based encryption, another big use case. 21:53:16 ... Non-interactive authenticated key agreement schemes, BLS short signatures, hyper-elliptic curve cryptography, lattice-based cryptography (not broken by quantum computers), 21:53:37 .. Tolga from Intel mentioned Shamir's Secret Sharing algorithm. This was posted on the mailing list. 21:54:04 ... Due to the use of doubles, as the only numeric type, we're limited to using 16bits for BigNum calculations. That means we have up to 8 times as many digits. 21:54:25 notes that the # of digits available is 'technically' dependent on the JS engine. Most engines give you up to 26-28 21:54:52 ... For an O(N^2) algorithm, the "N" the number of digits is far larger in JS because we have to take bigger slices. This can be thousands of times more slow. 21:55:16 ... Bit operations have to be cast from a double to an integer, for the bit operation performed, back and forth to double. This is slow. 21:55:17 drogersuk has joined #crypto 21:55:58 ... Another potential problem is jsut allocation in JS, very slow by measurements. 256-bit addition takes 7 nanoseconds in native, 10x slower in JS Chrome. 21:56:11 .... Allocating an array to take the result takes a microsecond. 21:56:50 .... Another potential problem is if you implement in JS a NIST-Prime, we can do many more optimizations. 21:56:53 vgb has joined #crypto 21:57:31 ... Side channel or memory attacks, e.g. trying to keep keys safe. If we design BigNum API, memory can at least be cleaned up. 21:57:39 ... That's not always a problem, but with secrets, it might be. 21:57:55 ... Why not JS language support? My sources say that this is very unlikely to materialize. 21:57:59 q+ 21:58:13 ... Even if it did, it would not be optimized for Crypto Math. 21:58:29 ... What we'd really like are cryptographically optimized routines. 21:58:34 q+ 21:58:42 .... If we have RSA and other things, then the OS must have some kind of math. 21:58:57 ... There are certainly open source impls of these things. 21:59:05 ... Implementing it is not that hard. 21:59:38 q? 22:00:14 arun: one reason to make sure it was minuted accurately was to make sure it can be taken back internally to Mozilla 22:00:33 ... have had threads going on with people at Mozilla (brendan eich, ben adida, others) to understand this 22:00:40 ... Question: Do you think you can make your performance data public? 22:00:50 jmackay: I will need to ask 22:01:20 arun: It'll be helpful for discourse. We've seen developments like emscripten, asm.js, Native client, etc 22:01:35 ... can we evaluate those, look at what the performance overheads are 22:01:37 MihcaelH has joined #CRYPTO 22:01:48 ... there are probably use cases here that can't be addressed by JS alone 22:02:01 ... You also mentioned because we have RSA already, somewhere we must have a place to do the math 22:02:08 MichaelH has joined #CRYPTO 22:02:14 ... not necessarily true. We may only have access to the algorithm, and it encapsulates the math internally 22:02:27 ... You also mentioned that TC39 won't take on this work. That's both true and not true 22:02:35 ... they are taking on BigNum work, that's the untrue part 22:02:48 ... but it might be true that they are not taking on crypto math 22:02:53 ... ex: they are taking on int64 22:03:15 ... they are taking on operations, so while it may not be that they're taking on crypto math, they are taking on operations 22:03:21 ... which might be a path to crypto math 22:03:35 ... speaking for myself, not for mozilla, I'm thinking this might be better addressed at the language, not the interface 22:03:49 ... not necessarily trying to interface out the bignum math 22:04:04 ... I suspect if I were a betting man, Mozilla might say better to do this at a language level 22:04:07 ack arun 22:06:02 jyates has joined #crypto 22:06:13 rsleevi: Gave a general +1 to arun, but trying to clear out JS and dealing with memory is NOT a WebCrypto WG action. 22:06:42 rsleevi: other aspect is trying to find the right balance of API. How low? How high? There's a lot of work on optimizers. If we can see numbers, that would be good. 22:06:50 rsleevi: can we do things in the engine to make this better? 22:07:00 q? 22:07:08 ack rsleevi 22:07:40 q+ 22:08:08 arun: mentions public-script-coord@ as the place for the liasing of TC39 and the Web API folks 22:08:27 q+ 22:08:39 virginie: At MSFT, did you look at other places to bring the API? Why this group? 22:09:20 jyates_ has joined #crypto 22:09:22 JM: we want to do crypto in our browsers, but can't. 22:09:32 JM: I have two XBox teams asking me for crypto in JS, but we can't cater to it. 22:09:37 q+ 22:10:03 JM: The reason we came here was to see if there's interest from other folks about doing this. 22:10:10 JM: from our perspective, we start with the numerics. 22:10:16 JM: it makes sense to us to build the numerics. 22:10:17 q+ 22:10:46 rsleevi: ONe of the other elements that arun touched on, that I want to echo, is having worked with a wide variety of crypto APIs, one of the things you do is draw a boundary around the API. 22:10:55 .... You don't get access to the internal implementation. 22:10:57 jyates has joined #crypto 22:11:16 .... The CNG API is not a publicly accessible one. 22:11:53 ... MOST browsers, while they have this, STILL draw boundaries for regulatory reasons. 22:12:14 .... Another challenge this group faces is while we're a web crypto WG, Crypto is SO huge that we can't be everything. 22:12:41 q+ 22:12:47 .... We have TLS libraries, we have crypto, .... we're trying to find the right balance between generally applicable and specific exposed stuff. 22:12:51 ack next 22:12:54 ack next 22:12:58 drogersuk has joined #crypto 22:12:59 ... I'm having a hard time understanding wha you've described as the 90% and the 10%. 22:13:55 MJ: MSFT brought this proposal here because this is math specialized for doing cryptography. It is math over finite fields, specialized for cryptographic purposes. MultiplyMUD, etc. are core of crypto operations, but not "other" BigNum math. 22:14:01 q? 22:14:16 israelh has joined #Crypto 22:14:18 Mountie: I'm not an implementor. As a user, it may conflict. 22:14:34 s/MultiplyMUD/MultiplyMod/ 22:14:35 Mountie: I think opens the possibility to all users. I give my +1. 22:15:01 JM: Someone mentioned Korea. 22:15:02 q+ 22:15:07 ack next 22:15:10 ack next 22:15:12 JM: could this solve that? 22:15:47 Karen: You mentioned your use cases. With modern secure element, like smart cards, support BigNum. 22:16:02 Karen: Identity based encryption is all inside smartcard technology. 22:16:17 Karen: consider smartcards. 22:16:18 ack next 22:16:49 VGB: Why did TC39 take this on? 22:17:13 rsleevi: What's coming out in ES6 is partial support for arbitrarily defined types. 22:17:24 rsleevi: ES6 partially introduced support for this. 22:17:49 rsleevi: ES6 --> ES7 will really implement these. Brendan Eich has already prototyped this. 22:18:00 rsleevi: this has 64 bit registers, etc. 22:18:28 rsleevi: The ES6 spec extended types, and attributes of types. 22:18:43 jin has joined #crypto 22:18:48 rsleevi: ES7 put the final patches on this. Repeatedly during these discussions, BigNums were seen as part of the reason for this. 22:19:00 q? 22:19:01 rsleevi: This got us away from the hell of using doubles everywhere. 22:19:13 jmackay has joined #crypto 22:19:16 q- 22:19:26 q? 22:19:39 Promised links: 22:19:40 http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies 22:19:53 and Brendan's patch https://bugzilla.mozilla.org/show_bug.cgi?id=749786 22:21:21 q? 22:22:30 arun: BigNum *alone* won't solve Korean banking, but it MIGHT allow implementation of proprietary algorithms. 22:23:24 q+ 22:23:42 VGB: maybe an action would be to release our perf data 22:23:46 q+ 22:24:11 JM: It might not change the course of things, but hopefully implementors will look at allocataors 22:24:25 JM: what we need is for these expensive operations to have efficient implementations. 22:24:41 q- 22:25:04 q? 22:25:09 ack next 22:25:49 arun: Mozilla will likely consider this a language feature, and NOT an interface within an API 22:26:19 karen: this looks like a language feature. 22:26:29 JM: Yes, the interface feature was the cheapest option. 22:27:18 Karen: Korean banking case can be generalized to a non-US banking case. 22:29:47 q+ 22:29:53 MW: Why would TC39 consider such a specialist API, for crypto only, to be taken on as a work item? 22:30:15 rsleevi: well, in other languages, you can go to the metal pretty fast. But on the web, you go to an API group, or the JS language group. 22:31:08 q? 22:31:10 vgb has joined #crypto 22:31:15 ack next 22:31:44 MW: I like finite fields 22:33:41 Topic: Algorithm Identifiers and Registries 22:33:45 jmackay has joined #crypto 22:34:15 TLR: You have algorithm identifiers. What happens when this group ends? How should they live 10-15 years from now? 22:34:16 MichaelH has joined #CRYPTO 22:34:45 TLR: from that perspective, we could use URIs as identifiers. We could use registries. We could maintain a registry in the form of an RFC. 22:35:20 TLR: if there is resistance, how can we square the circle and [mitigate it]. 22:35:31 q+ 22:35:36 q+ 22:36:01 q+ 22:36:02 TLR: is there a way we can articulate the issues? How expensive is it to use an algo as an extension point? 22:37:02 TLR: what is the likelihood of change, and rate of change? Can we figure out a mechanism that fits into the three variables? Briefly, there are a number of options. We've been known to run free for all registries. We've had some working groups known to have a Wiki. We also have the ability to figure out an IANA registry. 22:37:19 q? 22:37:21 TLR: With that range of options, can we talk about rate of change, desirable cost of change, and policies that might match that. 22:37:24 ack next 22:37:36 q? 22:37:46 jyates has joined #crypto 22:37:52 rsleevi: We have an extensible API, that wasn't designed for extensibility. 22:38:54 rsleevi: we talked about window.crypto.RSA, window.crypto.AES. The fact that we have identifiers that are extensible, is a plus, but like other APIs, like WebGL, etc., the best approach is to use a WG to build consensus between implementors and users. 22:39:20 rsleevi: it's important for browser vendors to get together and discuss how to behave. 22:40:02 rsleevi: a free for all registry is scary. It's like vendor prefixing. 22:40:26 q+ 22:40:34 rsleevi: if going through standards and rec track, the same way that indexedDB extends navigator, that's how an algo should be added and extended. 22:40:49 rsleevi: what do we do when we have lots of algos? Where do we list all that? 22:40:58 rsleevi: could be webplatform.org. 22:41:20 rsleevi: it's more important to have a consensus process. 22:41:47 rsleevi: that's the opinion from UA side. Other side -- server side -- could have different concerns. 22:41:52 q? 22:42:14 ... Like Netflix, not looking for a web browser user agent. But from the browser side, I want to see rec track WG action to see how this looks. 22:42:39 TLR: The long term implications of saying "you may support other algos, but others don't." 22:42:56 .... has arbitrary implications, and security implications. 22:43:10 ... is a consequence of names being too hard to get into the agreed upon list. 22:43:23 .... having an open extension point seems more dangerous than a free for all registry. 22:43:49 ... I partly agree with REC track. 22:43:55 q? 22:44:04 rsleevi: Treating it like we treat other rec tracks is the right course of action. 22:44:12 q? 22:44:17 q+ 22:44:25 ack next 22:44:32 q+ 22:44:35 rbarnes: I think you're exagerating the complexity and need for consensus. 22:44:43 Zakim, close the queue 22:44:43 ok, virginie, the speaker queue is closed 22:44:46 rbarnes: This has been done in other contexts. 22:44:49 hhalpin has joined #crypto 22:44:56 q? 22:44:58 q+ 22:44:59 rbarnes: in the IETF, have a lot of experience with registries with varying levels of control. 22:45:13 ... I would think an expert review process would be appropriate. 22:45:26 ... This group could set guidelines. 22:45:41 ... An expert can then follow guidelines. 22:45:42 ack next 22:46:02 VGB: I agree with Thomas that the open extensibility point is more dangerous than the free for all registry. 22:46:14 VGB: The open extension point without that control is bad. 22:46:38 VGB: REC track might be MORE than essential. If I look at the way algos function, it's not that it springs up for the first time in a W3C group. 22:47:12 VGB: *gives examples* Given that, doing this document, we pretty much took things from spec. and slotted them in, and called it done. 22:47:27 VGB: If a new algo comes along, here's how you support it. 22:47:46 VGB: A REC track document might be over-kill. 22:47:50 ack next 22:48:54 arun: who else does this? 22:49:04 q? 22:49:05 TLR: nobody exactly, but XML Security. 22:49:54 and XML security should be considered an anti-pattern for everything :) 22:49:55 TLR: XML Security was done 10 years ago, and was done differently than this. Don Eastlake volunteered to maintain a list of URIs for this work in an Internet draft. It was effectively a registry. 22:50:05 ... the registry existed in a document. 22:50:33 TLR: Another cautionary tale -- some folks wrote an RFC about how to encode keys. They had no clue about the limitations of XML Schema. 22:50:42 TLR: That was a useless case of extending the API. 22:50:54 TLR: Folks with clues about the implementation environment need to look at this stuff. 22:51:26 q? 22:51:27 TLR: The WG as an institution won't be around indefinitely, so at some point there has to be something in place. AES, SHA, etc. will evolve. At that point what's the cost, and what happens 22:52:30 TLR: Can we try to explore writing down a slightly more formal version of the criteria for inclusion, something like the Don Eastlake role? 22:52:53 q+ 22:53:00 TLR: There are plenty of ways to do this badly. But these shouldn't stop us from doing some things well. 22:53:44 rsleevi: my comments to respond to vgb -- algorithms have inputs in their spec not always exposed to the API to implement them. We'd object to treating this as different from any other web apps API. 22:53:59 We might what to extend this discussion. 22:54:01 rsleevi: the choice of algos and extensions are fundamental to the web api. 22:54:04 q+ 22:54:24 Can wrap up take 30 minutes rather than one hour? 22:54:37 rsleevi: what you've described doesn't match what WHATWG and WebApps does. 22:54:40 q? 22:54:50 ack rsleevi 22:55:23 TLR: one distinction -- we're dealing with a space in which algos replace others, which is different than other API specs. 22:56:08 Notes that you have extensibility points in HTML5 - think of rel link registry in the WHATWG for wiki. 22:56:15 VGB: SHA-3 is out. Might we have a test case that explores how to retire SHA-3? 22:56:25 s/retire/expose/ 22:56:53 s/retire/extension 22:57:08 VGB: SHA-3 is about to arrive. How to include SHA-3 is a good test case. 22:57:24 s/retire SHA-3/include SHA-3 22:57:58 rsleevi: SHA-3 has aspects that aren't ready e.g. params 22:58:51 Try with GOST, SEED, Camilia, Aria, Clief 22:59:53 TLR: I'm happy to help, but I don't want to design a process that nobody uses. 23:00:53 Topic: Key Agreement 23:01:13 ISSUE-36? 23:01:13 ISSUE-36 -- Semantics for key generation versus key derivation -- open 23:01:13 http://www.w3.org/2012/webcrypto/track/issues/36 23:01:16 ISSUE-43? 23:01:17 ISSUE-43 -- Separate method for key agreement -- open 23:01:17 http://www.w3.org/2012/webcrypto/track/issues/43 23:02:18 q? 23:02:40 rsleevi: one point to add to rbarnes' proposal is key agreement is actually key agreement protocols, with multiple stages. 23:02:54 rbarnes: propose to handle key agreement in the same action as derivation / generation 23:03:31 rsleevi: I wanted to say this might be similar to multi-stage key derivation, but we'll need to address multi-stage things in the API. 23:03:55 VGB: are you talking multi-stage as in Diffie-Hellman or as in [somethingElse]? 23:04:02 rsleevi: that's what we need to clarify. 23:05:21 s/[somethingElse]/MQV/ 23:05:34 /me thanks rsleevi :) 23:06:16 Virginie: we may address a round of comments on the cert aspect. Summer will be the period for tests. Will the commando team make progress on shims? 23:06:27 Virginie: and, progressing on the security documentation? 23:06:36 Virginie: After, go for last call in October. 23:06:44 drogersuk has joined #crypto 23:07:03 q? 23:07:16 Virginie: meet in the summer? 23:08:23 Mountie: Korea would host a meeting. We need some motivation to get folks interested in Crypto API. 23:08:56 Virginie: have a meeting close to IETF meeting. 23:09:42 Virginie: Then there's the November TPAC meeting. 23:09:50 ... show of hands, who will meet in summer? 23:10:12 Some hands go up in the room. 23:11:12 q? 23:11:17 rsleevi: What issues would warrant a f2f in summer? Wrap/Unwrap might be one. 23:11:18 q+ 23:11:42 Virginie: Testing and shim might warrant a meeting. 23:11:45 q? 23:11:58 DDahl: Testing might want one. 23:12:18 NVDB: Going to last call without a meeting -- isn't that risky? 23:12:25 Virginie: Every two weeks we have a conf. call. 23:12:49 Virginie concludes enough traction for F2F summer. 23:13:01 The main issue with a f2f this summer would be collocating near IETF JOSE WG meeting to make sure all open issues related to JOSE are finished. 23:15:40 hhalpin: Possible issues are wrap/unwrap and short names, which will likely require liasing with JOSE to work through 23:15:40 crypto has joined #crypto 23:15:45 scribenick: rsleevi 23:16:03 hhalpin: Possibly a side-trip to Korea to investigate the certificate case, before/after TPAC 23:16:35 virginie: Scheduling for meeting, close to IETF timing 23:16:58 kodonog: Possibly co-locating with IETF the days right before the IETF meeting (in Berlin) 23:17:41 Dates for IETF 87 are July 28 - Aug 2 23:17:43 http://tools.ietf.org/agenda/87/ 23:18:28 kodonog: talking 25/26 (Thur/Fri) before IETF 23:20:38 in Korea? 23:21:33 q? 23:21:53 q- hhalpin 23:22:46 virginie: We have two options - before IETF or after IETF 23:23:38 ... need to secure hosting afterwards if we're going after 23:23:49 ... will finalize by e-mail 23:24:05 Topic: Conference calls 23:24:17 virginie: Currently meeting at 20:00 UTC every other week 23:24:49 ... proposal for 19:00 UTC 23:25:58 ... consensus for keeping it at 20:00 UTC 23:26:51 Reminder: No telecon next Monday 23:27:15 Let's just say keep it at 20:00 UTC 23:27:17 jimsch: 27 of May may need to be shifted (US holiday?) 23:27:46 We've ignored other holidays in the past :) 23:27:51 virginie: Next call is May 6 23:29:12 RRSAgent, draft minutes 23:29:12 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html wseltzer 23:29:24 tlr: Thanks to PayPal 23:29:27 [applause] 23:30:03 RRSAgent, draft minutes 23:30:03 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html wseltzer 23:30:13 trackbot, end teleconf 23:30:13 Zakim, list attendees 23:30:13 sorry, trackbot, I don't know what conference this is 23:30:19 trackbot, end meeting 23:30:21 RRSAgent, please draft minutes 23:30:21 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html trackbot 23:30:22 RRSAgent, bye 23:30:22 I see 13 open action items saved in http://www.w3.org/2013/04/24-crypto-actions.rdf : 23:30:22 ACTION: markw to clarify how public/private key pairs are retrieved with respect to naming [1] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-02-45 23:30:22 ACTION: watsonm to clarify how public/private key pairs are retrieved with respect to naming [2] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-02-57 23:30:22 ACTION: mark to clarify how public/private key pairs are retrieved with respect to naming [3] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-03-16 23:30:22 ACTION: karen to write use case description describing the use case [4] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-21-43 23:30:22 ACTION: arun to add JOSE use case [5] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-54-36 23:30:22 ACTION: arun to add caveats showing that web crypto WG is only addressing a subset of some use cases [6] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-55-28 23:30:22 ACTION: arun to add BrowserID use case to use cases document [7] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-57-27 23:30:22 ACTION: arun to document a cross-origin use case for webcrypto [8] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T17-36-40 23:30:22 ACTION: israelh to draft goal statement explaining a bit about the goals of being wrappable specific to use case [9] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-17-29 23:30:22 ACTION: sleevi to include statement about web platform in the doc [10] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-17-45 23:30:22 ACTION: david rogers to add docs to webplatform [11] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-18-04 23:30:22 ACTION: drogers2 to add docs to webplatform [12] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-18-16 23:30:22 ACTION: ddahl, selfissued, and rbarnes to develop a higher-level shim [13] 23:30:22 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-21-59 23:30:22 Zakim, list attendees 23:30:22 sorry, trackbot, I don't know what conference this is 23:30:30 RRSAgent, please draft minutes 23:30:30 I have made the request to generate http://www.w3.org/2013/04/24-crypto-minutes.html trackbot 23:30:31 RRSAgent, bye 23:30:31 I see 13 open action items saved in http://www.w3.org/2013/04/24-crypto-actions.rdf : 23:30:31 ACTION: markw to clarify how public/private key pairs are retrieved with respect to naming [1] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-02-45 23:30:31 ACTION: watsonm to clarify how public/private key pairs are retrieved with respect to naming [2] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-02-57 23:30:31 ACTION: mark to clarify how public/private key pairs are retrieved with respect to naming [3] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-03-16 23:30:31 ACTION: karen to write use case description describing the use case [4] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-21-43 23:30:31 ACTION: arun to add JOSE use case [5] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-54-36 23:30:31 ACTION: arun to add caveats showing that web crypto WG is only addressing a subset of some use cases [6] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-55-28 23:30:31 ACTION: arun to add BrowserID use case to use cases document [7] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T16-57-27 23:30:31 ACTION: arun to document a cross-origin use case for webcrypto [8] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T17-36-40 23:30:31 ACTION: israelh to draft goal statement explaining a bit about the goals of being wrappable specific to use case [9] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-17-29 23:30:31 ACTION: sleevi to include statement about web platform in the doc [10] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-17-45 23:30:31 ACTION: david rogers to add docs to webplatform [11] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-18-04 23:30:31 ACTION: drogers2 to add docs to webplatform [12] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-18-16 23:30:31 ACTION: ddahl, selfissued, and rbarnes to develop a higher-level shim [13] 23:30:31 recorded in http://www.w3.org/2013/04/24-crypto-irc#T21-21-59