<trackbot> Date: 28 July 2014

<rbarnes> is there an agenda posted somewhere?

scribenick wseltzer

Intro

Virginie: Agenda will begin by focusing on sensitive bugs

<bal> dialing back in...

<rsleevi> bug 25607?

-> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0097.html

<MichaelH> - 25607 on security recommendation : https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607

Bug 25607, Security Recommendations

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607

<bal> muted now, thanks

Virginie: Security recommendations
... Have some editorial notes; still have open comment that we should make reference to know attacks
... Akamai comments, post from Graham Steele
... CFRG could maintain document with reference to attacks and potential vulnerabilities in WebCrypto algorithms

<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.

<harry> Graham Steel will make a first version.

Virginie: Proposed resolution: close the bug by endorsing clarifications in ED and referencing IETF CFRG
... adding that reference when the doc is available

rbarnes: Sounds fine to me

BAL: Not sure CFRG has yet agreed to take up the work

Wendy: CFRG expressed interest, although not formal commitment

Harry: Response generally positive; no objections

<harry> Note that we did formally ask the CFRG as well, no objections.

<harry> i.e. Individual Submission - and the W3C did commit to helping with that process.

BAL: This could certainly proceed as an ID (individual submission); it would take process for it to become official work of CFRG

<harry> So that people in the WG do not have to pay attention - unless they want to :)

Virginie: Is that still a good resolution?

BAL: We'll need to see text, but in principle, sounds as though it can work

<harry> I'm happy to take that action.

Harry: Happy to take the action to get a suitable first version from Graham Steel, put it through the IETF proces

MichaelH: What is the timeline for having a trackable ID from CFRG?

Harry: expect a document by early September

<MichaelH> ack

<harry> Worse case, if IETF doesn't accept we could make it a WG note.

Harry: and IETF response shortly after (weeks, not months)

<harry> [looking]

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).

<rsleevi> +1

<MichaelH> +1

<rbarnes> +1

Virginie: +1 if you agree, -1 if you object

<bal> +1

<vgb> +1

<kodonog> +1

<Karen_> +1

<harry> virginie +1

<harry> looks like resolution!

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).

<MichaelH> - 25985 on interoperability https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

Bug 25985, Interoperability

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 Bug 25985

Virginie: This bug on interoperability received lots of comments
... one suggestion, what about writitng browser profile after we have done implementation testing?
... This profile would be non-normative
... So potential resolution, wait for testing, write non-normative profile

<rbarnes> comments from anne, like annevk?

<rsleevi> yes

<harry> yes, annevk

<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)

Virginie: potential resolution, bug stays open, then later write non-normative profile

rsleevi: there could be several profiles.
... There's a use case for smart TVs, traditional web, sysapps
... So suggestion was that all use cases benefit from normative requirements, but their sets of normative reqs differ
... It will be tricky to nail down normative reqs for each use case, but we could do so
... They don't have to be non-normative

MichaelH: Trying to understand how we'd make browsers interoperable
... keys are stored in the browser

rsleevi: The issue of interop is not about key storage, but the set of algorithms exposed to the Web
... so, e.g., web devs can know that if a browser claims to support WebCrypto, it supports SHA1
... interop requriment is that web devs don't have to guess about algo support

MichaelH: Is that even achievable?

rbarnes: At the level we have now, there's not such a combinatorial issue
... you'd batch them into API levels
... e.g. WebCrypto level 1 is what everyone does now; level 2 is next version
... I'm fine having normative requirements, but that might make us more conservative
... PKCS1 is everywhere; PSS not so widespread

rsleevi: Spec will not have normative requirements; a dictionary of algorithms and very precise implementations

<rbarnes> most of the impact of that conservatism is probably on EC curves

rsleevi: but not requirement on what UAs implement what algos

