[minutes] Re: W3C Web Crypto WG - monday 4th of march

Draft minutes below and at



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

                               - DRAFT -

             Web Cryptography Working Group Teleconference

04 Mar 2013

   See also: [2]IRC log

      [2] http://www.w3.org/2013/03/04-crypto-irc


          +, Wendy, mountie, +1.512.257.aabb,
          virginie, +1.408.540.aacc, markw, +1.707.799.aadd,
          rsleevi, emily, ddahl, +1.703.284.aaee, rbarnes,
          +1.512.257.aaff, John_Simmons, karen, hhalpin,




     * [3]Topics
         1. [4]Welcome
         2. [5]minutes of previous call
         3. [6]web crypto api
         4. [7]High level API
     * [8]Summary of Action Items

   <wseltzer> me trackbot, prepare teleconf

   <trackbot> Date: 04 March 2013

   <mountie> zakim aaaa is mountie

   <virginie> agendda?

   <wseltzer> [agenda
   /0017.html ]



minutes of previous call

   <virginie> [10]http://www.w3.org/2013/02/18-crypto-minutes.html

     [10] http://www.w3.org/2013/02/18-crypto-minutes.html

   <wseltzer> scribenick: johnsim

   no objection - minutes are approved

web crypto api

   call for action on whether we need to get IANA registration

   <hhalpin> Its not a requirement, but its a discussion that we
   need to take seriously

   <hhalpin> we would *not* do it without a WG decision.

   any comments?

   Ryan: strong objections. some of the fundamental objections is
   chartered purpose - web browsers versus generic API

   hhalpin: algorithm agility - other working groups have had
   similar problems - face to face or a separate phone call for
   this issue


   <rsleevi> Registries: Good for protocols, bad for APIs

   Virginie: would like to understand how this should work -
   perhaps dedicated call to get common terminology would be

   <hhalpin> I think it depends. For example, one way to get
   around is to use URIs for algorithms, which is what XML-DSIG

   Virginie: joint working group - ? or better face-to-face?

   hhalpin: others have had this problem - a discussion between me
   and ryan - different positions - be careful before closing
   issue down

   <rbarnes> we need to clarify (1) what properties we need to get
   out of the process for managing algorithms, (2) what the
   concrete proposed processes are for adding algorithms are, and
   (3) how they perform relative to the requirements

   <hhalpin> Given that lots of other WGs and W3C staff are at
   Paypal, that makes sense.

   virginie: set up call for appropriate people?
   ... one call before f2f meeting
   ... harry - ACTION - one call dedicated to that
   ... comments?

   <hhalpin> Like I said, I'm OK for not having a registry, but
   Thomas Roessler W3C brought that up when there was an internal
   review and still wants to see a wider discussion.

   <wseltzer> ACTION hhalpin to schedule call about registry, due

   <trackbot> Created ACTION-76 - Schedule call about registry,
   due 4/15 [on Harry Halpin - due 2013-03-11].

   Virginie: next idea of this call - different proposals - harry
   mentioned we did not close previous action

   hhalpin: issue 18 we should go for consensus now

   <virginie> PROPOSAL : close ISSUE-18 on the basis that the WG
   is not going to adress this feature

   <wseltzer> ISSUE-18?

   <trackbot> ISSUE-18 -- Should it be possible to perform
   CryptoOperations as a 'streaming' operation with URI semantics?
   -- closed

   <trackbot> [11]http://www.w3.org/2012/webcrypto/track/issues/18

     [11] http://www.w3.org/2012/webcrypto/track/issues/18

   <hhalpin> PROPOSAL: Close ISSUE-18 - Should it be possible to
   perform CryptoOperations as a 'streaming' operation with URI

   <rbarnes> +1

   <virginie> +1

   <hhalpin> +1

   <mountie> +1

   <ddahl_> +1

   <wseltzer> +1

   <rsleevi> +1

   <hhalpin> There are no proposals, thus it should be closed.

   <hhalpin> CLOSED: ISSUE-18 - Should it be possible to perform
   CryptoOperations as a 'streaming' operation with URI semantics?

   Virginie: next one related to ISSUE 40

   <wseltzer> ISSUE-40?

   <trackbot> ISSUE-40 -- How should we define key discovery,
   noting asynchronicity -- open

   <trackbot> [12]http://www.w3.org/2012/webcrypto/track/issues/40

     [12] http://www.w3.org/2012/webcrypto/track/issues/40

   Virginie: Wide issue and key discovery API was solving it.

   Watson: thought this should be closed.

   <hhalpin> However, have we thought through the privacy and
   security implications enough?

   <virginie> PROPOSAL : Close ISSUE-40 -- How should we define
   key discovery, noting asynchronicity

   <markw> +1

   <rsleevi> +1

   <virginie> +1

   <ddahl_> +1

   <hhalpin> I have brought those up, there was concerns from the
   cryptographic and security community here.

   <hhalpin> -1

   <rbarnes> +1


   <wseltzer> +1

   <mountie> +1

   <hhalpin> Actually, there's not consensus :)

   <scribe> CLOSED: Issue 40

   Review the crypto API and there is concerns about security
   boundaries, import/export, as long as we can discuss new and
   different ways to address these concerns

   hhalpin: happy to close the issue with the caveat that we get a
   proper review
   ... before going to last call

   Ryan: i am going to suggest that we close these issues. we
   should not be keeping broad issues open.

   <hhalpin> i.e. there were concerns re security boundaries and
   the possibility of "super-keys"

   Virginie: issue 40 is broad, and does not mention the privacy
   concern you are highlighting, and open an action about the
   review related to privacy aspects.

   <rsleevi> strongly disagree re: UX

   hhalpin: happy to close but object to closing issue 9 without
   proper review

   Virginie: could you write down so we have an action as you have
   described - also problem of user action - is that linked?

   Hhalpin: user action is one way of dealing with it. Issue 9 is
   appropriate to hold the problem

   Virginie: process point. do we need to go again to the voting?
   or do we say working group after discussion agreed

   <hhalpin> So, thus I say: I change my vote to +1 given that we
   keep ISSUE-9 open.

   <hhalpin> And thus,

   <hhalpin> CLOSED: ISSUE-40

   <wseltzer> ISSUE-37?

   <trackbot> ISSUE-37 -- Method naming -- open

   <trackbot> [13]http://www.w3.org/2012/webcrypto/track/issues/37

     [13] http://www.w3.org/2012/webcrypto/track/issues/37

   Virginie: next issue - that could be discussed - proposed to be
   closed - Issue 37

   <virginie> PROPOSAL: Close ISSUE-37 - Method Naming

   hhalpin: relates to JOSE working group

   <rbarnes> yes, this is not jose

   <rbarnes> that's later :)

   ryan: this issue has nothing to do with JOSE, just API naming

   <hhalpin> Ah, that's fine.

   ryan: resolved since our draft 2 - nothing to do with JOSE

   <rsleevi> +1

   <hhalpin> PROPOSAL: Close ISSUE-37 - Method Naming

   <hhalpin> +1

   <rbarnes> +1

   <ddahl_> +1

   <virginie> +1

   <mountie> +1

   <wseltzer> +1

   <markw> +1

   <karen1> +1

   <hhalpin> No text changes required, current editors draft is

   <scribe> CLOSED: Issue 37

   <rsleevi> ISSUE-33?

   <trackbot> ISSUE-33 -- Clarify text in section 5.1 with respect
   to how key tainting is handled with multi-origin scenario --

   <trackbot> [14]http://www.w3.org/2012/webcrypto/track/issues/33

     [14] http://www.w3.org/2012/webcrypto/track/issues/33

   <virginie> PROPOSAL: Close ISSUE-33 - Clarify text in section
   5.1 with respect to how key tainting is handled with
   multi-origin scenario

   <rsleevi> +1

   <markw> +1

   <virginie> +1

   <rbarnes> +1

   <mountie> +1

   <ddahl_> +1

   <hhalpin> Can someone specify what we are doing to close the
   issue? It seems to be informative text

   <rbarnes> nothing, afaict

   <rsleevi> We're acknowledging that the current text is

   <hhalpin> The working group thinks key tainting should be
   allowed and no informative text is necessary to warn people or
   WebApp developers around key tainting.

   <hhalpin> Does that capture the resolution?

   <hhalpin> +1

   <scribe> CLOSED: Issue 33

   <rsleevi> ISSUE-31?

   <trackbot> ISSUE-31 -- Problems with keys attribute of the
   Crypto interface -- open

   <trackbot> [15]http://www.w3.org/2012/webcrypto/track/issues/31

     [15] http://www.w3.org/2012/webcrypto/track/issues/31

   Virginie: next item - ISSUE-32

   key discovery API - concerns raised with original draft 1, no
   longer an issue in key discovery draft

   <virginie> PROPOSAL: CLOSE ISSUE-31 -- Problems with keys
   attribute of the Crypto interface

   <rbarnes> +1

   <rsleevi> +1

   <virginie> +1

   <mountie> +1

   <markw> +1

   hhalpin: addressed and closed or moved to the key discovery

   <hhalpin> i.e. moved and closed

   <hhalpin> or just moved

   <hhalpin> The issue tracker is for multiple documents

   <rsleevi> moved and closed (as the organization that raised it,
   I can confirm our concerns have long since been addressed)

   <hhalpin> So, its not relevant for the key discovery API.

   <hhalpin> +1

   <scribe> CLOSED: Issue-31

   <rsleevi> ISSUE-29?

   <trackbot> ISSUE-29 -- Handling of block encryption modes and
   padding -- open

   <trackbot> [16]http://www.w3.org/2012/webcrypto/track/issues/29

     [16] http://www.w3.org/2012/webcrypto/track/issues/29

   Virginie: next issue is last one, so to have chance to discuss
   high level api

   decided to continue to treat them as independent algorithms.

   <virginie> PROPOSAL : Close ISSUE-29 -- Handling of block
   encryption modes and padding

   <rsleevi> +1

   <mountie> +1

   <virginie> +1

   <markw> +1

   <ddahl_> +1

   <karen1> +1

   <wseltzer> +1

   <rbarnes> +1, if you're ok with the combinatorial explosion :)

   <hhalpin> +1

   <scribe> CLOSED: Issue-29

   Virginie: pay attention to the high level API

