20:06:48 <RRSAgent> RRSAgent has joined #crypto
20:06:48 <RRSAgent> logging to http://www.w3.org/2013/04/01-crypto-irc
20:06:50 <selfissued> selfissued has joined #crypto
20:06:50 <trackbot> RRSAgent, make logs public
20:06:50 <virginie> agenda?
20:06:50 <hhalpin> hhalpin has joined #crypto
20:06:52 <trackbot> Zakim, this will be SEC_WebCryp
20:06:53 <trackbot> Meeting: Web Cryptography Working Group Teleconference
20:06:53 <trackbot> Date: 01 April 2013
20:06:53 <Zakim> ok, trackbot, I see SEC_WebCryp()3:00PM already started
20:06:55 <selfissued> Mike Here
20:06:56 <wseltzer> chair: Virginie
20:07:21 <hhalpin> Zakim, who's on the phone?
20:07:21 <Zakim> On the phone I see nvdbleek (muted), rbarnes, [Microsoft], [Google], jyates, mountie, wseltzer, Virginie_Galindo, [Microsoft.a], Netflix, Michael_Hutchinson, ddahl, [Microsoft.aa],
20:07:24 <Zakim> ... arunranga (muted), Karen, [Microsoft.aaa]
20:07:24 <Zakim> [Google] has rsleevi
20:07:24 <Zakim> Netflix has markw, mitchz
20:07:24 <Zakim> [Microsoft] has Jason, Vijay, Tony, Mike_Jones
20:08:14 <selfissued> Virginie - confirmed the call agenda
20:08:31 <wseltzer> [agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0158.html ]
20:08:41 <wseltzer> scribenick: selfissued
20:08:50 <wseltzer> minutes: http://www.w3.org/2013/03/18-crypto-minutes.html
20:08:52 <nvdbleek> zakim, code?
20:08:52 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek
20:09:00 <wseltzer> s/minutes: /previous call minutes:/
20:09:07 <Zakim> + +31.61.877.aadd
20:09:16 <Zakim> +[IPcaller]
20:09:22 <wseltzer> zakim, aadd is nvdbleek
20:09:22 <Zakim> +nvdbleek; got it
20:09:23 <selfissued> Virginie - the minutes of the previous call are approved
20:09:24 <hhalpin> Zakim, [IPcaller] is hhal;pin
20:09:24 <Zakim> +hhal;pin; got it
20:09:29 <nvdbleek> zakim, I a +31
20:09:29 <Zakim> I don't understand 'I a +31', nvdbleek
20:09:37 <hhalpin> Zakim, hhal;pin is hhalpin
20:09:37 <Zakim> +hhalpin; got it
20:09:53 <rsleevi> Zakim, aadd is nvdbleek
20:09:55 <Zakim> sorry, rsleevi, I do not recognize a party named 'aadd'
20:10:23 <hhalpin> RESOLVED: http://www.w3.org/2013/03/18-crypto-minutes.html are the correct minutes from the previous meeting
20:10:44 <hhalpin> topic: low-level API
20:11:47 <selfissued> Ryan: Active discussions of low-level API issues are ongoing
20:11:53 <selfissued> ... Would like additional participation
20:12:14 <rbarnes> q+
20:12:23 <markw> q+
20:12:30 <selfissued> ... particularly on key wrapping proposal
20:12:36 <selfissued> ... also on default parameters
20:12:44 <virginie> q?
20:13:07 <rbarnes> ack
20:13:11 <rbarnes> ack rbarnes
20:13:51 <rsleevi> q+
20:14:00 <virginie> q+
20:14:07 <selfissued> Mark: We need forcing functions to actually close issues.
20:14:37 <selfissued> Ryan: Let's create issues and have them be focused
20:15:06 <selfissued> ... Our discussions have often been at too abstract a level
20:15:18 <virginie> q?
20:15:21 <markw> Let's discuss http://www.w3.org/2012/webcrypto/track/issues/12
20:15:21 <rsleevi> eg: Issue-37
20:16:08 <rsleevi> Can we first resolve the issues from our past calls?
20:16:17 <rsleevi> The ones we felt we were progressing to closing?
20:16:45 <virginie> http://www.w3.org/2012/webcrypto/track/
20:17:13 <markw> Can we just close Issue-37 - noone has mentioned any problems with the current names for ages
20:17:55 <selfissued> Virginie: Proposes that we make decisions on open issues during next F2F meeting
20:18:16 <selfissued> Mike: Agrees with this proposal
20:18:38 <selfissued> Virginie: Not all issues are related to the low-level API
20:18:59 <selfissued> ... We need to identify which ones the working group members need to look at
20:19:16 <markw> +1 to closing Issue-37
20:19:33 <rbarnes> +1 to closing ISSUE-37
20:20:16 <selfissued> Ryan: Many of these issues are historical and aren't closely related to the current drafts
20:20:30 <rsleevi> ISSUE-7?
20:20:30 <trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
20:20:30 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/7
20:20:33 <virginie> q?
20:20:41 <virginie> ack virginie
20:20:48 <rsleevi> ISSUE-17?
20:20:48 <trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open
20:20:48 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/17
20:21:07 <rsleevi> ISSUE-22?
20:21:07 <trackbot> ISSUE-22 -- Should CryptoOperations be clonable -- open
20:21:07 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/22
20:21:38 <rbarnes> +1 to resolving these historical issues
20:21:38 <hhalpin> Maybe the best way to go through this list quickly is just have a list of issues sent out over email with proposed resolutions, the we close them all out en masse next call.
20:21:51 <markw> +1 to closing ISSUE-17
20:21:57 <rsleevi> ISSUE-29?
20:21:57 <trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
20:21:57 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
20:22:01 <selfissued> Ryan: Agree with Mark that we need a forcing function to close issues
20:22:02 <rbarnes> hhalpin: that sounds like a fine idea
20:22:04 <rsleevi> ISSUE-30?
20:22:04 <trackbot> ISSUE-30 -- How does the application know where the key is stored ? -- open
20:22:04 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/30
20:22:06 <hhalpin> i.e. the forcing function should be next meeting and then if there's any objections to closing them, we finalize that at our f2f.
20:22:13 <rsleevi> ISSUE-31?
20:22:13 <trackbot> ISSUE-31 -- Problems with keys attribute of the Crypto interface -- open
20:22:13 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/31
20:22:22 <rsleevi> ISSUE-32?
20:22:22 <trackbot> ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open
20:22:22 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/32
20:22:26 <hhalpin> I do agree almost all of these should be closed.
20:22:32 <rsleevi> ISSUE-37?
20:22:32 <trackbot> ISSUE-37 -- Method naming -- open
20:22:32 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/37
20:22:52 <rsleevi> ISSUE-38?
20:22:52 <trackbot> ISSUE-38 -- Key initialization and "finalization" -- open
20:22:52 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
20:22:58 <rsleevi> ISSUE-40?
20:22:58 <trackbot> ISSUE-40 -- How should we define key discovery, noting asynchronicity -- open
20:22:58 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/40
20:23:07 <rsleevi> yes, lets talk bignum - but there's the quick list :)
20:24:18 <hhalpin> markw?
20:24:21 <rsleevi> the wrap/unwrap proposal is ISSUE-35
20:24:31 <selfissued> Virginie: Asked Mark for an update on the key wrap/unwrap draft
20:24:31 <hhalpin> maybe move to BigNum, markw doesn't seem to be here.
20:24:56 <selfissued> Mark: Updated draft on the wiki
20:25:05 <selfissued> ... Proposed responses to the open issues
20:25:23 <selfissued> ... Proposes to use JWE wrapping of JWK objects
20:26:04 <selfissued> ... Added sections on using using RSA-OAEP and and AES Key Wrap
20:26:23 <rsleevi> q+
20:26:29 <selfissued> q+
20:26:37 <Zakim> -Karen
20:26:40 <MichaelH> MichaelH has joined #CRYPTO
20:26:59 <nvdbleek> http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal
20:27:09 <markw> http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal
20:27:17 <virginie> q?
20:27:38 <rbarnes> q+
20:27:50 <selfissued> Ryan: What about key types that are not supported in JOSE?
20:28:00 <selfissued> ... There needs to be a JWK representation
20:28:22 <selfissued> ... Nervous about tight coupling to JOSE
20:28:31 <virginie> q?
20:28:36 <rsleevi> ack markw
20:28:39 <rsleevi> ack rsleevi
20:29:45 <rsleevi> I think the question would be for DSA
20:29:58 <rbarnes> rsleevi: WebCrypto doesn't have DSA
20:30:01 <rbarnes> question would be DH
20:30:38 <selfissued> Mike:  The JOSE WG agreed to put the private and symmetric key representations in the JWK sec
20:30:57 <selfissued> ... If there are other key types that need JWK representations, they should be written up
20:31:14 <selfissued> Richard: +1 Mike - there's agreement on how to represent keys
20:31:33 <selfissued> ... the continuing discussions are about how to best wrap those representations
20:32:11 <virginie> q?
20:32:12 <selfissued> ... Both groups learn productive things from one another
20:32:15 <rbarnes> ack rbarnes
20:32:25 <rbarnes> plus, webex is hosting the meeting, so we should have good remote participation :0
20:32:29 <rbarnes> :)
20:32:35 <rsleevi> @selfissued Sorry if I wasn't clearer: It was the representation of wrapped keys (eg: symmetric keys vs asymmetric keys as an example of the ongoing discussions)
20:32:54 <hhalpin> Zakim, who's making noise?
20:32:58 <rsleevi> ack selfissued
20:33:05 <Zakim> hhalpin, listening for 10 seconds I heard sound from the following: mountie (15%), [Microsoft.aaa] (8%)
20:34:55 <virginie> q?
20:35:14 <selfissued> Virginie: Now we will move to the bignum agenda item
20:36:30 <selfissued> Jason Mackey: Author of bignum proposal
20:36:41 <rbarnes> rsleevi: ABV makes sense for OAEP / AES-KW; i could see wrapKey/unwrapKey returning a serialized JSON object
20:36:51 <selfissued> ... Use cases: Several anonymous and blinded signature schemes
20:37:11 <selfissued> ... U-Prove, elliptic curve pairing, attribute based encryption
20:37:19 <rsleevi> @rbarnes: Not sure it makes since for OAEP/AES-KW, since you're still returning a JWE-wrapped JWK (as per Mark's proposal)
20:37:33 <selfissued> ... Generally the ability to implement non-standard stuff, such as Chinese algorithms, etc...
20:37:44 <selfissued> ... without having to revise the WebCrypto API itself
20:37:55 <selfissued> ... performance reason to not write this in JavaScript
20:38:09 <selfissued> ... JavaScript doesn't really have integers - just doubles
20:38:19 <rbarnes> rsleevi: ah, i was thinking that KW / OAEP could apply to encrypt/decrypt as well ...
20:38:30 <markw> @rsleevi The choice is serialized UTF-8 JSON objects returned in a ABV vs Javascript objects == IDL dictionary
20:38:42 <selfissued> ... Can only effectively use 16 bit integers in JavaScript
20:38:58 <virginie> Initial proposal by Microsoft : http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0029.html
20:38:59 <selfissued> ... Bit operations also not supported - also not efficient
20:39:08 <virginie> q?
20:39:11 <rsleevi> @markw: json.stringify(), avoid the weird base64 dot-encoding of JWE
20:39:19 <selfissued> ... Garbage collection in the JavaScript runtime can't be controlled
20:39:30 <selfissued> ... Not possible to ensure that key material has really been deleted
20:39:43 <rbarnes> rsleevi: +infinity
20:39:58 <rsleevi> @markw: It goes back to the "UTF8 is hard"
20:40:11 <rsleevi> q+
20:40:20 <markw> I don't see any problem returning a Javascript object - it would be the thing that when serialized produces the JWE JSON Serialization
20:40:38 <selfissued> ... Bignum support not likely to be added to JavaScript language
20:41:00 <selfissued> ... Also, if added, it would likely be general-purpose - not optimized for crypto
20:41:05 <markw> someone mentioned canonicalization problems, but I don't think they apply since there's nothing calculated over the JSON serialization (which itself has no canonical version), AFAIK
20:41:32 <hhalpin> q+
20:41:33 <selfissued> ... Significant optimizations are possible by crypto-focused bignum operations
20:41:43 <rbarnes> markw: that's correct, the canonicalization issue was raised by someone who wanted to do JWK key fingerprints
20:42:15 <selfissued> ... Three pieces: High-level helper functions, integer group object, elliptic curve object
20:42:19 <hhalpin> My question will be 1) are these primitives more or less uniformly supported across different operating systems and 2) what's the reactions from other browser vendors?
20:42:36 <selfissued> ... Tried to be clear which functions are required and which are optional
20:42:46 <rsleevi> q?
20:42:50 <rbarnes> q+
20:42:56 <selfissued> ... For instance, divide-by-2 operation is not essential, but provides efficiencies
20:43:10 <rbarnes> q-
20:43:15 <selfissued> q+
20:43:37 <selfissued> Ryan: Discussed in-house in Google - a lot of opposition
20:44:03 <selfissued> ... Want good definitions of use cases for the bignum work
20:44:17 <vgb> @rsleevi,markw regarding JSON-encoding JWE - are you saying we would define field names for the 4-5 parts that are now dot-separated? Some existing ciphertext fields don't have names in the JWE drafts.
20:44:56 <selfissued> On the other thread - JOSE also decided to add JSON Serializations to the JWS and JWE drafts
20:45:14 <vgb> i see - those are being defined now?
20:45:24 <markw> @vgb: JOSE have already defined a JSON serialization which puts the 5 parts into a JSON object, instead of dot-separated
20:45:24 <selfissued> Ryan: Support for using value proxies
20:45:37 <selfissued> ... Mozilla has implemented them as a proof of concept
20:45:44 <vgb> @selfissued,markw thanks for the update
20:45:46 <markw> http://self-issued.info/docs/draft-jones-jose-jwe-json-serialization-02.html
20:46:04 <selfissued> ... Value proxies are a robust way to extend JavaScript
20:46:27 <selfissued> ... Concern about constant conversion between internal and external representations
20:46:27 <virginie> q?
20:46:53 <selfissued> ... A big gap for multiplicative subgroups
20:47:06 <selfissued> ... Supportive of the goals, but need a clear set of objective
20:47:23 <rbarnes> vgb: some of us are also trying to make the JOSE JSON format more JSON, less base64
20:47:49 <selfissued> ... Will try to put the remarks together on the list
20:48:31 <rsleevi> http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies
20:48:45 <selfissued> Harry: Question: Are these primitives uniformly implemented?
20:48:50 <arunranga> q+
20:48:52 <rsleevi> No, the primitives are not widely exposed at all. MPI is almost always seen as part of the crypto boundary and entirely opaque
20:49:02 <rsleevi> ack rsleevi
20:49:07 <rsleevi> ack hhalpin
20:49:25 <hhalpin> And in particular, given the goal is that uniformity across browsers is importance, I'd like to hear Mozilla.
20:49:28 <selfissued> ... What is the feedback from other browser vendors?
20:49:28 <arunranga> zakim, unmute me
20:49:28 <Zakim> arunranga should no longer be muted
20:49:54 <selfissued> Mike: bignum useful for Korean national algorithms
20:50:26 <selfissued> Vijay: There isn't a strong use case from Browser ID - discussed with Ben Adida
20:50:32 <hhalpin> I can see blind signatures being within scope in general, but we'd really need to clarify the use-cases
20:50:46 <selfissued> ... Could also do Browser ID without bignum
20:50:52 <vgb> s/Vijay/ArunRanga/
20:50:54 <ddahl> arunranga: +1
20:51:02 <rbarnes> arunranga: +1
20:51:21 <selfissued> Arun: Wants to double down on getting the low-level API right
20:52:17 <selfissued> Ryan: Getting push-back from several sources in Google
20:52:44 <selfissued> ... Bignum APIs tend to be buried in crypto API implementations and not exposed
20:52:49 <selfissued> ... Not exposed in NSS
20:52:53 <virginie> q?
20:52:58 <arunranga> q-
20:53:02 <virginie> ack selfissued
20:53:03 <arunranga> Zakim, mute me
20:53:03 <Zakim> arunranga should now be muted
20:53:11 <rsleevi> Nope
20:53:18 <hhalpin> Is there a way to address the use-cases on a higher-level than a generic BigNum that works with NSS?
20:53:21 <rsleevi> q+
20:53:23 <selfissued> Jason: Ryan seems worried that people would misuse this or use it wrog
20:53:27 <hhalpin> (i.e. blind signatures use-cases)
20:53:38 <selfissued> ... Concern valid for any kinds of crypto APIs
20:54:04 <selfissued> ... bignum enabling technology for advancing crypto functions in browsers
20:54:25 <selfissued> ... Allows experts to build crypto libraries that perform well in the browser
20:54:45 <selfissued> ... Easy with native code, but impossible with only access to current JavaScript APIs
20:55:18 <selfissued> ... Eventual JavaScript support for 32 and 64 bit integers are a start, but don't complete the picture
20:55:56 <arunranga> I'm not totally sure the "startlingly slow" critique is spot on.
20:56:05 <selfissued> ... To Ryan: This wasn't meant to be the final draft of the API.  If there's a problem, let's address it.
20:56:35 <arunranga> hhalpin, impossible to hear.
20:56:48 <rsleevi> q?
20:56:56 <arunranga> hhalpin's question about "universally implemented" had to do with the underlying operating systems.
20:57:24 <hhalpin> is it true or not re NSS and the underlying operating systems as regards these proposed BigNum primitives?
20:57:33 <selfissued> Ryan: I think my points were misunderstood - we can continue discussion on the mailing list
20:57:43 <arunranga> I hope Jason does attend.
20:57:46 <selfissued> Virgine: F2F meeting planning
20:57:52 <selfissued> ... Asked Jason to attend
20:58:03 <rsleevi> @hhalpin: NSS, GnuTLS, and OpenSSL all treat their bignum implementations as internal APIs, *not* part of the public API and with no statements of portability or the like
20:58:32 <rsleevi> @hhalpin: From the start, the goal was to *not* bring the JS engine into the cryptographic boundary
20:58:38 <rsleevi> which this would
20:59:13 <selfissued> ... Would like to not make low-level and high-level APIs at risk by adding bignum work
20:59:32 <selfissued> ... Wants to continue bignum discussions on the list
20:59:43 <selfissued> Virginie: Please register for the F2F meeting
20:59:48 <selfissued> ... Will send a draft agenda too
20:59:58 <selfissued> ... Goal to close as many low-level API issues as possible
21:00:06 <selfissued> ... together with key discovery API
21:00:31 <selfissued> ... Don't have clear use cases for high-level API
21:00:52 <selfissued> ... One proposal to spend two hours of our meeting on the high-level API, in part to work on use cases
21:01:01 <selfissued> ... Possibly make it open to non-WG members
21:01:32 <arunranga> rsleevi, can we induce slightlylate to attend the "public" part of the meeting?
21:02:05 <arunranga> ^^slightlyoff
21:02:19 <rbarnes> if we do a public part, we might want to start with a brief tutorial on the current API, e.g., a walk-through of http://demo.polycrypt.net/hello/
21:02:21 <selfissued> ... Wants to understand pepole's priorities for use of time at the meeting
21:02:33 <selfissued> ... Next call will be one week before the F2F meeting in two weeks
21:02:49 <hhalpin> I can chair, no problem
21:02:56 <wseltzer> q+
21:03:11 <hhalpin> Do we want to keep 20:00 UTC or go to 19:00 UTC?
21:03:19 <hhalpin> Mountie?
21:03:28 <mountie> 20:00 UTC is better
21:03:28 <selfissued> Virginie proposes to have the call an hour earlier
21:03:36 <selfissued> +1 to moving to 19:00 UTC
21:03:41 <vgb> +1
21:03:42 <hhalpin> I'm OK with either.
21:03:43 <virginie> +1
21:03:45 <ddahl> either
21:03:46 <selfissued> (this would be Noon pacific)
21:03:49 <nvdbleek> +1 to moving to 19:00 UTC
21:03:51 <mountie> -1 for 19:00 UTC
21:03:51 <rbarnes> either
21:03:51 <MichaelH> +1
21:03:54 <rsleevi> +1 to 19:00
21:04:01 <arunranga> either
21:04:02 <jyates> either
21:04:06 <hhalpin> I am noticing that we would make the life much harder to for folks in Korea.
21:04:38 <hhalpin> Given that we still have the Korean banking use-case on the table, it makes sense to keep to 20:00
21:04:48 <wseltzer> ack ws
21:04:57 <rsleevi> ack me
21:05:08 <selfissued> Virginie:  We will not be changing the time, at least for the next call, as it would be very difficult in Asia
21:05:31 <hhalpin> I would be interested in hearing in more detail re Korean banking use case and the BigNum proposal, that was kinda unclear
21:05:33 <Zakim> -[Google]
21:05:34 <Zakim> -[Microsoft]
21:05:43 <Zakim> -jyates
21:05:46 <Zakim> -Netflix
21:05:46 <Zakim> -ddahl
21:05:46 <Zakim> -mountie
21:05:46 <Zakim> -wseltzer
21:05:46 <Zakim> -rbarnes
21:05:46 <Zakim> -Virginie_Galindo
21:05:46 <Zakim> -[Microsoft.aa]
21:05:48 <Zakim> -nvdbleek.a
21:05:48 <Zakim> -[Microsoft.aaa]
21:05:51 <wseltzer> trackbot, end teleconf
21:05:51 <trackbot> Zakim, list attendees
21:05:51 <Zakim> As of this point the attendees have been markw, nvdbleek, hhalpin, +1.202.596.aaaa, rbarnes, rsleevi, jyates, +82.22.14.0.aabb, mountie, wseltzer, Virginie_Galindo,
21:05:55 <Zakim> ... +1.512.257.aacc, mitchz, Michael_Hutchinson, ddahl, arunranga, Karen, Jason, Vijay, Tony, Mike_Jones, +31.61.877.aadd
21:05:59 <Zakim> -[Microsoft.a]
21:05:59 <trackbot> RRSAgent, please draft minutes
21:05:59 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/01-crypto-minutes.html trackbot
21:06:00 <trackbot> RRSAgent, bye
21:06:00 <RRSAgent> I see no action items
21:06:01 <Zakim> -hhalpin