WebCrypto Working Group -- 11 Jun 2012

<ddahl> thanks wseltzer

<MitchZ> Netflix on area code 408

<wseltzer> Some good scribe instructions, for further reference: https://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html

<MitchZ> zakim aaee is Netflix

<hhalpin> scribe: Karen

Harry: help scribe

<JimD> there is some command to see who is talking

<ddahl> Channy: are you on the phone?

<wseltzer> Channy, are you on the phone or just IRC?

<hhalpin> scribenick: Karen

<sdurbha> p18 sdurbha

<Channy> ddahl, just IRC

<ddahl> Channy: thx

Virginie: agenda

Survey about API

<virginie_galindo> http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis

<ddahl> http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis

David presents summary

David: most want low level api
... we will figure out what does that mean
... one of question does not worded well - who will use api
... main answer: web app users
... main activities will be messaging, chatting, signature behind it
... a good set of data. we can get more answers as we go along. please read through raw data

virginie: thank you David for the efforts
... any comments?

sdurbha: emails seem to want high level api

david: there are still discussions on what that means high or low level api
... I think low level is better so we can implement more func and follow standard
... high level api can be built on top

harry: messaging and chatting on top is surprising.

vgb: what is not clear - how people think this api with relation to tls
... an addition?
... to implement tls in browser?

virginie: one feature - for web app to manage their security

<hhalpin> I'm pretty sure we are NOT going to replace TLS :)

virginie: feature 2: tracking tls session

<ddahl> vgb: I don't think people want to be able to implement all of TLS, however, I think they do want to be able to secure and sign data before this data is pushed to the wire

<ddahl> wtc: rsleevi: got it! thanks!

wtc: ryan and I will contact david later in design api

david: use cases are not to replace tls

<hhalpin> I imagine we are going to add some functions that let people sign and encrypt some parts of the DOM dynamically using a few cross-browser methods.

david: using secure messaging as an example - three persons involved

<ddahl> Karen: that is rsleevi :)

david: bob and alice may be two users using carol's service

sorry

rsleevi: tls is only suited for two people talking

<Zakim> rsleevi, you wanted to respond

virginie: to leverage what david said, we should focus on low level api first
... allow developers to control the operations
... we can work on high level later

<sdurbha> +1

<rsleevi> +1

<hhalpin> +1

<JimD> +1

<ddahl> +1

<hhalpin> PROPOSAL: Start with low-level

<vgb> +1

<emily> +1

<wtc> +1

<wseltzer> +1

<hhalpin> RESOLUTION: Start with low-level API, then focus on high-level API

Virginie: a3 use cases

Use-cases

virginie: channy has updated the use cases http://www.w3.org/2012/webcrypto/wiki/Use_Cases
... channy has updated use cases

<Channy> Use-cases on wiki were gathered from mailinglist and commnutiy group. It was classified by charter goals. Please feel free to edit by anyone.

<hhalpin> Any volunteers?

<ddahl> virginie_galindo: I can help you

virginie: make sure we don't put complicated use cases in the primary features

