See also: IRC log
<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
Other topics?
<virginie_galindo> http://www.w3.org/2012/06/04-crypto-minutes.html
Virginie: previous minutes http://www.w3.org/2012/06/04-crypto-minutes.html
<hhalpin> PROPOSAL: accept http://www.w3.org/2012/06/04-crypto-minutes.html as minutes for the previous meeting, any objections?
Harry: as long as no one object, it is approved
<hhalpin> RESOLVED: accepted http://www.w3.org/2012/06/04-crypto-minutes.html as minutes for the previous meeting.
Virginie: take way does not replace minutes
<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
+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
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
virginie: topics: draft api
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
<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
+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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/alone/along/ Succeeded: s/p1/wtc/ Succeeded: s/p1/PhilipG/ Succeeded: s/14min/40min/ Succeeded: s/p1/wtc/ Found Scribe: Karen Inferring ScribeNick: Karen Found ScribeNick: Karen Default Present: +33.6.13.23.aaaa, +1.707.799.aabb, virginie_galindo, Wendy, +1.773.939.aacc, Jim_Davenport, vgb, +1.650.214.aadd, rsleevi, wtc, ddahl, +1.408.540.aaee, +1.512.257.aaff, Mike_Jones, emily, hhalpin, Karen, MitchZ, +1.978.936.aagg, sdurbha, pgladstone, markw, harry Present: +33.6.13.23.aaaa +1.707.799.aabb virginie_galindo Wendy +1.773.939.aacc Jim_Davenport vgb +1.650.214.aadd rsleevi wtc ddahl +1.408.540.aaee +1.512.257.aaff Mike_Jones emily hhalpin Karen MitchZ +1.978.936.aagg sdurbha pgladstone markw harry David_Hooley Got date from IRC log name: 11 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/11-crypto-minutes.html People with action items: add rsleevi vgb WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]