<rbarnes> (i hope it's obvious that EC curves are an important element here)

rsleevi: requirements documents will await testing and determination of use cases
... consensus among browsers seems to be that browser profile should be normative
... but different use cases may have different interop requirments

selfissued: Whether it's normative or not, we do need to keep at least one profile so we can achieve interop
... Choices should be driven by what's commonly available
... and interoperable set sufficient for interop with JOSE
... PCKS1, 1.5 signatures, RSA encryption, AES keywrap. GCM highly recommended

Wendy: don't need to set normativity/non-normativity of profiles

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations-implementers

<rbarnes> note that we've already broken JOSE compatibility by removing "RSA1_5"

Virginie: Several profiles possible

Proposed Resolution: Leave bug open; expect resolution after testing phase with development of one or more profiles

<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.

MichaelH: We should resolve the question of normative/non-normative now

Virginie: we could say normative, if people agree

Harry: It's harder to say what exactly will be least common set before implementation, testing
... it's kicking the can down the road until we can see what implementations will exist

MichaelH: We should say that at least one or more profile will be normative

<harry> I think the idea was that different kinds of implementations may have different sets, possibly without LCDs

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations-implementers

rbarnes: Our objective with the profile is to specify what's both desirable and feasbile to implement
... what subset of the current proposal
... current proposal: see what's implemented, then document that

Virgine: prefer to resolve that we will address after testing phase

Proposed Resolution: Leave the bug open; expect to resolve it after testing phase by developing one or more profiles

<rsleevi> +1

<rbarnes> +!

Virginie: +1 to agree, -1 to object

<selfissued> +1

<markw> +1

<rbarnes> +1

<mdwood> +1

<Karen_> +1

<rbarnes> yeah!!!!

RESOLUTION: Leave the bug open; expect to resolve it after testing phase by developing one or more profiles

<MichaelH> - 25839 on curve25519 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

<harry> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

Bug 25839, NUMS and 25519

<harry> Brian's proposed changes are here: http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html (attached as WORD Doc)

Virginie: Microsoft and BAL have provided us with a document
... Will we include this curve in our main spec, as provided by Microsoft, or
... will we make it a dedicated extension, with its own rec track

<harry> Note extenisve comments and notice also that Trevor Perrin has resolved to direclty address 25519

Virginie: Recently, we got an offer from Trevor to write up 25519 as an extension

<harry> Also note extensive discussion in CFRG on named curves for TLS

<rbarnes> harry: yes, taking action on this seems a little premature given that

Virginie; I have suggested that we vote to endorse Microsoft's description either within API directly or as extension

<kodonog> +1 (for 25985 ... <didn't hit return>)

<harry> http://www.ietf.org/mail-archive/web/cfrg/current/maillist.html

<rbarnes> what was the proposed resolution?

BAL: I want to make everyone in the WG aware that this was the topic of extensive discussion at last week's IETF
... both NUMS, 25519, and others at higher level
... No resolution yet from CFRG
... Requirements-gathering for a few more weeks, then 4-week comment period
... When I wrote the doc, I put in 4 curves
... There does not seem to be much interest in the Weirstrass curves, more interest in the performant versions
... If I were rewriting it now, I'd probably include only twisted-Edwards
... prefer to see a non-NIST optiom in the main spec

<bal> Slight correction: *6* curves were added initially

<harry> wseltzer: It seems discussions are energetic in IETF and CFRG

<bal> I'd scale back to *3*

<bal> for the main spec

<harry> ... so now is not the best time to have new curves although what is recommended to TLS will likely have wide implementation

<harry> ... it would be good if we could be synchronized with what ends up being recommended by TLS

rbarnes: I sympathize with Brian's desire to get non-NIST curves included as soon as possible

<markw> +1 to what Richard said

rbarnes: procedurally, it would be easier to handle this as an extension

<rbarnes> in other words, let's have the fight once, in CFRG :)

selfissued: My main concern is that we should have an easy way to add algorithms without having to revise the spec
... we need an extension mechanism

bal: a further complication; TLS WG took action to take all their existing EC specs to standards track

<harry> See here for extensibility bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

bal: so a subsequent discussion for TLS will be what should be mandatory to implement
... Right now, nothing EC is MTI
... but depending how we do this, extensions, profiles, we might need to make extension specs mandatory for some interop profiles
... I have a preference to get this into the spec quickly

<Zakim> rsleevi, you wanted to respond to selfissued

rsleevi: I don't think in practice that extension spec or main spec will change availability for the web
... procedural track and availability/implementation differ

<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.

rsleevi: I dont' think it would be a problem to support extensions as part of MTI profile

<MichaelH> Harry +1

rsleevi: interdependencies are part of the extensibility bug
... We don't yet have a good point for extensibility
... so hearing from implementers would be helpful

<harry> So we merge that into the extensibility mechansim and try to fix that process before going out of Last Call.

rsleevi: WG needs to do more review, to identify extensibility bugs and resolve them
... definitely need to make the spec extensible, let every algo stand on its own
... concern re naming of algos
... think of main spec as just
... "colleciton of extensions"

<harry> Sounds like we may need a good proposal on extensibility and then a call next week.

markw: We do have an extension point; you can add more algorithms

<rsleevi> Well, our extension plan is buggy, that's my point :)

<rsleevi> Not that we don't ahve one, it's just buggy

bal: The extensions that allow you to add new algs don't really work well with EC, or mirror IETF

<rsleevi> I do agree with bal@ that we do need to fix curve extensibility :)

<rbarnes> +1 to having curves be a separate extension point

bal: implementatoins; independent libraries can be updated relatively quickly

harry: This bug sounds as though it's merging with the extension bug
... so I suggest we focus on extensibility

bal: Depends on process. There's some text on the bug
... I'd like to get a pre-acceptance of extension spec
... showing commitment to offer customers a non-NIST option

<rbarnes> +1 to a "non-NIST curves" deliverable

<harry> sounds reasonable to me.

bal: if we don't put it into the main spec today

Virginie: Feeling that including the contribution as an extension is reasonable
... so propose resolution "wg endorses curve provided by Microsoft as extension document"

<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)