<wseltzer> ACTION: Add use-cases from the survey to the wiki [recorded in http://www.w3.org/2012/06/11-crypto-minutes.html#action01]

<Channy> I think it may be rearranged by low-level and high-level.

virginie: use case: validated document

http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0022.html

document sent by ?

PhilipG: tls proxy is a fact

<wseltzer> PhilipG: Defense in depth, accepting that TLS proxies are a fact of life, and provide security in the face of those.

philip: it is possible for a client to authenticate even if there is tls proxy

ryan: I am concerned that entire web security model is built on tls
... don't know any browser can guarantee the security even with the defense in depth

virginie: philip you can write down the use case

philip: I am not sure it is relevant
... I will write it down anyway

virginie: any suggestions on use cases?

Jim: a lot of discussions on smart card
... we might want to create an abstraction on hardware devices
... we want to make sure the api we create can support hardware devices

Welcome

virginie: topics: draft api

draft API

Technical Discussion

virginie: 40min to discuss technical topics

David: latest update is section 7

<virginie_galindo> http://www.w3.org/2012/webcrypto/WebCryptoAPI/

david: added link to JWA (json algorithms)
... we will benefit to use same identifiers as jwa

<harry> +1 re-using identifers from JOSE WG

david: updated examples in the strawman

<ddahl> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#algorithms

<rsleevi> +1 to the re-use

virginie: thank you for the work

david: try to begin proposal on key identifier
... we might want to add some meta data on key identifier

virginie: proposal GUID from mitch
... will we reuse?

<virginie_galindo> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0015.html

david: that's an ideal way to identity key

ryan: concern: will two users of two different sites have same or different GUID? if the same, it is possible to track user
... I like the string id, which may not have this concern
... example: netflex.p1

<ddahl> rsleevi: I think the JOSE WG has examples like that - origin + sequence number

wtc: agree with ryan

p1: the goal is to unique identify the key so that it can be revoked

wtc: hash of a secret key may accomplish the goal of identify the key without reveal the key

mitch: privacy concern is the one we share.
... the uuid or hash may reveal too much
... we don't need to build all use cases but need to discuss the privacy concern

<ddahl> i may be wrong, but the JOSE WG seems to not require any kind of specific id except that it is a string

harry: charter is very clear that we don't want to mandate a particular key identifier scheme

<rsleevi> The question seems less to do with key identification, and more about key discovery

virginie: we need to name the key in order to handle it

<rsleevi> Key identification serves as a means of key discovery, but is not the only one

<harry> i.e also the discovery of the properties of the key

<harry> which is different than sticking all the properties in its idenfication scheme

virginie: a need for the editors to come out a proposal
... on key identifier.

david: Ryan and others have given feedback
... enumeration of propertities

<ddahl> virginie_galindo: +1

<rsleevi> +1

virginie: it is important and part of the design api

david: will share tomorrow or next day

virginie: next topic: discovery mechanism
... netflex proposal? how to discovery key?

<virginie_galindo> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0030.html

david: no conclusion yet

ryan: do conclusion yet
... need to consider mitch example where a particular key can only be used for a particular purpose case, mode etc
... also need to consider more general use case that the key can be used in more cases

<MitchZ> Just to throw one more oddball use case out there: we have seen one case of a single keytext block inside of hardware used as any of: DES, 3DES, 2DES (!), and AES-128 algorithms

<MitchZ> I believe this is unusual, though

ryan: need to design api that can balance these cases

<MitchZ> and could be handled by simply mapping the single keytext block to several different keys

<ddahl> also, I have been re-reading all of the latest JOSE JWK specs to help inform this discussion

<MitchZ> but, cipher mode, padding, etc. may really be limited on a key-by-key basis

virginie: we need to build and write down the api
... expect other participants to help
... next topic: smart card discussion - lot of exchanges
... our charter - we should not put anything specific to smart card
... many use cases that need smart card
... we need to find some ways to handle this

<harry> we don't want to bake in device-specific API features, but maybe we can do those use-cases with right level of abstraction.

<JimD> use cases should not EXCLUDE smart cards explicitly; however, I agree that we may need to create an abstraction for the use of smart cards or other hardware-based devices

virginie: may be we can have a round table to discuss this

ryan: I have no objection to smart card, but have concern on security model
... don't believe any website can benefit from know smart card
... a client having keys stored in smart card is fine
... we should not have anything specific to smart card

<harry> +1 keys stored in smart card

<harry> i.e. think of it as another container

Chan: I believe all use cases can be met by windows.cypto

<rsleevi> Karen: s/Chan/wtc/

<JimD> a browser-specific solution doesn't seem to be a good answer

sdurbha: there are javascript api's that support crypto, but it is not possible to securely transfer keys.

<rsleevi> sdurbha: As an alternative for/enhancement of <keygen>, correct?

sdurbha: smart card support for keys is very appealing

<sdurbha> rsleevi, correct

virginie: provisioning of the key is out of the scope

vgb: use case of key management

<Channy> @JimD, a browser can use standard as like Firefox's impl. http://en.wikipedia.org/wiki/Federal_Information_Processing_Standard

vgb: where does key come from: local storage - not relevant to SC; key exchange; you have a key that is sent by a out of band way
... the service knows it is in a smart card because it gives to the card.

<JimD> well said, vgb

<PhilipG> +1

<JimD> +1

<ddahl> +1

<sdurbha> +1

<harry> +1

<rsleevi> vgb: +1. I think the matter of smart cards is a matter of key discovery, largely

vgb: we don't need smart card support, but need to know it comes from. e.g. smart card

<virginie_galindo> +1

<rsleevi> vgb: -1 to key provisioning within smart cards :)

