18:45:52 <RRSAgent> RRSAgent has joined #crypto
18:45:52 <RRSAgent> logging to http://www.w3.org/2012/06/04-crypto-irc
18:46:31 <virginie_galindo> +agenda 1- Welcome 
18:46:48 <virginie_galindo> +agenda Welcome 
18:48:45 <virginie_galindo> agenda+ Welcome
18:49:10 <virginie_galindo> agenda+ Survey about Web Crypto API use cases and features 
18:49:36 <virginie_galindo> agenda+ Draft API technical discussion 
18:50:08 <virginie_galindo> agenda+ Group Life (F2F, liaison)
18:52:59 <asad> asad has joined #crypto
18:53:43 <emily> emily has joined #crypto
18:54:27 <jmdacruz> jmdacruz has joined #crypto
18:58:55 <wseltzer> Callers, please stand by. We're working on the dial-in bridge.
18:59:09 <JimD> I was just about to ask.  Thanks.
19:00:02 <wtc> wtc has joined #crypto
19:00:32 <rbarnes> rbarnes has joined #crypto
19:00:51 <rbarnes> telephone bridge isn't letting me in, "code invalid"
19:01:33 <virginie_galindo> hi all, wendy is working on the bridge, to let us all enter
19:01:37 <wseltzer> Our usual bridge is down.  Please use code 1932 (1WEB) instead.
19:01:39 <jmdacruz> same here
19:02:09 <wseltzer> wseltzer has changed the topic to: WebCrypto WG: Conference Code 1932 (1WEB)
19:02:20 <christopherkula> christopherkula has joined #crypto
19:03:05 <wseltzer> zakim, code?
19:03:05 <Zakim> the conference code is 1932 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), wseltzer
19:03:14 <Zakim> +[Microsoft]
19:03:19 <MitchZ> MitchZ has joined #crypto
19:03:26 <Zakim> - +1.512.257.aabb
19:03:46 <Karen> Karen has joined #crypto
19:03:46 <markw> markw has joined #crypto
19:03:50 <sdurbha> sdurbha has joined #crypto
19:04:05 <Zakim> +ddahl
19:04:08 <vgb> vgb has joined #crypto
19:04:15 <ddahl> hello
19:04:36 <emily> virginie: just letting you know, I'll have to leave after about 30 mins today
19:04:45 <vgb> hi, is anyone else having trouble with the passcode on the phone call?
19:04:51 <Zakim> + +1.512.257.aaff
19:04:55 <ddahl> vgb: code is now 1932
19:05:06 <Zakim> + +1.408.540.aagg
19:05:13 <Zakim> +christopherkula
19:05:21 <markw> Zakim, aagg is Netflix
19:05:21 <Zakim> +Netflix; got it
19:05:25 <Zakim> +[Microsoft.a]
19:05:40 <Zakim> +??P21
19:05:45 <Zakim> +??P24
19:05:57 <rbarnes> zakim who is on the line?
19:06:12 <Zakim> + +1.650.214.aahh
19:06:13 <sdurbha> I think ??P21 is me
19:06:26 <rbarnes> zakim, who is on the phone?
19:06:26 <Zakim> On the phone I see +1.203.436.aaaa, +1.703.284.aacc, +54541320aadd, emily, JimD, +33.6.13.23.aaee, [Microsoft], ddahl, +1.512.257.aaff, Netflix, christopherkula, [Microsoft.a],
19:06:29 <Zakim> ... ??P21, ??P24, +1.650.214.aahh
19:06:33 <rbarnes> zakim, I am aacc
19:06:33 <Zakim> +rbarnes; got it
19:06:43 <rbarnes> zakim, who is on the phone?
19:06:43 <Zakim> On the phone I see +1.203.436.aaaa, rbarnes, +54541320aadd, emily, JimD, +33.6.13.23.aaee, [Microsoft], ddahl, +1.512.257.aaff, Netflix, christopherkula, [Microsoft.a], ??P21,
19:06:46 <Zakim> ... ??P24, +1.650.214.aahh
19:06:52 <wseltzer> zakim, aaaa is wseltzer
19:06:53 <Zakim> +wseltzer; got it
19:06:54 <wtc> zakim aahh is Google
19:07:01 <vgb> Zakinm, [Microsoft.a] is me
19:07:06 <vgb> Zakim, [Microsoft.a] is me
19:07:06 <Zakim> +vgb; got it
19:07:11 <jmdacruz> zakim, aadd is Intel
19:07:11 <Zakim> +Intel; got it
19:07:15 <virginie_galindo> Zakim aaee is virginie_galindo
19:07:23 <sdurbha> Zakim, ??P21 is sdurbha
19:07:23 <Zakim> +sdurbha; got it
19:07:41 <wseltzer> Note to callers, our usual bridge is down.  Please use code 1932 (1WEB) instead.
19:07:53 <wseltzer> zakim, who is on the call?
19:07:53 <Zakim> On the phone I see wseltzer, rbarnes, Intel, emily, JimD, +33.6.13.23.aaee, [Microsoft], ddahl, +1.512.257.aaff, Netflix, christopherkula, vgb, sdurbha, ??P24, +1.650.214.aahh
19:08:04 <wtc> Zakim: aahh is Google
19:08:08 <wseltzer> zakim, aaee is virginie_galindo 
19:08:08 <Zakim> +virginie_galindo; got it
19:08:18 <crypto> crypto has joined #crypto
19:08:27 <virginie_galindo> Zakim:aaee is virginie_galindo
19:08:31 <wseltzer> zakim, aaff is Gemalto
19:08:31 <Zakim> +Gemalto; got it
19:08:41 <wseltzer> zakim, Gemalto has Asad and Karen
19:08:41 <Zakim> +Asad, Karen; got it
19:08:56 <wseltzer> zakim, aahh is Google
19:08:56 <Zakim> +Google; got it
19:09:04 <wseltzer> zakim, who is on the call?
19:09:04 <Zakim> On the phone I see wseltzer, rbarnes, Intel, emily, JimD, virginie_galindo, [Microsoft], ddahl, Gemalto, Netflix, christopherkula, vgb, sdurbha, ??P24, Google
19:09:07 <Zakim> Gemalto has Asad, Karen
19:09:09 <rsleevi> rsleevi has joined #crypto
19:11:24 <wseltzer> agenda?
19:12:03 <wseltzer> scribenick: wtc
19:12:14 <wseltzer> scribe: wtc
19:12:34 <wseltzer> Meeting: WebCrypto WG Call, June 4
19:12:40 <wseltzer> Chair: Virginie_Galindo
19:13:12 <wtc> virginie_galindo: survey, technical discussions of draft API, and group life, 20 minutes on each topic.
19:13:53 <wtc> virginie_galindo: Dutch Telecom is a new group member.
19:14:21 <virginie_galindo> http://www.w3.org/2012/05/21-crypto-minutes.html
19:15:09 <wseltzer> zakim, close this agendum
19:15:09 <Zakim> agendum 3 closed
19:15:10 <Zakim> I see 3 items remaining on the agenda; the next one is
19:15:10 <Zakim> 1. Welcome [from virginie_galindo]
19:15:16 <wseltzer> zakim, take up agendum 2
19:15:16 <Zakim> agendum 2. "Survey about Web Crypto API use cases and features" taken up [from virginie_galindo]
19:15:33 <rbarnes> where can we see the answers?
19:15:43 <wtc> virginie_galindo: we have received 36 answers to the survey.
19:16:14 <rsleevi> Google regretfully didn't submit a response in time - we were still collecting some internal responses, hopefully we'll be able to add more details following this call
19:16:26 <wtc> ddahl: I'm still analyzing the answers. I will send the entire result set to the mailing list.
19:17:09 <wtc> ddahl: we have received a lot of good info. It would be nice to give the raw data to everyone.
19:17:57 <wtc> virginie_galindo: I find it interesting that many people told us how they plan to use the API.
19:18:26 <wtc> virginie_galindo: people requested both high-level and low-level APIs. We will need to accomodate that.
19:18:47 <ddahl> let me know if you can access the summary and data here: https://docs.google.com/spreadsheet/gform?key=0Ah178LzElb1CdHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E&hl=en#chart
19:19:23 <wtc> ddahl: the link to the survey is https://docs.google.com/spreadsheet/gform?key=0Ah178LzElb1CdHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E&hl=en#chart
19:19:34 <rsleevi> ddahl: Attempting as sleevi@google.com indicates requesting access is necessary. Would it make more sense to bring this to the wiki?
19:20:24 <wtc> virginie_galindo: do the editors need help to analyze and summarize the responses?
19:21:08 <ddahl> rsleevi: sure. I can export a spreadsheet
19:21:42 <wseltzer> q+
19:22:09 <wtc> ddahl: a summary can be automatically generated by Google docs.  Need to figure out how to make that available.
19:23:01 <wseltzer> q-
19:23:21 <wtc> wseltzer: we started from primary features in the charter. We're using the survey to clarify the ambiguity, in particular around the secondary features and other questions.
19:23:22 <ddahl> rsleevi: does this link work? https://docs.google.com/spreadsheet/pub?key=0Ah178LzElb1CdHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E&output=html
19:23:32 <rsleevi> ddahl: Yes
19:23:51 <ddahl> ok, that is the raw data in a google docs spreadsheet
19:24:00 <wseltzer> zakim, take up agendum 3
19:24:00 <Zakim> agendum 3. "Draft API technical discussion" taken up [from virginie_galindo]
19:24:19 <wtc> virginie_galindo: moving on to the technical discussions on the draft API.
19:25:02 <wtc> virginie_galindo: is there any noticeable change in the update to the Editor's Draft?
19:25:34 <wtc> ddahl: I have very rough drafts of feature discovery API and algorithm identifiers in github.
19:25:42 <rsleevi> ddahl: +1 to w3c hg
19:25:47 <wtc> ddahl: I will send a link out to it.
19:26:33 <ddahl> Link to a "rough ideas" github: https://github.com/daviddahl/web-crypto-ideas
19:27:04 <ddahl> q+
19:27:10 <wtc> virginie_galindo asked wseltzer if it's fine to use an external tool such as github for collaborating on early rough drafts.
19:27:51 <wtc> ddahl: I am agnostic to the location of the repository. I used github simply because I'm familiar with it.
19:28:12 <ddahl> q-
19:29:05 <ddahl> I will add links in the README to the w3c sites/official repo
19:29:36 <wtc> ddahl: the link to the "rough ideas" github is: https://github.com/daviddahl/web-crypto-ideas
19:30:36 <wtc> virginie_galindo: two open issues from the last conference call: random number generation and the list of algorithms.
19:31:10 <wseltzer> [I will add these links to the group homepage]
19:31:29 <Karen> q
19:31:37 <Karen> q+
19:31:45 <rsleevi> q+
19:31:50 <vgb> q+
19:32:02 <wtc> virginie_galindo: question to the working group: if we use the random number generator from the HTML group, would you be happy with that?
19:32:40 <wtc> Karen: a crypto API doesn't seem complete without a random number generator.
19:33:02 <Zakim> + +46.7.02.69.aaii
19:33:37 <wtc> Karen: second, if we need a better RNG that what's provided by the OS or the HTML working group, such as one that's FIPS compliant, we should be able to do that.
19:35:52 <wtc> rsleevi: I'd like to first respond to Karen's comment. Nothing in the HTML RNG spec precludes the use of a FIPS-compliant RNG.
19:36:13 <asad> q+
19:36:25 <wseltzer> ack karen
19:36:29 <wseltzer> ack rsleevi 
19:36:57 <wseltzer> ack vgb
19:37:46 <wtc> rsleevi: I support having an RNG in the crypto API.  Perhaps the HTML RNG can point to the RNG in the crypto API in the future.
19:38:43 <Zakim> -emily
19:38:58 <wtc> vgb: how would a programmer know whether the RNG in the crypto API or in the HTML5 is cryptographically strong?
19:40:27 <wtc> asad: how would an application dictate that the random numbers be generated by the browser or delegated to a more secure element such as a smart card?
19:40:49 <wseltzer> ack asad
19:40:54 <rsleevi> vgb, asad: How would/could a web application trust any response it receives, given that the javascript is a hostile environment
19:41:01 <wtc> asad: the application should be able to specify their RNG requirements rather than relying on the decision made by the browser.
19:42:29 <saerd> saerd has joined #crypto
19:42:59 <wseltzer> virginie_galindo: hears demand for RNG in the crypto API
19:43:35 <Karen> q+
19:43:59 <wseltzer> wtc: the HTML5 RNG will be a strong random generator, don't need to deprecate (or duplicate) that
19:44:19 <vgb> q+
19:44:53 <wseltzer> ack Karen 
19:44:55 <wseltzer> ack vgb
19:45:02 <wtc> Karen: how would one prove a RNG is cryptographically strong?
19:45:36 <rsleevi> Karen: I think any FIPS compliance issue is entirely at the whim of the browser/implementation, and not something that the web application could guarantee
19:46:35 <rsleevi> q+
19:46:55 <wtc> virginie_galindo: there was a discussion of managing the keys by key identifiers (also known as "key isolation"), but not sure if we have reached a consensus.
19:47:32 <MitchZ> what does "keys by data" mean?
19:47:33 <wtc> rsleevi: if we support the use of secure elements such as smart cards, then opaque keys (using keys by key identifiers) are a must.
19:47:47 <ddahl> Karen: proving the strength of the RNG from content JS is basically not possible - this may be possible via some kind of additional browser features that via UI?UX you can signal to the user that the current RNG operation is strong and legitimate
19:47:59 <rsleevi> MitchZ: The raw key material
19:48:12 <MitchZ> q+
19:48:17 <sdurbha> q+
19:48:18 <wtc> rsleevi: passing the raw key bytes to functions would be the most flexible.
19:48:28 <rsleevi> wtc: passing the raw key bytes would be the /least/ flexible
19:48:29 <wseltzer> ack MitchZ 
19:48:55 <MitchZ> q-
19:48:59 <wseltzer> ack sdurbha 
19:49:20 <ddahl> rsleevi: how about an API to access specific key material via the ID if the key was generated with this in mind? 
19:49:27 <wtc> MitchZ: support rsleevi's opinion that managing the keys by identifiers would be the most flexible.
19:49:36 <ddahl> in which case you could then use the raw bytes
19:49:45 <rsleevi> ddahl: I don't believe accessing key material, by ID or not, is a use case that can be supported by secure elements
19:49:52 <ddahl> rsleevi: ok
19:49:54 <virginie_galindo> q+
19:50:01 <rsleevi> ddahl: The point of the secure elements is that the key bytes cannot be extracted :)
19:50:07 <vgb> q+
19:50:14 <ddahl> rsleevi: i just remember ekr saying we might need this functionality for certain operations
19:50:16 <wseltzer> ack virginie_galindo 
19:50:26 <wtc> sdurbha: I'd like to hear more about the security implications of making the raw key bytes available to JavaScript.
19:50:43 <ddahl> rsleevi: i would rather not have access to the raw material for 99% + of operations
19:50:50 <rsleevi> ddahl: Yes. My point is that you cannot ever implement opaque key with raw bytes, but you can implement raw byte keys with key IDs
19:51:10 <ddahl> rsleevi: ok, cool
19:51:11 <rsleevi> ddahl: So if you do need raw bytes, you /may/ be able to extract the raw bytes from a key id, but it's not a must
19:51:20 <wseltzer> q?
19:51:23 <MitchZ> +1: for 100% of our current key usage, we don't want the app to have any access
19:51:27 <ddahl> rsleevi ++
19:51:28 <wseltzer> ack vgb
19:51:43 <asad> q+
19:52:20 <sdurbha> q+
19:52:38 <wseltzer> ack next
19:53:07 <wtc> vgb: we can skip the key isolation discussion if we agree that there is a requirement for "using keys by key IDs".
19:53:38 <jmdacruz> q+
19:53:49 <wseltzer> ack next
19:53:57 <wtc> asad: making private or secret keys available to JS lose the nonrepudiation aspect of that.
19:55:08 <Karen> q+
19:55:13 <wseltzer> ack next
19:55:14 <rsleevi> sdurbha: I believe there is still a need for ACLs, potentially origin bound. This was discussed in the hierarchy of temporary, persistent, and high-value keys
19:55:20 <wtc> sdurbha: how to stop unauthorized use of a key identified by an identifier?  So rules for key use are still needed.
19:56:10 <wseltzer> ack next
19:56:11 <rsleevi> sdurbha: If there is an existing key with a key ID, it may be up to the browser to determine how to determine access. It may prompt the user (eg: similar to geolocation APIs), it may look at pre-defined origin rules, etc. So I don't think having a key identifier means all origins must be aware of that key identifier. This is especially important for privacy
19:56:46 <ddahl> the initial ideas were to bind most keys by ID and origin. However, this is limiting, so we might want to think about a smart way to optionally allow cross-domain key usage
19:56:54 <wtc> Karen: sometimes an application needs to extract a key, even from a secure element.
19:57:44 <wtc> Karen: for example, to improve performance.  But it must be done carefully, for example, it should be encrypted with a key encryption key and should be erased after use.
19:57:58 <Zakim> -Intel
19:58:21 <wtc> Karen: a key identifier/handle is not sufficient for the security of the API.
19:58:22 <rsleevi> ddahl: I see two types of key bindings we may wish to support. During key generation (when generated via an app), it may wish to enumerate the origins allowed access to that key. For pre-provisioned keys, they may be pre-provisioned with origins or prompt the user.
19:58:40 <rsleevi> q+
19:58:50 <virginie_galindo> q+
19:58:51 <wtc> Karen: so again the caller (an web app) needs to prove they are authorized to use the key.
19:58:56 <ddahl> rsleevi: yes, that does sound like a nice way to allow additional access
19:59:00 <sdurbha> q+
19:59:01 <ddahl> or rather usage
19:59:52 <wtc> Karen: this is especially important if the provider holds multiple keys that belong to more than one security domain, web site A should not be allowed to use a key that belongs to web site B.
20:00:06 <wseltzer> ack rsleevi 
20:00:35 <wseltzer> q- later virginie_galindo 
20:00:55 <wseltzer> q+ virginie_galindo 
20:01:03 <wtc> rsleevi: in the original editor's draft, keys are bound to the origin. This is likely to remain true.
20:01:25 <Zakim> -[Microsoft]
20:01:47 <wseltzer> ack next
20:02:23 <wtc> rsleevi: key identifiers may be bound to a particular origin, but we need to allow them to refer to a underlying key that can be shared.
20:02:32 <wseltzer> ack next
20:03:16 <wtc> virgine_galindo: consensue: managing keys by key IDs. consensus: managing keys by origin.
20:03:28 <Zakim> -vgb
20:03:54 <wtc> ddahl: I can propose something for key identifiers and key origin for the next conference call.
20:04:18 <rsleevi> q+
20:04:24 <wseltzer> ack rsleevi 
20:04:52 <wtc> virginie_galindo: I have a question about a "safe" and "unsafe" APIs mentioned on the mailing list.
20:05:18 <ddahl> I can see an API for key generation to look like: generateKeys("ALGORITHM_ID", ["mozilla.org", "google.com"])
20:07:06 <rsleevi> virginie_galindo: It's unfortunate without ekr and some of the proponents for 'safe' APIs on the call
20:07:35 <wtc> rsleevi: it seems more "security agile" for "API safety" to be enforced by the implementation as security threats evolve over time, rather than specifying it in the standard. 
20:08:02 <wseltzer> zakim, take up agendum 4
20:08:02 <Zakim> agendum 4. "Group Life (F2F, liaison)" taken up [from virginie_galindo]
20:08:13 <wtc> virginie_galindo: moving on to the fourth item, group life. F2F meeting.
20:08:19 <Zakim> -rbarnes
20:09:05 <wtc> virginie_galindo: possible dates for F2F meeting are 23-24 July and 16-17 August.
20:09:30 <wseltzer> q+
20:10:14 <wseltzer> ack wseltzer 
20:10:35 <wtc> wseltzer: I suggest announcing the two candidate dates on the mailing list. Should finalize it as soon as possible.
20:11:49 <wseltzer> virginie_galindo: Anyone not planning to attend TPAC in Lyons?
20:11:55 <wseltzer> s/Lyons/Lyon/
20:11:59 <wtc> virginie_galindo: the next F2F meeting will be during TPAC in Lyon.
20:12:28 <wtc> virginie_galindo: we can meet with the Web Security and Web Apps WGs at TPAC.
20:12:43 <asad> q+
20:13:21 <wtc> virginie_galindo: please let me know if there is any IETF group we should liaise with.
20:13:39 <wtc> virginie_galindo: the location of the first F2F meeting will be in the Americas.
20:13:54 <wtc> ddahl: we are considering Vancouver, BC, Canada.
20:14:27 <wtc> virginie_galindo: the reason for Vancouver is that the IETF will meet in the following week.
20:15:20 <wtc> virginie_galindo: please look at github for the feature discovery and algorithm identifiers.
20:15:42 <wtc> virginie_galindo: we have discussed key identifiers and relation to the same origin policy.
20:16:00 <wtc> virginie_galindo: next week we'll look at the results of the survey.
20:16:29 <wtc> virginie_galindo: next call will be in seven days at the same time.
20:16:37 <wtc> wseltzer: this will be our regular time.
20:16:41 <Zakim> -??P24
20:16:42 <Zakim> -sdurbha
20:16:43 <Zakim> -ddahl
20:16:43 <Zakim> -Samuel
20:16:44 <Zakim> -Gemalto
20:16:44 <Zakim> -Netflix
20:16:45 <Zakim> -wseltzer
20:16:45 <Zakim> -Google
20:16:47 <Zakim> -virginie_galindo
20:16:54 <Zakim> -JimD
20:17:08 <Zakim> -christopherkula
20:17:10 <Zakim> Team_(admin)18:59Z has ended
20:17:10 <Zakim> Attendees were +1.203.436.aaaa, +1.512.257.aabb, +1.703.284.aacc, +54541320aadd, emily, JimD, +33.6.13.23.aaee, [Microsoft], ddahl, +1.512.257.aaff, +1.408.540.aagg,
20:17:10 <Zakim> ... christopherkula, Netflix, +1.650.214.aahh, rbarnes, wseltzer, vgb, Intel, sdurbha, virginie_galindo, Asad, Karen, wtc, rsleevi, +46.7.02.69.aaii, Samuel
20:17:12 <wseltzer> rrsagent, make minutes 
20:17:12 <RRSAgent> I have made the request to generate http://www.w3.org/2012/06/04-crypto-minutes.html wseltzer
20:17:19 <wseltzer> rrsagent, make logs public
20:17:20 <christopherkula> christopherkula has left #crypto
20:17:21 <rbarnes> rbarnes has left #crypto
20:17:33 <hooley> hooley has left #crypto
20:26:53 <virginie_galindo> virginie_galindo has left #crypto
21:55:54 <tl> tl has joined #crypto
22:18:53 <ddahl> ddahl has joined #crypto
23:30:38 <abstractj> abstractj has joined #crypto