07:38:53 <RRSAgent> RRSAgent has joined #crypto
07:38:53 <RRSAgent> logging to http://www.w3.org/2012/11/01-crypto-irc
07:38:55 <trackbot> RRSAgent, make logs webcrypto
07:38:55 <markw_> markw_ has joined #crypto
07:38:55 <Zakim> Zakim has joined #crypto
07:38:57 <trackbot> Zakim, this will be SEC_WebCryp
07:38:57 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
07:38:58 <trackbot> Meeting: Web Cryptography Working Group Teleconference
07:38:58 <trackbot> Date: 01 November 2012
07:39:07 <wseltzer> Chair: Virginie Galindo
07:39:58 <pal> pal has joined #crypto
07:40:27 <rsleevi> rsleevi has joined #crypto
07:41:36 <selfissued> How did it feel, Virginie?
07:43:49 <rsleevi> http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012
07:43:55 <ddahl> ddahl has joined #crypto
07:44:06 <rsleevi> http://www.w3.org/2012/webcrypto/track/
07:44:15 <rsleevi> Agenda & Issues, respectively
07:45:00 <christine_> christine_ has joined #crypto
07:45:10 <mountie> mountie has joined #crypto
07:45:19 <jin> jin has joined #crypto
07:45:24 <ttanaka2> ttanaka2 has joined #crypto
07:46:11 <rsleevi> Present+ Ryan_Sleevi
07:47:01 <Milan> Milan has joined #crypto
07:49:11 <rsleevi> Present+ olivier, Gemalto
07:49:26 <rsleevi> Present+ David_Rogers, invited expert
07:49:44 <rsleevi> Present+ Wendy_Seltzer, W3C
07:50:14 <rsleevi> Present+ Wan_Teh_Chang, Google
07:50:39 <rsleevi> Present+ David_Dahl, Mozilla
07:51:35 <sangrae> sangrae has joined #crypto
07:51:59 <rsleevi> Present+ Mountie_Lee, Paygate/Mobile Web Forum
07:52:33 <rsleevi> Present+ Mike_Jones, Microsoft
07:56:25 <rsleevi> Present+ Virginie_Galindo, Gemalto
07:57:09 <wtc> wtc has joined #crypto
07:58:29 <rsleevi> virginie: Agenda overview, scribe hunting
07:58:45 <rsleevi> Present+ Richard_Barnes, BBN
07:58:57 <hhalpin> hhalpin has joined #crypto
07:59:02 <rsleevi> scribenick: selfissued
07:59:05 <rsleevi> scribe: Mike_Jones
07:59:19 <amirabella> amirabella has joined #crypto
07:59:23 <markw_> Is it possible to avoid the key format discussions overlapping with the Encrypted Media and Media Source discussions in HTML ?
07:59:42 <markw_> I will can you exactly when those are scheduled shortly
07:59:46 <hhalpin> agenda+ status
07:59:51 <hhalpin> agenda+ usability
07:59:56 <hhalpin> agenda+ keyformat
08:00:03 <hhalpin> agenda+ implementations
08:00:05 <hhalpin> agenda+ usecases
08:00:11 <selfissued> Mike Jones - I am the scribe for this hour
08:00:34 <hhalpin> trackbot start meeting
08:00:44 <wseltzer> [agenda on the wiki: http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0149.html ]
08:00:54 <wseltzer> [http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012#Proposed_agenda]
08:00:56 <hhalpin> tpacbot, start meeting
08:02:00 <hhalpin> chair: virginie_gallindo
08:02:04 <hhalpin> scribe: selfissued
08:02:50 <drogersuk> Present+ David_Rogers
08:03:27 <selfissued> Virginie: We want to understand what our disagreements are and why we have them
08:03:55 <selfissued> ... We have lots of open issues - we should be creating actions during this meeting to close them
08:04:16 <selfissued> The WG can eat together at Bouchon lyonnais
08:04:31 <rsleevi> http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012
08:04:43 <virginie_galindo> https://www.w3.org/2012/10/TPAC/live/schedule/
08:04:47 <wseltzer> [tpac live app https://www.w3.org/2012/10/TPAC/live/schedule]
08:04:53 <selfissued> Sign up for dinner at the URL above by noon
08:06:11 <JonathanJ1> JonathanJ1 has joined #crypto
08:07:33 <selfissued> Mountie:  Asks us to consider call times that work for Asian members
08:07:56 <wseltzer> wseltzer has changed the topic to: WebCrypto F2F. call-in code 1932#
08:08:03 <kotakagi> kotakagi has joined #crypto
08:08:05 <rbarnes> rbarnes has joined #crypto
08:08:12 <JonathanJ1> Present+ Jonathan_Jeon
08:08:38 <JonathanJ1> rrsagent, draft minutes
08:08:38 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
08:08:44 <selfissued> We have 53 group participants
08:08:50 <selfissued> We have 11 invited experts
08:08:55 <selfissued> We have 20 organizations
08:09:04 <kotakagi> kotakagi has left #crypto
08:09:11 <selfissued> We have 10-20 participants in each call
08:09:23 <selfissued> We have 17 group members registered for this F2F
08:10:12 <selfissued> We have a 2 year charter
08:10:33 <selfissued> Virginie: FWPD draft published
08:10:39 <selfissued> ... very few formal comments
08:10:54 <selfissued> ... Formal comments from Oxford, DT
08:11:16 <selfissued> ... Some informal comments in tweets, etc. criticizing the premise behind the work
08:11:37 <selfissued> ... We have 30 open issues and 9 high-priority issues
08:11:41 <bjkim> bjkim has joined #crypto
08:12:26 <selfissued> ... They are sorted into specific domains: crypto, functional, design, key, definition, next usability
08:12:28 <wseltzer> [issues list: http://www.w3.org/2012/webcrypto/track/issues/open?sort=product ]
08:12:46 <Wonsuk> Wonsuk has joined #crypto
08:12:53 <selfissued> ... We have a wiki with use cases and an editor for it - Arun from Mozilla
08:13:36 <selfissued> ... We are almost ready to make a blog post about the work
08:14:04 <selfissued> ... Proposed next steps for two upcoming months
08:14:19 <selfissued> ... Publish a new working draft incorporating solved issues
08:14:25 <selfissued> ... Create a use case specification
08:14:37 <hhalpin> blogpost will be posted as soon as tlr gets a chance to look over a version, happy to discuss his issues first thing in the morning
08:14:39 <selfissued> ... Create a draft security document
08:14:48 <timeless> timeless has joined #crypto
08:14:59 <selfissued> ... Possibly a draft high level API description
08:16:01 <selfissued> Mike:  We would need to decide whether to have a high-level API at all or not at this point
08:16:32 <rsleevi> priority list: https://docs.google.com/spreadsheet/ccc?key=0Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E#gid=0
08:17:15 <selfissued> Mountie:  Asked about issue prioritization
08:17:37 <selfissued> Virginie:  Certificate management is currently categorized as a secondary feature
08:18:07 <selfissued> Virginie:  The working group is contribution based
08:19:31 <selfissued> At this point in the agenda, Ryan Sleevi will give an overview of the state of the API
08:22:43 <selfissued> Ryan: Goal recommendation-track specification
08:22:49 <wseltzer1> wseltzer1 has joined #crypto
08:23:02 <selfissued> ... Long list of primary features
08:23:21 <selfissued> ... Also list of secondary features
08:23:36 <selfissued> ... (Many of the secondary features about keys and key management)
08:23:49 <selfissued> ... Why are there so many features?
08:24:51 <selfissued> ... Today Web Apps have JavaScript that runs in a browser
08:25:10 <selfissued> ... Today most Web Apps use cryptography only through SSSL
08:25:33 <selfissued> ... Today a few have JavaScript crypto libraries
08:26:42 <selfissued> ... Today native apps can use crypto without even being aware of it, such as protected storage
08:26:45 <tpacbot> tpacbot has joined #crypto
08:27:29 <tlr> tlr has joined #crypto
08:27:36 <selfissued> ... Some native apps use crypto APIS such as CAPI, CNG, CDSA, CC, PKCS#11, etc.
08:28:03 <selfissued> ... Some native apps use software and smart card cryptographic providers
08:29:14 <selfissued> ... The full picture can be even more complex, including NFC, Bluetooth, USB, ISA, Smart Card, PC/SC, etc.
08:29:30 <selfissued> ... Sometimes national crypto features as well
08:30:46 <selfissued> ... In Asia and Europe, often browser plugins used to give access to native crypto implementations
08:31:53 <selfissued> ... Plugins are not the future
08:32:04 <selfissued> ... They will not work across mobile browsers, etc.
08:32:32 <selfissued> ... Standards are often set on a national basis
08:32:55 <selfissued> ... We need to understand the problem space to produce a workable solution
08:33:05 <selfissued> ... The problem space is huge
08:33:57 <selfissued> ... Tomorrow Web Apps should be able to use crypto without being highly aware of it (just like native apps today)
08:34:17 <selfissued> ... Tomorrow Web Apps should be able to directly use crypto APIs (just like native apps today)
08:35:17 <selfissued> ... There are lots of other W3C efforts that relate to this
08:35:44 <selfissued> ... Web intents, accessibility, UI, NFC, Smart Card API, etc.
08:36:08 <Wonsuk> Wonsuk has left #crypto
08:37:07 <markw> markw has joined #crypto
08:37:26 <selfissued> ... Lots of middleware in W3C WGs
08:37:50 <selfissued> ... Gemalto will be proposing a smart card API in another WG
08:38:13 <selfissued> ... We want to move from plugin-based solutions to standards-based solutions
08:38:22 <virginie_galindo> q+
08:39:53 <wtc> wtc has joined #crypto
08:41:32 <selfissued> Ryan:  Combined, the different W3C APIs and efforts can provide a rich standards-based Web App platform
08:41:43 <selfissued> ... We shouldn't feel like we have to do everything
08:44:14 <JonathanJ1> rrsagent, draft minutes
08:44:14 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
08:44:33 <hhalpin> q+
08:44:51 <selfissued> Virgine: We should use the work of other WGs to drive UI decisions - not make them ourselves
08:46:53 <selfissued> Ryan: One current hole is key storage
08:47:13 <selfissued> ... We may need UI to inform users that the web application has access to sensitive information
08:47:51 <selfissued> ... Some UI elements, such as presentation of document to sign, may be the subject of national standards
08:48:41 <selfissued> David Rogers:  What levels of assurance do we think are achievable?
08:49:23 <selfissued> Ryan:  We need to assure that what is shown to the user is what is actually acted upon
08:49:45 <selfissued> ... For instance, sending $100, rather than saying that $100 is being sent and actually sending $1000
08:50:23 <selfissued> ... We may want to capture some of this through Web intents
08:51:06 <selfissued> q+
08:52:23 <selfissued> Ryan: We need to prevent the intent provider from being owned
08:52:35 <selfissued> ... This is being addressed in the Web App sec WG
08:53:20 <selfissued> David: Criminals do client side attacks
08:53:27 <wseltzer> q?
08:53:31 <wseltzer> ack hhalpin
08:53:37 <selfissued> ... Our security model needs to encompass this
08:54:34 <selfissued> Harry: We split the Crypto API work out of the WebApp security work, but we still depend upon WebAppSec
08:55:33 <selfissued> David: We need to clearly state our security considerations to do a professional job
08:58:23 <selfissued> Mike: Does the web intent and UI work you're describing result in work for this WG?
08:58:48 <selfissued> Ryan: No, my point was that end-to-end solutions will necessarily depend upon work in other WGs as well
08:59:20 <selfissued> (the WG is now taking a 15 minute break)
09:13:33 <wseltzer> rrsagent, draft minutes
09:13:33 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html wseltzer
09:13:43 <RRSAgent> I'm logging. I don't understand 'make minutes public', wseltzer.  Try /msg RRSAgent help
09:14:06 <trackbot> Sorry, wseltzer, I don't understand 'trackbot, make logs public'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.
09:14:44 <wseltzer> ISSUE-12?
09:14:44 <trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open
09:14:44 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/12
09:14:49 <wseltzer> ISSUE-14?
09:14:49 <trackbot> ISSUE-14 -- Representation of raw key material -- open
09:14:49 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/14
09:14:50 <rbarnes> rbarnes has joined #crypto
09:14:54 <wseltzer> ISSUE-19?
09:14:54 <trackbot> ISSUE-19 -- Does it make sense to have authorized-origin and specific-origin keys -- open
09:14:54 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/19
09:14:58 <rbarnes> hello, i will be your scribe this hour
09:15:05 <wseltzer> scribenick: rbarnes
09:15:06 <rbarnes> virginie: intro
09:15:30 <rbarnes> ddahl: <getting presentation set up>
09:15:52 <cjkula> cjkula has joined #crypto
09:16:09 <JonathanJ1> JonathanJ1 has joined #crypto
09:16:25 <rbarnes> selfissued: suggest people who didn't introduce themselves introduce themselves
09:16:47 <rbarnes> mark, harry, cjkula, rbarnes
09:17:18 <rbarnes> ddahl: as we're working through these usability issues, keep in mind things like code examples
09:18:17 <rbarnes> … don't know any web developers who could use the API today
09:18:26 <rbarnes> … that's OK, but we should keep that in the back of our heads
09:20:02 <rbarnes> hhalpin: to rsleevi: what is your feeling on high level vs. low level
09:20:14 <drogersuk> drogersuk has joined #crypto
09:20:18 <rbarnes> rsleevi: probably part of a holistic look at the API and how we make it easier to use
09:20:42 <virginie_galindo> q?
09:20:54 <virginie_galindo> ack selfissued
09:20:57 <rbarnes> ddahl: i'm also keeping in mind that there will be a "jQuery of web crypto" to create abstractions
09:21:06 <rbarnes> … so we don't need to address everything here
09:21:28 <rbarnes> rsleevi: it creates more objects to be defined, could get back into the problems with key generation/derivation
09:21:39 <rbarnes> … creating ontologies and applying them consistently is a hard problem
09:21:46 <rbarnes> … algorithm vs. operation is a tricky question
09:22:02 <rbarnes> … e.g. if you're only using the objects once, maybe it's not even meaningful
09:22:15 <virginie_galindo> q+
09:22:51 <rbarnes> wtc: it's clear that certain things belong to operation, e.g., IV
09:23:13 <rbarnes> … so if we make IV a parameter of the algorithm identifier, we run into problems with algorithm comparison
09:24:11 <rbarnes> mountie: the current spec has many algorithms, but there are lots of others
09:24:25 <rbarnes> … e.g., Korea has several local algorithms
09:24:45 <rbarnes> … updating specs can be difficult, maybe separating things could help adaptability
09:25:06 <rbarnes> virginie_galindo: we decided as WG that we are going to recommend some algorithms and describe them a bit more
09:25:15 <rbarnes> … we know we can't address all the algorithms in the world
09:25:16 <rsleevi> q+ to respond to mountie
09:25:23 <rbarnes> … but we need to provide some guidance to web developers
09:25:28 <selfissued> q+
09:27:02 <markw> q+
09:27:02 <hhalpin> q+
09:27:05 <Zakim> rsleevi, you wanted to respond to mountie
09:27:24 <rbarnes> rsleevi: quick response to mountie: sounds like that issue is slightly different than what we're discussing
09:27:37 <rbarnes> … more about document organization / modularization, do that later
09:28:08 <rbarnes> … in response to wtc on algorithm normalization: don't think it requires a change to the rules
09:28:17 <virginie_galindo> q?
09:28:25 <rbarnes> … the normalization rules were our jacky way to deal with using strings in some places and not others
09:28:35 <rbarnes> s/jacky/hacky/
09:29:59 <rbarnes> … this issue is about calling convention
09:30:18 <rbarnes> selfissued: in terms of doc organization, we should be very clear about what things are part of the algorithm vs. which are data
09:30:34 <rbarnes> … e.g., mgf vs. iv / authenticated data
09:30:54 <rbarnes> … don't have a strong opinion on the need to separate as a calling convention, but should be clear editorially
09:31:27 <wtc> wtc has joined #crypto
09:31:41 <wtc> q+
09:31:50 <rbarnes> markw: pretty confusing when people look at this at first and see all this stuff in AlgorithmIdentifier
09:31:59 <rsleevi> q+
09:32:17 <wseltzer> ack selfissued
09:32:18 <wseltzer> ack markw
09:32:18 <markw> q-
09:32:29 <wseltzer> ack hhalpin
09:32:41 <rbarnes> hhalpin: from a process standpoint, agree with ryan that this is part of a larger usability issue
09:32:48 <rbarnes> … should we just have the usability discussion now?
09:33:05 <rbarnes> … what we need in the spec is, what is the larger pattern / anti-pattern for parameterization?
09:33:44 <ddahl> q+
09:33:57 <rbarnes> … my intuition is that keeping operations separate kind of makes sense, but it also makes things more complicated
09:34:15 <hhalpin> ack hhalpin
09:34:16 <rbarnes> virginie_galindo: you're looking at ryan, but everybody should be concerned
09:34:31 <wseltzer> ack wtc
09:34:54 <rbarnes> wtc: seems a little extreme to have to make two dictionaries just to do a simple CBC operation
09:35:11 <rbarnes> … if i want an AES-CBC mode key, don't want to specify an IV parameter
09:35:13 <markw> q+
09:35:29 <rbarnes> … maybe we should separate namespaces for "key algorithms" and "operation algorithms"
09:35:33 <wseltzer> ack rsleevi
09:35:54 <rbarnes> rsleevi: feedback from i've received from internal developers is that the use of a single dictionary is seen as a natural point
09:36:10 <rbarnes> … many APIs are preferring dictionaries over positional arguments
09:36:30 <rbarnes> … i wouldn't worry about using dictionaries here
09:36:49 <rbarnes> … to respond to wt.'s point, we do have some separation now, between key generation parameters and operation parameters
09:37:01 <rbarnes> selfissued: could we project the part of the spec that says that?
09:37:41 <virginie_galindo> example of issue impact http://www.w3.org/2012/webcrypto/WebCryptoAPI/ section 24.3.2
09:38:28 <rbarnes> rsleevi: <projects, shows RSAKeyGenParams>
09:38:37 <rbarnes> … so there is some separation now
09:38:45 <virginie_galindo> q?
09:38:53 <rbarnes> … in a broader sense of improving usability, let's get some concrete proposal
09:39:06 <rbarnes> … if we're going to split, then someone needs to propose text
09:39:46 <rbarnes> … absent a proposal, we're going to continue to circle on this
09:40:21 <rbarnes> ddahl: was going to say the same thing that wtc did
09:40:26 <wseltzer> ack ddahl
09:40:29 <wseltzer> ack markw
09:40:47 <rbarnes> markw: we can talk about whether it's a good idea in principle, then someone can go off and write something specifc
09:41:03 <rbarnes> … you could even go as far as creating an Algorithm object
09:41:27 <rbarnes> … regarding things like AES keys, could be useful to separate key algorithms from operational algorithms
09:41:31 <rsleevi> q+
09:41:49 <rbarnes> … my implementors were like "there's no such thing as an AES-CTR key, there's an AES key"
09:41:56 <wseltzer> ack rsleevi
09:42:05 <rbarnes> rsleevi: that's a separate point, and a reasonable one to discuss
09:42:12 <rbarnes> … don't want to mix keys in some spaces
09:42:44 <rbarnes> … when you're dealing with an implementation's cryptographic spec, does it support CBC but not CTR
09:42:48 <rbarnes> … or not GCM
09:43:12 <rbarnes> … you could create a key for GCM, but not be able to use it
09:43:47 <rbarnes> … for AES, it's less of a big deal, for asymmetric, might waste a lot of time on keygen if say there's no OAEP
09:43:52 <virginie_galindo> q?
09:43:56 <rbarnes> markw: well, there should be capability discovery
09:44:08 <virginie_galindo> agenda?
09:44:08 <rbarnes> rsleevi: for now, the key is the starting point for capability discovery
09:44:27 <rbarnes> … if we're going to revisit discovery, we would need some proposals
09:44:53 <rbarnes> … the way that it works today is that trying to initialize the operation is the point at which you learn about unsupported algorithms
09:45:16 <rbarnes> rogers: isn't that kind of inefficient?
09:45:44 <rbarnes> rsleevi: yes, kind of.  but you might not find out until operation time (e.g., with a smart card)
09:45:45 <virginie_galindo> q?
09:46:24 <rbarnes> … this starts to move toward secondary features, like multiple key stores and how to deal with that
09:47:05 <rbarnes> virginie_galindo: who would like to volunteer to improve the parameters / identifiers
09:47:09 <rbarnes> <wtc volunteers>
09:47:39 <rbarnes> wtc: want to propose a solution, but it might not separate operational parameters
09:47:51 <rbarnes> … see a hole in the current editor's draft in specifying parameters for key generation
09:48:04 <rbarnes> rsleevi: that's not the ISSUE-12 problem, that's a new problem
09:48:58 <rbarnes> hhalpin: maybe wtc can solve ISSUE-12 while he's at it
09:49:07 <rbarnes> virginie_galindo: markw and etc can work together
09:49:36 <rsleevi> s/etc/wtc/
09:49:52 <rsleevi> ACTION Wan-Teh and Mark to work on proposal for ISSUE-12
09:49:53 <trackbot> Created ACTION-58 - And Mark to work on proposal for ISSUE-12 [on Wan-Teh Chang - due 2012-11-08].
09:58:31 <kotakagi> kotakagi has joined #crypto
10:05:04 <pal> pal has joined #crypto
10:05:49 <tlr> tlr has joined #crypto
10:09:08 <markw> markw has joined #crypto
10:11:06 <ttanaka2> ttanaka2 has joined #crypto
10:12:06 <slightlyoff> slightlyoff has joined #crypto
10:14:27 <wtc> wtc has joined #crypto
10:15:08 <rsleevi> scribenick: wtc
10:15:25 <selfissued> To sign up for dinner, log in at https://www.w3.org/2012/10/TPAC/live/schedule and click on the start next to "Web Crypto WG dinner" so that the star turns gold
10:15:52 <wtc> virginie_galindo: in this session we will start with usability and then switch to key formats.
10:16:03 <rsleevi> ISSUE-14?
10:16:03 <trackbot> ISSUE-14 -- Representation of raw key material -- open
10:16:03 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/14
10:16:32 <wtc> ddahl: ISSUE-14: representation of raw key material. We are going back and forth on how to represent key material.
10:16:59 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html rsleevi
10:17:17 <wtc> ddahl: ASN.1 DER seems natural for a low-level API, but JSON should also be supported. Perhaps there should be a way to convert between the formats.
10:17:59 <virginie_galindo> q?
10:18:00 <rbarnes> q+
10:18:03 <wtc> ddahl: are there any key types that can't be represented in JSON?
10:18:24 <rsleevi> q+
10:18:31 <selfissued> q+
10:18:49 <hhalpin> hhalpin has joined #crypto
10:18:50 <wseltzer> tantek: is this meant to cover the use-case of someone posting public key on a web page?
10:18:51 <wtc> Celik: will this allow people to publish their public keys on their websites?
10:19:10 <olivier> q+
10:19:15 <hhalpin> My thinking re key publication is that folks will keep using armored ASCII key encryption of their public keys
10:19:32 <hhalpin> This is more app-facing
10:19:35 <rsleevi> @hhalpin: You mean the form that is not specified/standardized anywhere?
10:19:35 <markw> q+
10:19:39 <virginie_galindo> q?
10:19:51 <ekr> ekr has joined #crypto
10:19:54 <ekr> q+
10:20:02 <wtc> ddahl: Yes. But we need to cover other types of keys. There is a lot of back and forth about this. I am not sure how to solve this issue.
10:20:32 <hhalpin> when you see people publish keys, its usually something like this: http://www.ibiblio.org/hhalpin/harryhalpin.asc.gpg
10:20:49 <rsleevi> @hhalpin: What, no WebID love? ;)
10:20:51 <hhalpin> i.e. on "their webpage" which was Tantek's question, as hje's a microformat guy
10:21:21 <virginie_galindo> q?
10:21:25 <wtc> ddahl: we could standardize on using ASN.1 DER internally and then specify which key types could be exported in JSON.
10:21:33 <hhalpin> q+
10:21:49 <wtc> slightlyoff: could you give an example of a key type that couldn't be represented in JSON?
10:22:17 <hhalpin> well, we have to chose one :)
10:22:22 <wseltzer> ack rsleevi
10:22:27 <wtc> rbarnes: why do we need to even standardize on a key format?
10:22:53 <hhalpin> re import, export - but that's in secondary features in particular
10:23:07 <wtc> rsleevi: we need to find out what is easier for developers in practice.
10:23:47 <wtc> rsleevi: there are cases where JSON would make sense or ASN.1 DER would make sense.
10:23:49 <virginie_galindo> q?
10:23:57 <JonathanJ1> rrsagent, draft minutes
10:23:57 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
10:24:41 <wtc> rsleevi: requiring an application to convert from other formats to the format we choose would be acceptable.
10:25:09 <hhalpin> https://tools.ietf.org/html/draft-ietf-jose-json-web-key-06
10:25:17 <wtc> rsleevi: I raised this issue because at that time it wasn't clear based on the use cases which format would be optimal.
10:25:25 <hhalpin> q?
10:26:15 <slightlyoff> Present+ Alex_Russell
10:26:56 <wtc> selfissued: the JOSE working group felt that there are compelling reasons not to reinvent a new format.
10:27:35 <HadleyBeeman> HadleyBeeman has joined #crypto
10:27:45 <wtc> selfissued: for certain use cases we would recommend just using ASN.1 DER for things like keys used in an attestation chain.
10:28:21 <matt> matt has joined #crypto
10:28:40 <wtc> selfissued: the Editor's API is in a good position because the import/export methods take a key format argument.
10:28:43 <matt> matt has left #crypto
10:29:05 <matt> matt has joined #crypto
10:29:15 <wtc> selfissued: In the JOSE working group I will ask if the private key document should become a working group document.
10:29:30 <kotakagi> kotakagi has joined #crypto
10:29:44 <wtc> selfissued: I'd like opinions on whether we would like a standard JSON representation of shared (symmetric) keys.
10:30:02 <virginie_galindo> q?
10:30:23 <virginie_galindo> ack selfissued
10:30:39 <virginie_galindo> ack olivier
10:31:03 <wtc> olivier: I'd need strong motivation to invent new formats for keys. DER encoding is sufficient for using the crypto API. What's the motivation for a new format?
10:31:09 <matt> matt has left #crypto
10:31:17 <matt> matt has joined #crypto
10:31:20 <matt> matt has left #crypto
10:31:48 <wtc> ddahl: to give web developers who are not familiar with crypto a more transparent view of what's in the key.
10:32:35 <wtc> markw: If you have JSON, you have serialization. Whereas JavaScript objects don't.
10:32:44 <tantek_> tantek_ has joined #crypto
10:33:00 <wtc> markw: we need a serialization format for every key type that we need to wrap.
10:33:20 <wtc> markw: also the key attributes.
10:33:31 <wtc> markw: I don't know if such standard exists.
10:34:06 <wtc> markw: I'd prefer if the JOSE working group take on the representation of private keys and symmetric keys.
10:34:48 <rsleevi> q?
10:34:54 <rsleevi> ack markw
10:35:17 <rsleevi> Present+ Eric_Rescorla
10:35:21 <wtc> markw: extending JSON web keys seems to be a good way to reach our goal (of facilitating key wrapping).
10:36:04 <rbarnes> fwiw, i would be fine with doing JWK or PEM-encoded DER.  i just don't see that this is a hugely difficult question
10:36:46 <wtc> ekr: in most cases apps don't need to inspect the keys, so transparency of the key format isn't important in those cases. But when they do, it would be a hassle to have to write a DER decoder.
10:37:03 <virginie_galindo> q?
10:37:12 <virginie_galindo> ack ekr
10:37:17 <wtc> ekr: why not support multiple formats?
10:37:17 <rsleevi> q+
10:37:23 <hhalpin> ack hhalpin
10:37:35 <wtc> markw: there is no DER format for key attributes (for key wrapping).
10:38:49 <wtc> hhalpin: it would be dangerous if web developers need to do DER encoding themselves. So I think we need to support ASN.1 DER. The question is whether we should *also* support a JSON format.
10:39:11 <selfissued> q+
10:39:16 <markw> q+
10:40:32 <wtc> rsleevi: usability is an issue. If we give developers 10 options for key format, it would be hard to figure out which format would be appropriate for the particular application.
10:40:54 <rbarnes> q+
10:42:02 <JonathanJ1> rrsagent, draft minutes
10:42:02 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
10:42:04 <wtc> rsleevi: so we need to focus on usability. Also, I'd like to clarify the DER format. It is actually a much larger set because DER is just an encoding format. For example, there are two ways to represent an RSA public key in the DER format.
10:42:08 <hhalpin> I think *also* support JSON Web Key as its probably not too hard and much easier for developers to understand.
10:42:17 <hhalpin> Zakim, close queue
10:42:17 <Zakim> ok, hhalpin, the speaker queue is closed
10:42:39 <wtc> rsleevi: can we make our API as easy to use as jQuery, so that they don't need to become a crypto expert to use it?
10:42:43 <slightlyoff> what rsleevi said  = )
10:43:24 <wtc> selfissued: is there a DER key format which is just a bare key?
10:43:37 <wtc> rbarnes: yes, SubjectPublicKeyInfo.
10:43:37 <virginie_galindo> q?
10:43:51 <rsleevi> ack rsleevi
10:43:53 <rsleevi> ack selfissued
10:44:08 <rsleevi> ack markw
10:45:18 <hhalpin> RRSAgent, make minutes public
10:45:18 <RRSAgent> I'm logging. I don't understand 'make minutes public', hhalpin.  Try /msg RRSAgent help
10:45:19 <cjkula> q+
10:45:21 <wtc> markw: the important issue is the format of the key to be wrapped, because the key format for unwrapped key can be converted (just a matter of programming).
10:46:22 <bjkim> bjkim has joined #crypto
10:46:26 <darobin> darobin has joined #crypto
10:46:42 <ekr> ekr has joined #crypto
10:46:48 <ekr> q+
10:47:02 <pal> q+
10:47:18 <wtc> rbarnes: have support for ASN.1 based formats when there are requirements to work with legacy systems, but prefer JWK for other applications.
10:47:27 <hhalpin> just to clarify, it seems like for legacy reasons ASN.1 import/export is necessary, and since its not too hard, lets use JOSE(++) keys that map directly to the JSON objects in the API as well.
10:47:44 <jin> jin has joined #Crypto
10:48:02 <darobin> darobin has left #crypto
10:48:18 <hhalpin> this helps usability as we cannot expect webdevs to deal with ASN.1 formats, but we ideally do not want keys to be sent around using JSON in the future.
10:48:25 <hhalpin> s/not want/want
10:48:26 <hhalpin> :)
10:49:06 <wtc> rbarnes: the focus here is on just the keys, not X.509 certificates.
10:50:05 <wtc> virginie_galindo: we need a volunteer to write a proposal for this issue.
10:50:19 <tantek> tantek has joined #crypto
10:50:19 <ekr> SPKI in this case = http://tools.ietf.org/html/rfc5280#section-4.1.2.7
10:50:31 <wtc> rsleevi: the current Editor's API has a KeyFormat argument for the key import and export APIs.
10:51:15 <ekr> This list needs to add SPKI
10:51:41 <rsleevi> @ekr: Is that volunteering to propose additional text? ;-)
10:51:50 <virginie_galindo> was about to ask the same
10:52:12 <rsleevi> (or perhaps this is an issue for the editors to clarify edition)
10:52:24 <ekr> "subjectpublickeyinfo" "The RFC 5280 SubjectPublicKeyInfo format"
10:52:32 <ekr> Actually, I would remove both PKCS#1
10:52:36 <ekr> values
10:52:43 <ekr> in favor of the wrapped versions
10:53:08 <wtc> rsleevi: the need to support many formats would be extra burden for implementors of the API and also usability concerns for developers who will use the API.
10:54:17 <virginie_galindo> q?
10:54:20 <rsleevi> ISSUE-35?
10:54:20 <trackbot> ISSUE-35 -- Handling of wrap/unwrap operations -- open
10:54:20 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/35
10:54:27 <rsleevi> Zakim, reopen the queue
10:54:27 <Zakim> ok, rsleevi, the speaker queue is open
10:54:57 <wtc> markw: ISSUE-35: handling of key wrap/unwrap operations.
10:55:21 <rbarnes> for reference, SPKI = PKCS#1 + algorithmIdentifier
10:55:25 <wtc> markw: ISSUE-35: handling of key wrap/unwrap operations.
10:56:18 <wtc> markw: (goes over his proposal for ISSUE-35).
10:57:06 <virginie_galindo> q?
10:57:16 <rbarnes> ack rbarnes
10:57:18 <rsleevi> q+ to respond?
10:57:24 <wtc> virginie_galindo: format for raw keys, and format for wrapping keys and attributes together.
10:57:26 <cjkula> Trying to understand this issue better -- is there any reason that a legacy encoding method cannot be wrapped in JSON? Reasons for this being 1) providing additional semantic information about the key, and 2) providing a standard-format structure that can be key-wrapped, for instance. I wouldn't think this imposes a great additional burden on end coders...
10:57:36 <rsleevi> q-
10:58:29 <wtc> virginie_galindo: should we add a SubjectPublicKeyInfo format to Section 15: KeyImporter interface?
10:59:30 <wtc> rsleevi: the proposal is to replace "pkcs1-public" with SubjectPublicKeyInfo because SPKI can also represent non-RSA public keys.
10:59:50 <ekr> as wtc says. Also, they are typed.
11:00:05 <tobie> tobie has joined #crypto
11:02:09 <wtc> selfissued: JOSE is an open group. If anyone would like JOSE to specify the formats for private keys and symmetric keys, send a request to the JOSE working group.
11:03:02 <rsleevi> q+ to respond to markw_
11:03:05 <wtc> markw: we need a format for wrapping a key with its attributes. We need to ensure a path to success for this issue.
11:03:55 <wtc> selfissued: this week would be a good time to send the request because JOSE will meet in Atlanta next week.
11:04:12 <virginie_galindo> q?
11:04:17 <wtc> selfissued: rbarnes, ekr, and I can act as coordinators.
11:04:58 <wtc> rsleevi: the handling of key attributes is a secondary feature.
11:06:13 <wtc> hhalpin: that refers to just the attributes that aren't necessary to primary features.
11:07:24 <rsleevi> ACTION Ryan to update the formats to remove PKCS#1 and add SPKI
11:07:24 <trackbot> Created ACTION-59 - Update the formats to remove PKCS#1 and add SPKI [on Ryan Sleevi - due 2012-11-08].
11:07:37 <wtc> virginie_galindo: Action item: ddahl to update the key format list in the API draft.
11:08:21 <wtc> virginie_galindo: ISSUE-19: does it make sense to have authorized-origin and specific-origin keys
11:08:56 <wseltzer> ISSUE-35?
11:08:56 <trackbot> ISSUE-35 -- Handling of wrap/unwrap operations -- open
11:08:56 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/35
11:09:11 <wtc> virginie_galindo: ISSUE-35: handling of wrap/unwrap operations.
11:09:34 <wtc> markw: proposal was emailed on Oct. 30.
11:09:53 <virginie_galindo> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0142.html
11:09:56 <wtc> markw: make wrap/unwrap a sub-case of export/import.
11:10:17 <wtc> markw: see http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0142.html for the proposal
11:10:44 <wtc> markw: added boolean attribute 'wrapped'.
11:11:05 <wtc> markw: added createKeyImporter method.
11:11:21 <ekr> q
11:11:23 <ekr> q+
11:11:37 <wtc> markw: similarly for createKeyExporter method.
11:11:59 <wtc> markw: with all the descriptions.
11:12:34 <ekr> btw, bad idea to use the term "extractor" here. It's a term of art in crypto.
11:13:00 <ekr> Unfortunately, "exporter" is a term of art in TLS, but that's probably less confusing
11:13:01 <wtc> marks: rules for resolving conflicts between the attributes and usages inside and outside the wrapped keys are specified.
11:13:35 <rsleevi> q-
11:14:51 <wtc> markw: (goes over specification of RSA PKCS #1 v1.5 and OAEP and AES key wrap for key wrapping.
11:16:10 <virginie_galindo> q?
11:17:36 <wtc> ekr: can you talk about the JavaScript security model for your proposal?
11:19:25 <rsleevi> q+
11:20:08 <virginie_galindo> ack ekr
11:20:10 <virginie_galindo> q?
11:20:24 <wtc> markw: a key that is not exportable should not be exported in either raw format or wrapped format.
11:21:51 <ekr> q+
11:22:07 <rbarnes> q+
11:22:14 <virginie_galindo> ack rsleevi
11:22:34 <ekr> q-
11:22:35 <ekr> q+
11:22:42 <ddahl> q+
11:22:48 <wtc> rsleevi: I'd like to make sure we have enough diversity of use cases for key wrapping so that we design a good key wrapping API that solves the problem space.
11:22:53 <markw> q+
11:23:08 <hhalpin> q+
11:23:33 <ekr> the only reason this needs to be inside the API boundary is the type enforcement on import
11:23:40 <ekr> everything else could be implemented outside the API boundary
11:23:47 <pal> q+
11:24:32 <markw> @ekr: yes
11:25:55 <rsleevi> ack rbarnes
11:26:00 <selfissued> q+
11:26:05 <selfissued> q+
11:26:18 <wtc> rbarnes: without key wrapping, an app would need to export the raw key and encrypt the key as data.
11:26:40 <rsleevi> ack ekr
11:26:44 <rsleevi> Zakim, close the queue
11:26:44 <Zakim> ok, rsleevi, the speaker queue is closed
11:27:27 <rsleevi> ack ddahl
11:27:29 <rsleevi> ack markw
11:27:54 <cjkula> I feel that key wrapping is integral to key import-export. Aren't keys (otherwise) being shuffled around unprotected?
11:28:11 <mib_3gfypn> mib_3gfypn has joined #crypto
11:28:48 <rsleevi> ack hhalpin
11:29:23 <wtc> hhalpin: I really appreciate the proposal by markw. It is a great contribution to the WG.
11:29:42 <wtc> q+
11:30:47 <virginie_galindo> q?
11:32:33 <virginie_galindo> ack pal
11:34:38 <rsleevi> ack selfissued
11:35:06 <hhalpin> ekr, for non-native English speakers, could you write you not on trust boundaries in in IRC?
11:36:15 <wtc> virginie_galindo: members should look at markw's proposal and send comments to the mailing list.
11:36:37 <selfissued> FYI, JOSE currently only uses RFC 3394 key wrapping, not RFC 5649 key wrapping, because it didn't have a need for wrapping keys of arbitrary size
11:36:44 <hhalpin> i.e. enforcement on wrapped import is making "the assumption" that the JS is itself not trusted here.
11:36:45 <wtc> virgine_galindo: we will continue the discussion during the Use Cases session later.
11:36:50 <ekr> Sure. The point i was making is that in general, the key exportable features in this API are designed against some future compromise of the JS. This is a design in which the JS has the key in its hand and yet you're saying you don't trust it.
11:37:05 <wtc> selfissued: FYI, JOSE currently only uses RFC 3394 key wrapping, not RFC 5649 key wrapping, because it didn't have a need for wrapping keys of arbitrary size
11:37:22 <wtc> virginie_galindo: we'll reconvene at 2:00 PM.
11:37:27 <tantek> re: Issue 14, I've started collecting real world examples of public publishing of public keys on web pages: http://microformats.org/wiki/key-examples
11:37:42 <tantek> hopefully that will provide some useful input for Issue 14
11:37:45 <ddahl> tantek: thanks
11:37:46 <tantek> http://www.w3.org/2012/webcrypto/track/issues/14
11:37:49 <hhalpin> thanks tantek!
11:37:57 <rsleevi> RRSAgent, draft minutes
11:37:57 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html rsleevi
11:38:07 <ddahl> tantek: I also have a deep interest in key publishing
11:38:14 <hhalpin> We're going through the use-cases at 4:00 PM if you could be there, that could be useful to talk about this more
12:15:07 <HadleyBeeman> HadleyBeeman has joined #crypto
12:51:23 <tpacbot> tpacbot has joined #crypto
12:52:02 <bjkim> bjkim has joined #crypto
12:53:49 <markw> markw has joined #crypto
12:56:22 <selfissued> selfissued has joined #crypto
12:58:40 <pal> pal has joined #crypto
12:59:54 <ttanaka2> ttanaka2 has joined #crypto
13:00:25 <JonathanJ1> JonathanJ1 has joined #crypto
13:01:08 <drogersuk> drogersuk has joined #crypto
13:01:37 <tantek> tantek has joined #crypto
13:02:02 <rbarnes> rbarnes has joined #crypto
13:02:10 <rbarnes> rbarnes has joined #crypto
13:02:20 <yune> yune has joined #crypto
13:04:59 <kotakagi> kotakagi has joined #crypto
13:05:40 <kotakagi> kotakagi has joined #crypto
13:05:49 <Ruinan> Ruinan has joined #crypto
13:08:57 <ekr> ekr has joined #crypto
13:09:10 <jin> jin has joined #crypto
13:12:01 <sangrae> sangrae has joined #crypto
13:12:30 <virginie> virginie has joined #crypto
13:12:33 <hhalpin> hhalpin has joined #crypto
13:12:44 <hhalpin> scribenick: hhalpin
13:13:07 <hhalpin> rsleevi: ISSUE-17: Scope and API for custom key attributes, lets delay till Mark can be here
13:13:55 <rsleevi> ISSUE-17?
13:13:55 <trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open
13:13:55 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/17
13:14:34 <hhalpin> lets do key storage now
13:15:29 <mountie> mountie has joined #crypto
13:15:34 <JonathanJ1> rrsagent, draft minutes
13:15:34 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
13:15:59 <virginie> How does the application know where the key is stored ? http://www.w3.org/2012/webcrypto/track/issues/30
13:17:02 <hhalpin> rsleevi: Previously, we considered key storage do be done in localStorage
13:17:03 <rbarnes> q+
13:17:24 <hhalpin> ... however, there was concern re having yet another mechanism to key storage
13:17:40 <hhalpin> ... that could then track users
13:18:01 <ekr> q+
13:18:02 <hhalpin> ... my proposal is not to store raw key in localstorage
13:18:11 <ekr> can you reopen the queue pls
13:18:13 <hhalpin> Zakim, open the queue
13:18:13 <Zakim> ok, hhalpin, the speaker queue is open
13:18:18 <ekr> q+
13:18:18 <hhalpin> q+ rbarnes
13:18:40 <hhalpin> ... then we remove our notion of key storage
13:18:54 <ddahl> ddahl has joined #crypto
13:19:00 <virginie> q?
13:19:07 <mountie> q+
13:19:13 <hhalpin> ... and then web storage should be re-iused
13:19:16 <rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0133.html
13:19:45 <hhalpin> ... and then our key material can then by WebIntents, workers, etc.
13:19:53 <wtc> wtc has joined #crypto
13:20:48 <hhalpin> ekr: thinking re key storage, you have a key in some non-persistant storage
13:20:57 <mountie> mountie has joined #crypto
13:20:57 <hhalpin> .. IndexDB stores the key object
13:21:10 <hhalpin> rsleevi: and the app doesn't have to see the key material
13:21:34 <hhalpin> ekr: but if key is just a handle to something to a token, then you need alot of special logic to sync up IndexedDB object with key storage
13:21:50 <hhalpin> ... worried about this getting out of sync
13:22:00 <hhalpin> rsleevi: that problem exists regardless of where we do key storage
13:22:05 <mountie> q+
13:22:21 <hhalpin> ... it stores the permission set and can know you have the key authorized, how to retrieve the key
13:22:28 <hhalpin> ... we return all that data from indexeddb
13:22:38 <hhalpin> ... you can try to do that and key may be gone
13:22:49 <tlr> tlr has joined #crypto
13:22:52 <hhalpin> ... but that's just like removing a smartcard, you only discover this if you try to use th ekey
13:22:56 <hhalpin> s/ekey/key
13:23:01 <hhalpin> s/th/the
13:23:45 <hhalpin> ekr: if this is going to have right semantics so that structure of handle guarantees
13:23:52 <virginie> q?
13:24:03 <hhalpin> alexrussell: we're returning opaque handle
13:24:24 <slightlyoff> q+
13:24:57 <hhalpin> rsleevi: we don't have token storage thought out
13:25:05 <rsleevi> ack ekr
13:25:06 <hhalpin> ... but we can guarantee for localstorage
13:25:11 <hhalpin> s/localstroage/indexedDB
13:25:18 <slightlyoff> q-
13:25:23 <hhalpin> q+
13:25:44 <ekr> here's the sequence of events I'm concerned about: I generate a key with a token and get a handle to it. I then store the key in indexdb. Sometime later, the user tells indexb to erase it's local storage. Does this cause the side effect of garbage collecting the key.
13:26:03 <markw> q+
13:26:15 <rsleevi> q+
13:26:19 <rbarnes> ack
13:26:20 <hhalpin> rbarnes: I'm not sure if this really helps, as we want special handling anyways
13:26:23 <rsleevi> ack rbarnes
13:26:24 <rbarnes> ack rbarnes
13:26:25 <hhalpin> ... for keys
13:26:30 <rsleevi> ack mountie
13:26:33 <hhalpin> mountie: queston for UI part
13:26:43 <hhalpin> ... you are dependent on the browser vendor
13:27:03 <hhalpin> ... for the korean users we need to modify the selection, getting user consent
13:27:09 <hhalpin> ... we would like to add messages
13:27:17 <hhalpin> ... delivered in the UI itself
13:27:32 <virginie> q?
13:27:41 <markw> q-
13:28:27 <slightlyoff> q+
13:29:23 <rsleevi> ack hhalpin
13:29:23 <hhalpin> ack hhalpin
13:29:43 <rbarnes> it also seems a little funny that other groups are free to define new storage modalities, but this group can't?
13:29:53 <hhalpin> just noting that I did run Ryan's proposal by HTML WG, IndexedDB was seen as the preferable storage modalities
13:30:13 <hhalpin> definitely to be preferred over localstorage, which has various speed etc. interests
13:30:55 <hhalpin> and webapp frameworks being developed in other WGs are moving to consensus to not define new many storage modalities
13:31:14 <hhalpin> rsleevi: while localstorage does only strings, indexeddb can to the same lifetime considerations
13:31:24 <hhalpin> ... so the argument is that it makes lifetime management easier
13:32:26 <hhalpin> ... as regards UI considerations
13:32:36 <hhalpin> ... so we're focussed first on non-token key storage
13:32:45 <rsleevi> ack rsleevi
13:32:50 <hhalpin> ... but remember that as regards key storage, its after user has already gone through a UI
13:32:59 <hhalpin> ... so we're assuming that actually works
13:34:45 <rsleevi> ack slightlyoff
13:34:51 <ddahl> q+
13:35:16 <slightlyoff> ack
13:35:27 <hhalpin> slightlyoff: my general point was to go with structured clone, not go to localstorage or indexeddb
13:35:49 <hhalpin> ... as there might be yet another storage mechanism
13:35:53 <hhalpin> ... so stay neutral on storage
13:35:59 <hhalpin> ... but do not define another keystrorage
13:36:19 <alexandremorgaut> alexandremorgaut has joined #crypto
13:36:25 <olivier> olivier has joined #crypto
13:36:50 <hhalpin> ddahl: does the developer have to do it the storage mechanism directly, or does the API handle this?
13:37:15 <hhalpin> rsleevi: we are imaginging that what is stored is like a pointer
13:37:19 <hhalpin> ... local storage does a GET on this value
13:37:23 <hhalpin> s/GET/get
13:37:34 <cjkula> cjkula has joined #crypto
13:37:53 <hhalpin> ... what my proposal gets away from is another storage mechanism, we just deal with structured clone
13:38:03 <hhalpin> ... whether its FileAPI or IndexedDB or whatever
13:38:19 <virginie> q?
13:38:40 <slightlyoff> q+
13:38:40 <hhalpin> ddahl: mozilla would prefer indexeddb
13:38:53 <hhalpin> rsleevi: but we as the group don't worry about it
13:38:59 <hhalpin> ... we just don't get another storage mechanism
13:39:01 <hhalpin> q+
13:39:02 <rsleevi> ack ddahl
13:39:04 <rsleevi> ack slightlyoff
13:39:35 <hhalpin> slightlyoff: we've backed away from localstorage due to issues with sync
13:39:58 <hhalpin> ... but that be a big deal in the future
13:40:19 <hhalpin> .. but imagine that we could make localstorage
13:40:26 <hhalpin> ... we want to create invariance around card/key
13:40:48 <virginie> q?
13:41:16 <rsleevi> hhalpin: From a process perspective, unless implementor objection, lets get consensus
13:41:43 <rsleevi> hhalpin: Proposal: Remain neutral on the nature of storage and do *not* define a key storage mechanism in our API
13:41:59 <rsleevi> virginie: objections?
13:42:06 <hhalpin> ack hhalpin
13:42:24 <plinss> plinss has joined #crypto
13:43:30 <hhalpin> RESOLUTION: For non-token backed keys, we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object
13:43:44 <hhalpin> ACTION: rsleevi to specify text that makes it clear we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object
13:43:44 <trackbot> Created ACTION-60 - Specify text that makes it clear we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object [on Ryan Sleevi - due 2012-11-08].
13:43:48 <rsleevi> ISSUE-3?
13:43:48 <trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review
13:43:48 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/3
13:43:52 <rsleevi> ISSUE-38?
13:43:52 <trackbot> ISSUE-38 -- Key initialization and "finalization" -- open
13:43:52 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
13:44:38 <virginie> reminder priority table of issues is here : https://docs.google.com/spreadsheet/ccc?key=0Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E#gid=0
13:45:53 <hhalpin> rsleevi: ISSUE-38
13:46:04 <hhalpin> ... we imagine that keys can be marked so we can't back-up key
13:46:09 <hhalpin> ... or that we actually can
13:46:29 <virginie> we are managing http://www.w3.org/2012/webcrypto/track/issues/38
13:46:34 <ekr> q+
13:47:07 <tlr> tlr has joined #crypto
13:47:28 <hhalpin> ... and once key is intialized, we can change it.
13:47:29 <virginie> ack hhalpin
13:47:39 <hhalpin> q+
13:47:41 <ekr> q-
13:47:46 <virginie> q?
13:47:59 <hhalpin> ekr: why can't we just move key to a non-exportable container and just delete it
13:48:11 <virginie> virginie has joined #crypto
13:48:11 <hhalpin> ack hhalpin
13:48:37 <ddahl> q+
13:48:39 <rsleevi> q+
13:49:20 <rsleevi> ack ddahl
13:49:42 <hhalpin> I'm thinking that if this work around is used a lot, I could see an ease-of-use issue for including this as a class of keys
13:49:59 <hhalpin> ddahl: I want to avoid too many features, so let's keep it low priority
13:50:01 <cjkula> q+
13:50:18 <hhalpin> rsleevi: lets make sure the WG doesn't want it, but I agree with ddahl
13:50:54 <virginie> q?
13:50:58 <rsleevi> ack rsleevi
13:51:02 <rsleevi> ack cjkula
13:51:43 <hhalpin> cjkula: how about the case where the export gets screwed up?
13:52:43 <hhalpin> rsleevi: but we're still OK in terms of crashing
13:52:58 <hhalpin> virginie: PROPOSAL: lets cloes ISSUE-38 to reclassify it as a next version
13:53:09 <hhalpin> any objections?
13:53:11 <rsleevi> ISSUE-3?
13:53:11 <trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review
13:53:11 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/3
13:53:17 <hhalpin> RESOLUTION: loes ISSUE-38 to reclassify it as a next version
13:53:30 <cjkula> ack cjkula
13:53:45 <hhalpin> ISSUE-3: Decide whether algorithm discovery is necessary
13:53:45 <trackbot> ISSUE-3 Decide whether algorithm discovery is necessary notes added
13:54:26 <hhalpin> rsleevi: we have two kinds of keys, browser-generated and maintained keys
13:54:29 <hhalpin> ... and storage-backed keys
13:54:38 <hhalpin> ... how do we manage discovery?
13:54:51 <hhalpin> ... first proposal, can we know if a browser as implemented a particular operation?
13:55:20 <hhalpin> ... its hard, since AES-128 may be supported by a browser but not a smartcard
13:55:21 <drogersuk> q+
13:55:39 <hhalpin> ... and since the important point that smartcard doesnt give up key material
13:55:48 <hhalpin> ... so the intial proposal is we can't do discovery
13:55:58 <hhalpin> ... we just try to do the key
13:57:52 <mountie> q+
13:57:59 <ekr> q+
13:58:18 <hhalpin> PROPOSAL: We don't have a generic algorithm discovery procedure
13:59:06 <rsleevi> q+
14:00:01 <drogersuk> Re: algo discovery - we need to consider about broken algorithms and people using old (insecure) versions of browsers
14:00:08 <hhalpin> mountie: we want to make sure algorithm is available, if browser returns true or false, that helps, we dn't need a true list
14:00:17 <drogersuk> this may lead us to the solution to the discovery problem
14:00:35 <drogersuk> q+
14:00:35 <virginie> ack drogersuk
14:00:46 <ekr> q-
14:00:49 <drogersuk> q+
14:00:51 <virginie> ack mountie
14:01:00 <hhalpin> ekr: I don't like your solution but lets go with it as it will never work.
14:01:02 <virginie> ack rsleevie
14:01:13 <ekr> hhalpin: that's not quite what I was saying.
14:01:30 <ekr> More "this is distasteful but it's the best we know how to do I suspect"
14:01:41 <virginie> q?
14:01:49 <hhalpin> s/I don't like your solution but lets go with it as it will never work/his is distasteful but it's the best we know how to do I suspect
14:01:52 <virginie> ack rsleevi
14:01:53 <ekr> The best we can do is define clear semantics for what "I don't support it" looks like"
14:02:08 <hhalpin> rsleevi: we want to discuss the warning itself separately
14:03:05 <hhalpin> ... for your point mountie, the problem is in the details, it may only support with all parameters listed
14:03:12 <hhalpin> ... or you just initialize the key
14:03:13 <JonathanJ1> rrsagent, draft minutes
14:03:13 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
14:04:10 <mountie> q+
14:04:21 <ddahl> q+
14:04:42 <hhalpin> drogersuk: if we do have the notion of list of discoverable crypto algs, how do we handle spoofing attack?
14:05:26 <rsleevi> q+ to respond to drogersuk
14:05:30 <rsleevi> ack drogersuk
14:05:32 <hhalpin> ... how do you handle algorithm export issues
14:05:43 <rsleevi> Zakim, close the queue
14:05:43 <Zakim> ok, rsleevi, the speaker queue is closed
14:05:57 <hhalpin> ack mountie
14:07:30 <slightlyoff> q+
14:07:38 <hhalpin> mountie: I'm thinking browser environment we may to support in order to run certain apps
14:07:51 <hhalpin> ddahl: maybe we can just punt that piece of code to web-developers
14:07:59 <ddahl> q-
14:08:00 <ekr> ekr has joined #crypto
14:08:22 <slightlyoff> can't do this via the queue, so let me do this here: it won't work that way. JS libraries are going to try to feature detect
14:08:22 <hhalpin> rsleevi: how do you trust algorithm list is authentic, does not change with what we currently do
14:08:31 <hhalpin> ... server should never trust client JS
14:08:38 <hhalpin> I might add it has no choice
14:08:44 <slightlyoff> and that means that punting to them is all about "them" having some visibility into what you can do in each situation
14:08:56 <hhalpin> rsleevi: its a feature to polyfill new algs in the agent
14:09:00 <hhalpin> ... not a bug
14:09:01 <mountie> q+
14:09:29 <hhalpin> ... markw shows that they have some trustworthy operation
14:09:34 <hhalpin> ... that only they can perform
14:10:12 <hhalpin> ... algs do get turned off in regulatory environments by user as well, not just browser
14:10:19 <hhalpin> ... less than ideal discivery, but new proposals welcome
14:10:28 <ddahl> I am going to assume developers will do this regardless - especially since we will probably not be able to produce a comprehensive, pre-init() algorithm discovery api
14:11:22 <slightlyoff> sorry, that's just not the world that library authors will get behind...you can't keep the libraries up to date, so they try to make what they know about the world conditional based on what they can observe
14:11:22 <hhalpin> ... if you don't have a seed key and not sure if its' available, lets try is a good way to do
14:11:34 <hhalpin> ... versioning APIs is terrible on the Web, feature discovery is better way
14:11:41 <hhalpin> .... browser capabilities etc.
14:12:07 <virginie> q?
14:12:15 <virginie> ack rsleevi
14:12:15 <Zakim> rsleevi, you wanted to respond to drogersuk
14:13:43 <kotakagi> kotakagi has joined #crypto
14:14:00 <hhalpin> drogersuk: the polyfill is a threat, is it not?
14:14:15 <hhalpin> ... can not attacker go after it?
14:15:19 <hhalpin> rsleevi: we need to discuss this more, but during break
14:16:25 <hhalpin> PROPOSAL: Do not have a generic algorithm discovery procedure
14:16:42 <hhalpin> ACTION: mountie to determine if a generic algorithm procedure is necessary for his use-case
14:16:42 <trackbot> Created ACTION-61 - Determine if a generic algorithm procedure is necessary for his use-case [on Mountie Lee - due 2012-11-08].
14:19:37 <virginie> Break 15 minutes reconvening @ 15:30
14:28:45 <kevin> kevin has joined #crypto
14:36:10 <ttanaka2> ttanaka2 has joined #crypto
14:37:01 <rsleevi> scribenick: rsleevi
14:37:04 <rsleevi> scribe: Ryan_Sleevi
14:37:19 <Alexandre_Morgaut> Alexandre_Morgaut has joined #crypto
14:37:39 <rsleevi> topic: Presentation by Richard Barnes regarding implementation experience
14:38:25 <Yune> Yune has joined #crypto
14:38:33 <bjkim> bjkim has joined #crypto
14:38:34 <rsleevi> rbarnes: BBN is working on a pure polyfill implementation of the API
14:38:46 <rsleevi> ... Start prototyping the API, keeping up with it as it evolves
14:38:57 <rsleevi> ... allows developers to start experimenting with the API and getting used to the concepts
14:39:05 <rsleevi> ... attempts to provide an abstraction that prevents access to the raw API
14:39:12 <rsleevi> ... get feedback as to how usable the API is
14:39:21 <rsleevi> ... provides a space for experimentation of new features
14:39:28 <rsleevi> ... plan is to be open source and collaborative
14:39:36 <rsleevi> ... implemented in JS, has all the existing caveats
14:39:44 <rsleevi> ... *not* intended for real applications
14:40:05 <rsleevi> ... perhaps in the future, after security analysis, but not recommended nor a goal for now
14:40:26 <rsleevi> ... trying to emulate the web crypto API separation in JS
14:40:51 <rsleevi> ... Current Web Crypto: Keys stored (raw) in localStorage or IDB
14:40:58 <rsleevi> ... All key material is accessible to content
14:41:17 <rsleevi> ... Implementation/Experimental API: Provide an API separation from content for key storage
14:41:23 <rsleevi> ... Does so via origin separation
14:42:01 <rsleevi> ... Get people used to not having access to the raw key bytes
14:42:47 <rsleevi> ... maybe some security benefits
14:42:52 <rsleevi> ... eg: encrypting key store, forced key expiration
14:43:17 <rsleevi> drogersuk: Q regarding last pass. There's a hardware token you can get with lastpass, how does that relate?
14:44:01 <rsleevi> rbarnes: Not quite familiar with the LastPass implementation
14:44:16 <rsleevi> rsleevi: re: LastPass - authentication security, not a key storage security
14:44:27 <rsleevi> rbarnes: Just getting started. Basic framework for cross-origin operations
14:44:32 <rsleevi> q+
14:44:37 <rsleevi> zakim, open the queue
14:44:37 <Zakim> ok, rsleevi, the speaker queue is open
14:44:38 <rsleevi> q+
14:45:13 <rsleevi> rbarnes: Funded by US DHS STD
14:45:30 <hhalpin> q+
14:45:37 <virginie> q?
14:45:41 <rsleevi> http://code.google.com/p/html5-crypto-api/
14:46:44 <rsleevi> q+
14:46:48 <rsleevi> ack rsleevi
14:46:50 <rsleevi> q+
14:46:52 <rsleevi> ack hhalpin
14:47:01 <wtc> wtc has joined #crypto
14:47:18 <rsleevi> ack rsleevi
14:47:37 <rbarnes> q?
14:47:58 <hhalpin> note that W3C/MIT is getting a grant from NGRC for continuing this work.
14:48:12 <hhalpin> So if people are looking for funding in this area, I think now is a good time to strike
14:48:16 <hhalpin> ack hhalpin
14:48:40 <rsleevi> rsleevi: Hooray for the implementation. Demonstrates that this API is polyfillable today
14:49:03 <rsleevi> virginie: Question for Mozilla and Microsoft as to when they'll be implementing
14:49:17 <rsleevi> selfissued: Not aware of any committment to implement. Not to say there is no committment, just not sure
14:49:52 <rsleevi> ddahl: Been focused on Firefox OS. Needs to finish Mozilla's implementation of getRandomValues
14:50:20 <rsleevi> ddahl: Next step to consider extension implementations as an experimental API
14:50:37 <rsleevi> ddahl: Working to get excitement and feedback from other Mozilla engineers. Difficult at present with focus on Firefox OS
14:50:46 <virginie> q?
14:50:54 <rsleevi> drogersuk: Just ask them about what security do they want in FirefoxOS
14:53:26 <rsleevi> rsleevi: Agenda item for this quarter to begin working and looking at the implementation, need to work out some very obvious usability issues before exposing to developers
14:53:39 <rsleevi> ???: Working on server implementation, in particular in node.js
14:54:00 <rsleevi> virginie: Not yet formal WG member. Do you know when you will join?
14:54:03 <rsleevi> ???: Not yet, working on it
14:54:15 <rsleevi> s/???/Alexandre Mogel/
14:54:51 <JonathanJ1> JonathanJ1 has joined #crypto
14:55:08 <rsleevi> [ working out details and waiting for Arun to call and join ]
14:55:27 <rsleevi> [ small break ]
14:56:21 <virginie> [discussion about crypto node.js]
14:59:11 <JonathanJ1> rrsagent, draft minutes
14:59:11 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
14:59:58 <arunranga> arunranga has joined #crypto
15:00:17 <kevin_> kevin_ has joined #crypto
15:00:46 <rsleevi> Zakim, what is the phone number?
15:00:46 <Zakim> I don't understand your question, rsleevi.
15:00:55 <ke> ke has joined #crypto
15:01:22 <arunranga> Zakim, what is the number?
15:01:22 <Zakim> I don't understand your question, arunranga.
15:01:41 <ddahl> arunranga: you are our only hope
15:01:51 <hhalpin> Arun, can you dial in?
15:01:55 <drogersuk> zakim is a name not a number...
15:01:57 <drogersuk> 6
15:02:02 <ke> rrsagent, draft minutes
15:02:02 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html ke
15:02:05 <ddahl> arunranga: i was joking about you appearing like a tupac hologram to discuss use cases
15:02:08 <hhalpin> Zakim, what's the code?
15:02:08 <Zakim> the conference code is 1932 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
15:02:15 <rsleevi> Zakim, what is the code?
15:02:15 <Zakim> the conference code is 1932 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), rsleevi
15:02:17 <hhalpin> OK, its always the same
15:02:37 <hhalpin> 1.617.761.6200 code 1932
15:03:09 <Zakim> Team_(admin)08:00Z has now started
15:03:16 <Zakim> +arunranga
15:03:54 <arunranga> I am the first participant in the new conference.  The old conference id, namely 27978# is not working.
15:04:09 <rsleevi> @arunranga: We're having technical difficulties
15:04:15 <rsleevi> @arunranga: Phones are hard. We're going shopping.
15:04:24 <arunranga> Heh :)
15:04:33 <arunranga> Comparisons to Tupac are always welcome, BTW
15:06:17 <virginie> oups...legal working on it (legal team :))
15:06:56 <tobie> present+ Tobie_Langel
15:08:01 <Zakim> + +33.4.72.82.aaaa
15:08:01 <virginie> a bit of reading about use cases http://dev.w3.org/2006/webapi/FileAPI/OverviewUseCases.html
15:08:06 <wtc> wtc has joined #crypto
15:08:17 <ddahl> HI ARUN
15:08:24 <rsleevi> virginie: notes 150 people present in the room
15:08:28 <rsleevi> [ laughter ]
15:08:33 <rsleevi> ...: 20 people
15:09:06 <pal> pal has joined #crypto
15:09:06 <rsleevi> virginie: Objective is to discuss use cases and get your (arun) view on use cases we have and in the wiki
15:09:20 <rsleevi> arunranga: Don't be thrown off by the fact that the document shared in IRC is from FileAPI
15:09:41 <rsleevi> ...: Had the repository as easy access to hg on a w3c server
15:09:49 <rsleevi> ...: Goal is to find a way to publish a use cases document
15:09:50 <christine> christine has joined #crypto
15:10:03 <rsleevi> ... likes the role model document we have - the scenarios document for the media api
15:10:10 <tobie> q+
15:10:10 <rsleevi> ... good template for how we can model our use cases
15:10:32 <rsleevi> ... most of the use cases that are in the wiki are good, but wanted to focus on the use cases that were declared as pressing problems
15:10:38 <rsleevi> ... wanted to make sure that the API could address them
15:11:07 <rsleevi> ... no real apple-apples comparison between what we've got (as an API) and what they (media api) do
15:11:13 <rsleevi> ... but we can use the model as a point of discussion
15:11:27 <slightlyoff> OH HAI arunranga
15:11:30 <virginie> q?
15:11:33 <arunranga> :)
15:11:37 <rsleevi> tobie: introductions
15:12:11 <rsleevi> tobie: here to talk about their (Facebook) use cases if it's valuable
15:12:14 <markw> markw has joined #crypto
15:12:22 <rsleevi> arunranga: Good to talk about those use cases at some point
15:12:49 <rsleevi> ... Try to break use cases in terms of rich scenarios and break them up into required components
15:12:58 <rsleevi> ... broke spec into cluster of requirements
15:13:12 <rsleevi> [ reviewing operation types from the draft ]
15:13:51 <rsleevi> arunranga: Break any rich scenario type into these sets of operation types
15:14:18 <rsleevi> arunranga: When you consider the S. Korea use case, it may not actually be possible with the API to meet those needs
15:14:40 <rsleevi> ... assuming everyone reviewed the document that was sent
15:14:48 <rsleevi> virginie: Any questions about this document or to the editor
15:15:00 <bblfish> bblfish has joined #crypto
15:15:07 <rsleevi> mountie: For the use case for the korean banking, many things are missing
15:15:33 <rsleevi> arunranga: Yeah. Are many things missing from the actual API, or simply details from the use case?
15:15:45 <bblfish> q?
15:15:52 <rsleevi> mountie: certificate enrollment is an important part of the process, but just described simply, without trusted key generation or cert enrollment process
15:15:54 <tobie> ack tobie
15:15:59 <ke> ke has left #crypto
15:16:01 <rsleevi> mountie: Without those types, this scenario cannot be implemented
15:16:30 <rsleevi> arunranga: Acknowledged. We have origin scoped keys, but over there, no one can see it's an origin scoped certificate, it comes from a central source, correct?
15:16:53 <rsleevi> arunranga: When we impose the technology requirement of an origin scoped set of keys, we can't really do the central authority scenario
15:16:54 <hhalpin> q+
15:16:58 <rsleevi> q+
15:17:07 <Ruinan> Ruinan has joined #crypto
15:17:37 <hhalpin> ISSUE-19 is still open http://www.w3.org/2012/webcrypto/track/issues/19
15:17:42 <rsleevi> virginie: Not sure if we want to have online discussion of the use cases, or if it would be more useful to have the right people to interview
15:17:51 <hhalpin> i.e. whether or not we should allow "specific" origin keys
15:17:52 <bblfish> you can interview me :-)
15:18:02 <rsleevi> arunranga: I like the idea of interviewing. It would have been nice to do it in person, but there were hurricanes and things
15:18:25 <rsleevi> present+ Henry_Story
15:18:45 <rsleevi> bblfish: Has a use case, is this the right time to give a quick use case?
15:19:01 <rsleevi> arunranga: have you had a chance to read the API?
15:19:04 <virginie> q?
15:19:15 <rsleevi> bblfish: I have a general use case, but I haven't followed the API closely
15:19:33 <rsleevi> bblfish: Wants an API to log out the TLS layer
15:20:00 <rsleevi> ... has a use case similar to browser ID, working with Web ID
15:20:08 <rsleevi> ... Is that something someone can do with this API?
15:20:14 <rsleevi> ... Do a browser ID sign on with the cryptographic material
15:20:26 <rsleevi> virginie: Question for clarification regarding browser id
15:20:41 <rsleevi> ddahl: I would not want to conflate what we're doing here with browser ID
15:20:53 <rsleevi> ddahl: browser ID has polyfills for other browsers regarding APIs
15:21:03 <rsleevi> ddahl: Mozilla is building into natively for Firefox, but that's completely separate
15:21:18 <rsleevi> bblfish: So you're not going to use this API to do things like signing?
15:21:30 <rsleevi> ddahl: Already implemented via polyfills
15:21:37 <rsleevi> q-
15:21:40 <hhalpin> ack hhalpin
15:21:44 <rsleevi> q+
15:21:55 <rsleevi> hhalpin: One thing to do is to order the use cases, perhaps by the most urgent
15:22:02 <virginie> q+
15:22:06 <rsleevi> hhalpin: Then ask about other use cases people want to go through
15:22:48 <wtc> arun: I like the Gangman Bank's name "-)
15:22:55 <ekr> What does "TLS log out" mean?
15:23:14 <virginie> ack rsleevi
15:23:29 <hhalpin> q+
15:23:56 <ekr> Seriosuly, I have no idea what it's supposed to mean
15:24:04 <wtc> ekr: if the TLS session uses a client certificate, invalidate that TLS session.
15:24:05 <rsleevi> rsleevi: Is the document meant to describe what our API (version 1) did, or what the API (product of the WG over iterations) will do?
15:25:18 <virginie> our reference for use cases used to be here : http://www.w3.org/2012/webcrypto/wiki/Use_Cases
15:25:31 <mountie> q+
15:25:58 <hhalpin> ack hhalpin
15:26:05 <ekr> wtc. thanks
15:26:06 <hhalpin> use-cases were in a wiki but not maintained
15:26:14 <ekr> That seems like a bit of a niche feature.
15:27:08 <rsleevi> arunranga: It sounds like what Henry is asking for is not really quite in scope
15:27:17 <rsleevi> ... goal would be to construct use cases and scenario as fully in scope of doing
15:27:22 <rsleevi> ... that should be the test that we hold to our API
15:27:44 <rsleevi> ... definitely want to hear more from those present and be able to maybe follow up with them online
15:27:56 <rsleevi> hhalpin: Just know that TLS logout is within secondary scope
15:28:02 <rsleevi> arunranga: Kind of want to get all the primary ducks lined up
15:28:18 <rsleevi> [ virginie loads document for presentation ]
15:28:40 <rsleevi> virginie: Would like to know for which use cases do you have someone to talk to, to complete the description, or do you want to look for someone now?
15:28:48 <rsleevi> arunranga: All of the use cases are based on what we've seen go around
15:28:59 <rsleevi> ... wants to follow up with tobie to discuss the caching scenario
15:29:44 <rsleevi> arunranga: What Netflix currently has on the wiki is very technical, doesn't quite disclose a scenario or workflow. Want to work out more high-level details
15:30:06 <rsleevi> virginie: 3.1 - Mountie will comment. 3.2 - Netflix will comment. 3.3 - Tobie for comment
15:30:40 <rsleevi> arunranga: 3.4/3.5 for discussion with nadim
15:31:11 <rsleevi> mountie: Who is the use cases target audience? Non-developers or for developers?
15:31:30 <rsleevi> mountie: This document seems like for normal process showing some examples / sharing some stories, not for help for developers
15:31:35 <hhalpin> q+
15:31:35 <rsleevi> ... We should focus more for developers
15:31:59 <rsleevi> ... Banking has a sequence of very complex operations
15:32:10 <hhalpin> http://dev.w3.org/2006/webapi/FileAPI/OverviewUseCases.html
15:32:10 <rsleevi> ... If we split out what operations and what functionalities, that would be helpful for more developers
15:32:12 <hhalpin> use-case docu
15:32:17 <hhalpin> q?
15:32:29 <rsleevi> virginie: The objective is to have very story-driven scenario first, then functional requirements, then technical requirements
15:32:46 <virginie> ack virginie
15:32:50 <virginie> ack mountie
15:32:57 <virginie> ack hhalpin
15:32:58 <rsleevi> hhalpin: The document is not for ordinary users (developers). It's to drive the discussion about what features are in and are not the API, to help the WG drive work
15:33:15 <rsleevi> hhalpin: To make sure it's clear to the editor what features should or should not be introduced to the api
15:33:27 <rsleevi> ... in the process of describing the banking use case, we'll describe the use case in the most accurate possible manner
15:33:35 <rsleevi> ... and then the WG will discuss how the use case affects the design of the API
15:33:46 <rsleevi> ... if the WG decides it's important, then the use case could drive change to the API
15:34:16 <rsleevi> mountie: For smaller topics, like implementing non-repudiation, implementing secure channels, identifying users
15:34:43 <rsleevi> ... for non-repudiation, there are so many use cases that can be involved
15:34:51 <rsleevi> ... for online banking, there's too many operations, it's too wide
15:35:13 <rsleevi> ... suggestion: Split into things like non-repudiation for online banking, and just discuss the non-repudiation aspect
15:35:32 <rsleevi> hhalpin: We're not clear what the needs are. Can you discuss the use case?
15:35:48 <rsleevi> arunranga: Agreed. It would be pretty invaluable to see if we can pit our API against the existing technology stack
15:35:59 <rsleevi> q+
15:36:07 <rsleevi> arunranga: Thinks the origin policy is at odds with the korean use case
15:36:09 <hhalpin> so we need more info re the banking use-case and the use-case doc is the place to do it.
15:36:54 <rsleevi> q-
15:37:33 <tantek> tantek has joined #crypto
15:37:51 <rsleevi> virginie: Looking for name of motivated people to drive the story
15:38:13 <rsleevi> [ harry volunteers to help arun work on documents in the cloud ]
15:38:36 <virginie> q?
15:38:53 <tantek> q+
15:39:16 <rsleevi> tobie: Do you have specific questions on the use case?
15:39:33 <rsleevi> arunranga: Where we left off, you guys are using local storage and wanting to make sure any code or local resources you cache/store don't get tampered with by third parties
15:39:36 <tantek> rsleevi - no, I am wondering if any of these use cases touch on public key discovery on the web.
15:39:50 <rsleevi> ... one way to do that would be to send across some sort of trusted / private-key signed hash to verify the resources
15:39:59 <rsleevi> ... is there more detail that you want fleshed out
15:40:30 <wtc> q+
15:41:09 <virginie> q?
15:41:19 <rsleevi> q+ to respond to arun
15:41:20 <cjkula> q+
15:41:40 <rsleevi> tantek: Tried to look through use cases quickly - do any touch on public key discovery on the web?
15:41:50 <bblfish> q+
15:41:51 <rsleevi> tantek: If not, would that be a reasonable case to add?
15:42:10 <bblfish> !+ for tantek
15:42:14 <bblfish> +1 for tanktek
15:42:40 <rsleevi> rsleevi: Nothing in the current doc about it. If you're volunteering to write one, that'd be good
15:43:10 <tantek> here's some research I've done of pages on the web that currently *do* publish public keys in visible text: http://microformats.org/wiki/key-examples
15:43:13 <ddahl> tantek: no, but it sounds a lot like my AddressbookAPI from DOMCrypt: https://github.com/daviddahl/domcrypt/blob/master/extension/domcrypt/content/addressbookManager.js#L103
15:43:32 <rsleevi> arunranga: So far, it doesn't
15:43:58 <rsleevi> rsleevi: suggests its something tantek should write one
15:44:07 <rsleevi> [ wtc volunteers for documents int he cloud use case ]
15:44:46 <virginie> q?
15:44:51 <tantek> q-
15:44:52 <rsleevi> arunranga: Another area for feedback is the MO that we're using (breaking things into requirements and then using requirements to describe use cases/scenario) is the right way to go
15:44:58 <virginie> ack wtc
15:45:10 <rsleevi> arunranga: There's more than one way to look at the API, is breaking it up the way it's done the right way?
15:45:16 <tlr> tlr has joined #crypto
15:45:54 <wtc> arunranga: the "nigori" protocol used in Chrome is specified in http://www.links.org/files/nigori-protocol.html . I think Firefox Sync would be another good use case.
15:46:33 <rsleevi> rsleevi: does the signed code use case actually require signatures and keys?
15:46:40 <rsleevi> tobie: No, it's just a hash
15:46:49 <rsleevi> arunranga: That's actually a good clarification
15:46:59 <virginie> adding alex morgaut on the speaker queue
15:47:02 <rsleevi> ... assumed what was happening was that it was not just a hash, but a hash signed by a private key
15:47:10 <virginie> q?
15:47:13 <rsleevi> ... and on the client side we'd have to duplicate the hash and verify the signature
15:47:20 <virginie> ack rsleevi
15:47:20 <Zakim> rsleevi, you wanted to respond to arun
15:47:22 <rsleevi> tobie: That's... much safer... than we were looking for
15:47:37 <rsleevi> tobie: Just wanted to make sure that the code has not been tampered with. Really does not require more than a checksum
15:47:57 <mountie> q+
15:47:59 <rsleevi> ... getting a hash from the network and just comparing it with the data
15:48:06 <bblfish> My use case was mostly about enabling to do what BrowserId does currently ( or  at least what I read up on it 5-6 moths ago)
15:48:17 <rsleevi> tobie: We're using HTTPS, so we assume the network is safe/secure, and we trust the browser
15:48:23 <bblfish> but it looks like the right people are here anyway....
15:48:31 <rsleevi> arunranga: I think we can actually give you your use case and raise you one
15:48:33 <rsleevi> [ laughter ]
15:48:35 <JonathanJ1> rrsagent, draft minutes
15:48:35 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
15:48:41 <rsleevi> arunranga: I think the hash part is easy and that our API can do
15:48:48 <rsleevi> ... and I think we can give you cryptographic validity for the hash
15:49:00 <rsleevi> ... we can probably do your use case and better
15:49:18 <rsleevi> cjkula: Arun's story is storing javascript *and other resources*
15:49:30 <rsleevi> tobie: That wasn't the initial use case. It was just javascript, which is code we need to run
15:49:39 <rsleevi> ... it might extend to CSS, due to the fact that CSS may be executable in IE
15:49:44 <rsleevi> ... but not needed for other resources
15:49:51 <rsleevi> cjkula: Kinda said, I liked the idea of other resources
15:49:56 <rsleevi> tobie: Yeah, but we don't need it
15:50:07 <rsleevi> arunranga: I assumed what we could do for script we could use for other things
15:50:19 <rsleevi> tobie: I actually don't need more than that
15:50:23 <hhalpin> q+
15:50:32 <trackbot> trackbot has joined #crypto
15:50:54 <rsleevi> ack cjkula
15:50:57 <rsleevi> ack bblfish
15:51:25 <rsleevi> ??1: When we implemented localStorage, we also implemented userStorage
15:51:30 <virginie> alexandre morgaut
15:51:36 <hhalpin> note that re the "code-signing" in storage use-case is also necessary for a number of other projects from OITP (Open Internet Tools Project).
15:51:40 <virginie> from 4D company, a new W3C member
15:51:41 <rsleevi> ... I wonder if implementing userStorage, which would be encrypted with some user authentication, if that would be useful for you
15:51:42 <hhalpin> q- hhalpin
15:51:53 <rsleevi> tobie: If user meant web user, and not OS user, that might be useful, yes
15:52:13 <rsleevi> ... worried about two (logical) users using the same desktop or mobile device (with same OS user / mobile user)
15:52:25 <rsleevi> ... it's not uncommon to have four to five different sessions/users back to back on the same device
15:52:39 <rsleevi> s/??1/alexandre morgaut/
15:52:57 <rsleevi> alexandre: just wondering if userStorage would be useful
15:53:10 <rsleevi> tobie: I don't think turning forms based auth into http auth would be useful for us
15:53:21 <rsleevi> q+
15:53:53 <rsleevi> mountie: similar concerns with protecting JS source and verifying integrity of JS source
15:54:10 <rsleevi> ... want signed JS to verify that the JS code is correct
15:54:20 <rsleevi> ... not sure how we can verify the JS code
15:54:20 <arunranga> q+ to ask mountie a question
15:54:59 <rsleevi> mountie: If we had enough confidence that JS confidence is the same as from the server, that'd be very helpful
15:55:05 <rsleevi> virginie: New person for arun to interview
15:55:15 <rsleevi> ack mountie
15:55:20 <rsleevi> ack arunranga
15:55:21 <Zakim> arunranga, you wanted to ask mountie a question
15:55:46 <rsleevi> arunranga: There's a slight difference from mountie's description (JS code verification vs activeX) and tobies, which is merely to make sure that sources that have been cached that haven't been tampered with
15:56:06 <rsleevi> ... with activex, there is a digitally signed cab file where running code must be signed
15:56:14 <rsleevi> ... not sure if that case is met
15:56:23 <rsleevi> ... if simply verifying something that is cached, that may be an apples-apples comparison
15:56:25 <hhalpin> q+
15:56:27 <rsleevi> ... but not sure if that's the case
15:56:37 <rsleevi> ... lots of stuff that is arguably out of scope in the existing market
15:56:58 <rsleevi> mountie: thinks the cases are the same
15:57:09 <tantek> I've written up a step-by-step use case scenario - is this approximately the format that is appropriate for the Use Cases document for the Crypto API? http://microformats.org/wiki/key-examples#meeting_someone_and_sending_private_messages
15:57:19 <Yune> Yune has joined #crypto
15:58:31 <rsleevi> rsleevi: Describes proposal for encrypted indexedDB, does that fit into facebook's threat model
15:58:51 <hhalpin> ack hhalpin
15:58:59 <rsleevi> rsleevi: "key" would actually come from Facebook server, given to user, user can use the key, key is removed when user logs out. Just couples localStorage to HTTP session auth
15:59:01 <rsleevi> ack rsleevi
15:59:31 <rsleevi> tobie: Seems reasonable. Users do log out of the page before giving phone away, so this would likely prevent tampering / address the threat model
15:59:41 <rsleevi> hhalpin: Question regarding what makes Korean use case out of scope
15:59:50 <tantek> if the use case I wrote up seems in scope, sufficiently relevant, and in a good enough format, please feel free to incorporate it copy/paste etc. as you see fit - I shared it per CC0 (PD). a citation back to the URL http://microformats.org/wiki/key-examples#meeting_someone_and_sending_private_messages would be appreciated but is not required.
15:59:57 <rsleevi> arunranga: It seems that when we look at how we're doing key generation, etc, we subject it to SoP
16:00:19 <rsleevi> ... in the korean case, keys come from a central cert authority, which is a different origin from the sites that wish to use the credentials
16:00:29 <rsleevi> ... so not sure how other origins would have access to the key material
16:00:49 <rsleevi> ... existing certificates are a lot like multi-origin cert, which differs fundamentally from what we're discussing
16:00:52 <rsleevi> q+ to respond to arun
16:00:57 <hhalpin> http://www.w3.org/2012/webcrypto/track/issues/19
16:01:16 <rsleevi> hhalpin: Wonders if allowing slight variations to SoP would address the korean use case
16:01:24 <kotakagi> kotakagi has joined #crypto
16:01:25 <rsleevi> ... also about code signing
16:01:42 <rsleevi> arunranga: Yeah, current spec definitely seems like a show-stopper
16:01:54 <rsleevi> ... was wondering if we could mold some of those use cases into what we're trying to do here
16:01:56 <rsleevi> ... not sure
16:02:20 <JonathanJ1> rrsagent, draft minutes
16:02:20 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html JonathanJ1
16:02:38 <markw> <offtopic> FYI for everyone in WebCrypto - HTML WG would like to use JWK with symmetric keys to pass keys to the "clearkey" keysystem </offtopic>
16:03:12 <mountie> q+
16:03:13 <virginie> q?
16:03:31 <ddahl> tantek: is there any effort in W3 to standardize a Contacts WebAPI (like the Firefox OS API)?
16:03:39 <virginie> ack rsleevi
16:03:39 <Zakim> rsleevi, you wanted to respond to arun
16:03:40 <rsleevi> rsleevi: thinks that the current API can actually be suitable to meet the korean use cases without changing the security guarantees
16:03:44 <rsleevi> ack mountie
16:03:54 <tlr> tlr has joined #crypto
16:03:55 <tantek> ddahl: yes I'm writing up our contacts API for submission to SysApps WG.
16:04:05 <rsleevi> mountie: One of the issues includes verifying certificates, accessing certificate extensions, OCSP
16:04:21 <rsleevi> mountie: For secondary features, can discuss more about the needs
16:04:32 <rsleevi> virginie: OCSP?
16:04:34 <ddahl> tantek: awesome
16:04:48 <rsleevi> mountie: OCSP is for revocation checking when verifying certificates.
16:05:01 <jin> OCSP - Online Certificate Status Protol
16:05:02 <rsleevi> virginie: Understands the technology - but not sure how this is in scope for the API
16:05:17 <jin> s/Protol/Protocol
16:05:26 <rsleevi> mountie: Wants an API to verify the certificate
16:05:36 <virginie> q?
16:05:44 <rsleevi> virginie: Definitely a secondary feature
16:06:04 <virginie> q?
16:06:07 <rsleevi> drogersuk: Not a fan of OCSP, esp for mobile
16:06:17 <rsleevi> virginie: Any more questions for Special Guest Tobie?
16:07:01 <rsleevi> arunranga: will be following up with additional people
16:07:15 <rsleevi> arunranga: Is this the right approach for this document? This approach of the draft
16:07:40 <rsleevi> virginie: What has been suggested to the WG is that the use cases are part of the next WG deliverable
16:07:49 <rsleevi> ... what you have described is the right way to progress
16:07:51 <rsleevi> q+
16:08:07 <virginie> q+
16:08:45 <arunranga> Strong +1 to rsleevi
16:09:03 <wseltzer> q+
16:09:16 <arunranga> Namely we should describe what we *can* do (and are doing).
16:09:39 <wseltzer> ack rsleevi
16:09:57 <rsleevi> rsleevi: Would like to see sort of two parallel efforts - which is use cases document (to be published) shows what *is* possible with draft API
16:10:07 <rsleevi> rsleevi: and wiki or some sort of separate tracking for what we'd *like* to do
16:10:17 <virginie> q?
16:10:24 <rsleevi> arunranga: Thinks it's important the use cases document exposes what we can do with the API
16:10:38 <rsleevi> arunranga: Secondary place for what we'd like to do and scope future work
16:10:50 <rsleevi> ... helps focus security discussion of primary features
16:10:58 <ttanaka2> ttanaka2 has joined #crypto
16:11:00 <rsleevi> ... and can categorically show if something is possible or not possible
16:11:10 <rsleevi> ... secondary document to serve as roadmap
16:11:35 <rsleevi> virginie: reports previous discussion of key wrapping / unwrapping
16:11:49 <rsleevi> virginie: it wasn't clear if it was an urgent use case for others beyond Netflix
16:12:01 <rsleevi> ... Question for arun while going through use cases is where key wrap/unwrap fit in
16:12:22 <rsleevi> arunranga: short answer is yes, it seems possible to cobble together with existing API
16:12:29 <wseltzer> [I just wanted to suggest that we not spend too much energy on editorial selection among use cases at this point. Better to get the wishlist well-documented, and then see what we can accomplish in-scope.]
16:12:33 <wseltzer> q-
16:12:40 <wseltzer> ack virginie
16:13:19 <rsleevi> [ tobie volunteers himself for discussion with arun ]
16:13:46 <rsleevi> virginie: Thanks for calling in arun
16:13:49 <ddahl> thanks arunranga !
16:13:54 <arunranga> :)
16:14:38 <rsleevi> virginie: Last issue that we have to solve that is high level is the one that is related to origin
16:14:41 <rsleevi> ISSUE-19?
16:14:41 <trackbot> ISSUE-19 -- Does it make sense to have authorized-origin and specific-origin keys -- open
16:14:41 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/19
16:15:25 <rsleevi> virginie: Good progress on today's issues
16:15:34 <rsleevi> virginie: Reminder: Tomorrow is 8:*30*
16:15:47 <rsleevi> Topic: Agenda review for Friday
16:16:00 <rsleevi> [ virginie is presenting proposed agenda again ]
16:16:22 <rsleevi> virginie: Big question: What is a "high-level" API
16:16:29 <ddahl> arunranga: the secure messaging use case also needs "SIGN"
16:16:30 <rsleevi> virginie: What we think it is, what can the group deliver
16:16:48 <arunranga> Zakim, mute me
16:16:48 <Zakim> arunranga should now be muted
16:17:48 <arunranga> ddahl, good point.  i'll probably follow up with you and nadir.
16:17:58 <ddahl> arunranga: anytime:)
16:17:58 <arunranga> s/nadir/nadim
16:18:03 <rsleevi> virginie: PROPOSAL: Stop the meeting
16:18:14 <rsleevi> virginie: RESOLUTION: The meeting is stopped.
16:18:29 <Ruinan> Ruinan has left #crypto
16:18:36 <rsleevi> Zakim, draft the minutes
16:18:36 <Zakim> I don't understand 'draft the minutes', rsleevi
16:19:00 <Zakim> -arunranga
16:19:08 <rsleevi> RRSAgent, please draft the minutes
16:19:08 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html rsleevi
16:20:01 <wseltzer> trackbot, end meeting
16:20:01 <trackbot> Zakim, list attendees
16:20:01 <Zakim> As of this point the attendees have been arunranga, +33.4.72.82.aaaa
16:20:09 <trackbot> RRSAgent, please draft minutes
16:20:09 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/01-crypto-minutes.html trackbot
16:20:10 <trackbot> RRSAgent, bye
16:20:10 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2012/11/01-crypto-actions.rdf :
16:20:10 <RRSAgent> ACTION: rsleevi to specify text that makes it clear we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object [1]
16:20:10 <RRSAgent>   recorded in http://www.w3.org/2012/11/01-crypto-irc#T13-43-44
16:20:10 <RRSAgent> ACTION: mountie to determine if a generic algorithm procedure is necessary for his use-case [2]
16:20:10 <RRSAgent>   recorded in http://www.w3.org/2012/11/01-crypto-irc#T14-16-42