<MitchZ> +1, but would aim for a target where the "smart card keys" are used in a way consistent with the "runtime created keys" or "preprovisioned keys"

<MitchZ> in other words, not necessarily "outside the sandbox" to get to the last part of your comment.

vgb: at the browser level - discover the key

<vgb> MitchZ, I agree that the API should be consistent between the various types of keys

philip: provided that smart card portability of the key is a part of the use case

<vgb> my point was that we should allow the possibility of accessing keys that were not created/initally received within the browser

philip: the easy of use is an important factor

<harry> hmmm...should we write a proposal/resolution here?

<rsleevi> harry: wtc and I can take up an ACTION item to propose something

<vgb> rsleevi - we're in violent agreement :)

<sdurbha> :)

sorry, I didn't catch that

<vgb> I have a half-composed email draft on this, will send out ot email list today

<JimD> Thanks, vgb

<harry> VGB or Rsleevi, can you write *something* in IRC that captures in 1-3 sentences the precise proposal re the idea of accessing keys?

Virginie: vgb and ryan will propose something

<rsleevi> harry: The browser should be agnostic as to the 'source' of the key - whether within the browser or outside

<harry> ACTION: VGB and RSleevi to write a proposal and send to mailing list for approval next meeting [recorded in http://www.w3.org/2012/06/11-crypto-minutes.html#action02]

<vgb> Basic proposal on key access: there are 3 families of use cases

virginie: next topic: group life

<vgb> 1. Ephemeral / local-only use, as for local encrypted storage

Group Logistics

<vgb> 2. Keys created through key exchange

virginie: f2f meeting - 24-25th of july

<vgb> 3. Keys that are distributed to parties and provisioned offline

<harry> maybe do a quick go through in IRC to see who can come to those dates?

virginie: who will be ready to attend the meeting?

<wseltzer> PROPOSAL: F2F July 24-25.

<ddahl> +1

<virginie_galindo> +1

<rsleevi> -1

<wtc> +1

<JimD> -1 on other travel that week

<harry> +1 (assuming no conflict with IETF)

<emily> -1 (unlikely to be able to attend any f2f)

<vgb> The proposal is that while the API model should treat all these keys consistently as much as possible, it should also provide a discovery model for the 3rd class, since that is a special need for that class

+1 for Asad I guess

<wseltzer> +1

<MitchZ> +1

<MitchZ> +1 for Mark Watson

<vgb> +1

<Channy> -1 (no sponsorship for travel :)

<ddahl> rsleevi: will you be available for phone calls those days?

<rsleevi> ddahl: I wouldn't trust my phone where I'm going to be (Black Hat Briefings) ;-)

virginie: location?

<ddahl> rsleevi: ah, thanks

virginie: any problem moving to silicon valley?

David: we can accomodate at mountain view office

<harry> RESOLVED: Meeting 24-25th in Vancouver ala poll

virginie: thank you all.

<harry> Meeting Adjourned

you are welcome. Sorry for missing some points

<harry> Karen, if you can send this link the mailing list for review: https://www.w3.org/2012/06/11-crypto-minutes.html

- DRAFT -

WebCrypto Working Group

11 Jun 2012

Attendees

Contents

Survey about API

Use-cases

Welcome

draft API

Technical Discussion

Group Logistics

Summary of Action Items

Scribe.perl diagnostic output