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: 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
David presents summary
David: most want low level
... 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
... 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
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
<hhalpin> PROPOSAL: Start with low-level
<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
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
... I will write it down anyway
virginie: any suggestions on use cases?
Jim: a lot of discussions on
... 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
david: added link to JWA (json
... we will benefit to use same identifiers as jwa
<harry> +1 re-using identifers from JOSE WG
david: updated examples in the strawman
<rsleevi> +1 to the re-use
virginie: thank you for the work
david: try to begin proposal on
... we might want to add some meta data on key identifier
virginie: proposal GUID from
... will we reuse?
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
... 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
... enumeration of propertities
<ddahl> virginie_galindo: +1
virginie: it is important and part of the design api
david: will share tomorrow or next day
virginie: next topic: discovery
... netflex proposal? how to discovery key?
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
<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
<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
<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 :)
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.
<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
<MitchZ> +1 for Mark Watson
<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) ;-)
<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: +126.96.36.199.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: +188.8.131.52.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]