Draft minutes from [W3C Web Crypto WG] 28 July call

Thanks to all who participated in today's WebCrypto WG call.  Draft
minutes can be found at:

and in text below.


      [1] http://www.w3.org/

                               - DRAFT -

             Web Cryptography Working Group Teleconference

28 Jul 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/07/28-crypto-irc


          karen_oDonoghue, Wendy, +1.503.712.aaaa, JYates,
          Matt_Wood, BAL, Michael_Hutchinson, rbarnes,
          Virginie_Galindo, Karen, hhalpin, rsleevi, markw,
          [Microsoft], vgb, Mike_Jones




     * [3]Topics
         1. [4]Intro
         2. [5]Bug 25607, Security Recommendations
         3. [6]Bug 25985, Interoperability
         4. [7]Bug 25839, NUMS and 25519
     * [8]Summary of Action Items

   <trackbot> Date: 28 July 2014

   <rbarnes> is there an agenda posted somewhere?

   scribenick wseltzer


   Virginie: Agenda will begin by focusing on sensitive bugs

   <bal> dialing back in...

   <rsleevi> bug 25607?



   <MichaelH> - 25607 on security recommendation :

     [10] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607

Bug 25607, Security Recommendations


     [11] 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

   <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

   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

     [12] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

Bug 25985, Interoperability

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

     [13] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

   Virginie: This bug on interoperability received lots of
   ... 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
   ... 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

   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



   <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

   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



   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

   Virgine: prefer to resolve that we will address after testing

   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

     [16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839


     [17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

Bug 25839, NUMS and 25519

   <harry> Brian's proposed changes are here:
   l/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

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


     [19] 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
   ... 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

   <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

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

     [20] 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
   ... 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

   <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

   <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

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

   <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

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

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

   <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

   <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

   <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


   trackbot, end teleconf

Summary of Action Items

   [End of minutes]

    Minutes formatted by David Booth's [21]scribe.perl version
    1.138 ([22]CVS log)
    $Date: 2014-07-28 21:05:13 $

Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Monday, 28 July 2014 21:11:29 UTC