00:04:25 nkic has joined #crypto 00:09:12 tantek has joined #crypto 00:17:43 tantek_ has joined #crypto 00:21:19 manu1 has joined #crypto 00:33:43 manu2 has joined #crypto 00:55:19 mountie has joined #crypto 01:01:01 vgb has joined #crypto 01:02:53 hhalpin has joined #crypto 01:03:19 rbarnes has joined #crypto 01:03:22 MichaelH has joined #crypto 01:03:24 working on joining the audio... 01:04:03 kotakagi has joined #crypto 01:05:11 yeah, i got "this conference is restricted at this time" 01:05:27 oh 01:05:44 zakim, who is here? 01:05:46 jehoochen_ has joined #crypto 01:05:55 no zakim 01:06:05 trackbot, start meeting 01:06:07 RRSAgent, make logs public 01:06:07 Zakim has joined #crypto 01:06:09 Zakim, this will be CRYPT 01:06:09 ok, trackbot; I see SEC_WebCryp()8:00PM scheduled to start 6 minutes ago 01:06:10 Meeting: Web Cryptography Working Group Teleconference 01:06:10 Date: 15 November 2013 01:06:26 rbarnes_ has joined #crypto 01:06:42 is the conference code 27978# (like usual) or 26633# (like yesterday)? the former works for me (i'm there now), but the latter is "restricted" 01:07:03 I'm about to find out 01:07:05 zakim, what's the code? 01:07:05 the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), vgb 01:07:13 virginie has joined #crypto 01:08:12 zakim, call Wuzhou_east 01:08:12 ok, rigo; the call is being made 01:08:22 zakim, who's on the call? 01:08:22 SEC_WebCryp()8:00PM has not yet started, rbarnes_ 01:08:23 On IRC I see virginie, rbarnes_, Zakim, jehoochen_, kotakagi, MichaelH, rbarnes, hhalpin, vgb, mountie, manu2, tantek, nkic, ekr, danny_, rigo, eroman, rsleevi, RRSAgent, timeless, 01:08:23 ... trackbot, slightlyoff, wseltzer 01:08:28 mete has joined #crypto 01:08:51 tony has joined #crypto 01:09:29 jin has joined #crypto 01:09:39 ChristianFuhrhop has joined #crypto 01:09:43 sangrae has joined #crypto 01:09:50 leckie has joined #crypto 01:10:23 mz-modeltaxi has joined #crypto 01:10:40 Agenda: 01:10:51 Agenda: http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda 01:11:01 Chair: Virginie Galindo 01:11:06 junil has joined #crypto 01:11:32 kodonog has joined #crypto 01:11:45 scribenick: kodonog 01:12:23 zakim, who is making noise? 01:12:24 sorry, vgb, I don't know what conference this is 01:12:32 scribe: kodonog 01:12:46 zakim, this is crypt 01:12:46 ok, rigo; that matches SEC_WebCryp()8:00PM 01:12:48 i might *like* to leave before 02:30 ;) 01:13:07 tough luck :) 01:13:27 dsuwirya has joined #crypto 01:13:41 zakim, who is making noise? 01:13:54 some participants need to leave by 3:30 local time... 01:13:56 vgb, listening for 13 seconds I could not identify any sounds 01:14:01 Topic: Buglist 01:14:12 minami has joined #crypto 01:14:13 markw has joined #crypto 01:14:16 https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20cryptography 01:14:18 Anders has joined #crypto 01:14:19 https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29868&order=bug_id&product=Web%20Cryptography&query_based_on=&query_format=advanced&resolution=--- 01:14:23 israelh has joined #crypto 01:14:49 virginie has joined #crypto 01:14:57 order for today, bug review, webRTC, 01:15:15 hhalpin has joined #crypto 01:15:26 bug# ? 01:15:36 trackbot, start meeting 01:15:38 RRSAgent, make logs public 01:15:40 Zakim, this will be CRYPT 01:15:40 ok, trackbot; I see SEC_WebCryp()8:00PM scheduled to start 15 minutes ago 01:15:41 bug#23660 01:15:41 sure 01:15:41 Meeting: Web Cryptography Working Group Teleconference 01:15:41 Date: 15 November 2013 01:15:45 bug 23660 01:15:49 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23660 01:15:59 topic: Finishing Up Going through Bugzilla on API 01:16:02 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23662 01:16:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23695 01:16:25 finish specification 01:17:02 q+ 01:17:28 csjung has joined #crypto 01:17:29 23695 - public keys are always extractable, extracability of private key pairs is TBD, probably look like MS implementation 01:18:07 MichaelH: put private extractable as an enum in your list? 01:18:08 csjung has joined #crypto 01:18:28 rsleevi: there is no word for extractable 01:18:44 confusing this with the conversation about usages 01:18:58 q+ 01:19:10 to all attendees, reminder : our wiki agenda is here : http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda 01:19:40 ack MichaelH 01:19:59 Mete: why do we not have a generate key pair method and just a singluar generate key 01:20:08 rsleevi: a couple of answers 01:20:38 ... if you split along the notion of key pair, you would need parallel operations, 01:21:01 .... this creates a significant surface for all those 01:21:40 Gang has joined #crypto 01:21:43 q? 01:21:47 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23728 01:21:47 ack mete 01:21:55 AndyF has joined #crypto 01:21:55 ... doing this would cause significant rework of api 01:22:01 leckie has joined #crypto 01:22:37 bug 23728: spec needs to be clear, operations are asynchronous, what happens to the underlying data 01:22:44 .... interpretations 01:23:03 ... one is you freeze the object 01:23:28 ... caller cannot reuse that object but would need to reallocate new memory 01:23:41 ... another interpretation you can use copy on write 01:23:53 ... apple engrs concerned about performance implications 01:24:02 ... you'd be adding a copy on every write 01:24:16 taocai has joined #crypto 01:24:26 ... would only be meaningful for webcrypto but would have broader implications 01:25:05 ... third options implementation copies on callers data, any further mutations of underlying data are not reflected in the cryptographic operations 01:25:05 q? 01:25:11 q+ 01:25:31 ... spec will do third 01:25:56 israel: can we infer some of these strategies based on array buffer or arraybuffer view 01:26:46 rsleevi: (missed his answer) 01:27:36 ack virginie 01:27:42 answer: in terms of WebIDL, there's no requirement that we make a copy of the ArrayBuffer. The spec needs to clarify explicitly to make a copy 01:27:44 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23729 01:28:26 23729: implications inconsistent error handling 01:29:01 [note to the attendees interested in web RTC, richard posted some slides here http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf] 01:29:32 ... likely will go with a DOM string, error handling will be consistent 01:29:35 q? 01:29:52 ... mostly a webIDL clarification 01:30:41 .... instead of a sequence of keys would be a sequence of DOMstrings 01:30:51 ... reason this is important 01:31:02 ekr has joined #crypto 01:31:10 ... 2 interpreattions... you ignore them or you error out 01:31:39 ... because this is a security api, blindly accepting things is not good practice 01:32:04 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23762 01:32:32 related to key usages, how a default key usage behaves 01:32:47 proposed resolution, key usage is a mandatory attribute, 01:33:09 ... in the case of JWK, the caller would need to know the import key and 01:33:20 ... same behavior for handling different algorithms 01:34:08 ... if caller is specifying a set of key usages the aren't supported, it would fail 01:34:14 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23779 01:34:41 23779: dup and cleanup bug on webIDL semantic nits 01:34:43 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23786 01:35:13 23786: request for clarification on import key, similar to previous discussion 01:35:50 ... if parameters are an incompatible intersection, it fails 01:36:03 each algorithm would define the set of parameters 01:36:19 some algorithms don't have this problem 01:36:20 q? 01:36:30 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23796 01:37:10 23796: in case of JWA, how to JWA and webcrypto algorithms meet, 01:37:31 ... mark working with JOSE wg on JWA algorithm registry, 01:37:47 ... jose has a use were enc means encrypt/decrypt/wrap, and unwrap 01:37:58 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23831 01:38:00 ... need to figure out how to parse these in an attribute preserving way 01:38:06 .... discusssion on the list... 01:38:15 23831" 01:38:23 q? 01:38:25 q+ 01:38:29 filled yesterday by mete to add HMAC-SHA1 01:38:31 will be done... 01:39:04 MichaelH: HMA-SHA1 as a recommended? 01:39:21 it would likely be better to use a less loaded term than "recommended" 01:39:27 such as just "supported" 01:39:34 rsleevi: we can debate whether it is recommended for legacy or 01:39:40 accordinga 01:40:19 Israel: in the webIDL, are we creating an array of arraybuffers 01:40:51 tantek has joined #crypto 01:41:01 rsleevi: sequence is treated as a contiguous buffer 01:42:35 ... goal is to prevent a JS author from having to copy 01:44:02 Israel: complicates implementation and increases the test matrix 01:44:29 ... make copies in some cases and not others means you have to decide when to copy 01:44:30 tantek has joined #crypto 01:45:07 ... do we need this level of detail? 01:45:16 rsleevi: we could take this out 01:45:27 ... it was added in the april version 01:45:54 ... downside to taking it out, once we force a particular pattern on a JS author we can never optimize that pattern 01:46:18 q+ to ask about algorithms 01:46:29 Israel will file a bug about sequence and we will go back to a single operation model 01:47:01 q? 01:47:06 ack rigo 01:47:06 rigo, you wanted to ask about algorithms 01:47:50 +1 adding 25519 01:48:10 Rigo: question on algorithms potentially impacted by Snowden revelations 01:48:42 rsleeve: the few people that have raised concerns are not reinforced by the cryptographic community 01:48:55 ... including the cfrg in the community 01:49:18 my concerns have been addressed 01:49:26 hhaplin: what is the browser support 01:49:41 just wondering if there was any plan to add brainpool to default implementations 01:50:08 and any plans to add or not? 01:50:12 vijay: microsoft out of the box for the 3 suiteB curves 01:51:08 25519 is not covered yet (ditto Brainpool), still in TLS WG 01:52:02 there will be a test-suite 01:52:12 that should specify clearly what developers can rely on. 01:53:18 JonathanJ has joined #crypto 01:53:42 +1 rsleevi's epic trip through issue list and bugzilla 01:54:00 Richard's slides: http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf 01:54:08 topic: WebRTC and WebCrypto 01:54:58 http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf 01:55:11 Richard Barnes 01:55:26 webRTC meeting earlier this week 01:56:17 ... rbarnes presenting referenced slide set 01:56:36 ... need some way for applications to control which keys are used in the handshake 01:58:21 stephane has joined #crypto 01:58:25 wonsuk has joined #crypto 02:00:46 notes the point re "never been accessed to JS" re private key material 02:00:54 q+ 02:01:09 csjung_ has joined #crypto 02:01:42 ... proposal add two things, specific key usage and flag 02:01:46 q+ 02:02:04 vgb: It would be legal, but it would be an error 02:02:06 csjung__ has joined #crypto 02:02:16 that is, the usage would result in an error, because unsupported usages = throw an error 02:02:29 rsleevi: but an implementation could support it and not violate the spec, right? 02:02:31 the only change is that it goes from a sync error (webIDL) to an async error (reject the promise) 02:02:32 manu2 has joined #crypto 02:02:34 vgb: Correct 02:02:57 so... can we take that off the table as a spec issue? 02:03:07 ... webcrypto would be a reasonable way to implement this because most of the requirements are already met 02:03:34 @vgb: You still need/want a spec to describe how this new key usage works ;) 02:03:52 @vgb: Otherwise, you end up in a situation where one UA uses a keyUsage of "dtls", another uses a keyusage of "webrtc" 02:04:01 @vgb: The latter one being the 'right' one ;) 02:04:08 rsleevi: true, but that spec does not need to be this one? 02:04:31 q+ 02:04:37 rsleevi: as an implementor I have zero interest in this. 02:04:38 q+ 02:04:41 q+ seems like we are moving encryption to far up the stack 02:04:44 ... disagree that it is easy to implement 02:05:14 ... if i wanted to use ECDH how is that communicated in the dtls certificate 02:05:24 kotakagi has joined #crypto 02:06:17 q+ to say it seems like we are moving encryption to far up on the stack to have it at the application programming level 02:06:22 ... define a set of webcrypto objects that can't be used with webcrypto 02:06:28 JonathanJ has joined #crypto 02:06:40 ... i don't see a way that this api makes sense to expose 02:07:03 .... a whole host of algorithms that just don't work 02:07:11 ... better suited for the webRTC group to explore 02:07:43 q+ 02:07:47 ... webRTC could explore their needs for crypto, if they wanted to expose those to JS developers 02:08:11 q+ 02:08:13 (rsleevi... you might want to better summarize for the minutes) 02:08:30 Mountie: I agree with Ryan. 02:09:52 mountie: if webcrypto handles certificates then this might be workable 02:11:01 ekr: appropriate kind of keys here are ECDSA and RSA 02:11:20 ekr: true that you couldn't impose an AES key, but surely that's true all over webcrypto, not webrtc's problem if the class hierarchy isn't rich enough 02:11:28 ekr: pfs is not a problem 02:11:41 ... if webrtc wants this, they should ask for it -- that's what this is 02:11:57 ... could make up some other class of key objects that you use only with webrtc, but that seems like of inferior 02:12:01 q+ to respond to ekr 02:12:25 ... if we want webrtc to say "please use rsa/ecdsa", we would need to restate everything that web crypto has already done 02:12:39 ekr, could you put this in IRC? 02:12:50 i've been trying to scribe ekr 02:12:58 What rbarnes is saying is fairly accurate 02:13:03 (in terms of my scribing) 02:13:36 Well, we discussed this last week 02:13:44 or rather M-T 02:13:44 tao has joined #crypto 02:13:49 and then decided to bring it to webcrypto 02:14:06 hhalpin: we should continue the discussion over the mailing list 02:14:33 MichaelH: the property here is that "this key was internally generated and never marked exportable" 02:15:05 ... 2 new things, DTLS key usage and guarantee not used by webcrypto 02:15:05 rsleevi: the guarantee is that it was *generated* by webcrypto but never available for private computations by the JS 02:15:49 AndyF, you wanted to say it seems like we are moving encryption to far up on the stack to have it at the application programming level 02:16:05 AndyF: from webRTC working group 02:16:27 note : andy is from Verisign, as an observer here 02:16:37 ... looking at putting dtls certificate into api 02:16:49 andy: WebRTC has already decided to do DTLS. That's not an open question. 02:17:26 ... why is this being done at this level? how do I guarantee the integrity of that keystore 02:17:34 andy: also, the dtls is all done by the browser, this is only giving the app a degree of control over how it's odne 02:17:37 it seems like this distinction between extractibility in terms of generation vs. unwrapped/imported is interesting and orthogonal to the DTLS key usage. I'd be interested in knowing if any other use-cases need finer grain storage/generation concerns beyond how we currently specify extractability. 02:18:05 hhalpin, I think that's arguably true, though it's a sort of limited guarantee because you have to trust the browser. 02:18:17 … that's true for WebRTC, but it's not that common a setting. 02:18:18 rigo: meta discussion... w3c part of research project looking at webrtc security 02:18:30 hhalpin: any financial related implementation requires finer grained controls/knowledge related to key storage/generation 02:18:53 hhalpin: ... requires or can benefit from it 02:19:01 ... together with IAB will organize a workshop prior to next IETF, 02:19:08 ... this would be a good topic for that workshop 02:19:20 ... project is to create a research roadmap 02:19:29 rsleevi, you wanted to respond to ekr 02:19:41 ekr, I think we just have to say the browser is a trust anchor with this API - would still be interested in a more detailed proposal re extractability 02:19:44 rsleevi: webrtc cares about identity, certificates 02:19:46 we need to carefully scope the claims we make about key security 02:19:57 +1 02:19:57 ... these are problems we have intentionally deferred from v1 of the api 02:20:12 clearly, we don't care if it's "DTLS" or "WebRTC" 02:20:24 "peerconnection" was also suggested 02:20:42 q+ 02:20:46 quite the contrary, we don't want to share them across origins 02:20:47 q+ 02:21:15 actually, you probably could use RSA-PSS. 02:21:21 In some future TLS world 02:21:30 (Though I don't think that that's a material change) 02:21:35 ... this is the certifications plus conversation and is a fundamental design issue 02:21:41 q- 02:21:43 ... webrtc should deal with it at a high level 02:22:13 webrtc has decided to separate identity from the crypto 02:22:25 dtls provides the key exchange and proof of possession 02:22:35 identity providers bind public keys to identity 02:22:54 so the work we're talking about, at the dtls layer, is not bound into the identity part, it's more crypto-focused 02:23:07 02:23:20 leckie has joined #Crypto 02:23:33 s/hhalpin: any/hhalpin, any/ 02:23:37 we don't really care about the certs in the DTLS exchange, just the keys 02:23:50 s/hhalpin: ... requires/hhalpin, ... requires/ 02:23:51 SDP exchanges key fingerprints, which get bound to identities at a different layer 02:23:53 as rbarnes is saying: the certificate is just a key carrier because of the way DTLS works. 02:24:24 session description protocol 02:24:25 Session Description Protocol 02:24:30 jinx! 02:24:55 so really all we're talking about here is *key* management, not *identity* management 02:25:01 virginie: this topic is for future work 02:25:14 ... no direct endorsement, need more description 02:25:40 ... this is not a small adjustment, it is a new requirement 02:26:00 i disagree with the characterization of this as a huge change. it fits on a slide, as would the implementation. 02:26:23 @rbarnes: No it wouldn't :) 02:26:25 but i will take this to the list. clearly there's a need to expand more on the context 02:26:38 rsleevi: challenge accepted :) 02:26:39 ... i don't agree with ryan on the complexity 02:27:11 rsleevi, {\tiny \begin{verbatim} …. \end{verbatim}} 02:27:13 @rbarnes: Having been involved in both implementations in Chrome, they're entirely different stacks and security models. Getting keys from one to the other is a non-trivial change with fundamental security implications 02:27:41 ... happy with other groups coming to us 02:27:44 rsleevi: I'm not sure it's as hard as you think it is, but I'd be happy to talk to you about chrome 02:27:46 :) 02:28:03 break for 30 02:40:11 tony_ has joined #crypto 02:50:10 rbarnes_ has joined #crypto 02:51:43 rbarnes__ has joined #crypto 02:53:39 taocai has joined #crypto 02:55:38 tantek has joined #crypto 03:02:30 vgb has joined #crypto 03:04:52 we back yet? 03:05:05 is 30 minutes different in china? 03:05:28 markw has joined #crypto 03:05:44 mete has joined #crypto 03:06:10 mountie has joined #crypto 03:08:29 virginie has joined #crypto 03:08:59 Zakim, dial Wuzhou_East 03:08:59 ok, rsleevi; the call is being made 03:09:07 we will start in few seconds... get ready ! 03:09:09 sangrae has joined #crypto 03:09:23 rbarnes: 30 minutes is a SHOULD implement, not a MUST implement 03:09:35 jin has joined #crypto 03:10:10 leckie has joined #crypto 03:10:35 upcoming wrap/unwrap import, key discovery 03:11:02 minami has joined #crypto 03:11:18 rrsagent, pointer? 03:11:18 See http://www.w3.org/2013/11/15-crypto-irc#T03-11-18 03:11:38 scribenick: eroman 03:11:48 nkic has joined #crypto 03:11:49 TOPIC: Wrap/Unwrap 03:12:40 rrsagent, generate minutes 03:12:40 I have made the request to generate http://www.w3.org/2013/11/15-crypto-minutes.html wseltzer 03:12:57 rrsagent, make logs public 03:13:27 virginie equesting rsleevi to give a status update on wrap/unwrap 03:13:30 q+ 03:13:34 s/equesting/requesting 03:13:44 q? 03:13:57 q- 03:14:17 q+ 03:14:42 rsleevi: No outstanding technical issues. There is text to integrate into the spec from Netflix discussions but otherwise nothing major 03:16:13 Mark Watson: We are happy with the approach that we proposed and there are just some details to work out. There are details to work out on the "usage" attribute for the JWK 03:16:25 rsleevi: Matter of coordinate with JOSE on how it works 03:16:30 ack vgb 03:16:37 ack markw 03:17:09 manu2 has joined #crypto 03:17:18 tantek has joined #crypto 03:17:20 tony has joined #crypto 03:17:43 Mark Watson: We need to decide what we want to register. They [JOSE] provide the registry. Way to differentiate what applies to JWK 03:18:21 ... If anyone thinks that we don't need to accurately represent a WebCrypto Key in JWK then can bring it up now 03:18:21 q? 03:18:54 virginie: We can definitely close this topic and switch to topic of Key Discovery API 03:19:01 TOPIC: Key Discovery API 03:19:30 hhalpin has joined #crypto 03:19:57 csjung has joined #crypto 03:19:58 Mark Watson: The API has not changed, just 1 issue with the text (add API for discovering the names) 03:20:18 Virginie: There are no outstanding issues, just this one new request that we are about to discuss 03:22:46 MichaelH: The intent here is there is a mechanism by which we can have a "data concentrator" which has access to the internet which has subordinate devices which don't have access to the internet. Example: Home automation system. Device controller is a UA talking to the internet via a ???. Each device has a key-pair. When the service provider needs to update 03:22:46 it will quiz the concentrator to say what keys have certificates that I can use. Those certificates are identified by a "GetKey" function which will return only keys that match the certificate origin. 03:23:05 s/???/PLC 03:23:46 q+ 03:23:48 rsleevi: I feel like this is changing the API to meet a particular usecase 03:24:29 rsleevi: What about a "GetKeyByID" mechanism instead 03:24:39 MarkW: Doesn't know what the IDs are 03:24:46 q+ 03:25:01 rsleevi: the whole idea of named keys is the server can ask the UA 03:25:35 Takahiro has joined #crypto 03:25:35 .. in this particular home automation device... can assign unique device IDs to light switch 1 etc.. 03:25:46 So he wants a GetKey by origin essentially? 03:25:48 ... getKeyByDevice(0) 03:26:09 clarification to eroman: 03:26:13 getKeyById("device0") 03:26:33 getKeyByName("device0"), getKeyByName("device1") 03:26:52 q+ 03:27:22 @vgb: You have to get the Key object first; pre-provisioning IDB isn't (yet) supported, which is why we have named key discovery to begin with 03:27:47 MarkW: Just to fix some of the context things... It is getkeybyname not getkeyby id. The idea is these have an ID and a name. The name is pre-provisioned thing that identifies this key among a small number of keys that were bound to the device is our use case. So you have this notion of factory pre-provisioning a device with particular keys for the origin. 03:27:47 i.e. key1, key2, or whatever we decide to call them. and then they have IDs that identify the keys among all the devices. and then there was this idea of what if i don't know the names. we didn't have a use case where we didn't know the names. this is a use case that was brought up. 03:28:00 q- 03:28:34 rsleevi: could an implementation do that on its own and still be compliant with the spec? 03:28:34 .. Ryan is right you could have these names dynamically allocated from a known set (device0, device1 and so on). we might decide this is awkward because next time you reboot the device they may have all changed around. this is awkard. 03:29:07 ... maybe the key is associated to something completely different like a person. we have agreed this is out of scope for version 1. 03:29:51 ... the API proposed is pretty simple. so if we decide to support this use case shouldn't be too complicated. however we would have to think about the privacy considerations. 03:30:11