07:39:05 <RRSAgent> RRSAgent has joined #crypto
07:39:05 <RRSAgent> logging to http://www.w3.org/2012/11/02-crypto-irc
07:39:07 <trackbot> RRSAgent, make logs public
07:39:09 <trackbot> Zakim, this will be SEC_WebCryp
07:39:09 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
07:39:10 <trackbot> Meeting: Web Cryptography Working Group Teleconference
07:39:10 <trackbot> Date: 02 November 2012
07:39:17 <wseltzer> Chair: Virginie Galindo
07:39:43 <mountie> mountie has joined #crypto
07:40:18 <selfissued> selfissued has joined #crypto
07:41:02 <jin> jin has joined #crypto
07:42:07 <opoto> opoto has joined #crypto
07:42:46 <sangrae> sangrae has joined #crypto
07:42:59 <rsleevi> agenda+ High level API
07:43:11 <rsleevi> agenda+ Global Unique Identifier (Mark)
07:43:15 <kotakagi> kotakagi has joined #crypto
07:43:52 <rsleevi> agenda+ WebAppSec joint session
07:44:00 <rsleevi> angeda+ Korean use case demo
07:44:07 <rsleevi> agenda+ Korean use case demo
07:44:07 <rbarnes> rbarnes has joined #crypto
07:44:15 <rsleevi> agenda+ Security framework
07:44:16 <rbarnes> bonjour!
07:44:17 <rsleevi> agenda?
07:44:27 <rsleevi> Zakim, close agenda 1
07:44:27 <Zakim> agendum 1, status, closed
07:44:28 <Zakim> I see 9 items remaining on the agenda; the next one is
07:44:28 <Zakim> 2. usability [from hhalpin]
07:44:29 <rsleevi> Zakim, close agenda 2
07:44:30 <Zakim> agendum 2, usability, closed
07:44:30 <Zakim> I see 8 items remaining on the agenda; the next one is
07:44:30 <Zakim> 3. keyformat [from hhalpin]
07:44:31 <rsleevi> Zakim, close agenda 3
07:44:31 <Zakim> agendum 3, keyformat, closed
07:44:31 <Zakim> I see 7 items remaining on the agenda; the next one is
07:44:31 <Zakim> 4. implementations [from hhalpin]
07:44:33 <rsleevi> Zakim, close agenda 4
07:44:33 <Zakim> agendum 4, implementations, closed
07:44:34 <Zakim> I see 6 items remaining on the agenda; the next one is
07:44:34 <Zakim> 5. usecases [from hhalpin]
07:44:34 <rsleevi> Zakim, close agenda 5
07:44:35 <Zakim> agendum 5, usecases, closed
07:44:35 <Zakim> I see 5 items remaining on the agenda; the next one is
07:44:35 <Zakim> 6. High level API [from rsleevi]
07:44:42 <rsleevi> agenda?
07:45:03 <rsleevi> topic: Agenda bashing and review
07:45:06 <ddahl> ddahl has joined #crypto
07:45:14 <rsleevi> scribe: Ryan_Sleevi
07:45:17 <rsleevi> scribenick: rsleevi
07:45:29 <drogersuk> drogersuk has joined #crypto
07:45:40 <rsleevi> Reviewing http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012
07:46:03 <rsleevi> Topic: High level API
07:46:30 <rsleevi> virginie: Lots of different views on what "high level" means, depending on peoples' backgrounds
07:46:38 <rsleevi> ... need to come to a common definition/understanding of what a high level API means
07:47:51 <rsleevi> ddahl: Demo'd an API called DOMCrypt at TPAC last year
07:48:01 <rsleevi> ... wanted to put well-designed crypto in the hands of people who don't know crypto
07:48:22 <rsleevi> ... talking to Brendan Eich, mentioned "You're handing people a gun, a footgun"
07:48:30 <rsleevi> ... high level, low level, both still fairly dangerous
07:48:31 <sangrae> sangrae has joined #crypto
07:48:47 <rsleevi> ... even a low level API tends to be an API wrapped in an API wrapped in an API wrapped in an API
07:48:49 <virginie> virginie has joined #crypto
07:48:55 <wtc> wtc has joined #crypto
07:49:11 <rsleevi> ... question as to whether the original API was low level or high-level
07:49:26 <sburr> sburr has joined #crypto
07:50:30 <rsleevi> [ ddahl presenting an IDL ]
07:50:37 <rsleevi> ddahl: always wanted something high level
07:51:01 <rsleevi> ... looking over feedback from community, lots of people asking "Where is the new crypto? The webby crypto? The API for web developers"
07:51:12 <rsleevi> ... the low-level API is not necessarily that, very difficult to approach if not versed in crypto
07:51:49 <rsleevi> ... lots of time going back and forth with rsleevi on outlets like hacker news engaging community
07:52:02 <rsleevi> ... discussions with other Mozilla people, "no reason you cant do both" - a high level and low level
07:52:28 <rsleevi> ... take something that just has a few methods, use JOSE for all inputs and outputs
07:52:34 <rsleevi> ... hopefully end up with something that's pretty easy to use
07:52:48 <rsleevi> ... very little choices for developers
07:52:56 <rsleevi> ... will not suffice for most use cases in this group
07:53:06 <rsleevi> ... but will give developers of new applications good crypto
07:53:14 <rsleevi> ... no concerns for legacy/backwards compatibility
07:53:25 <rsleevi> ... entirely domain bound (same origin policy)
07:53:43 <Ruinan> Ruinan has joined #crypto
07:53:44 <rsleevi> ... methods such as "encryptAndSign" or "verifyAndDecrypt"
07:54:26 <Ruinan> Ruinan has left #crypto
07:54:33 <rsleevi> ... keys are mostly pairs, identified by an id
07:54:40 <rsleevi> ... mostly event driven
07:55:28 <rsleevi> [ demo-ing example JS for this API ]
07:57:42 <rsleevi> ddahl: The whole concept is to make it as idiot proof as possible
07:57:51 <rsleevi> ... sort of an introductory concept
07:58:18 <mountie> q+
07:58:19 <rbarnes> q?
07:58:20 <rsleevi> ... want to investigate looking at perhaps two tracks
07:58:29 <selfissued> q+
07:58:41 <hhalpin> hhalpin has joined #crypto
07:58:51 <rsleevi> q+
07:58:55 <hhalpin> q+
07:59:02 <rsleevi> virginie: Is it too early for technical details and discussion?
07:59:12 <rsleevi> virginie: WG needs to decide if it wants to engage/work on this
07:59:28 <rsleevi> ... question is whether WG feels it will detract from work on low-level API
07:59:40 <cjkula> cjkula has joined #crypto
07:59:47 <rsleevi> ... do we need to re-design proposal, now that we have a proposal, based on use cases?
08:00:05 <rsleevi> ... want to get comments in that sense
08:00:30 <rsleevi> q?
08:00:37 <rsleevi> ack mountie
08:00:59 <rsleevi> mountie: when we look at the documents in the WG, we can see the secondary features
08:01:11 <rsleevi> ... and high level API is in secondary
08:01:27 <rsleevi> ... some interest in high-level APIs, but some interest in other secondary features
08:01:39 <rsleevi> ... wasn't sure the distinction between secondary features and if they were part of the high level API
08:02:35 <rsleevi> ... current JS mechanism is not ideal for non-unicode encoding (eg: shift-jis)
08:02:56 <rsleevi> ... how will encrypt work and concerns about page encodings
08:02:59 <rsleevi> ack selfissued
08:03:08 <kotakagi> kotakagi has joined #crypto
08:03:30 <rsleevi> selfissued: To the extent of a high level, we should make sure not to go create new formats
08:03:45 <rsleevi> ... if we do something at the high level, we should look at produce and consuming JOSE data formats
08:03:54 <rsleevi> ddahl: Sort of thought JOSE was assumed here
08:04:01 <rsleevi> selfissued: Would be important to state it in the proposal
08:04:11 <rsleevi> ddahl: The work going on in JOSE paves the way for this
08:04:24 <markw> markw has joined #crypto
08:04:27 <rbarnes> q+
08:04:34 <rsleevi> selfissued: Curious why all APIs use public keys, but not symmetric keys
08:04:39 <rsleevi> ddahl: Not designed yet
08:04:43 <rsleevi> ack rsleevi
08:06:12 <rsleevi> rsleevi: Existing platform APIs tend to be just two APIs (protect and unprotect)
08:06:19 <rsleevi> rsleevi: mentioned OS X Keychain APIs, windows DPAPI
08:06:37 <virginie> q?
08:06:42 <virginie> q+
08:06:43 <rsleevi> rsleevi: wanting to understand the design rationale for this API (encryptAndSign/decryptAndVerify) as opposed to something called just "box" and "unbox"
08:06:47 <rbarnes> q-
08:06:51 <hhalpin> ack hhalpin
08:07:10 <rsleevi> hhalpin: Not a full proposal yet. Possibly still not high-level enough. Considered "box" and "unbox"
08:07:18 <rsleevi> s/hhalpin/ddahl/
08:07:18 <drogersuk> q+
08:07:38 <rsleevi> hhalpin: clarification: high-level and low-level API are different than the primary/secondary features
08:07:46 <rsleevi> hhalpin: That is, high-level API does not necessarily mean secondary features
08:08:06 <rsleevi> hhalpin: concerned that we're still not down with the low-level API that covers all the primary features
08:08:20 <rsleevi> ... spending 3-4 months discussing high-level API, that's 3-4 months less spent discussing low-level API
08:08:29 <jin> jin has joined #crypto
08:08:29 <rsleevi> ... on a scheduling level, there's 2-3 important questions
08:08:32 <rsleevi> ... Do we have enough time?
08:08:37 <rsleevi> ... Do we have agreement on a draft?
08:08:44 <rsleevi> ... Do we have agreement on what a high-level API should be?
08:09:09 <mountie> q+
08:09:10 <rsleevi> ... If we do have time, and we should do it, do we do it as one draft put out in time for our next heartbeat publication, or do we do it after we've published a new low-level API
08:09:12 <selfissued> q+
08:09:36 <rsleevi> ... Do you (ddahl) feel confident enough that you can put it into a draft quickly
08:10:06 <rsleevi> ddahl: Not quite happy with the API as being proposed. Other APIs we can crib from (mention Nacl's box/unbox).
08:10:17 <rsleevi> ... Think we can come up with something quickly, using JOSE for formats
08:10:20 <virginie> q-
08:10:36 <rsleevi> ... as far opinions about scheduling, switching contexts, etc, would want more opinions from WG
08:10:41 <rsleevi> ... personally holding out for a high-level API
08:10:51 <rsleevi> ... trying to integrate and address feedback/criticism from public
08:11:08 <rsleevi> ack drogersuk
08:11:14 <rsleevi> drogers: I think there is an argument for the API
08:11:39 <rsleevi> ... discussing recent papers/security research that came out in the past few weeks regarding crypto being hard
08:11:49 <rsleevi> ... that APIs are technically correct, but combined in misimplemented ways
08:11:56 <rsleevi> ... then when trying to fix the implementation, people make it worse
08:12:04 <rsleevi> ... Can we as a WG make things easier/safer - default safe even
08:12:21 <wseltzer> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
08:12:25 <rsleevi> drogersuk: Convinced me we need to do something easier for people
08:12:30 <rsleevi> q?
08:12:33 <rsleevi> ack mountie
08:12:43 <rsleevi> mountie: thinks we need three tracks
08:12:51 <rsleevi> ... low level for primary features, low level for secondary features, high level
08:12:52 <rbarnes> q+
08:13:03 <rsleevi> ... concerned that secondary features have more priority than high level API
08:13:30 <rsleevi> ... can one single high-level API cover multiple operations that would be safe?
08:13:47 <rsleevi> ... normally designing web applications/services has some sort of sequence of operations
08:14:01 <rsleevi> ... one single high level API can remove some common mistakes
08:14:07 <rsleevi> ... but need secondary features
08:14:09 <rsleevi> ack selfissued
08:14:27 <rsleevi> selfissued: the value of a draft high-level API using JOSE formats is currently JOSE formats are malleable
08:14:41 <shige___> shige___ has joined #crypto
08:14:42 <virginie> q?
08:14:46 <virginie> q+
08:14:50 <rsleevi> ... to the extent that developing an API and using them, discovering that there is a difficulty or mismatch, we can course correct work in JOSE and this WG
08:14:53 <JonathanJ1> JonathanJ1 has joined #crypto
08:15:07 <rsleevi> ... if we make a mistake in either group (JOSE, here), we can fix them if we do it sooner than later
08:15:16 <rsleevi> ... that said, make it a separate work item from the low level spec
08:15:22 <rsleevi> ... completely distinct from the low-level API
08:15:33 <rsleevi> ... with possibly a different set of editors
08:15:54 <rsleevi> rbarnes: chiming in, +1 to the davids (drogersuk, ddahl) and mike (selfissued)
08:16:06 <rsleevi> ... good that it can remove a lot of rope from the API
08:16:14 <Takahiro> Takahiro has joined #crypto
08:16:17 <rsleevi> ... question about choosing a lot of defaults for people
08:16:49 <rsleevi> ... is there a way to take concepts of smoothing out some of the bumps that can make the low-level API easier to use, like the high-level API seems to be
08:17:05 <rsleevi> virginie: What were the actual use cases that you think the current high-level API can address?
08:17:11 <rsleevi> ... what is the story for this API?
08:17:23 <JonathanJ1> JonathanJ1 has joined #crypto
08:17:32 <rsleevi> ddahl: solves the sort of chat/messaging use case
08:17:37 <rsleevi> ... solves document storage in the cloud
08:17:43 <rsleevi> ... not trusting the server
08:17:46 <rsleevi> q+
08:17:50 <rsleevi> ... local storage/encryption
08:17:51 <rbarnes> ack rbarnes
08:17:52 <rsleevi> ack rbarnes
08:17:55 <rsleevi> ack virginie
08:18:17 <hhalpin> Should do a straw-poll just to see how many people "want to add this work-package?"
08:18:19 <rsleevi> ddahl: personally would use it for conceptual ideas like "never use email", replacing it with a completely webby toolkit
08:19:08 <rsleevi> virginie: How does key exchange work in this API if key exchange is out of scope
08:19:41 <rsleevi> virginie: people want "one click crypto", where negotiation is part of the API
08:20:00 <rsleevi> ddahl: keyex is out of scope, but other APIs may be possible
08:20:50 <hhalpin> q+
08:20:57 <rsleevi> ack rsleevi
08:21:19 <rsleevi> rsleevi: this API doesn't really work if you don't trust the server (eg: doc ex)
08:21:27 <rsleevi> rsleevi: So what's the security properties here
08:21:49 <rsleevi> ddahl: it does somewhat, like if you put encrypted data on a server, and that server is seized, the data is still sitting on the server in an unopenable state
08:21:57 <rsleevi> ddahl: Chief use case is messaging
08:21:58 <rbarnes> q?
08:22:06 <rbarnes> q+
08:22:19 <rsleevi> ddahl: Messaging has won the web. email is dying. This can fit in with that
08:22:40 <rsleevi> hhalpin: Given that there's a lot of prior work with high-level APIs, it should be possible to create a spreadsheet comparing other high-level APIs
08:22:46 <rsleevi> ... eg: keyczar, sjcl, nacl
08:23:01 <JonathanJ1> rrsagent, draft minutes
08:23:01 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
08:23:06 <rsleevi> ... real question is given the amount of work needed on the low level API, does this WG want to take on the low-level API
08:23:33 <JonathanJ1> Present+ Jonathan_Jeon
08:23:34 <rsleevi> ... originally during the WG, we did a survey from the community re: high-level vs low-level API, WG said low-level API
08:23:53 <rsleevi> hhalpin: PROPOSAL: straw-poll in the WG as to whether we should adopt this in the WG
08:24:10 <rsleevi> ddahl: Traditionally in DOM APIs, we start off with something low-level, then abstract it higher (eg: DOM -> jQuery)
08:24:30 <cjkula> q+
08:24:38 <virginie> ack hhalpin
08:24:41 <rsleevi> ... it feels to me that now that we've experimented with some of the low-level API, it might be a quicker win to get something to market by doing something very high level
08:24:44 <opoto> q+
08:24:50 <mountie> q+
08:24:58 <markw> q+
08:25:00 <hhalpin> Note that I would like the straw poll!
08:25:14 <rsleevi> ack rbarnes
08:25:36 <rsleevi> rbarnes: Back to use cases/stories, the upside of having all the prior art is that we can choose what variety of things we want to support
08:25:44 <rsleevi> ... think it should be possible to support a variety of use cases with a high level API
08:26:10 <rsleevi> ... thinks losing configuration/key management operations may not be a bad thing
08:26:24 <rsleevi> ... thinks its an 80/20% problem, and 80% of problems can be addressed by the high-level
08:26:34 <hhalpin> \me the real question is what is the crypto API for the 99% :)
08:26:47 <selfissued> q+
08:27:09 <rsleevi> rbarnes: seems like there is energy in the room to work on the high level
08:27:13 <rsleevi> ack cjkula
08:28:02 <rsleevi> cjkula: not sure if high-level wrappers (ala jquery) can provide the same assurances that implementing in the browser
08:28:05 <rsleevi> ack opoto
08:28:23 <rsleevi> opoto: If the entire high-level API can be implemented in JS using the low-level API, why should we standardize the high-level API?
08:28:43 <rsleevi> ... looking at DOM vs jQuery - there have been many high-level APIs adopted in the market (besides jQuery) depending on the use case
08:28:52 <rsleevi> ... built on the common DOM/low-level API
08:29:07 <rsleevi> ... maybe this will be the case for crypto to - there will be several high-level APIs based on different domains/use cases
08:29:17 <rsleevi> ... should this WG impose just one?
08:29:37 <rsleevi> ... not convinced about imposing a single high-level API
08:29:40 <rsleevi> q?
08:29:44 <rsleevi> ack mountie
08:30:01 <rsleevi> mountie: David's proposal is different that what I expected
08:30:11 <rsleevi> ... many Korean users expected high-level API to touch on secondary features
08:30:29 <rsleevi> ... for these types of high-level APIs, there are so many other developers, let other teams (like jQuery team) develop them
08:30:31 <tlr> tlr has joined #crypto
08:30:34 <tlr> q+
08:30:36 <rsleevi> ... and we can propose low-level APIs, like secondary features
08:30:52 <virginie> Zakim, close the queue
08:30:52 <Zakim> ok, virginie, the speaker queue is closed
08:31:24 <rsleevi> markw: It would be a good thing if people implemented JOSE libraries implemented atop low-level API
08:31:36 <rsleevi> ... good if there were multiple of those, perhaps as student projects
08:31:50 <rsleevi> ... help work out JOSE issues, help prove out the low level API
08:32:06 <rsleevi> ... but it might be too early to jump into standardizing a JOSE library
08:32:16 <rsleevi> ... JOSE library may not be that complex to implement in JS
08:32:26 <rsleevi> ... wouldn't want this group to be distracted from getting the low level API to work
08:32:39 <JonathanJ3> JonathanJ3 has joined #crypto
08:32:39 <rsleevi> ... want to make sure you really have users and implementors really driving for that work
08:32:44 <rsleevi> ... which there is for the low-level API
08:32:46 <rsleevi> ack markw
08:32:49 <cjkula> q+
08:33:00 <rsleevi> tlr: Confused by this discussion
08:33:21 <rsleevi> ... considering this charter discusses where the high-level API sits
08:33:34 <rsleevi> ... discussion here rehashes the chartering discussions
08:33:58 <rsleevi> ... need to decide if the WG can't meet the chartered goal, and perhaps have a chartering discussion
08:34:04 <rsleevi> q?
08:34:07 <rsleevi> ack tlr
08:34:12 <JonathanJ3> JonathanJ3 has joined #crypto
08:34:22 <rsleevi> tlr: a bit uncomfortable with where this discussion is going w/r/t charter
08:34:32 <rsleevi> selfissued: response to markw's comments
08:34:46 <markw> q+
08:34:46 <rsleevi> ... I think there's value in prototyping an API that uses JOSE
08:34:55 <rsleevi> ... proves out JOSE, proves out the low-level API
08:35:06 <rsleevi> ... sympathetic to mark's comments regarding whether it's time to standardize
08:35:18 <rsleevi> ... can easily publish a draft leaving open a timeframe as to when it actually becomes a standard
08:35:31 <rsleevi> ... building an end-to-end implementation is one of the more valuable things we can do
08:35:33 <rsleevi> ack selfissued
08:35:49 <pal> pal has joined #crypto
08:35:53 <rsleevi> markw: Agree that it's good to implement, but not within this group
08:36:00 <rsleevi> ... people can implement and bring their feedback to the group
08:36:06 <rsleevi> ... but don't start standardizing yet
08:36:19 <rsleevi> virginie: many opinions within the group
08:36:35 <rsleevi> virginie: Who is interested in this work?
08:36:44 <rsleevi> virginie: How will it be worked on? Seems consensus for secondary doc
08:37:12 <rsleevi> ... seems like no one is opposing this work
08:37:23 <rsleevi> ... various questions to work out if this group decides to work on a high level API
08:38:29 <hhalpin> PROPOSAL: Should the Working Group engage with a higher-level API as demonstrated by ddahl?
08:38:33 <ddahl> +1
08:38:36 <hhalpin> +1
08:38:41 <selfissued> +1
08:38:43 <drogersuk> +1
08:38:48 <cjkula> +1
08:38:48 <wseltzer> [Charter: The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications. "]
08:38:52 <sangrae> +1
08:38:53 <mountie> -1
08:38:53 <rsleevi> +1
08:38:55 <opoto> +1
08:39:15 <rbarnes> +1
08:39:17 <wseltzer> +1
08:39:31 <wtc> +1
08:39:47 <rsleevi> http://www.w3.org/2011/11/webcryptography-charter.html
08:40:03 <hhalpin> PROPOSAL: Who would volunteer to work on the higher-level API as a deliverable?
08:40:12 <ddahl> +1
08:40:12 <rbarnes> +1
08:40:15 <selfissued> +1
08:42:11 <rsleevi> virginie: Sounds like this can be done separate from the main WG, perhaps on a different dedicated call
08:42:41 <rsleevi> ... would really like it to be clear what the use cases and operations that this high-level will help
08:42:54 <hhalpin> PROPOSAL: The Web Crytpo WG adds a high-level API as a deliverable to the working group contigent on the activity level of those in the WG who volunteer for this task
08:43:35 <hhalpin> Any objections?
08:44:49 <rsleevi> drogersuk: Doesn't a high-level API go against our charter?
08:44:53 <rsleevi> [ laughter ]
08:45:08 <drogersuk> @rsleevi that's not what I said
08:45:10 <rsleevi> hhalpin: Discussing the history of high-level API vs low-level API during chartering
08:45:22 <drogersuk> the proposal as it stands goes against the charter
08:45:34 <rsleevi> s/high-level API/proposal as it stands/
08:46:43 <hhalpin> To be more clear, I don't want this proposal to be interpreted as the "high-level" API taking priority for the entire WG over the lower-level API
08:46:47 <rsleevi> virginie: If you say a high level API shouldn't disturb a low-level API, you can't force that. It's contribution driven. If ddahl focuses on a high-level API, that can affect the low-level API
08:47:38 <hhalpin> PROPOSAL: The Web Crytpo WG adds a high-level API as a deliverable to the working group that does not stop the low-level API
08:48:51 <markw> q+
08:49:21 <rsleevi> tlr: concerned about this WG working on two docs - market confusion, confusion within the group, confusion about the charter
08:49:37 <drogersuk> q+
08:49:43 <JonathanJ1> rrsagent, draft minutes
08:49:43 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
08:50:20 <rbarnes> q?
08:50:31 <mountie> q+
08:50:53 <hhalpin> We could say "PROPOSAL: The Web Crytpo WG adds a high-level API as a Rec-track deliverable to the working group, and the WG does not stop work on its a current Rec-track API"
08:51:05 <rsleevi> markw: Netflix's position was always that what the charter calls for is what the WG is working on now (the LG)
08:51:17 <rsleevi> markw: So whether it's called high level or low level, it needs to support the cases in the charter
08:51:37 <rsleevi> drogersuk: Concern is not high-level vs low-level, but is it usable?
08:52:11 <rsleevi> rbarnes: I'm not convinced at this point that there's actually separate documents, but the proposal implies it
08:52:44 <rsleevi> virginie: Even if we've triggered some negative remarks with our low-level API, there are still people very interested in the low level API, so we should not abandon this work
08:53:02 <hhalpin> I was not answering the question of whether its one Rec-track document or two quite yet until we get the drafts further along.
08:53:13 <rsleevi> virginie: Important to have it done as two separate efforts, so that we don't have a dependency between the two. We may merge them later
08:53:45 <rsleevi> rbarnes: In agreement that this is mostly a usability concern
08:53:46 <hhalpin> virginie, perhaps re-open queue
08:53:56 <virginie> yeap
08:53:59 <rsleevi> rbarnes: Proposes simplifying the low-level API
08:54:02 <hhalpin> Zakim, open the queue
08:54:02 <Zakim> ok, hhalpin, the speaker queue is open
08:54:02 <rsleevi> Zakim, reopen the queue
08:54:03 <Zakim> ok, rsleevi, the speaker queue is open
08:54:31 <rsleevi> [ 10 minute break ]
08:54:34 <JonathanJ1> rrsagent, draft minutes
08:54:34 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
08:58:26 <pal> pal has joined #crypto
09:05:30 <wtc> wtc has joined #crypto
09:06:08 <rbarnes_> rbarnes_ has joined #crypto
09:06:47 <rbarnes_> rbarnes_ has joined #crypto
09:07:17 <rsleevi> virginie: in terms of priority, main priority stays low-level API
09:07:26 <rsleevi> ... virginie and tlr to work on messaging and ensuring its consistent
09:07:39 <virginie> q?
09:07:39 <cjkula> q+
09:07:40 <rsleevi> ... high level API is worked on by a separate group in parallel
09:07:47 <hhalpin> q+
09:07:48 <rsleevi> ack cjkula
09:08:06 <rsleevi> cjkula: It didn't seem to me that we didn't say we were never doing a high level API
09:08:23 <rsleevi> ... just that we had to focus on the low-level primitives we needed in order to enable a high level API
09:08:36 <rsleevi> virginie: We never made a decision to close discussion on high-level API
09:08:44 <virginie> q?
09:08:48 <rsleevi> selfissued: Actually, we just closed that issue
09:08:50 <rsleevi> ack hhalpin
09:09:07 <rsleevi> hhalpin: When we started with DOMCrypt, it became clear in a few calls that most of the use cases would not be satisfied with DOMCrypt
09:09:24 <rsleevi> ... put out several proposals on IRC, didn't really get closure on
09:09:26 <virginie> http://www.w3.org/2012/webcrypto/track/issues/7
09:09:37 <rsleevi> ISSUE-7?
09:09:37 <trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
09:09:37 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/7
09:09:41 <virginie> issue 7 is related to do we work or not on high level api
09:10:18 <rsleevi> hhalpin: regarding usability, there are sort of two different APIs going on within the cryptographic space
09:10:32 <virginie> q?
09:10:49 <rsleevi> rbarnes: The distinction for me is APIs that deal on octets and APIs that deal on data structures
09:11:14 <rsleevi> ... there seems to be a bright line and we need to decide where we sit
09:11:56 <rsleevi> ... on one hand, getting the octet based API is key, but it needs to be simple
09:12:01 <rsleevi> ... current API is octets and not simple
09:12:05 <hhalpin> PROPOSAL: The Web Crypto WG adds a higher-level API as a Rec-track deliverable to the working group but does not stop the WG work on the current API
09:12:10 <rsleevi> ... david's proposal is simple and not octets
09:12:22 <rsleevi> ... we perhaps need something different
09:12:43 <tlr> q+
09:12:59 <pal> q+
09:13:20 <wseltzer> ack tlr
09:13:21 <rsleevi> tlr: What I hear is there are a set of use cases that correspond to a set of use cases that are on the low level API
09:13:37 <rsleevi> ... things like OpenPGP, thinks those are distinctly not in the charter
09:14:13 <ddahl> q+
09:14:16 <rsleevi> ... hears use cases like what rbarnes said, I want to box something, ship it up to a web app, send it to another server, unbox it, not have to worry about it
09:14:19 <virginie> q?
09:14:22 <virginie> q+
09:14:25 <rsleevi> ... so what is the correct understanding of the high-level API?
09:14:29 <wseltzer> ack pal
09:14:40 <rsleevi> pal: What are the implications of adding something to Rec-Track in the context of the existing work?
09:14:48 <hhalpin> its really a matter of exposing parameters as well, not just operating on octets.
09:14:51 <rsleevi> pal: Does it make that work contingent upon this work?
09:14:52 <wseltzer> ack ddahl
09:14:54 <rsleevi> virginie: no
09:15:13 <rsleevi> ddahl: When we talk about high-level/low-level, I think we need to still have more discussion on what the distinction between them
09:15:30 <hhalpin> q+
09:15:31 <rsleevi> ddahl: What I'm thinking of when we talk high-level, I'm thinking only consumes JOSE, or higher, and has little configuration
09:15:38 <rsleevi> ddahl: Has only two to four methods
09:15:55 <virginie> q?
09:16:13 <wseltzer> ack virginie
09:16:41 <rsleevi> q+
09:17:13 <rsleevi> virginie: The task of the contributors will be to explain the differences clearly
09:17:18 <JonathanJ1> rrsagent, draft minutes
09:17:18 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
09:17:22 <hhalpin> ack hhalpin
09:17:47 <rsleevi> hhalpin: There were some use cases that we thought we could with high level
09:18:04 <rsleevi> ... but after looking at the use cases we had, it was clear they could only be accomplished with something lower level
09:18:30 <rsleevi> ... it seemed that most of the use cases were actually motivated by exposing configuration options and details
09:18:43 <rsleevi> ... it sounds plausible when you first think about it, that a high level API can solve all the problems
09:18:49 <rsleevi> ... but it actually wasn't the case
09:19:01 <Takahiro> Takahiro has joined #crypto
09:19:21 <Alexandre_Morgaut> Alexandre_Morgaut has joined #crypto
09:19:22 <rsleevi> ... high level API hides the configuration details, which intuitively seems good, but its not clear yet what use cases it identifies
09:19:23 <ddahl> q+
09:19:45 <rsleevi> tlr: It's important that everyone in the group has a shared mental model for this work
09:19:49 <wseltzer> ack rsleevi
09:21:59 <rsleevi> rsleevi: We need to have an understanding as to what *is* a high level API
09:22:23 <rsleevi> rsleevi: would like those who want to work on a high level API to actually put a proposal forward to make it clear what they think a high level API is
09:22:42 <rsleevi> ddahl: I never intended DOMCrypt to address all the use cases. Just those use cases related to messaging
09:22:50 <hhalpin> PROPOSAL: The Web Crypto WG attempts to define a draft higher-level API as deliverable but not stop work on the current API
09:23:20 <hhalpin> Any objections?
09:23:20 <ddahl> +1
09:23:26 <mountie> +1
09:23:41 <sangrae> +1
09:23:46 <wtc> +1
09:23:50 <selfissued> +1
09:23:57 <JonathanJ1> +1
09:23:57 <cjkula> +1
09:23:59 <hhalpin> +1
09:23:59 <opoto> +1
09:24:22 <hhalpin> You can abstain explicitly Markw
09:24:39 <hhalpin> RESOLUTION: The Web Crypto WG attempts to define a draft higher-level API as deliverable but not stop work on the current API
09:26:11 <hhalpin> ACTION: ddahl (and others) to bring back functions and a draft WebIDL for the higher-level API
09:26:11 <trackbot> Created ACTION-62 - (and others) to bring back functions and a draft WebIDL for the higher-level API [on David Dahl - due 2012-11-09].
09:26:58 <hhalpin> ACTION: virginie and tlr to handle any concerns from public and communications about WG's work
09:26:58 <trackbot> Created ACTION-63 - And tlr to handle any concerns from public and communications about WG's work [on Virginie GALINDO - due 2012-11-09].
09:27:24 <wseltzer> [break]
09:27:47 <rsleevi> RRSAgent, draft minutes
09:27:47 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html rsleevi
09:28:15 <wseltzer> wseltzer has changed the topic to: WebCrypto F2F; shout in IRC if you want to call-in
09:33:46 <JonathanJ3> JonathanJ3 has joined #crypto
09:46:56 <rbarnes> rbarnes has joined #crypto
09:55:14 <rbarnes> rbarnes has joined #crypto
09:59:17 <opoto> opoto has joined #crypto
09:59:46 <pal> pal has joined #crypto
10:01:08 <mountie> mountie has joined #crypto
10:04:27 <drogersuk> drogersuk has joined #crypto
10:04:32 <wtc> wtc has joined #crypto
10:05:03 <Takahiro> Takahiro has joined #crypto
10:06:12 <wtc> scribenick wtc
10:06:45 <wtc> Zakim: scribenick wtc
10:08:11 <wtc> markw: the discussion of ISSUE-25 will start at 11:30
10:08:52 <wtc> virginie: I suggest we discuss the security framework during the 20 minutes before 11:30.
10:09:23 <wtc> ... we have been discussing the security assets that are coming together with our API.
10:09:28 <rsleevi> topic: security framework
10:09:59 <mlee> mlee has joined #crypto
10:10:27 <hhalpin> hhalpin has joined #crypto
10:10:48 <tlr> tlr has joined #crypto
10:10:49 <mlee> mlee has left #crypto
10:10:58 <wtc> ... Security Framework: building a common understanding on what the Web Crypto API brings to the web security
10:11:30 <mountie> mountie has joined #crypto
10:11:41 <wtc> virginie: received questions about the actual value of our API after the FPWD was published.
10:12:27 <wtc> ... (goes over the slides of the presentation)
10:12:56 <wtc> ... security features of the API is left to UA know how. Crypto capabilities rely on OS capabilities.
10:13:37 <wtc> ... Web app quality evaluation is left to the user. The actual security of the API is left to implementers know how.
10:14:18 <wtc> ... such as: *integrity of the API, *local storage protection (TPM, secure elements, etc.), *WebApp identification/execution
10:14:52 <Alexandre_Morgaut> Alexandre_Morgaut has joined #crypto
10:15:52 <wtc> ... The value of our deliverable is: * standardizing the functional behavior of crypto operations, * help developers use the crypto operations correctly, * include the features of secure elements in the API (an controversial issue).
10:16:34 <hhalpin> q+
10:16:49 <ddahl> q-
10:17:03 <wtc> virginie: I pose two questions to the working group:
10:17:19 <rbarnes> q?
10:17:30 <hhalpin> ack hhalpin
10:17:33 <wtc> ... 1. why not writing down this value propositon? 2. can we make it better?
10:17:40 <wtc> virginie: any questions?
10:17:52 <drogersuk> http://w3cmemes.tumblr.com/image/34766205708
10:18:19 <wtc> hhalpin: we should have stated up front this is an API that adds new capacity to web apps but doesn't changes the security aspects.
10:18:34 <rbarnes> q+
10:18:38 <wtc> ... it might be useful to add a few brief sentences to clarify that. We seem to have done that.
10:19:03 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html wseltzer
10:19:03 <wtc> hhalpin: this should be in the first paragraph or even the abstract, not in section 5.
10:19:10 <Takahiro> Takahiro has left #crypto
10:19:31 <Takahiro> Takahiro has joined #crypto
10:19:44 <wseltzer> s/scribenick wtc/scribenick: wtc/
10:19:53 <sburr> sburr has joined #crypto
10:20:09 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html wseltzer
10:20:13 <hhalpin> Well, what I was suggesting to be exact was that we have a *very* brief mention of these in the intro and status parts of the API, and then point people to the Security Considerations in Section 5.
10:20:32 <wtc> rbarnes: I agree we should have a forward reference of the security considerations at the beginning of the API spec.
10:20:41 <wtc> scribenick: wtc
10:21:07 <wtc> markw: would be useful to enumerate the security models relevant to this API.
10:21:12 <mountie> q+
10:21:16 <hhalpin> q+
10:21:17 <drogersuk> q+
10:21:17 <rbarnes> ack rbarnes
10:21:59 <wtc> markw: there are models that have different levels of trust for the user agent and the JavaScript code.
10:22:24 <rsleevi> ISSUE-21?
10:22:24 <trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open
10:22:24 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/21
10:22:33 <wtc> mountie: for ISSUE-21: content-security policy
10:22:57 <wtc> ... Tobie of Facebook talked about the protection of JavaScript code yesterday.
10:23:27 <wtc> ... It is our role to suggest a solution for the integrity of JS code.
10:23:33 <hhalpin> ack hhalpin
10:23:48 <rsleevi> ack mountie
10:24:15 <wtc> hhalpin: a question for tlr: we need one or two sentences at the beginning.
10:24:37 <wtc> ... Is there a document from the WebAppSec group that we can point to?
10:25:13 <wtc> tlr: I think it's useful to describe the security models and how our API behaves in the security models.
10:25:20 <tlr> q?
10:25:28 <rsleevi> ack drogersuk
10:25:51 <wtc> drogersuk: the security and threat models, we have to decide which are in scope.
10:26:35 <virginie> q+
10:26:40 <rsleevi> ack virginie
10:26:44 <wtc> drogersuk: the dependency on the work of the WebAppSec WG -- should we iterate...
10:26:49 <hhalpin> To be clear, I was suggesting that we work on this document *with* WebAppSec WG if they already have a document they are working on. The other option is for us to try to work on that document by ourselves.
10:26:52 <kenji> kenji has joined #crypto
10:27:43 <wtc> virginie: if we have an internal document describing the security models we have in mind, with someone editing it, then we can have a liaison with the WebAppSec WG.
10:28:14 <wtc> drogersuk: 1. we have to make it clear we have a direct dependency on the security and thread models.
10:28:22 <rsleevi> s/thread/threat/
10:28:36 <wtc> ... 2. We need to say "security and threat" model, not just security model.
10:29:02 <wtc> virginie: who would like to lead that? drogersuk?
10:29:22 <wtc> drogersuk: I'd be happy to help. I won't be able to commit until January.
10:30:04 <wtc> virginie: can you come up with a description of the security and threat model for this WG, that would be helpful.
10:30:31 <hhalpin> q+
10:30:40 <sgodard> sgodard has joined #crypto
10:30:49 <wtc> tlr: WebAppSec doesn't usually work on crypto issues.
10:31:16 <wtc> drogersuk: how do you think the liaison between our WG and WebAppSec WG would work?
10:31:27 <sgodard> Present+ sgodard
10:32:11 <wtc> rbarnes: the easiest thing to do would be draft up some text and take it to the WebAppSec WG.
10:32:14 <rsleevi> q?
10:32:24 <hhalpin> ack hhalpin
10:32:46 <rsleevi> q+
10:33:10 <wtc> hhalpin: most of the reviewers were looking for security considerations for "users".
10:33:31 <drogersuk> q+
10:33:46 <wtc> rsleevi: there are no real differences in security considerations for this API and, say, full screen mode.
10:33:51 <virginie> Security considerations in the spec http://www.w3.org/2012/webcrypto/track/actions/55 and http://www.w3.org/2012/webcrypto/track/actions/52
10:34:09 <virginie> some actions that may answer harry expectation from the spec
10:34:30 <wtc> ... my view as an implenter is there is no fundamental difference between this API and storing keys in the local storage.
10:34:33 <virginie> ack rsleevi
10:34:36 <pal> q+
10:34:42 <wtc> ... there is nothing special.
10:34:45 <pal> time check
10:35:17 <hhalpin> q?
10:35:38 <wtc> ... if you need constant-time crypto operations, then this can best be provided by our API. This is why the security considerations focus on developers.
10:35:43 <wseltzer> zakim, close queue
10:35:43 <Zakim> ok, wseltzer, the speaker queue is closed
10:36:07 <pal> q-
10:36:10 <wtc> drogersuk: when people hear crypto, people expect security.
10:36:28 <wseltzer> ack drogersuk
10:36:35 <wseltzer> zakim, reopen queue
10:36:35 <Zakim> ok, wseltzer, the speaker queue is open
10:36:55 <wtc> virginie: next topic is ISSUE-25: Global Unique ID for pre-provisionned symetric keys
10:37:01 <rsleevi> ISSUE-25?
10:37:01 <trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- open
10:37:01 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/25
10:37:10 <hhalpin> ACTION: drogersuk to draft security and threat model for WebCrypto API given considerations of Web Application Security Model
10:37:10 <trackbot> Sorry, couldn't find drogersuk. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
10:37:15 <wtc> virginie: ACTION-17 is associated.
10:37:17 <rsleevi> topic: Global Unique Identifiers
10:37:40 <wtc> virginie: markw provided a proposal on Oct. 29.
10:38:28 <rigo> rigo has joined #crypto
10:38:28 <virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html
10:38:40 <wtc> markw: we had an action item to propose global unique IDs for pre-provision keys.
10:39:14 <wtc> markw: if you need to use a pre-provisioned key, you need an identifier on the server side to look up the symmetric key.
10:39:50 <wtc> markw: we want a common way for TV manufacturers for pre-provisioned symmetric keys.
10:40:34 <wtc> ... we are interested in origin-specific pre-provisioned keys.
10:41:04 <wtc> ... if user agents need pre-provisions keys for different origins, those should be different keys.
10:41:59 <wtc> ... I suggested deleting the text about suggeting deriving keys from a master key.
10:43:09 <wtc> markw: the main part of the proposal is the designate a property, "uid" for pre-provisioned symmetric keys.
10:43:48 <wtc> markw: rsleevi suggested we should specify the properties of the "uid" property.
10:44:12 <ddahl> q+
10:44:31 <wtc> markw: the proposal s http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html
10:44:45 <virginie> ack ddahl
10:44:46 <wtc> ddahl: is this property optional?
10:45:08 <wtc> markw: yes, it has to be optional.
10:45:30 <wtc> ... depends on the aplications whether they want to provide it.
10:45:56 <wtc> ddahl: I have seen specs with optional items like this that caused problems.
10:46:16 <rsleevi> q+
10:46:53 <virginie> ack rsleevi
10:47:33 <wtc> rsleevi: my concern has been this optional attrbute will never be implementable in desktop browsers (as opposed to TVs or devices).
10:47:46 <pal> q+
10:48:32 <wtc> rsleevi: I wonder how much of this has to be specified, and how much of this should be left to the video streaming industry and the device vendors.
10:48:41 <markw> q+
10:48:51 <virginie> q+
10:49:21 <wtc> pal: what does an "optional" unique identifier mean?
10:49:52 <wtc> rsleevi: there are ways to uniquely identify a symmetric key.
10:50:18 <virginie> q?
10:50:21 <hhalpin> q+
10:50:58 <wtc> rsleevi: my concern is as an implementer, if I read the spec, I don't know if I need to implement it.
10:51:27 <pal> q-
10:51:39 <wtc> markw: the spec is http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html
10:51:41 <rsleevi> q+
10:51:53 <rsleevi> ack virginie
10:52:06 <wtc> virginie: do you see any means to make it better?
10:52:28 <rsleevi> RRSAgent, draft minutes
10:52:28 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html rsleevi
10:53:05 <markw> http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0012.html
10:53:22 <wtc> markw: correction: the proposal is http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0012.html
10:53:32 <wtc> ... this clarifies what the identifier would look like.
10:53:55 <ddorwin> ddorwin has joined #crypto
10:55:15 <rsleevi> ack markw
10:55:25 <wtc> ... some text characterizing the global unique identifier.
10:55:45 <hhalpin> ack hhalpin
10:55:46 <virginie> q?
10:56:00 <markw> The second email is extended text to be added to the first
10:56:32 <wtc> hhalpin: there are two options we have. It's clear not all implementers are going to implement "uid". The issue is where to put it in the spec.
10:57:19 <wtc> ... option 1: in the spec, but mark as optional. option 2: not specified in the spec.
10:57:24 <pal> q+
10:58:11 <wtc> markw: putting in the spec will save some messy code that needs to be written by developers (if different vendors use different properties).
10:58:12 <hhalpin> ack hhalpin
10:58:16 <hhalpin> q+ hhalpin
10:58:47 <wtc> rsleevi: putting it in the spec won't resolve the ambiguity to the implementors.
10:59:58 <wtc> ... I don't know how consistent this will be.
11:00:28 <markw> q+
11:00:33 <rsleevi> ack rsleevi
11:00:46 <wtc> ... I don't know if we have enough people with the right background to know if this is the right global unique identifier to standardize.
11:01:19 <wtc> pal: assigning a unique identifier to a key is not an exceptional thing.
11:01:27 <virginie> q+
11:02:29 <rsleevi> ack pal
11:02:34 <hhalpin> ack hhalpin
11:02:36 <wtc> pal: if the semantics of the id is the id shall be unique, then it's up to the provider of the id to make sure it is global. I don't see the downside of specifying an optional uid attribute.
11:03:26 <pal> q+
11:03:28 <wtc> hhalpin: what we need to decide is whether to put this in "extra attributes" or as an (optional) first-class attribute.
11:04:08 <pal> q-
11:04:17 <pal> q+
11:04:36 <wtc> hhalpin: is there any other member of the WG, besides Netflix, who would like to use "uid"?
11:05:27 <wtc> markw: I just need to standardize the attribute's name and semantics. It is fine to us for it to be in the "extra attributes".
11:05:37 <hhalpin> so just to clarify, its part of "extra" in 10.2
11:05:53 <hhalpin> thus, it should be clear to implementers that its optional, but we need some more text around "extra"
11:06:27 <wtc> markw: we (Netflix) would be implementing the user side of it...
11:06:55 <rsleevi> q+
11:07:07 <virginie> ack markw
11:07:12 <wtc> markw: the Web Crypto API will be on our list of web/HTML technologies for device manufacturers.
11:07:21 <rsleevi> ack virginie
11:07:42 <wtc> virginie: speaking as Gemalto, I see some value of this feature.
11:08:10 <wtc> virginie: speaking as the chair, I see there is a "market" probem, but not a technical problem.
11:08:21 <markw> I suggest we ask the Web & TV Interest group for opinions on whether the proposal meets the requirements they have raised earlier in the week
11:08:58 <wtc> ... The market problem: markw should make it clear it's the market, not just Netflix, that is interested in it.
11:09:15 <wtc> pal: it's clear there is interested in this feature.
11:09:40 <rsleevi> ack pal
11:09:47 <wtc> pal: I am interested in understanding whether there are technical challenges for implementing global unique identifiers.
11:10:34 <markw> q+
11:10:41 <wei_> wei_ has joined #crypto
11:10:51 <wtc> rsleevi: we have several members of the WG who have participated in the WG since the beginning, and the features they want are not yet in the current API spec.
11:11:38 <pal> q+
11:11:47 <wtc> rsleevi: the technical challenge is "you know it when you see it"...
11:12:08 <kenji> kenji has left #crypto
11:12:13 <wtc> rsleevi: in addition, pre-provisioned keys have different security attributes than "browser-mediated" keys.
11:12:48 <wtc> rsleevi: there are some user tracking issues with the global unique identifiers. These have to be considered.
11:13:12 <virginie> q?
11:13:18 <drogersuk> q+
11:13:41 <markw> q-
11:13:51 <rsleevi> ack rsleevi
11:13:56 <wtc> rsleevi: we should focus on features that improve the security of the current state of "JS crypto" on the web...
11:13:56 <pal> q-
11:14:15 <wtc> markw: if we have to drop features, we should drop features that don't have a proposal.
11:14:38 <wtc> drogersuk: the tracking aspect...
11:15:05 <pal> q+
11:15:11 <rsleevi> ack drogersuk
11:15:13 <wtc> ... maybe we need to think about it more and rewrite it.
11:15:17 <hhalpin> q+
11:15:22 <rsleevi> ack pal
11:15:33 <wtc> pal: thank you (rsleevi) for pointing out the issues.
11:16:06 <rsleevi> q+
11:16:22 <wtc> pal: if there is interest in a global id, it will help interoperabilty...
11:16:54 <wtc> hhalpin: we should write a proposal.
11:16:54 <selfissued> q+
11:17:24 <wtc> hhalpin: it's clear the focus is on a uid attribute, minus the certificate aspect.
11:18:01 <wtc> hhalpin: as long as it's clearly labeled as "extra", it should not confuse implementers. This is one proposal.
11:18:25 <rsleevi> ack hhalpin
11:18:28 <wtc> hhalpin: the other proposal is to continue discussion until the proposal is worked out ...
11:18:32 <markw> q+
11:18:47 <virginie> Zakim, close the queue
11:18:47 <Zakim> ok, virginie, the speaker queue is closed
11:19:19 <wtc> rsleevi: I am concerned about how fast we can find consensus on a minimum set of features.
11:19:49 <wtc> drogersuk: we can't let this descend into the debate of PCs vs. other devices.
11:19:50 <rsleevi> ack rsleevi
11:20:57 <rsleevi> ack selfissued
11:20:58 <rsleevi> ack markw
11:20:59 <wtc> selfissued: since markw has done the work of writing up a concrete proposal for their use case, it would be good for the working group to consider his proposal...if it meets the editors' requirements...
11:21:14 <hhalpin> PROPOSAL: Accept Netflix's proposal for a uid under "extra" minus the certificate aspect, as long as the technical details are worked out to the editor's satisfaction
13:04:25 <RRSAgent> RRSAgent has joined #crypto
13:04:25 <RRSAgent> logging to http://www.w3.org/2012/11/02-crypto-irc
13:04:37 <npdoty> scribenick: npdoty
13:04:40 <odinho_> odinho_ has joined #crypto
13:04:43 <npdoty> virginie: we are here just to provide an API
13:04:55 <npdoty> ... slide with members of the WG, 53 participants
13:05:05 <npdoty> ... 10 to 20 people on a weekly conference call
13:05:13 <sgodard> Present+ sgodard
13:05:14 <npdoty> ... 11 invited experts too
13:05:28 <npdoty> ... deliverables: Web Crypto API, currently in FPWD
13:05:42 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html odinho_
13:05:50 <npdoty> ... wiki list of use cases, which maybe will move to an actual specification
13:06:10 <npdoty> ... have started to discuss security
13:06:24 <npdoty> ... a "high level api", an abstraction
13:06:39 <npdoty> virginie: Use Cases for Web Crypto
13:07:03 <npdoty> ... client confirming the integrity of data, p2p communication, protected storage (local or remote)
13:07:30 <npdoty> ... just a wiki page at the moment, clear among the WG but want to formalize
13:07:42 <npdoty> ... Web Crypto API
13:07:54 <npdoty> ... great job by the editors, Ryan and David
13:08:16 <npdoty> ... generate, import, export, encrypt, decrypt, sign, verify, digest, rng
13:08:39 <npdoty> ... recommended set of algorithms, but not mandatory
13:08:52 <npdoty> ... 30 issues at the moment
13:08:56 <odinho_> i/scribenick: npdoty/Topic: Joint meeting, Crypto and WebAppSec
13:09:05 <npdoty> ... would like reviews from WebAppSec
13:09:25 <npdoty> virginie: possible collaboration with WebAppSec
13:09:56 <npdoty> ... received some comments that this is a dangerous API because it requires expertise, because JS is not secure, because.....
13:10:23 <npdoty> ... decide explicitly the value of this API, write down which security problems we are responsible for and what we are not
13:10:29 <npdoty> ... the "API value proposition"
13:10:51 <npdoty> ... could collaborate because you know the state of the art of web security
13:11:06 <npdoty> ... links! [help the scribe by dropping them in please]
13:11:34 <sgodard> slide links please ?
13:11:55 <npdoty> bhill2: can introduce the scope of webappsec work....
13:11:57 <virginie> Our main page http://www.w3.org/2012/webcrypto/
13:12:13 <virginie> Our wiki http://www.w3.org/2012/webcrypto/wiki/Main_Page
13:12:21 <npdoty> bhill2: three deliverables that may have some to little relevance for what crypto is doing
13:12:24 <virginie> Our mailing list http://lists.w3.org/Archives/Public/public-webcrypto/
13:12:28 <npdoty> ... least to most relevant:
13:12:53 <npdoty> ... 1) clickjacking vulnerabilities and secure mashups across origins, embedding iframes and other content
13:13:11 <npdoty> ... confusing user interface, breaking the visual integrity of a page when it's embedded
13:13:31 <npdoty> ... nothing cryptographic in the response, more about heuristics and comparing visual images
13:13:42 <npdoty> ... richer than today's X-Frame-Options header
13:13:58 <Takahiro> Takahiro has joined #crypto
13:14:07 <npdoty> ... a policy model with a feedback channel, more fine-grained, to enable integrated mashup applications currently considered unsafe
13:14:18 <npdoty> ... 2) content security policy, about to go to CR next week
13:14:20 <hhalpin> hhalpin has joined #crypto
13:14:35 <npdoty> ... reducing the attack surface of applications to injection vulnerabilities, like XSS
13:14:59 <npdoty> ... voluntarily declare a more-restrictive least privilege environment, limit which origins are allowed for embedding images, scripts
13:15:14 <npdoty> ... be able to white-list the origin of external content
13:15:55 <npdoty> ... in 1.1 of CSP, discussing only inline script blocks that match to a hash or similar; may be comparable to signed applications
13:16:31 <npdoty> ... start with the assumption that the DOM environment is untrusted, so would probably want cryptographic enforcement to be done in the user agent rather than in the DOM itself
13:16:40 <npdoty> ekr: +1
13:16:58 <npdoty> bhill2: so I'm not sure those elements would be consumers of a DOM-based crypto API
13:17:21 <npdoty> ... but if you were producing formats for cryptographic signatures over a block of JavaScript, that could be a reference or joint work with webappsec
13:17:29 <npdoty> ... what's the format of the thing you're going to sign?
13:17:52 <npdoty> ... 3) cross-origin resource sharing (CORS)
13:18:02 <npdoty> ... xhr between domains in a more secure fashion
13:18:24 <npdoty> ... allow for permission-relaxing by a resource declaring that it can be accessed more permissively across different origins
13:18:46 <npdoty> ... developers may be interested in applying different security services for resources that were fetched from a cross-origin request
13:19:09 <npdoty> ... always recommend in security considerations that you do some verification of the content that is retrieved
13:19:17 <npdoty> ... for data that wasn't confidential but needed to have integrity
13:19:31 <npdoty> ... an area where developers would be most interested in using the two groups' work in concert
13:19:49 <npdoty> ... what's the canonical format for signatures of content?
13:20:47 <npdoty> bhill2: going to be re-chartering soon, contemplating deliverables around link fingerprinting/hashing -- an attribute of an HTML tag/URI including a hash/fingerprint of a resource
13:20:57 <npdoty> ... could include large javascript libraries or other blobs and verify that they haven't changed
13:21:13 <npdoty> ... I want to load this analytics javascript from a 3rd-party site, but want to make sure it's a particular version that I've code reviewed
13:21:26 <npdoty> ... don't want my site to be compromised when the 3rd-party host has been compromised
13:21:45 <npdoty> ... regarding performance, can more effectively use CDNs and other types of caching
13:21:54 <npdoty> ... just in the strawman idea phase for a possible charter
13:22:13 <npdoty> ... overlap with this group in delivering signed objects
13:22:22 <virginie> q?
13:22:27 <Zakim> Zakim has joined #crypto
13:22:29 <npdoty> q?
13:22:34 <virginie> q+
13:22:41 <virginie> q-
13:22:49 <npdoty> odinho_: XHR is a common use of CORS, btw. img feth for use in canvas, eventsource, track element/video, fonts etc are other uses as well :)
13:23:40 <npdoty> bhill2: csp going to CR next week; CORS is hoping to go to PR once we have test suites to prove that interoperable implementations are ready
13:23:49 <npdoty> ... hoping to go to Rec in the next 4 to 6 months
13:24:09 <npdoty> ... clickjacking to go to Rec in the next 12 to 18 months, depending on implementations
13:24:26 <npdoty> ... csp will probably be at fpwd later this month, maybe Feb 2014 for Rec
13:24:52 <npdoty> bhill2: rechartering, not sure whether the new deliverable (link fingerprinting) will spark controversy
13:25:06 <gopal> gopal has joined #crypto
13:25:08 <npdoty> ... ~3 month process
13:25:30 <npdoty> ... expect that would be a one year time frame, to Rec around Feb 2014
13:25:45 <npdoty> @@: any approach if the user environment is compromised?
13:25:53 <rsleevi> s/@@/mountie/
13:26:05 <npdoty> bhill2: minimize the impact of injection vulnerabilities by setting a strong least-privilege policy
13:26:19 <npdoty> ... prevent some of the cases where reflected vulnerabilities will turn into active content
13:26:41 <virginie> q+
13:26:41 <npdoty> ... everything is only best effort, resource owners won't know how much the user agent has implemented
13:26:51 <npdoty> ... just prevent the execution of content
13:27:09 <npdoty> ... a defense in depth measure to reduce attack surface and privileges of resource, so that the damage is limited when compromises happen
13:27:22 <npdoty> ack virginie
13:27:22 <drogersuk> drogersuk has joined #crypto
13:27:43 <hhalpin> q+
13:27:46 <npdoty> virginie: you have a long section in your spec to limit your own liabilities?
13:28:34 <mountie> q+
13:28:38 <npdoty> bhill2: yes. I think it's not our group's purpose to tell the Web platform what it should/should not do
13:29:12 <npdoty> ... security can't just be on the server side any more, our group was chartered with the idea that applications are full-fledged and need security capabilities on the user agent side
13:29:22 <npdoty> ... in fact, the UA is the only place where some of these defenses can be built
13:29:53 <npdoty> ... we are working on the same assumption that the web app is a first-class citizen
13:30:06 <hhalpin> ack hhalpin
13:30:13 <npdoty> @@@: we all assume that the features will be there and that developers will screw them up <laughter>
13:30:47 <DanD> DanD has joined #crypto
13:31:01 <npdoty> hhalpin: when we asked for public feedback, we got feedback on the nature of our algorithms, but also got less helpful feedback via twitter
13:31:06 <rsleevi> s/@@@/Ryan_Ware/
13:31:22 <ware> s/@@@/ware/
13:31:42 <kotakagi> kotakagi has joined #crypto
13:31:52 <bhill2> http://www.w3.org/2001/tag/2011/02/security-web.html
13:31:58 <npdoty> ... still trying to clarify our high-level view of what our purpose is, drogersuk volunteered to edit
13:32:24 <npdoty> ... might be interesting joint work between our two groups (since CSP also has specific limited scope)
13:32:52 <npdoty> ... 2) link-fingerprinting is similar to a request from tobie about storing resources in local storage to prevent constant reloading over the network
13:33:04 <sangrae> sangrae has joined #crypto
13:33:13 <npdoty> ... 3) both want feedback from the crypto community, the security community and from the web app developer community
13:33:39 <npdoty> ... how can we get an adequate level of review that we're not sure that we have that you have received?
13:33:55 <npdoty> bhill2: document from the TAG, presented by larry masinter, as an input document
13:34:02 <tlr> tlr has joined #crypto
13:34:05 <npdoty> ... what are the security properties of the Web and what is the history of the model
13:34:20 <npdoty> ... might have more bandwidth available to pick up these non-normative and definitional documents
13:34:31 <rsleevi> q+
13:34:31 <npdoty> ... maybe something I should include in our rechartering discussions
13:34:56 <npdoty> ... room for joint work with web crypto
13:35:14 <npdoty> ... architecture documents that don't exist, like documenting what is CSRF
13:35:26 <drogersuk> q+
13:35:41 <npdoty> ... would be nice to have a real, peer-reviewed explanation rather than just pointing to (in the academic fashion) the first instance, which might just be a short blog post
13:36:14 <npdoty> [scribe not following this response]
13:36:34 <npdoty> bhill2: the hard part is canonicalizing the boundaries of signing
13:36:41 <virginie> q?
13:36:44 <hhalpin> q?
13:37:09 <npdoty> mike: JOSE specifically takes the position that no canonicalization will occur, just base64 everything including white space, so you can sign or encrypt anything without canonicalization
13:37:31 <DanD> +q
13:37:37 <hhalpin> I believe bhill2 said that "Yes, there are a lot of use-cases for integrity checks on content, but the problem is not API-level but on the level of the boundaries of said object in its context in the DOM"
13:37:37 <npdoty> bhill2: not sure that works for everything that looks like an HTTP resource
13:38:04 <npdoty> ... might care about more than just the body of the resource, including headers that affect the security properties
13:38:16 <npdoty> mike: if you're signing a structured thing you still have to solve the problem
13:38:47 <npdoty> bhill2: while I'm an advocate of "don't canonicalize, just sign the byte stream", I don't know if that will work here
13:39:21 <npdoty> mountie: which vendor is working as an implementer? @@@@
13:39:33 <JonathanJ1> JonathanJ1 has joined #crypto
13:40:08 <npdoty> bhill2: lots of implementations of CORS even in niche mobile browsers; CSP has both a Chrome and Firefox implementation; partial implementation of sandbox features by IE
13:40:18 <npdoty> ... Opera is a member, complete implementation of CORS, not sure about the other features
13:40:42 <npdoty> ... user interface safety built in a firefox plugin, and willingness to build in
13:40:44 <JonathanJ1> JonathanJ1 has joined #crypto
13:40:46 <rsleevi> ack mountie
13:41:05 <hhalpin> ack rsleevi
13:41:15 <shige___> shige___ has joined #crypto
13:41:26 <npdoty> rsleevi: opportunities for more overlap; within our current spec we're not addressing the "key" security concerns
13:41:48 <npdoty> ... things that you cannot consistently implement in a JS environment
13:41:52 <kotakagi> kotakagi has joined #crypto
13:41:57 <npdoty> ... but key security is critical in understanding the security model
13:42:11 <npdoty> ... using origin-based security for keys -- good because it's a consistent model
13:42:23 <npdoty> ... but potentially grants an entire origin the possibility to execute operations with keys
13:42:41 <npdoty> ... could use a path-based model like in cookies, or expiration
13:42:50 <tlr> relevant: http://w2spconf.com/2008/papers/s2p1.pdf
13:42:52 <hhalpin> Perhaps we should list our WebAppSec related issues
13:43:14 <npdoty> ... a similar concern (to CSRF) is going to exist with keys which are used to authenticate a particular request
13:43:33 <npdoty> ... if an app can perform a key operation, it might have the same technical effect as sending a particular cookie through
13:43:51 <hhalpin> http://www.w3.org/2012/webcrypto/track/issues/21 Requiring Content-Security-Policy
13:44:16 <npdoty> bhill2: we are chartered to do joint work with the ietf websec working group
13:44:22 <hhalpin> http://www.w3.org/2012/webcrypto/track/issues/26
13:44:31 <hhalpin> Should key generation be allowed to specify multi-origin shared access
13:44:32 <npdoty> ... justifying why CORS isn't making it worse, and writing up a non-normative document explaining why would be helpful
13:44:58 <npdoty> ... purview of the ietf websec group, with which you might want to have more formal liaisons
13:45:13 <npdoty> bhill2: certainly willing to provide security reviews
13:45:16 <hhalpin> http://www.w3.org/2012/webcrypto/track/issues/33: arify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario
13:45:23 <hhalpin> s/arify/clarify
13:45:25 <npdoty> ... finer-grained origins probably a bad bad idea
13:45:37 <virginie> q?
13:45:59 <DanD> DanD has joined #crypto
13:46:02 <npdoty> ... header that specifies which resources shouldn't be given access to the crypto (resources that are user-generated or somesuch)
13:46:10 <npdoty> ... send an email to our group's list documenting those use cases
13:46:15 <npdoty> ... something we're willing to consider
13:46:27 <hhalpin> q+
13:46:38 <npdoty> drogersuk: volunteered to build the threat/security model
13:46:54 <npdoty> ... based on the general feedback, developers see this inherent link between crypto and security
13:47:01 <npdoty> ... we have a direct dependency on the security model of the Web
13:47:10 <npdoty> ... should clearly map that out for some of our detractors to be able to answer them quickly
13:47:32 <npdoty> ... understand our level of robustness
13:47:50 <npdoty> ... can make a meaningful statement about what threat models we're protecting against
13:48:04 <npdoty> ... protecting media content vs. protecting dissidents in hostile countries, vastly different use cases
13:48:14 <npdoty> ack drogersuk
13:48:41 <npdoty> DanD: <shepazu/villager joke>
13:48:54 <npdoty> ... Web security for dummies documentation could be in the WebPlatform docs
13:49:05 <tlr> very good point
13:49:13 <hhalpin> q?
13:49:24 <npdoty> ... currently have just a stub, but we could have a lot of hierarchical documentation there
13:49:29 <drogersuk> +1 to Dan's points
13:49:30 <npdoty> ... that's where you could document the threats
13:49:50 <npdoty> npd: +1, and we've talked about that as a place for documenting privacy practices for Web developers as well
13:50:08 <npdoty> shepazu: like a11y, like i18n, should be documented across
13:50:24 <npdoty> ... happy to work with anybody to help make that a reality
13:50:46 <npdoty> ack DanD
13:51:26 <npdoty> hhalpin: would be good to get an opinion on these currently open issues so we can close them
13:51:45 <npdoty> issue-21?
13:51:45 <trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open
13:51:45 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/21
13:52:22 <npdoty> hhalpin: different opinions on these, is this orthogonal? is this something we need to guide implementers on?
13:52:24 <npdoty> issue-26?
13:52:24 <trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- open
13:52:24 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/26
13:52:26 <npdoty> issue-33?
13:52:26 <trackbot> ISSUE-33 -- Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario -- open
13:52:26 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/33
13:52:41 <npdoty> hhalpin: should we have some multi-origin key generation?
13:52:59 <npdoty> ... need to decide that at some point in the next year; could use feedback on
13:53:16 <hhalpin> opinion on these issues in IRC would be great even
13:53:17 <npdoty> virginie: can collaborate on our api security value
13:53:27 <npdoty> ... use cases on signing of javascript
13:53:31 <npdoty> ... review respective specs
13:53:40 <hhalpin> since the first is clearly related to how to do security considerations in general, even though it calls out CSP in particular
13:53:45 <npdoty> ... come to each other's groups regularly
13:53:50 <hhalpin> the second two are of course similar to issues brought up by CORS
13:53:51 <npdoty> ... ask for feedback on specific issues
13:54:01 <npdoty> ... at least we now know each other
13:54:28 <npdoty> <kicks everyone out :)>
13:54:37 <JonathanJ1> rrsagent, draft minutes
13:54:37 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
14:07:40 <mountie> mountie has joined #crypto
14:10:15 <mountie> mountie has joined #crypto
14:11:05 <bhill2> bhill2 has joined #crypto
14:11:22 <ekr> ekr has joined #crypto
14:11:49 <rbarnes> rbarnes has joined #crypto
14:12:09 <mountie> http://prezi.com/ic9jbxr7u0wq/present/?auth_key=gftap1b&follow=xcv2fpybjd1u
14:12:23 <Takahiro> Takahiro has joined #crypto
14:12:26 <rbarnes> rbarnes has joined #crypto
14:13:30 <MartinSoukup> MartinSoukup has joined #crypto
14:13:57 <wseltzer> Topic: WebCrypto API & Korea
14:14:02 <wseltzer> ScribeNick: wseltzer
14:14:25 <pal> pal has joined #crypto
14:14:26 <wseltzer> mountie: showing http://prezi.com/ic9jbxr7u0wq/present/?auth_key=gftap1b&follow=xcv2fpybjd1u
14:14:50 <wseltzer> ... credit card processing as common in Korea, using certificate previously issued to browser
14:15:18 <wseltzer> ... [screenshots: certificate, plug-in, user selects bank, enters info]
14:15:44 <wseltzer> ... [UI for national certificate-related plugins; user enters password]
14:16:39 <wseltzer> ... activeX plugin for Korean national government tax website; visit site, requests to install plugin
14:16:56 <ddahl> q+
14:16:58 <wseltzer> ... user clicks yes, next login attempt, another plugin requests to install
14:17:26 <wseltzer> ... loading time about 3min30
14:17:51 <bhill2> bhill2 has joined #crypto
14:17:52 <wseltzer> ... [video showing website: http://www.hometax.go.kr/]
14:18:05 <wseltzer> selfissued: accepting an activeX control
14:18:26 <wseltzer> mountie: another provider's plugin
14:18:46 <wseltzer> ... now, no more plugins required, users enter ID and password
14:18:51 <tlr> tlr has joined #crypto
14:19:48 <wseltzer> ... user gets requested to reboot os, then finally successfully logs in
14:20:46 <wseltzer> ... showing digital certificate stored in the user's environment; issued based on face-to-face verification at bank branch
14:21:01 <wseltzer> ... stored in smart card or @@
14:21:32 <wseltzer> ... users are educated to "yes" on all plugins, became a national security hole
14:22:46 <wseltzer> ... IE about 65%, so only 65% of users can make payments using this binary plugin
14:23:02 <wseltzer> selfissued: plugins don't work in other browsers?
14:23:07 <wseltzer> mountie: mostly, no
14:23:20 <wseltzer> ... plus, metroUI doesn't allow any plugins
14:23:41 <wseltzer> ... regulations force the use of binary plugins . EFTA, Consumer Protection Act, Privacy...
14:24:09 <wseltzer> [slide: technical requirements by regulations]
14:25:16 <wseltzer> mountie: slide shows how requirements currently met by ActiveX could be implemented in JS with WebCrypto
14:26:33 <wseltzer> mountie: requirements: identify and authenticate; encrypt transmission; non-repudiation; protect user environment
14:26:47 <sgodard> sgodard has joined #crypto
14:26:59 <wseltzer> ... on-screen keyboard=mouse-based visual keyboard
14:27:24 <wseltzer> ... to defeat screen-scrapers, one of the requirements randomizes keys
14:28:57 <wseltzer> ... [slide: special interests]
14:29:18 <virginie> virginie has joined #crypto
14:29:18 <wseltzer> ... SEED, Korean standard alternative to AES; Certificates
14:30:14 <wseltzer> ekr: threat model? who does the certificate validate?
14:30:34 <wseltzer> ... why do we need validation on the client-side?
14:30:51 <sgodard> sgodard has left #crypto
14:33:11 <virginie> q?
14:34:44 <wseltzer> ... only the browser chrome can check validity, not the JS provided by the site you want to check.
14:36:19 <hhalpin> q+
14:37:10 <wseltzer> rsleevi: or plugins, SysAPI-level, but not JS
14:37:31 <wseltzer> mountie: we want to minimize requests to users to verify
14:38:02 <rsleevi> correction: point was to use SysApps - but not exposed/implemented in content JS
14:39:06 <wseltzer> ekr: suggest an additional scoping restriction, to origin *and* national PKI
14:40:42 <wseltzer> ... if the security property you need is to have browser enforce that signatures in this system are only those from national PKI; JS validating server cert just can't work unless you're in sysapps-installed-apps mode
14:42:05 <virginie> q?
14:42:27 <ekr> What I would suggest is simply a signature mode which includes trusted attributes over the origin of the JS.
14:42:44 <tlr> ekr, q+?
14:43:01 <ekr> yeah, I guess so. q+
14:43:10 <tlr> q+ ekr
14:43:19 <bhill2> bhill2 has joined #crypto
14:43:33 <virginie> ack hhalpin
14:43:37 <wseltzer> q?
14:43:37 <wseltzer> q?
14:43:38 <wseltzer> dme
14:43:43 <rsleevi> ack ddahl
14:43:44 <wseltzer> s/dme//
14:44:16 <wseltzer> mountie: government is planning to revise regs
14:44:16 <wtc> wtc has joined #crypto
14:44:53 <wseltzer> mountie: current regs have two tracks: binary plugins and web applications audited by government committee
14:45:12 <wseltzer> ... second route instigated by iPhone
14:45:36 <wseltzer> ... 2010 regs changed to allow non-plugin electronic transactions
14:45:57 <virginie> q?
14:46:31 <wseltzer> ddahl: what's being typed in?
14:46:33 <Takahiro_> Takahiro_ has joined #crypto
14:46:36 <wseltzer> mountie: usually a password
14:47:08 <wseltzer> ddahl: probably encoded in Korean-language codepage
14:47:28 <wseltzer> ... also, all these URLs are http. Is there lots of fraud?
14:48:43 <wseltzer> mountie: hacking and keylogging is a problem
14:49:34 <wseltzer> ekr: it would be useful to describe the threat model and implied security demands, rather than starting from the end of the tentacle as the system is currently designed
14:49:45 <virginie> q?
14:49:51 <wseltzer> ack ekr
14:52:34 <wseltzer> q+
14:53:25 <rsleevi> q+
14:53:36 <rsleevi> ack wseltzer
14:54:07 <hhalpin> We can check digital signatures with pre-provisioned keys I think.
14:54:33 <wseltzer> wseltzer: let's try to understand the problem and its security requirements off-line
14:55:00 <wseltzer> rsleevi: we want to help; we don't want to help by implementing insecure "solutions"
14:55:06 <virginie> Q+
14:55:11 <wseltzer> ack rsleevi
14:56:06 <wseltzer> rsleevi: it would be bad if we just tried to implement what exists in CryptoAPI; let's try to find the solution broader than WebCrypto
14:58:00 <hhalpin> q+
14:58:28 <tlr> ScribeNick: tlr
14:58:31 <tlr> mountie: @@
14:58:37 <kotakagi> kotakagi has joined #crypto
14:58:44 <tlr> rsleevi: as implementer, something we care a lot about. Would like good solution on technical merits.
14:58:55 <tlr> ... not sure if there's an action item -- there is engagement to be ha
14:58:58 <tlr> s/ha/had
14:59:07 <tlr> ... would like to be sure we can implement or deploy
14:59:14 <tlr> ... maybe an action item to take
14:59:42 <tlr> ... don't think the way things are done today aren't good technically
14:59:43 <tlr> q+
14:59:54 <tlr> mountie: don't expect every browser vendor to implement it
15:00:03 <tlr> ... work on alternatives
15:00:14 <tlr> ... if vendors are ever to implement, then that would be beneficial
15:00:58 <hhalpin> its a prezi, so I believe mountie could add the URI to IRC once he has a sec
15:01:19 <tlr> virginie: still important to understand use case better, then we can understand solution better
15:01:50 <ekr> q+
15:01:58 <tlr> virginie: recommended minimum set of algorithms -- not sure that was part of list?
15:02:03 <tlr> ... has to be discussed further
15:02:08 <JonathanJ1> rrsagent, draft minutes
15:02:08 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
15:02:12 <hhalpin> SEED was not part of the list, I think SEED is in Firefox, but is it in Webkit?
15:02:16 <tlr> ... think it's feasible to at least describe the algorithms you would need
15:02:27 <tlr> ... certificate management is a borderline feature
15:02:54 <tlr> ... signed javascript?
15:02:57 <tlr> mountie: webappsec?
15:03:27 <tlr> mountie: want to find out how to allow multi-origin access
15:03:35 <tlr> ... can discuss more
15:03:49 <tlr> virginie: discussed with Brad Hill about signed JavaScript
15:03:55 <hhalpin> So SEED support is not currently an outstanding issue for at least desktop, but is a problem for mobile rsleevi?
15:04:08 <tlr> ... important question - what are boundaries of code so you sign appropriate information?
15:04:15 <ekr> I don't have a problem with assigning a code point for SEED, but I hardly think it's appropriate to recommend it.
15:04:18 <tlr> ... @@
15:04:24 <rsleevi> hhalpin: Requiring SEED won't work, but I am 100% supportive of specifying how SEED should behave IF a UA implements it
15:04:43 <hhalpin> I guess what I'm trying to figure out is should we add SEED to the API as an option, although not in the minimum required set.
15:04:49 <virginie> q?
15:04:52 <tlr> mountie: interesting in JS functions - JS validation, require complex design.  How protect js code?
15:04:54 <virginie> ack virginie
15:04:58 <rbarnes> hhalpin: i didn't know we had a minimum required set
15:05:04 <rsleevi> hhalpin: And I'm saying yes, we should. Mountie has made a proposal to the list to do just that, and I have no objection to it
15:05:07 <ekr> rbarnes: I don't think so.
15:05:09 <tlr> q- later
15:05:12 <hhalpin> ack hhalpin
15:05:24 <rbarnes> in fact, i thought we explicitly said we *weren't* going to have any required algorithms
15:05:33 <tlr> hhalpin: want to be clear about what can and can't do
15:06:09 <tlr> ... digital signature component might be part of this
15:06:23 <tlr> rsleevi: web crypto is a component part of any solution that is meaningful to Korean use case
15:06:25 <ekr> seed is an alternative to AES
15:06:54 <rsleevi> q+
15:06:56 <tlr> hhalpin: not quite sure where in the flow seed is at
15:06:57 <tlr> q- later
15:07:13 <tlr> ack rsleevi
15:07:25 <tlr> rsleevi: support adding seed -- any algorithm that is meaningful
15:07:34 <hhalpin> However, would adding SEED actually help this use-case?
15:07:38 <tlr> ... there are things that can't be done in JS, but Web Crypto is well positioned to do.
15:07:42 <ekr> ROT13
15:07:53 <hhalpin> We could add SEED as a matter of principle, but having a use-case would help.
15:07:57 <ekr> Actually, we should do triple-ROT13. It's more secure
15:08:39 <virginie> q?
15:08:41 <tlr> ack ekr
15:08:55 <tlr> ekr: no problem adding SEED
15:09:06 <tlr> ... any algorithm that is plausibly defined
15:09:15 <tlr> ... I would have problems with very weak algorithms
15:09:48 <tlr> ... certificate thing- very marginal case for any application I have seen yet
15:10:01 <tlr> ... that brings us down to signed JS -- that belongs in sysapps
15:10:35 <virginie> q?
15:10:40 <tlr> ... SEED should be optional, not recommended
15:11:11 <ekr> my point is that certificates should be a tertiary feature
15:11:58 <wseltzer> tlr: many countries with similar requirements and similar flaws; opportunity to get together to understand the requirements better
15:12:21 <wseltzer> ... among implementers, country-based participants
15:12:52 <wseltzer> ... window of opportunity to understand this set of markets and their needs
15:13:09 <hhalpin> one way to operationalize this, off the top of my head, would be to detail out the use-case
15:13:17 <wseltzer> ... W3C could help to provide a forum, CG or BG; we'd need help from implementers and contacts
15:13:25 <hhalpin> and then seeing if we need to drag in other WGs from both IETF and W3C
15:13:32 <wseltzer> virginie: Arun compiling use-cases
15:13:50 <wseltzer> rsleevi: as implementers, we've been having these conversations, we think it's important
15:14:10 <wseltzer> ... as far as timing, start with the places API can be ussable now
15:14:11 <hhalpin> and then if that goes through, there's always the possibility of a W3C workshop in the future on this particular topic, not just for Korea but for similar countries
15:14:15 <virginie> q?
15:14:20 <virginie> ack tlr
15:14:21 <tlr> ack t
15:15:00 <ekr> q+
15:15:07 <hhalpin> So I think I am hearing we get an action to add SEED as an option?
15:15:12 <wseltzer> ack ekr
15:15:13 <tlr> yes
15:15:14 <rsleevi> q+
15:15:32 <wseltzer> ekr: Certificates are a tertiary feature
15:15:36 <rsleevi> +1
15:15:39 <hhalpin> rsleevi, you happy with an action to add SEED?
15:15:49 <rsleevi> @hhalpin: Yes
15:15:52 <rsleevi> q-
15:15:53 <wseltzer> virginie: we'll work on the use cases.
15:16:00 <wseltzer> ... Thank you, mountie
15:16:11 <selfissued> q+
15:16:26 <hhalpin> ACTION: rsleevi to add SEED to WebCrypto API
15:16:26 <trackbot> Created ACTION-64 - Add SEED to WebCrypto API [on Ryan Sleevi - due 2012-11-09].
15:16:47 <wseltzer> selfissued: that video looks very complicated. How many Korean users can get through it?
15:17:02 <wseltzer> mountie: Korean users are well-experienced clicking-through
15:17:22 <JonathanJ1> mountie's demo is very normal case in korea.
15:17:57 <wseltzer> rsleevi: there are many moving parts here, we want to get it right
15:18:10 <odinho_> odinho_ has left #crypto
15:19:02 <wseltzer> [break]
15:30:34 <npdoty> npdoty has joined #crypto
15:33:37 <ekr> ekr has joined #crypto
15:33:47 <rbarnes> rbarnes has joined #crypto
15:34:17 <rbarnes> rbarnes has joined #crypto
15:34:32 <yune> yune has joined #crypto
15:35:08 <mountie> mountie has joined #crypto
15:35:38 <wseltzer> ScribeNick: wseltzer
15:35:53 <wseltzer> Topic: Wrap Up
15:36:02 <hhalpin> hhalpin has joined #crypto
15:36:07 <wseltzer> virginie: I was planning a summary, but my brain is fried
15:36:44 <wseltzer> ... take-aways:
15:36:50 <wseltzer> ... address a few logistics issues
15:37:08 <hhalpin> notes that we also had a request to change meeting times
15:37:32 <wseltzer> ... next F2F. I'm used to 4x/year, but W3C tends towards less frequent.
15:37:45 <MartinSoukup> MartinSoukup has joined #crypto
15:38:38 <wseltzer> rsleevi: I'd suggest East Coast; estark, rbarnes
15:38:46 <wseltzer> rbarnes: I could look at Boston options
15:38:57 <wseltzer> ddahl: Mozilla Toronto
15:38:59 <rbarnes> … or dc
15:39:13 <wseltzer> mountie: We could host in Korea
15:39:26 <wseltzer> virginie: Looking at March dates
15:39:34 <wseltzer> rbarnes: IETF is March 10-15
15:40:06 <wseltzer> [Orlando, Florida]
15:40:45 <hhalpin> March 9-17 is SXSW
15:40:46 <wseltzer> virginie: I'll organize a poll for where/when
15:41:10 <hhalpin> We can be flexible, we don't have to meet exactly every 4 months, but a few weeks in or out should be fine
15:41:22 <wseltzer> ... Next, conference call timing; old action item to look for time that's better for Asian participants
15:41:46 <wseltzer> ... What about 8AM San Francisco; 11 Boston; 1600 France; midnight Korea
15:42:10 <wseltzer> hhalpin: 8 is possible but early for west coast
15:43:34 <hhalpin> It does not sound early but I have noticed last time that I tried to do a WG with this proposal people fell off.
15:44:18 <JonathanJ1> I think we can host next F2F meeting in Seoul.
15:44:34 <JonathanJ1> we were already hosted many W3C WG meeting. DAP WG, Media Annotation, MWBP WG ...
15:44:41 <ddahl> JonathanJ1: yay!
15:45:20 <hhalpin> I think its important people are realistic about their attendance at very late or very early hours
15:45:31 <wseltzer> mountie: midnight or 1 am would be possible
15:45:34 <hhalpin> Not just possible, but something that can be done weekly
15:46:14 <hhalpin> I'd like to hear from the rest of the participants outside of Mountie if possible?
15:46:46 <wseltzer> virginie: progress. high-level API to come back in one month with timeline
15:47:09 <wseltzer> ... priority in conference call; low-level API and use-cases; then in one month, change to high-level
15:47:21 <wseltzer> ... Dec., check status for next working draft
15:47:28 <hhalpin> 3 month heartbeat requirement puts us around new years
15:47:40 <wseltzer> ... by Christmas we'll need another draft.
15:47:43 <virginie> q?
15:48:12 <virginie> ack selfissued
15:48:54 <wseltzer> mountie: other volunteers in China; midnight better than 1 am
15:49:20 <wseltzer> virginie: thanks to the scribes
15:49:25 <ddahl> wseltzer: +1
15:49:40 <wseltzer> ... next Monday's meeting is canceled
15:49:57 <wseltzer> ... Next meeting: Nov. 12 at usual time 1900 UTC.
15:50:19 <JonathanJ1> how about make a questionary for next F2F schedule decision ?
15:50:50 <wseltzer> virginie: I've noted that on my 25-item action list
15:51:01 <JonathanJ1> rrsagent, draft minutes
15:51:01 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html JonathanJ1
15:51:23 <wseltzer> thanks to Virginie, Ryan, editors
15:51:26 <wseltzer> [applause]
15:51:35 <wseltzer> rrsagent, draft minutes
15:51:35 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html wseltzer
15:51:40 <wseltzer> trackbot, end meeting
15:51:40 <trackbot> Zakim, list attendees
15:51:40 <Zakim> sorry, trackbot, I don't know what conference this is
15:51:48 <trackbot> RRSAgent, please draft minutes
15:51:48 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-crypto-minutes.html trackbot
15:51:49 <trackbot> RRSAgent, bye
15:52:03 <wseltzer> RRSAgent, make record public
15:52:08 <wseltzer> rrsagent, bye
15:52:08 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2012/11/02-crypto-actions.rdf :
15:52:08 <RRSAgent> ACTION: rsleevi to add SEED to WebCrypto API [1]
15:52:08 <RRSAgent>   recorded in http://www.w3.org/2012/11/02-crypto-irc#T15-16-26