High level API

   David: i do have a draft, basically, something easier and safer
   to use for web app developers - still think this is not a
   counter proposal to low level API but an additional API
   ... don't want to put forward a proposal that another browser
   provider would not implement

   <hhalpin> I think the W3C would like a high-level API, as that
   was in our charter as well, under "Mission".

   hhalpin: concern some in w3c - can we get a reasonable high
   level API across different browsers?

   <hhalpin> and can we do a timeframe that makes sense?

   virginie: spoke with different developers - for the
   crypto-educated people, sounds usable, but those unfamiliar -
   it is a problem - so i support a high level API

   Ryan: i have been meeting with crypto community on this issue
   ... i strongly believe any high level API will have to be done
   by serious cryptographers - and we have none in this working
   ... if we embark on a high level API, it requires very concrete
   use cases and threat model

   <mountie> I agree with Ryan's opinion

   Ryan: Same level as low level API

   rbarnes: regardless high or low level, it will be handled by
   unskilled developers

   <rsleevi> That's like saying WebGL will be used by people who
   don't understand 3D. Sure, they're not the target of the API.
   It's a false premise to think you can deliver secure code
   without having to think about security.

   <rbarnes> ack

   virginie: i hear that we don't have the right people in the
   working group, so we should bring them in
   ... second, we will need appropriate use cases for designing
   the api

   <rbarnes> rsleevi: the difference is (1) when your webgl code
   doesn't work, it's obvious, and (2) when your webgl code is
   wrong, you don't expose sensitive information

   virginie: harry - you have been offering to try to organize
   some calls with people designing other high level api - still
   something you can do?

   Ryan: i think you have the steps wrong - first step is use
   cases and then getting right people on board for security

   <hhalpin> My concerns are even the people who want the
   use-cases aren't here.

   <hhalpin> But they may nonetheless be very valid use-cases for
   a high-level API by ordinary web-developers

   Virginie: end of conference call - no decision from this
   discussion - but clear direction - make use cases clear and get
   right people to join the working group

   wseltzer: administrative manner - European and US clocks go out
   of sync for next three weeks

   <rbarnes> jose on wednesday:

     [17] http://tools.ietf.org/wg/jose/agenda?item=agenda-86-jose.html

   <virginie> and thanks to simon fro scribing :)

   <wseltzer> trackbot, end teleconf

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

Received on Monday, 4 March 2013 21:24:53 UTC