W3C home > Mailing lists > Public > public-webcrypto@w3.org > December 2012

[minutes] 10 Dec WebCrypto teleconference

From: Wendy Seltzer <wseltzer@w3.org>
Date: Mon, 10 Dec 2012 11:13:03 -0500
Message-ID: <50C60A0F.7060504@w3.org>
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Our next call will be 17 December, 2000 UTC.

Minutes from today's call here:
http://www.w3.org/2012/12/10-crypto-minutes.html

and below in text form:

             Web Cryptography Working Group Teleconference

10 Dec 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/12/10-crypto-irc

Attendees

   Present
          +1.571.335.aaaa, Wendy, Nat_Sakimura, +1.408.458.aabb,
          Scott_Kelly, +1.303.543.aacc, zooko, ddahl,
          +1.512.257.aadd, +1.415.867.aaee, markw, virginie,
          arunranga, +47.40.22.aaff, +1.650.525.aagg, pal,
          Havard_Molland, +82.22.14.0.aahh, mountie, Alex_Russell,
          +1.512.343.aaii, karen, hhalpin, [Google], [Microsoft]

   Regrets
   Chair
          Virginie

   Scribe
          wseltzer

Contents

     * [3]Topics
         1. [4]Use Cases
         2. [5]New Spec Key Discovery
         3. [6]Web Crypto API
         4. [7]Group Life
     * [8]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 10 December 2012

   hi virginie

   <mountie> hi

   <zooko> hello!

   <ddahl> hi zooko

   <zooko> Hi ddahl

   <arunranga> Use Cases document in HG:
   [9]http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f9
   4c/Overview.html

      [9]
http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f94c/Overview.html

   <mountie> I'm at home. not available to use voice

   virginie: Thanks to people for making the effort to join this
   call, especially US folks for whom it's early, Asia for whom
   it's late

   [agenda:
   [10]http://lists.w3.org/Archives/Public/public-webcrypto/2012De
   c/0005.html]

     [10]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0005.html

   <scribe> scribenick: wseltzer

   <virginie> [11]http://www.w3.org/2012/11/26-crypto-minutes.html

     [11] http://www.w3.org/2012/11/26-crypto-minutes.html

   virginie: any objection to previous minutes? Approved.

Use Cases

   <arunranga> zakim unmute me

   virginie: Arun, can you introduce the use cases?

   arunranga:
   [12]http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f
   94c/Overview.html

     [12]
http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f94c/Overview.html

   <markw> I know, sorry!

   arunranga: Still chasing down a few people, including Mark, to
   give a bit more from a Netflix perspective.
   ... Goal is to give use cases, show sample code.
   ... Got lots of good feedback from Facebook, a real-world
   use-case.
   ... Questions still remain, such as whether we can do better
   with HMAC.
   ... Good feedback from Tantek, who wants to use public keys.
   ... If all follow up with me, we can have a draft by mid-week
   for heartbeat.

   virginie: questions for Arun?
   ... as you can see: banking transactions, video services, code
   sanctity, encrypted communications

   arunranga: nobody should be misled by the fact that I may have
   used Korean names, not a one-to-one match with S. Korea
   ... tried to construct the use-case around mountie's email

   <hhalpin> did we test to get consent to publish?

   virginie: people who need to provide arun with additional
   details, please have a close look
   ... we are trying to get this published at next heartbeat, WG
   consensus to go forward for publication on 17 Dec.

   <hhalpin> So everyone has a deadline to read it by the 17th :)

   <zooko> +1

   virginie: Any objection to having the spec go for publication
   17 Dec?

   <hhalpin> +1

   <virginie> +1

   <ddahl> +1

   [+1 = no objection]

   <mountie> +1

   <hhalpin> Just this one for now

   pal: is this publication of this spec alone, or others?

   <hhalpin> although we hope to publish all three (API, Mark's
   document, use-cases) in the next heartbeat

   virginie: To start, I asked just about the Use Cases.
   ... I'd like to get consensus for publication of each
   separately.

   pal: Recommend asking the question specifically so people know
   what they're approving.

   virginie: Any objection to having Use Cases doc published 17
   Dec?

   pal: no objection

   virginie: great, we'll go forward with the use cases on 17 Dec

   arunranga: Main goal is to produce primary, achievable use
   cases, that the API as it's emerging in draft can accomplish
   ... not secondary use cases

   <hhalpin> Its OK to list secondary use-cases as long as they
   are clearly marked as "secondary" and without consensus.

   virginie: Did you make any statement re relation between
   WebCryptoAPI and use cases?

   arunranga: I'd be happy to take feedback and add a note to that
   effect.

   <scribe> ACTION: virginie to propose language on relation
   between WebCryptoAPI and use cases [recorded in
   [13]http://www.w3.org/2012/12/10-crypto-minutes.html#action01]

   <trackbot> Created ACTION-70 - Propose language on relation
   between WebCryptoAPI and use cases [on Virginie GALINDO - due
   2012-12-17].

   virginie: The way you're writing this, we could later add new
   secondary features

   arunranga: yes

   markw: Clarify that use cases should be able to include
   pre-provisioned keys?

   arunranga: yes, we can include pre-provisioned keys. Looking to
   you (markw) for detail
   ... we can include a caveat that this particular feature may
   not be included in the WebCryptoAPI yet, but members of the WG
   are actively discussing

   markw: I don't consider it a secondary use case. It should
   either be published in the main draft or in the additional doc
   we're working on.

New Spec Key Discovery

   virginie: I'm sure you're all aware of how Mark came to prepare
   new specification on key discovery
   ... how to identify keys that may be pre-provisioned, so
   separate document.
   ... is there any problem or objection, or anyone who'd like to
   help Mark?

   markw: The intent is that this spec will have the same
   timeframe and Rec status as the main API
   ... either we should publish this at the same time as the main
   API loses support for pre-provisioned keys, so it's an atomic
   change
   ... when writing the new draft, only included suppor tfor
   origin named pre-provisioned keys.
   ... no reason it couldn't include others, so the timeframe is
   not impacted

   <arunranga> Link to draft?

   markw: added some material on privacy, based on indexdb
   document

   <virginie> Key discovery specification proposal
   [14]http://lists.w3.org/Archives/Public/public-webcrypto/2012De
   c/0001.html

     [14]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0001.html

   <hhalpin> I'll work on this after the phone call

   markw: Attached document to email because couldn't yet get it
   into hg tree

   <hhalpin> its possible there's an issue re permissions

   virginie: when you say we're publishing at the same time, do
   you mean heartbeat or more formal steps?

   markw: I mean for the heartbeat.

   <hhalpin> i.e. by Dec 17th

   markw: can we do it this time?

   virginie: I have no problem putting them on the same track.
   Will we be ready for 17 Dec?

   <arunranga> notes rsleevi is on the q

   virginie: question for the group, who has something to say
   about new spec? any objection to publishing?

   <rsleevi_> +1

   <hhalpin> +1

   rsleevi_: My suggestion would be to keep different forms of key
   discovery in different specs, for what implementers need.
   ... Mark's approach is good, useful to implementers interested
   in that functionality.
   ... There are technical concerns, but no reason not to publish
   the draft.

   virginie: thanks

   hhalpin: We can release multiple docs in the heartbeat.
   ... We need to specify when we release whether we expect them
   to be normative.
   ... And we'll say with Mark's doc that we expect it will be
   normative.
   ... Both API and Key Discovery will have to go through the same
   process.
   ... To become W3C recs, they need implementation, testing, vote
   from W3C AC
   ... let's send both docs down the normative track. Try to keep
   them to the same schedule

   virginie: +1 to what harry said.

   <hhalpin> Just to make sure W3C process is clear here

   virginie: Mark, anything more we need before publication?

   <hhalpin> its OK to publish drafty things

   markw: I expect comments over the week, but don't see any
   problem with going ahead.

   virginie: Any further comments? We'll go through formal process
   to approve pub next week.
   ... Thanks Mark for doing this quickly.
   ... Thanks both Ryan and Mark for working on docs.

Web Crypto API

   <rsleevi_> [15]https://dvcs.w3.org/hg/webcrypto-api/log

     [15] https://dvcs.w3.org/hg/webcrypto-api/log

   rsleevi_: obviously lots of changes.
   ... most of the focus is trying to resolve usability issues,
   tighten up API
   ... total 22 changes, some more significant than others.
   ... Highlighting: removal of key storage and key attributes.
   ... keystorage has been discussed at length on ml.
   ... intent to add text highlighting key discovery elsewhere.
   ... Key attributes, tightly coupled with notion of key storage
   ... e.g. if something is stored on a smartcard, attributes
   might change without the user agent
   ... exposing attribs as persistent not a good fit.
   ... so instead, make just the core functions of the key are
   attribs; others are stored where you store the key.
   ... application-specific or advisory attribs should be defined
   along with how you get the key from storage.
   ... e.g. synchronous, handles, etc.
   ... Concat added as an algorithm.
   ... Another change, overall workflow.
   ... earlier draft closer to PKCS11. init, process... , complete
   ... intent to share the objects, but implementers had concern
   it was too specific.
   ... explicit initialization step removed.
   ... that also removes the recyclability of crypto ops.
   ... added ability to supply data to be processed in call, e.g.
   hashing
   ... those are some of the major changes.
   ... easiest way to see them in practice is to look at examples
   doc.
   ... process data flow and state machine transition simplified
   for both developer and implementer.

   virginie: Any questions for Ryan?

   hhalpin: sounds sensible. 2 Qs: what did we do re zooko's
   questions on taxonomy of labeling?
   ... did we have any usability feedback?

   rsleevi_: taxonomy label distinct from security considerations.

   <slightlyoff> I have provided some feedback to rsleevi_ in
   private mail

   rsleevi_: didn't think the taxonomy was a good fit.

   <hhalpin> The taxonomy wasn't accepted I remember, but checking
   on security considerations

   <zooko> +q

   rsleevi_: Security considerations have not yet been
   incorporated.
   ... focus this time was usability.

   hhalpin: we might want to have security considerations in this
   round.

   <rsleevi_> Security considerations will not happen in next ED

   <slightlyoff> in particular, I continue to think that the
   CryptoOperation class needs to be a form of Promise

   <rsleevi_> (at least, I don't have time, ddahl?)

   hhalpin: to address earlier comments, if we can.

   <slightlyoff> and it's not today

   rsleevi_: I disagree it's necessary for the next WD. Don't see
   that I can add it.
   ... don't need to duplicate IRTF doc.

   virginie: we might have more developments re security review
   when David Rogers takes it up.

   <rsleevi_> slightlyoff: A non-multi-part CryptoOperation yes,
   but I don't think a multi-part operation fits in the promise
   model

   <mountie> for security consideration, we need to reference
   WebAppSec WG CSP

   <hhalpin> its generally good to be able to point to our
   response from a previous heartbeat in a new hearbeat, but we do
   of course only have so much time.

   markw: We haven't discussed removal of key attribs before
   ... is the intent that other specs might add attribs?

   <ddahl> rsleevi: Perhaps, I thought we had some new language
   for that section?

   markw: re pre-provisioned keys, we discussed ID attrib.
   ... re unwrapping, there might be attributes inside the
   wrapper, exposed on unwrapping.
   ... that would resurrect the requirement for attribs on the
   key.

   rsleevi_: key attribs relies on things not yet specified by
   JOSE
   ... would prefer not to include something on which there's no
   proposal for how it's going to work.

   <slightlyoff> rsleevi_: if there's a single answer to the
   operation (a single result), then it fits.

   rsleevi_: once there's more work from JOSE re key wrapping, we
   may reconsider.

   <rsleevi_> slightlyoff: Agreed

   <Zakim> rsleevi_, you wanted to respond to mark

   markw: can other specs add attributes?

   <hhalpin> In W3C process terms, there's no problem with
   specifying certain key attributes in a different document

   arunranga: also my Q. if a web developer wants to determine
   validity, they need to engage with the app?

   <hhalpin> it just makes things more confusing for readers.

   rsleevi_: start-date and end-date removed at our first
   face-to-face. too much variation.
   ... all these notions of validity are more closely related to
   application than to key storage.
   ... they're not universal concepts.
   ... very few APIs, except PKCS11, allow you to add attribs

   <slightlyoff> rsleevi_: 12.1's multi-part steps suggest to me
   that there's a single return value

   rsleevi_: Problem: exposing attrib directly leaves it undefined
   for all keys that don't have the attrib
   ... either you're defining default values or saying it may be
   present.
   ... Problematic if the underlying external storage system
   changes attribs, how do I reflect that to the caller? what's
   the UA to do?
   ... so for key object, if you want to talk about validity,
   stick it in indexdb, leave it to application to both store and
   enforce.

   <arunranga> ack

   rsleevi_: having a key-value store doesn't really fit

   virginie: does that make sense?
   ... does that mean we'll never have to use attributes in main
   API?

   zooko: I like Ryan's latest rev of the API.

   <slightlyoff> it's not using promises yet

   zooko: Consistently asynchronous using promises; a few
   one-shot.
   ... still think it would be good for usability and security to
   label algorithms as to whether they provide encryption,
   hashing, or something else

   <hhalpin> I'm partial to attributes personally, but I'm not
   going to object.

   rsleevi_: considering adding a table of contents, listing
   algorithms and supported ops.

   zooko: Sounds like a way to express what algorithms do, will
   look.

   markw: pre-provisioned keys creates a sub-class with attribs

   virginie: any comments, send them and proposed resolution to
   Ryan
   ... so prepare for WG decision on publication 17 Dec.

   <hhalpin> US-friendly time.

   <hhalpin> 20:00 UTC

   virginie: Additional call next week, 17 Dec. 20 UTC (3pm
   Boston, Noon Pacific)
   ... Quick question to David Dahl, progress on high-level API?

   ddahl: Drafts on github, getting comments from Richard Barnes,
   Mike Jones. Will ping them again.

   <mountie> 20:00 UTC ==> 05:00 AM KST

   virginie: please share on public list when in shape.

Group Life

   <rsleevi_> @slightlyoff: Both single and multi-part operations
   may result in multiple outputs (via progress events), along
   with a final event (oncomplete) indicating that the operation
   is completed / final values are calculated (or validated).
   Example of multiple onprogress events would be an encrypt
   (single part or multi-part), example of intermediate onprogress
   events but a single oncomplete would be a decrypt/MAC verify

   virginie: We'll have to decide when to hold our next meeting.
   ... We have offers from Korea and Boston for hosting.
   ... but first I'd like to find a date. Please fill out the
   doodle.
   ... We'll continue alternating phone call timing.
   ... In January, one call every two weeks, alternating times.

   <rsleevi_> @zooko: Consider something like Table 34 of
   [16]http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pd
   f or
   [17]http://www.w3.org/TR/xmlenc-core1/#sec-Table-of-Algorithms

     [16] http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pdf
     [17] http://www.w3.org/TR/xmlenc-core1/#sec-Table-of-Algorithms

   <slightlyoff> rsleevi_: so in the multiple progress for
   multi-part encrypt, are the chunks handed to the progress
   events also part of the final result?

   virginie: Next week, 17 Dec call to prepare publication.
   ... thanks to all the editors for their hard work

   <rsleevi_> @slightlyoff: That's what I think we're trying to
   figure out and nail down ;)

   virginie: Ryan, Arun, Mark, thank you!

   <rsleevi_> @slightlyoff: Whether to follow the File API model
   (which is "Yes"), or to follow the "save memory model" (which
   is "no")

   virginie: next week, focus on getting consensus to go for
   publication.
   ... talk to you in a week and on ml.

   RRSAgent: make minutes

   <slightlyoff> rsleevi_: if we want a streaming crypto
   operation, we should do that orthoginally

   trackbot, end teleconf

   <zooko> rsleevi_: this comment confused me:

   <zooko> // Unlike the signing example, which showed multi-part
   encryption, here we

   <zooko> // will perform the entire AES operation in a single
   call.

Summary of Action Items

   [NEW] ACTION: virginie to propose language on relation between
   WebCryptoAPI and use cases [recorded in
   [18]http://www.w3.org/2012/12/10-crypto-minutes.html#action01]

   [End of minutes]
     __________________________________________________________

-- 
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, 10 December 2012 16:13:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 December 2012 16:13:07 GMT