19:54:13 <RRSAgent> RRSAgent has joined #crypto
19:54:13 <RRSAgent> logging to http://www.w3.org/2014/07/28-crypto-irc
19:54:15 <trackbot> RRSAgent, make logs public
19:54:15 <Zakim> Zakim has joined #crypto
19:54:17 <trackbot> Zakim, this will be CRYPT
19:54:17 <Zakim> ok, trackbot; I see SEC_WebCryp()3:00PM scheduled to start 54 minutes ago
19:54:18 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:54:18 <trackbot> Date: 28 July 2014
19:55:26 <Zakim> SEC_WebCryp()3:00PM has now started
19:55:33 <Zakim> +karen_oDonoghue
19:56:34 <kodonog> kodonog has joined #crypto
19:57:04 <Zakim> +Wendy
19:57:28 <wseltzer> Chair: Virginie_Galindo
19:57:39 <Zakim> + +1.503.712.aaaa
19:58:05 <Zakim> +JYates
19:58:06 <wseltzer> zakim, aaaa is Matt_Wood
19:58:07 <Zakim> +Matt_Wood; got it
19:58:21 <Zakim> +[Microsoft]
19:58:30 <virginie> virginie has joined #crypto
19:58:42 <rbarnes> rbarnes has joined #crypto
19:58:58 <MichaelH> MichaelH has joined #crypto
19:59:09 <wseltzer> zakim, Microsoft has BAL
19:59:09 <Zakim> +BAL; got it
19:59:13 <bal> bal has joined #crypto
20:00:36 <Zakim> +Michael_Hutchinson
20:00:50 <markw> markw has joined #crypto
20:01:19 <Zakim> +??P5
20:01:39 <harry> Zakim, what's the code?
20:01:39 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), harry
20:01:41 <wseltzer> zakim, ??p5 is rbarnes
20:01:42 <Zakim> +rbarnes; got it
20:01:48 <Zakim> +Virginie_Galindo
20:01:50 <rbarnes> is there an agenda posted somewhere?
20:02:14 <Zakim> +Karen.a
20:02:30 <wseltzer> zakim, who is on the call?
20:02:30 <Zakim> On the phone I see karen_oDonoghue, Wendy, Matt_Wood, JYates, [Microsoft], Michael_Hutchinson, rbarnes, Virginie_Galindo, Karen.a
20:02:32 <Zakim> [Microsoft] has BAL
20:02:32 <Zakim> +[Google]
20:02:41 <Zakim> +[IPcaller]
20:02:46 <harry> Zakim, IPcaller is hhalpin
20:02:46 <Zakim> +hhalpin; got it
20:02:54 <Karen_> Karen_ has joined #crypto
20:03:12 <wseltzer> zakim, Google has rsleevi
20:03:12 <Zakim> +rsleevi; got it
20:03:18 <rsleevi> rsleevi has joined #crypto
20:03:28 <Zakim> +[Netflix]
20:03:40 <wseltzer> zakim, Netflix has markw
20:03:40 <Zakim> +markw; got it
20:03:48 <markw> Zakim, [Netflix] is me
20:03:48 <Zakim> +markw; got it
20:03:53 <Zakim> +[Microsoft.a]
20:04:10 <vgb> zakim, [microsoft.a] is me
20:04:10 <Zakim> +vgb; got it
20:04:10 <wseltzer> zakim, Microsoft.a has vgb
20:04:12 <Zakim> sorry, wseltzer, I do not recognize a party named 'Microsoft.a'
20:04:37 <wseltzer> scribenick wseltzer
20:04:49 <wseltzer> zakim, who is here?
20:04:49 <Zakim> On the phone I see karen_oDonoghue, Wendy, Matt_Wood, JYates, [Microsoft], Michael_Hutchinson, rbarnes, Virginie_Galindo, Karen.a, [Google], hhalpin, markw, vgb
20:04:52 <Zakim> [Microsoft] has BAL
20:04:52 <Zakim> [Google] has rsleevi
20:04:52 <Zakim> markw has markw
20:04:52 <Zakim> On IRC I see rsleevi, Karen_, markw, bal, MichaelH, rbarnes, virginie, kodonog, Zakim, RRSAgent, mdwood, jyates, harry, vgb, tantek, ale, terri, timeless, slightlyoff, tobie,
20:04:53 <Zakim> ... wseltzer, trackbot
20:06:06 <wseltzer> Topic: Intro
20:06:09 <Zakim> +[Microsoft.a]
20:06:21 <wseltzer> Virginie: Agenda will begin by focusing on sensitive bugs
20:06:40 <wseltzer> zakim, Microsoft.a has Mike_Jones
20:06:40 <Zakim> +Mike_Jones; got it
20:07:38 <Zakim> -[Microsoft]
20:07:44 <bal> dialing back in...
20:07:59 <selfissued> selfissued has joined #crypto
20:08:01 <rsleevi> bug 25607?
20:08:05 <wseltzer> -> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0097.html
20:08:14 <MichaelH> - 25607 on security recommendation : https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
20:08:17 <Zakim> +[Microsoft]
20:08:19 <wseltzer> Topic: Bug 25607, Security Recommendations
20:08:22 <rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
20:08:27 <bal> muted now, thanks
20:08:38 <wseltzer> Virginie: Security recommendations
20:09:11 <wseltzer> ... Have some editorial notes; still have open comment that we should make reference to know attacks
20:09:21 <wseltzer> ... Akamai comments, post from Graham Steele
20:10:07 <wseltzer> ... CFRG could maintain document with reference to attacks and potential vulnerabilities in WebCrypto algorithms
20:10:42 <harry> Essentially, we have a security considerations doc in the IETF CFRG, and Rich Salz from Akamai is happy with that solution as long as we link to said document when it exists.
20:10:50 <harry> Graham Steel will make a first version.
20:10:54 <wseltzer> ... Proposed resolution: close the bug by endorsing clarifications in ED and referencing IETF CFRG
20:11:08 <wseltzer> ... adding that reference when the doc is available
20:11:09 <wseltzer> q?
20:11:33 <wseltzer> rbarnes: Sounds fine to me
20:11:34 <harry> q+
20:11:46 <wseltzer> BAL: Not sure CFRG has yet agreed to take up the work
20:13:14 <wseltzer> Wendy: CFRG expressed interest, although not formal commitment
20:13:18 <bal> q+
20:13:40 <wseltzer> Harry: Response generally positive; no objections
20:13:48 <harry> Note that we did formally ask the CFRG as well, no objections.
20:14:09 <harry> i.e. Individual Submission - and the W3C did commit to helping with that process.
20:14:21 <wseltzer> BAL: This could certainly proceed as an ID (individual submission); it would take process for it to become official work of CFRG
20:14:23 <harry> So that people in the WG do not have to pay attention - unless they want to :)
20:14:28 <wseltzer> ack bal
20:15:05 <wseltzer> Virginie: Is that still a good resolution?
20:15:12 <harry> q+
20:15:19 <wseltzer> BAL: We'll need to see text, but in principle, sounds as though it can work
20:15:24 <harry> I'm happy to take that action.
20:15:26 <wseltzer> ack harry
20:15:43 <MichaelH> q+
20:15:55 <wseltzer> Harry: Happy to take the action to get a suitable first version from Graham Steel, put it through the IETF proces
20:16:06 <wseltzer> ack MichaelH
20:16:22 <wseltzer> MichaelH: What is the timeline for having a trackable ID from CFRG?
20:16:42 <wseltzer> Harry: expect a document by early September
20:17:03 <MichaelH> ack
20:17:08 <MichaelH> q-
20:17:28 <harry> Worse case, if IETF doesn't accept we could make it a WG note.
20:17:31 <wseltzer> ... and IETF response shortly after (weeks, not months)
20:17:34 <wseltzer> q?
20:17:51 <harry> [looking]
20:17:57 <wseltzer> Proposed resolution: The WG to resolve the bug 25607 by (1) endorsing clarifications from the recent editors draft and (2) referencing to a document listing algorithms attacks and vulnerabilities, maintained by IETF CFRG (to be added in the specification by the editors as soon as available).
20:18:42 <rsleevi> +1
20:18:45 <MichaelH> +1
20:18:45 <rbarnes> +1
20:18:47 <wseltzer> Virginie: +1 if you agree, -1 if you object
20:18:47 <bal> +1
20:18:50 <vgb> +1
20:18:51 <kodonog> +1
20:18:54 <Karen_> +1
20:18:58 <harry> virginie +1
20:19:13 <harry> looks like resolution!
20:19:23 <wseltzer> RESOLVED: The WG to resolve the bug 25607 by (1) endorsing clarifications from the recent editors draft and (2) referencing to a document listing algorithms attacks and vulnerabilities, maintained by IETF CFRG (to be added in the specification by the editors as soon as available).
20:20:07 <MichaelH> - 25985 on interoperability https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985
20:20:11 <wseltzer> Topic: Bug 25985, Interoperability
20:20:25 <wseltzer> -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 Bug 25985
20:20:40 <wseltzer> Virginie: This bug on interoperability received lots of comments
20:20:58 <wseltzer> ... one suggestion, what about writitng browser profile after we have done implementation testing?
20:21:31 <wseltzer> ... This profile would be non-normative
20:22:06 <wseltzer> ... So potential resolution, wait for testing, write non-normative profile
20:22:14 <rbarnes> comments from anne, like annevk?
20:22:17 <rsleevi> yes
20:22:21 <harry> yes, annevk
20:22:29 <wseltzer> q?
20:22:30 <rsleevi> q+
20:22:49 <harry> Annvk has not objected nor is he member of the WG, I think he may just want an explanation at this stage (i.e. non-browser implementations)
20:23:09 <wseltzer> Virginie: potential resolution, bug stays open, then later write non-normative profile
20:23:22 <wseltzer> rsleevi: there could be several profiles.
20:23:46 <wseltzer> ... There's a use case for smart TVs, traditional web, sysapps
20:24:07 <wseltzer> ... So suggestion was that all use cases benefit from normative requirements, but their sets of normative reqs differ
20:24:32 <wseltzer> ... It will be tricky to nail down normative reqs for each use case, but we could do so
20:24:46 <MichaelH> q+
20:24:48 <wseltzer> ... They don't have to be non-normative
20:24:51 <wseltzer> q- rsleevi
20:24:53 <wseltzer> ack MichaelH
20:25:22 <wseltzer> MichaelH: Trying to understand how we'd make browsers interoperable
20:25:36 <wseltzer> ... keys are stored in the browser
20:26:08 <harry> harry has joined #crypto
20:26:27 <wseltzer> rsleevi: The issue of interop is not about key storage, but the set of algorithms exposed to the Web
20:26:49 <wseltzer> ... so, e.g., web devs can know that if a browser claims to support WebCrypto, it supports SHA1
20:27:16 <wseltzer> ... interop requriment is that web devs don't have to guess about algo support
20:27:30 <rbarnes> q+
20:27:43 <wseltzer> MichaelH: Is that even achievable?
20:28:37 <wseltzer> rbarnes: At the level we have now, there's not such a combinatorial issue
20:29:01 <wseltzer> ... you'd batch them into API levels
20:29:18 <wseltzer> ... e.g. WebCrypto level 1 is what everyone does now; level 2 is next version
20:29:34 <wseltzer> ... I'm fine having normative requirements, but that might make us more conservative
20:30:03 <selfissued> q+
20:30:18 <harry> q- rbarnes
20:30:19 <wseltzer> ... PKCS1 is everywhere; PSS not so widespread
20:30:38 <wseltzer> rsleevi: Spec will not have normative requirements; a dictionary of algorithms and very precise implementations
20:30:41 <rbarnes> most of the impact of that conservatism is probably on EC curves
20:30:50 <wseltzer> ... but not requirement on what UAs implement what algos
20:30:57 <rbarnes> (i hope it's obvious that EC curves are an important element here)
20:31:08 <wseltzer> ... requirements documents will await testing and determination of use cases
20:31:25 <wseltzer> ... consensus among browsers seems to be that browser profile should be normative
20:31:37 <wseltzer> ... but different use cases may have different interop requirments
20:31:39 <bal> q+
20:31:42 <wseltzer> q+
20:31:51 <wseltzer> ack selfissued
20:32:23 <wseltzer> selfissued: Whether it's normative or not, we do need to keep at least one profile so we can achieve interop
20:32:34 <wseltzer> ... Choices should be driven by what's commonly available
20:32:44 <bal> q-
20:32:48 <wseltzer> ... and interoperable set sufficient for interop with JOSE
20:33:17 <wseltzer> ... PCKS1, 1.5 signatures, RSA encryption, AES keywrap. GCM highly recommended
20:34:25 <wseltzer> Wendy: don't need to set normativity/non-normativity of profiles
20:34:31 <rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations-implementers
20:34:35 <rbarnes> note that we've already broken JOSE compatibility by removing "RSA1_5"
20:34:38 <wseltzer> Virginie: Several profiles possible
20:35:09 <MichaelH> q+
20:35:18 <wseltzer> Proposed Resolution: Leave bug open; expect resolution after testing phase with development of one or more profiles
20:35:35 <wseltzer> q-
20:35:40 <harry> Just communicate to Boris and Annevk that we *will* have profiles that will achieve interop within clearly defined subsets of implementations, as should be known after test-suite.
20:36:01 <wseltzer> MichaelH: We should resolve the question of normative/non-normative now
20:36:06 <harry> q+
20:36:11 <wseltzer> ack MichaelH
20:36:39 <wseltzer> Virginie: we could say normative, if people agree
20:37:26 <wseltzer> Harry: It's harder to say what exactly will be least common set before implementation, testing
20:37:47 <wseltzer> ... it's kicking the can down the road until we can see what implementations will exist
20:38:04 <wseltzer> MichaelH: We should say that at least one or more profile will be normative
20:38:10 <rbarnes> q+
20:38:16 <wseltzer> ack harry
20:38:19 <harry> I think the idea was that different kinds of implementations may have different sets, possibly without LCDs
20:38:19 <wseltzer> ack rbarnes
20:38:31 <rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations-implementers
20:38:39 <wseltzer> rbarnes: Our objective with the profile is to specify what's both desirable and feasbile to implement
20:38:49 <wseltzer> ... what subset of the current proposal
20:39:06 <wseltzer> ... current proposal: see what's implemented, then document that
20:39:24 <wseltzer> Virgine: prefer to resolve that we will address after testing phase
20:40:14 <wseltzer> Proposed Resolution: Leave the bug open; expect to resolve it after testing phase by developing one or more profiles
20:40:22 <rsleevi> +1
20:40:24 <rbarnes> +!
20:40:25 <wseltzer> Virginie: +1 to agree, -1 to object
20:40:27 <selfissued> +1
20:40:27 <markw> +1
20:40:27 <rbarnes> +1
20:40:32 <mdwood> +1
20:40:33 <Karen_> +1
20:40:47 <rbarnes> yeah!!!!
20:40:57 <wseltzer> RESOLVED: Leave the bug open; expect to resolve it after testing phase by  developing one or more profiles
20:41:16 <MichaelH> - 25839 on curve25519 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
20:41:19 <harry> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
20:41:37 <wseltzer> Topic: Bug 25839, NUMS and 25519
20:41:39 <harry> Brian's proposed changes are here: http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html (attached as WORD Doc)
20:41:57 <wseltzer> Virginie: Microsoft and BAL have provided us with a document
20:42:21 <wseltzer> ... Will we include this curve in our main spec, as provided by Microsoft, or
20:42:36 <wseltzer> ... will we make it a dedicated extension, with its own rec track
20:42:45 <harry> Note extenisve comments and notice also that Trevor Perrin has resolved to direclty address 25519
20:43:04 <wseltzer> ... Recently, we got an offer from Trevor to write up 25519 as an extension
20:43:04 <harry> Also note extensive discussion in CFRG on named curves for TLS
20:43:33 <rbarnes> harry: yes, taking action on this seems a little premature given that
20:43:36 <wseltzer> Virginie; I have suggested that we vote to endorse Microsoft's description either within API directly or as extension
20:43:38 <kodonog> +1 (for 25985 ... <didn't hit return>)
20:43:39 <harry> http://www.ietf.org/mail-archive/web/cfrg/current/maillist.html
20:43:43 <wseltzer> q?
20:43:45 <bal> q+
20:43:55 <rbarnes> what was the proposed resolution?
20:44:16 <wseltzer> BAL: I want to make everyone in the WG aware that this was the topic of extensive discussion at last week's IETF
20:44:24 <wseltzer> ... both NUMS, 25519, and others at  higher level
20:44:29 <wseltzer> ... No resolution yet from CFRG
20:44:44 <wseltzer> ... Requirements-gathering for a few more weeks, then 4-week comment period
20:44:46 <wseltzer> q+
20:45:05 <wseltzer> ... When I wrote the doc, I put in 4 curves
20:45:05 <rbarnes> q+
20:45:08 <rbarnes> q-
20:45:23 <wseltzer> ... There does not seem to be much interest in the Weirstrass curves, more interest in the performant versions
20:45:39 <wseltzer> ... If I were rewriting it now, I'd probably include only twisted-Edwards
20:45:52 <wseltzer> ... prefer to see a non-NIST optiom in the main spec
20:46:03 <rbarnes> q+
20:46:10 <wseltzer> q- bal
20:46:14 <wseltzer> q- wseltzer
20:46:30 <bal> Slight correction: *6* curves were added initially
20:46:31 <harry> wseltzer: It seems discussions are energetic in IETF and CFRG
20:46:39 <bal> I'd scale back to *3*
20:46:44 <bal> for the main spec
20:46:59 <harry> ... so now is not the best time to have new curves although what is recommended to TLS will likely have wide implementation
20:47:15 <harry> ... it would be good if we could be synchronized with what ends up being recommended by TLS
20:47:23 <wseltzer> ack rbarnes
20:47:45 <wseltzer> rbarnes: I sympathize with Brian's desire to get non-NIST curves included as soon as possible
20:47:52 <selfissued> q+
20:47:57 <bal> q+
20:47:57 <markw> +1 to what Richard said
20:48:00 <wseltzer> ... procedurally, it would be easier to handle this as an extension
20:48:09 <harry> ack selfissued
20:48:30 <rbarnes> in other words, let's have the fight once, in CFRG :)
20:48:36 <wseltzer> selfissued: My main concern is that we should have an easy way to add algorithms without having to revise the spec
20:49:17 <wseltzer> ... we need an extension mechanism
20:49:42 <wseltzer> bal: a further complication; TLS WG took action to take all their existing EC specs to standards track
20:49:57 <harry> See here for extensibility bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618
20:49:59 <wseltzer> ... so a subsequent discussion for TLS will be what should be mandatory to implement
20:50:09 <wseltzer> ... Right now, nothing EC is MTI
20:50:36 <wseltzer> ... but depending how we do this, extensions, profiles, we might need to make extension specs mandatory for some interop profiles
20:50:54 <wseltzer> ... I have a preference to get this into the spec quickly
20:50:55 <Zakim> rsleevi, you wanted to respond to selfissued
20:51:23 <wseltzer> rsleevi: I don't think in practice that extension spec or main spec will change availability for the web
20:51:30 <bal> q+
20:51:51 <wseltzer> ... procedural track and availability/implementation differ
20:52:03 <harry> I am wondering aloud if this should be resolved in the same way we resolved "profiles", i.e. get a good extension mechanism and then kick this down the road - and then fix normativity at same time as BAL mentions.
20:52:09 <wseltzer> ... I dont' think it would be a problem to support extensions as part of MTI profile
20:52:17 <MichaelH> Harry +1
20:52:31 <wseltzer> ... interdependencies are part of the extensibility bug
20:52:37 <markw> q+
20:52:41 <wseltzer> ... We don't yet have a good point for extensibility
20:52:53 <wseltzer> ... so hearing from implementers would be helpful
20:52:55 <harry> So we merge that into the extensibility mechansim and try to fix that process before going out of Last Call.
20:53:11 <wseltzer> ... WG needs to do more review, to identify extensibility bugs and resolve them
20:53:18 <bal> q-
20:53:19 <bal> q+
20:53:22 <wseltzer> ... definitely need to make the spec extensible, let every algo stand on its own
20:53:30 <wseltzer> ... concern re naming of algos
20:53:46 <wseltzer> ... think of main spec as just
20:53:57 <wseltzer> ... "colleciton of extensions"
20:54:15 <harry> Sounds like we may need a good proposal on extensibility and then a call next week.
20:54:15 <bal> q-
20:54:28 <wseltzer> markw: We do have an extension point; you can add more algorithms
20:54:30 <bal> q+
20:54:35 <rsleevi> Well, our extension plan is buggy, that's my point :)
20:54:39 <rsleevi> Not that we don't ahve one, it's just buggy
20:55:02 <wseltzer> bal: The extensions that allow you to add new algs don't really work well with EC, or mirror IETF
20:55:03 <rsleevi> I do agree with bal@ that we do need to fix curve extensibility :)
20:55:10 <rbarnes> +1 to having curves be a separate extension point
20:55:16 <wseltzer> ... implementatoins; independent libraries can be updated relatively quickly
20:55:18 <wseltzer> ack bal
20:55:19 <harry> q+
20:55:44 <wseltzer> harry: This bug sounds as though it's merging with the extension bug
20:56:00 <wseltzer> ... so I suggest we focus on extensibility
20:56:40 <wseltzer> bal: Depends on process. There's some text on the bug
20:56:53 <wseltzer> ... I'd like to get a pre-acceptance of extension spec
20:57:03 <wseltzer> ... showing commitment to offer customers a non-NIST option
20:57:05 <rbarnes> +1 to a "non-NIST curves" deliverable
20:57:11 <harry> sounds reasonable to me.
20:57:12 <wseltzer> ... if we don't put it into the main spec today
20:57:39 <wseltzer> Virginie: Feeling that including the contribution as an extension is reasonable
20:58:27 <wseltzer> ... so propose resolution "wg endorses curve provided by Microsoft as extension document"
20:58:27 <rsleevi> As mentioned on the Curve25519 thread, I have no issues towards having people bring extension specs for discussion about adding to REC track. The only thing that really speaks to UA concerns would be MTI, but that's orthogonal to a REC track for (NUMS, Curve25519, 3DES, MD5, SEED, GOST, etc)
20:58:48 <wseltzer> ... we need to fix both extensibility and adding curves
20:58:50 <rsleevi> (Well, and any hypothetical IPR concerns about bringing an alg towards REC, but that's just W3C process)
20:59:15 <wseltzer> bal: I'd rather have something opposite NIST directly in the spec
20:59:23 <harry> The text is "The WG is endorsing the curve description provided by Microsoft, in a dedicated extension, which will have its own track to become a Recommendation."
20:59:32 <wseltzer> ... but if we must do it elsewhere, make sure it's on the smae timeline
20:59:37 <wseltzer> q+
20:59:37 <harry> Maybe we could have a straw poll on "main spec" vs. "extension"?
21:00:03 <MichaelH> Could the NIST curves also be in extension spec?
21:00:20 <bal> q+
21:00:27 <wseltzer> q-
21:00:33 <harry> wseltzer: Could we move the decision about whether text is in main spec or extension spec to later?
21:00:46 <harry> ... when we know how situation develops in IETF and CFRG.
21:00:51 <rsleevi> @MichaelH: as mentioned, conceptually, *all* algorithms are extension spec
21:01:07 <bal> q-
21:01:11 <wseltzer> Virginie: think we'll have to move the discussion to mailing list
21:01:27 <harry> I would have a call on "extension mechanisms"
21:01:27 <bal> +1
21:01:30 <wseltzer> ... propose a dedicated call
21:01:32 <Zakim> -rbarnes
21:01:41 <vgb> +1
21:01:43 <rsleevi> 2 weeks seems like too long. But +1 to a dedicated call
21:01:45 <kodonog> +1
21:01:47 <rbarnes> +1
21:01:56 <markw> +1 (sooner)
21:01:57 <selfissued> +1
21:01:58 <harry> Next week is fine with me if we make progress
21:02:02 <selfissued> or in one week is ok
21:02:03 <rsleevi> It seems like it'd be much more useful to just hash out on the mailing list, come to a proposed RESOLUTION, and just put that out on the list
21:02:15 <rsleevi> there seems to be a few requirements:
21:02:22 <rsleevi> - If an ext spec, main spec needs to support extension points
21:02:27 <rsleevi> - If an ext spec, it needs to be REC track
21:02:29 <wseltzer> Virginie: Call in 2 weeks
21:02:31 <harry> Depends likely how contentious mailing list discussion is.
21:02:41 <rsleevi> - If an ext spec, it should be on the same timeline as the main spec (I don't think we can commit to this, but for mailing list)
21:03:02 <rsleevi> I think these at least bear discussing, I think some of these are non-controversial and easy to resolve
21:03:12 <markw> @rsleevi - do you have a proposal for extension points ?
21:03:17 <wseltzer> Wendy: let's try to resolve or converge on mailing list
21:03:31 <wseltzer> Virginie: last bug we'll bring to the mailing list
21:03:42 <wseltzer> RESOLVED: Next call in 2 weeks, same time
21:04:00 <Zakim> -karen_oDonoghue
21:04:02 <Zakim> -JYates
21:04:02 <harry> RRSAgent, generate minutes
21:04:02 <RRSAgent> I have made the request to generate http://www.w3.org/2014/07/28-crypto-minutes.html harry
21:04:03 <Zakim> -vgb
21:04:06 <wseltzer> [adjourned]
21:04:06 <Zakim> -Karen.a
21:04:07 <Zakim> -Matt_Wood
21:04:07 <Zakim> -Virginie_Galindo
21:04:08 <harry> RRSAgent, generate minutes
21:04:08 <RRSAgent> I have made the request to generate http://www.w3.org/2014/07/28-crypto-minutes.html harry
21:04:09 <Zakim> -Wendy
21:04:10 <Zakim> -markw
21:04:10 <Zakim> -[Google]
21:04:22 <Zakim> -[Microsoft.a]
21:04:26 <Zakim> -Michael_Hutchinson
21:04:30 <Zakim> -[Microsoft]
21:05:00 <wseltzer> trackbot, end teleconf
21:05:00 <trackbot> Zakim, list attendees
21:05:00 <Zakim> As of this point the attendees have been karen_oDonoghue, Wendy, +1.503.712.aaaa, JYates, Matt_Wood, BAL, Michael_Hutchinson, rbarnes, Virginie_Galindo, Karen, hhalpin, rsleevi,
21:05:03 <Zakim> ... markw, [Microsoft], vgb, Mike_Jones
21:05:08 <trackbot> RRSAgent, please draft minutes
21:05:08 <RRSAgent> I have made the request to generate http://www.w3.org/2014/07/28-crypto-minutes.html trackbot
21:05:09 <trackbot> RRSAgent, bye
21:05:09 <RRSAgent> I see no action items