Virginie: we need to fix both extensibility and adding curves

<rsleevi> (Well, and any hypothetical IPR concerns about bringing an alg towards REC, but that's just W3C process)

bal: I'd rather have something opposite NIST directly in the spec

<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."

bal: but if we must do it elsewhere, make sure it's on the smae timeline

<harry> Maybe we could have a straw poll on "main spec" vs. "extension"?

<MichaelH> Could the NIST curves also be in extension spec?

<harry> wseltzer: Could we move the decision about whether text is in main spec or extension spec to later?

<harry> ... when we know how situation develops in IETF and CFRG.

<rsleevi> @MichaelH: as mentioned, conceptually, *all* algorithms are extension spec

Virginie: think we'll have to move the discussion to mailing list

<harry> I would have a call on "extension mechanisms"

<bal> +1

Virginie: propose a dedicated call

<vgb> +1

<rsleevi> 2 weeks seems like too long. But +1 to a dedicated call

<kodonog> +1

<rbarnes> +1

<markw> +1 (sooner)

<selfissued> +1

<harry> Next week is fine with me if we make progress

<selfissued> or in one week is ok

<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

<rsleevi> there seems to be a few requirements:

<rsleevi> - If an ext spec, main spec needs to support extension points

<rsleevi> - If an ext spec, it needs to be REC track

Virginie: Call in 2 weeks

<harry> Depends likely how contentious mailing list discussion is.

<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)

<rsleevi> I think these at least bear discussing, I think some of these are non-controversial and easy to resolve

<markw> @rsleevi - do you have a proposal for extension points ?

Wendy: let's try to resolve or converge on mailing list

Virginie: last bug we'll bring to the mailing list

RESOLUTION: Next call in 2 weeks, same time

[adjourned]

trackbot, end teleconf

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: wseltzer
Inferring Scribes: wseltzer
Default Present: karen_oDonoghue, Wendy, +1.503.712.aaaa, JYates, Matt_Wood, BAL, Michael_Hutchinson, rbarnes, Virginie_Galindo, Karen, hhalpin, rsleevi, markw, [Microsoft], vgb, Mike_Jones
Present: karen_oDonoghue Wendy +1.503.712.aaaa JYates Matt_Wood BAL Michael_Hutchinson rbarnes Virginie_Galindo Karen hhalpin rsleevi markw [Microsoft] vgb Mike_Jones
Found Date: 28 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/28-crypto-minutes.html
People with action items: