Web Cryptography Working Group Teleconference

12 Nov 2012

See also: IRC log


wseltzer, ddahl, +1.303.661.aaaa, virginie, +1.415.867.aabb, sdurbha, markw, rsleevi, wtc, +1.707.799.aacc, emily, +1.415.294.aadd, arunranga, hhalpin, +1.650.228.aaee, +1.650.458.aaff, Pierre


<trackbot> Date: 12 November 2012

<virginie> ??p5 is virginie


<scribe> chair: virginie

<scribe> scribe: hhalpin

<scribe> scribenick: hhalpin


The main topic of discussion will be ISSUE-5, the "Rethinking KeyStorage Issue"

PROPOSAL: Approve minutes of Oct 20th meeting and TPAC minutes?

RESOLUTION: Approved minutes of Oct 20th meeting and TPAC minutes

debrief F2F (optional)

<Chris> Zakim aaee is Chris

Folks are OK with skipping this and getting straight to issues

<wseltzer> [Minutes and slides linked from www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012]

Discussion of keystorage by Ryan Sleevi, security concerns (defining value of API) work led by David Rogers/WebAppSec

A few new issues and actions, including discussion of formats

Also, use-case document and Korean banking use-case was highly discussed.

use cases

Arun: not much progress since last call
... had some one off conversations about Korean use-case
... clear it can't be solved on its own
... by our API
... likely needs our API+SysApps
... even so, would require some substantial retooling of the use-case

<sdurbha> Virginie: Thanks for the recap, appreciate it

Arun: so in our document, we need to document what subset of the Korean banking use-case we can solve
... some recap of pgp key exchange and kerberos use-case

+1 gatekeeping, as said on mailing list, kerberos is pretty far out

arun: I think we should keep kerberos to more future work

That particular ticket is in SysTeam's Alexandre's hands, will keep pinging

Chris: Kept following up with the Facebook signed use of local storage use-case
... Is crypto-hashing good enough or do we need to get to certs?

Arun: Hashing plus signing might be even more!

Chris: I think maybe that could be handy

<emily> Somewhat tangential since it sounds like we're not considering Kerberos to be realistic, but here's a JS kerberos client that someone I know is working on: https://github.com/davidben/webathena

<virginie> http://www.w3.org/2012/webcrypto/track/actions/open

anyways, if Facebook doesnt need signed hashing, quite a few other folks claim they need it for reasons that I haven't had time to contemplate: Martus, Crypto.Cat, etc.

<wtc> emily: yes, rsleevi and I know davidben, too. He told us about his JS Kerberos client when we saw him last month.

<virginie> http://www.w3.org/2012/webcrypto/track/actions/67

<rsleevi> ACTION-67?

<trackbot> ACTION-67 -- Virginie GALINDO to legal aspects with respect to national directives -- due 2012-12-19 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/67

action review

Virginie: not completed actions there

<Zakim> rsleevi, you wanted to ask about ACTION-67

Virginie: lets make sure we label things correctly re some of the reqirements

rsleevi: I'm hoping to keep out of legal requirements
... other than state vaguely why one may not have some algorithms on same place

wselzter: we may want to have this legal conversation offline

Virginie: I just want it noted that some crypto is not allowed in certain countries, but should not disturb our work

mailing list discussion (summary)

rsleevi: the sum of our face to face was keystorage
... proposal was to remove new types of storage
... so that we assume whatever best of breed storage in WebApps is the best
... thus we will just define a structured clone for key objects
... thats it!
... markw said this gets rid of pre-provisioned keys
... can we support them in the spec, then we need to have a consideration for pre-provisioned keys
... my goal is to carefully scope features and try to keep spec thin

Virginie: so what is your take on pre-provisioned keys?

<arunranga> I am worried about storage in general; and I'm worried that the "best of breed" storage recommendation from WebApps WG will put us in a straightjacket.

rsleevi: both Google and Mozilla expressed concerns on implementation
... just a whole new host of pre-provisioned keys
... that extends lifetime of localstorage etc.

markw: it wasn't clear that removing keystorage removed the pre-provisioned key ideas
... I think its a good idea of using a structured clone algorithms
... its been there since the workshop and beginning for us
... we have some implementations where the implementers are not the one's that the W3C are usually used to, i.e. browsers!
... but other implementers are using things
... and will want them in the spec

<rsleevi> This is not at all uncommon that capabilities are limited to particular device types - see for example vibration events, geolocation, or touch events. However, they're traditionally split from device-agnostic bits to device-specific bits

markw: we want privacy concerns, I think its fine that users can remove pre-provisioned keys if they know some particular kind of service will stop operating
... i.e. if I remove the "Fox TV" key, then I can't watch Fox.

<markw> we don't need a separate key storage for pre-provisioned keys - we just need a way to find them and KeyStorage is the only way right now


<wseltzer> sdurbha: @@. If our goal is provide a library for basic crypto operations, who's waiting to use that?

<wseltzer> ... privacy. I don't see this as worse than cookie usage today.

<wseltzer> ... keys unique per application running on the device is not device ID.

<wseltzer> pal: Can we separate: structures and calls described by API; what happens behind the scenes (privacy, storage)

pal: what is the downside with connecting guid to a key?
... re privacy/storage

hhalpin: so quick note, we can go forward with ryan's keystorage issue in the next draft, and then in secondary features go after the multiple key container feature
... then last, wanted to point out that we need at least 2 implementers per feature
... so another implementer besides Netflix needs to implement and be part of our test-cases, and thus our WG
... I think that won't be a problem

rsleevi: in order to be comparable as regards privacy for another storage mechanism, then it has to have same lifetime as cookies+localstorage
... and thus if it was meant to be comparable, then you should just use localstorage
... if it isn't and has a longer lifetime, you effect the entire web platform
... so that's a reasonable concern
... if we go forward with pre-provisioned keys, it seems they should not have a separate storage than smartcards etc.
... we're talking about a lifetime that's different

<Zakim> rsleevi, you wanted to respond to sdurbha

markw: I'm not happy to put this in secondary features, but I'd like to retain finding pre-provisioned keys
... and we have proposed more text on the privacy issues

<rsleevi> Note: It wasn't there from the beginning. I proposed and added it during the two weeks leading to FPWD

<rsleevi> As a simple placeholder for how we thought storage would work

markw: so let's go forward, but have a read-only keystorage
... and do structured clone

pal: why is guid for keyid a big deal?

<rsleevi> pal: The conversation is right now focused on a different aspect, which is pre-provisioned keys in general

<markw> the unique id is a separate issue

<rsleevi> pal: we've not yet talked about GUID

virginie: if its optional, how is it dangerous?

the point is why have an optional feature in an API, why not use a custom attribute?

if its not optional, then we need to have multiple implenters actually do it.

<pal> introducing an optional id field that can be associated with a key does not necessarily introduces privacy issues

sdurbha: the key is access-controled by origin, the user consents for key to be used by application, and thus I don't see how this causes privacy concerns

thinks we need to take at least a straw poll on this!

<markw> @rsleevi: KeyStorage specifically was added when you say, but the idea of pre-provisioned keys has been part of our work from the first workshop

virginie: I would like to have more time since I see problems communicating

I might add we might just have fundamental disagreement in the WG, in which case we need to actually see how large disagreement is?

<markw> one point I missed: origin-specific pre-provisioned keys are much simpler than smart-card based keys, which are not necessarily origin-specific

I also don't think 2 hours of discussion between folks that fundamentally disagree will help, what is necessary is moving forward on consensus

<pal> @rsleevi: I guess I am wondering if the group can address the interoperability needs of pre-provisioned key users (thorugh the addition of an optional key id) separately from storage, privacy, etc.

but disagreement is a fact of life, and we can always vote as needed.

Its much preferable to get consensus, so perhaps people could make concrete proposals they think will be acceptable over the mailing list ASAP?

<wseltzer> [Doodle re: call time http://www.doodle.com/nnekkq62drchupts ]

Meeting adjourned

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/11/12 21:01:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/cline/clone/
Found Scribe: hhalpin
Inferring ScribeNick: hhalpin
Found ScribeNick: hhalpin
Default Present: wseltzer, ddahl, +1.303.661.aaaa, virginie, +1.415.867.aabb, sdurbha, markw, rsleevi, wtc, +1.707.799.aacc, emily, +1.415.294.aadd, arunranga, hhalpin, +1.650.228.aaee, +1.650.458.aaff, Pierre
Present: wseltzer ddahl +1.303.661.aaaa virginie +1.415.867.aabb sdurbha markw rsleevi wtc +1.707.799.aacc emily +1.415.294.aadd arunranga hhalpin +1.650.228.aaee +1.650.458.aaff Pierre
Found Date: 12 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/12-crypto-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]