<wseltzer> Yesterday's draft minutes: http://www.w3.org/2012/07/24-crypto-minutes.html
<wseltzer> virginie_galindo: 3 topics, key import, random generation, algorithms.
<wseltzer> Scribe: cjkula
<wseltzer> scribenick: cjkula
virginie_galindo: chance for people to volunteer for chapters/paragraphs of the draft API
cjkula: address storing public vs. private keys
vgb: need to be able to store both
... or just the public
sdurbha: not covered in the current draft
ddahl: assumed that there is a key that can get you a private key
virginie_galindo: open issue on public vs. private -- managing the key pair
virginie_galindo: start with Mike's presentation
Mike_Jones In work with JOSE: what algorithms are supported on what platforms
<wseltzer> [Mike Jones presenting chart: http://lists.w3.org/Archives/Public/public-webcrypto/2012Jul/0119.html]
scribe: want to build a spec that gets widely used
... trying to find out who can get what parts of the spec to work together
... [many platforms]
... coverage varied widely in the survey
<hhalpin> https://www.w3.org/2012/webcrypto/track/issues/5
<hhalpin> Issue 5 added on keypair handling
scribe: working on table (with others) on filling in support table
... HMAC/SHA2 family is ubiquitous
... RSA/public key encryption widely supported
... those without an integrity check, encryption and integrity keys are derived
... concat KDF is trivial to implement but doesn't have support
arun: what do the 'now' mean? Can these be independently implemented?
mike_jones: These could, perhaps, be implemented in the "no
" cases
scribe: and have been in some instances
... could follow up with a survey of how hard it is to add support for these platform/algorithms
<arun> s/"now"/"no"
scribe: elliptic curve better supported than I thought
... a number of platforms include Android or Bouncy Castle (which helps)
... ECDSA has 2 holes: PHP & iOS
... anyone have data on Ruby?
cjkula: can look at Ruby
wtc: 10.8 OSX supports ECDSA
... OS X and iOS supports AES CBC
... knows for a fact
mark_jones: Elliptic curve sigs not ubiquitous
... analytic platforms more likely to have
... key agreement D-H doesn't have a lot of support
... while AES key wrap is not too hard, not uniformly supported
vgb: NIST considers any valid encryption method a valid way of transferring keys
mark_jones: key wrap is spotty
mike_jones: ECB not a security weakness if only used for one block
... I've sent this (survey) project to the OpenID interop list
... sent a version to the JOSE group
... will be presenting next week
... in Vancouver
sdurbha: problem -- common denominator of platforms is so low
... what version of PHP, etc.?
vgb: the yesses are for service pack 2
mike_jones: switch gears and look at JOSE spec
... what is required etc.
virginie_galindo: is this a working document?
mike_jones: yes
rbarnes: process-wise anything can be changed
mike_jones: no changes have been requested in five drafts
rbarnes: ask again in 2 weeks
... a draft review
mike_jones: if you believe the status may change (option to recommended etc.) then...
... many companies say they have the power to do elliptic but not RSA
sdurbha: if implementing in a different way are they concerned about patent issues?
<wseltzer> https://tools.ietf.org/html/rfc6090
rbarnes: recent RFC 6090 -- here's how you do EC without violating patent
vgb: very muddled. many issues.
hhalpin: W3 spec relating to Elliptic Curve not done
virginie_galindo: do we need an action
hhalpin: until we get it finalized, be wary
mike_jones: new version requires ___ support
vgb: ECC support is required for XML DSig
... for certain curves widely thought to be non-infringing
hhalpin: be careful for now
vgb: not tested in court
wseltzer: We don't need to be that cautious
... the direction that that group is going is that there is a patent-free approach for implementation
rbarnes: do we run into these issues if we don't require these algorithms?
... or don't refer to them specifically
mike_jones: observation: to the extent the XML signature is W3 work we are probably safe
sdurbha: only SHA2 is required for JOSE
<wseltzer> ACTION: Wendy to return with report on XMLSec PAG [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action01]
<trackbot> Created ACTION-19 - Return with report on XMLSec PAG [on Wendy Seltzer - due 2012-08-01].
mike_jones: yes
... no alternative that was likely to be the case
... reason RSA and ECDSA are recommended: some can only use RSA, and other can ONLY use elliptic for processing power reasons
... move onto encryption algorithms
in current spec, PKCS1 encryption is required
scribe: OAEP is getting there
... OAEP
... static is recommended
... may be harder to build than originally thought
... AES key wrap surprisingly not widely deployed
vgb: difference between RFC telling you which algorithms may be infringing
... JOSE is telling you which algorithms might shoot you in the foot.
... its a JOSE debate
<karen> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04
mike_jones: two block encryption specified
... if we are going to require anything, we could require HMAC SHA. We could require
<wseltzer> mike_jones: argument for required is to provide a minimum footprint on which you can guarantee interop
mike_jones: one other thing about JOSE registry
... implementation algorithms may change over time
... registry will be updated over time
... if SHA2 is found to be less secure, it could be moved
sdurbha: I thought it was chaotic not to mandate anything. But: jurisdiction is the biggest problem.
... don't know how to deal with it.
... a real problem.
<wseltzer> [sdurbha refers to encryption export controls, makes requirements difficult]
virginie_galindo: different discussion -- either a MUST or a SHOULD. How do we handle it?
mike_jones: no strong preference how to WG proceeds
... with JOSE there is a case that a small set should be required
rbarnes: response to sdurbha -- not a problem that certain algorithms are not implementable.
... the problem is people trying to get things in
... people want to be in that registry
... all the national algorithms
... less true than with a cipher
... has to be there as opposed to be a generic algorithm off the street
... set ourselves up for brokering the problem
asad: when look at option to mandate or keep open, it's an open debate
... interesting in table, only HMAC required with JOSE
... some devices may choose this or that
... any case for designating a family or algorithms?
sdurbha: goes to root of why we need to require
... gives assurance to developers
asad: can use discovery for this
sdurbha: it's an infrastructure question
... what is the infrastructure on the server side?
virginie_galindo: would you still require a minimum set?
sdurbha: yes
wtc: express opinion of Chrome. don't want to mandate any algorithms
... easy to find info on the Web.
nadim: provide a table that list all the algorithms
wtc: can build a negotiation into cipher suite in your program
sdurbha: understand where you are coming from...
wtc: safely assume anything that is SSL will be available
sdurbha: but it's not just Chrome. Firefox, IE, Opera does it differently
... trying to reconcile all the browsers
... if Chrome is on Windows, what can I expect?
... what is the minimum
wtc: specify 3 or 4 sets of algorithms and build in a negotiation process into your cipher suite
... is my recommendation
... for instance with SSL can give list of 2 or 3 suites widely supported
sdurbha: If I choose EC not going to work
hhalpin: need to make progress on the topic
... have to reconcile two positions
... de facto browser share algorithms
... we don't want to mandate
... Real thing we want/have to do is demonstrate interop for normative features
... we can point to the test suite
... leave the door open to the test suite changing in the future
... developers know what is reliable, but punt the mandatory question to the test suite
... test suites are interesting. They can be updated (I believe -- will have to check)
... XML Dsig required two algorithms. SHA2 and SHA1 for backup reasons
... Say: these are recommended, and the test suite enforces, but there is not MUST
arun: there's precedent for this
hhalpin: everything gets punted down a level
... fundamentally a terminalogical debate
rbarnes: assuming there is no MUST in the spec but in the test suite instead, what is the status?
hhalpin: each feature, demonstrate interop, or you are not demonstrating compatibility with the test suite
... not SHOULD/MUST, it's DOES or DOES NOT [yoda?}
karen: good to have table. 2 points. safely say that the ones are all green should be recommended?
... the green ones: that's the FACT.
<hhalpin> I think the quesiton is to recommend ECDSA or not
vgb: couple points:
<hhalpin> as everything else is kinda obvious
vgb: once you mandate defaults, they are frozen in time.
... algorithms discovery does not make sense
... if we keep getting stuck, should we say the only mandated algorithm is the null algorithm? Just pass info through.
hhalpin: essentially what we hope to do with the test suite
virginie_galindo: solution has a consensus?
cjkula: like that the test suite is real and conforms to modern software team design
rbarnes: might be confusion about spec vs. test suite "requirements"
virginie_galindo: trying to reach a spec as a product
... reality is that we can make them agree
sdurbha: is it typical that the test suite results are published publicly?
hhalpin: yes
... And/or just put the table of recommend in the spec
... but refer to the test suite
<wseltzer> ISSUE-4?
<trackbot> ISSUE-4 -- Will the set of algorithm be required with a SHOULD or a MUST in Web Crypto API ? -- raised
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/4
virginie_galindo: suggest ACTION: MUST/SHOULD -- write a straw man proposal related to test suite
<wseltzer> ACTION: Harry to write a straw-man proposal re: incorporating "recommended" table and description of test suite [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action02]
hhalpin: I'll draft an HTML table, and how the test suite relates to it
<trackbot> Created ACTION-20 - Write a straw-man proposal re: incorporating "recommended" table and description of test suite [on Harry Halpin - due 2012-08-01].
virginie_galindo: next step will be to agree on the algorithms
<wseltzer> [break for 15 minutes]
virginie_galindo: discuss random number gen and key import after break
BREAK
<virginie_galindo> until 11:10 local time
<wseltzer> [meeting resumes]
<wseltzer> Scribe: markw
<wseltzer> scribenick: markw
@@: What was the resolution of whether to ahve required algorithms ?
virginie: Action has been allocated to Harry to create a table for the specification - no decisions yet
... any objections to refer to test suites in specification
<hhalpin> PROPOSAL: We do not have any mandatory to implement algorithms, but a set of recommend algorithms referred to in a table in the spec with associated test-suite
<hhalpin> +1
<virginie_galindo> +1
<ddahl> +1
<arun> +1
<vgb> +1
<asad> +1
<cjkula> +1
<wtc> +1
<wseltzer> +1
<hhalpin> RESOLVED: We do not have any mandatory to implement algorithms, but a set of recommend algorithms referred to in a table in the spec with associated test-suite
<wtc> +1 for rbarnes
virginie: next topic is key import
vgb: lots of scenarios aroudn sig verification and key agreement don't work without key import
... import formats are the tricky part
... for public keys PCKCS#1 works, for symmetric keys row bytes are fine
... would like to leave anything beyond that out of scope
sdurbha: is it required for public key operations that public keys are stored long-term on the client ? Don't you get them from the server in real-time /
vgb: yes, but where do you get the key object corresponding to the key ? Have to pass key bytes from the server into the API to create the key object
... traditionally the term for this is import
... I'm proposing that when importing you could specify that this will be a persistent key, but more often it's an ephemeral key. Persistent keys are less important, as you could always keep the key data in local storage
cjkula: interested in seeing if PGP can be implemented using this API in a very secure fashion ? Related use-case is the Korean individuals asserting their own identity in relation to instituions, which requires the ability to move private keys from place to place
... maybe that won't make it into this version
... how will this work when receiving data from the server, via AJAX for example ?
... does the data go direct from the AJAX call into WebCrypto ?
... also interested in a case where the keys stored on the server are encrypted, imported into WebCrypto still encrypted and only unlocked when the user provides the key through some UI when the key is to be used
vgb: most of what you said should be covered except you can't really mandate that the browser keeps the material encrypted
... can't tell the difference from the API layer between an implementation which is secure and one which leaks the keys
<virginie_galindo> ?
vgb: security considerations should tell implementors to take good care of the keys, though
wtc: first point: we need to move key import/export from secondary to primary features
<arun> +1 wtc about moving key import to primary
wtc: second point: import/export have two variants - plain and wrapped
... thrid point: import has similarities with key generation, for example whether key is persistent or temporary
rbarnes: wrapped key use-case is important. e.g. for JOSE. JOSE will define formats for wrapped keys.
ddahl: import of public key from Alice to Bob - Bob's browser storing that key implies a whole bunch of browser functionality overlapping with existing efforts for browsers to store contact information
vgb: likely many cases where holding on to the key BLOB as part of contact data and importing it into WebCrypto when needed
<wseltzer> ACTION: [browser makers] to do research/outreach on contacts and public keys [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action03]
<trackbot> Sorry, couldn't find user - [browser
ddahl: agree. need an action to figure out what the work and research is around contacts and public keys in browser manufacturers
<wseltzer> ACTION: ddahl, with other browser makers, to do research/outreach on contacts and public keys [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action04]
<trackbot> Sorry, couldn't find user - ddahl,
<wseltzer> ACTION: David with other browser makers, to do research/outreach on contacts and public keys [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action05]
<trackbot> Sorry, amibiguous username (more than one match) - David
<trackbot> Try using a different identifier, such as family name or username (eg. ddahl3, dmcgrew, drogers2, dhooley)
<ddahl> wseltzer, ddahl3
karen: import is like constructing a key with no parameters
<wseltzer> ACTION: ddahl3 with other browser makers, to do research/outreach on contacts and public keys [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action06]
<trackbot> Created ACTION-21 - With other browser makers, to do research/outreach on contacts and public keys [on David Dahl - due 2012-08-01].
karen: term import/export is from crypto providers perspective
... to be less confusing, 'import' is constructing a key with some set of parameters
... import just a different version of key constructor
... similarly, export is just 'get the key'
... I remember using some library where import/export is confusing when written from the libraries p.o.v.
vgb: this is a terminology debate
virginie: we can do terminology fixes later once we have seen the functional definition of the API
<wseltzer> ACTION: vgb and cjkula to describe key import/export functionality [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action07]
<trackbot> Created ACTION-22 - And cjkula to describe key import/export functionality [on Vijay Bharadwaj - due 2012-08-01].
virginie: next item is random generation
<kaepora> I am Nadim!
<kaepora> <---- Nadim
ok, got it, Nadim is kaepora
kaepora: before window.crypto.getrandomvalues we relied on JS math.random, which is not suitable for crypto
... window.crypto.getrandomvalues relies on dev/random or dev/urandom ?
<missed the answer>
<wseltzer> wtc: implementation-specific
kaepora: there is recent research which shows patterns in dev/urandom
<wtc> window.crypto.getRandomValues is specified at http://wiki.whatwg.org/wiki/Crypto
kaepora: suggest we come back to this later
wtc: random number generation function is already provided in window.crypto.getRandomValues so there is not point for WebCrypto to provide another one
... unfortunate that window.crypto.getRandomValues uses RC4
... could update the specification if this is a problem for people
... we don't want applications to use this random number generator to generate keys. Prefer for them to use the key generation functions
virginie: should our spec not refer to window.crypto.getRandomValues ?
wtc: we can refer to it for use for identifiers etc., but not for keys
virginie: aren't such identifiers out of scope ?
vgb: maybe, but you still need nonces and other things that require randomness
karen: discussed yesterday that operations can be done on a smartcard using this API. Smartcards may have True Random Number Generator based on physically phenomenon
... if we do provide this API then people may get access to this better RNG
wtc: window.crypto.getRandomValues should be able to use smartcard as source of entropy
karen: just want to make sure app has access to this high quality RNG when available
vgb: agree with wtc. getRandomValues is defined. Propose we incorporate that by reference and call this done.
... exact choice of PRNG, where do the seeds come from etc. is not up to us.
... maybe we should have informative text saying implementations should use the best RNG on the platform
<rbarnes> ok, i'll ask in IRC
<rbarnes> :)
<rbarnes> what's the standardization status of window.crypto.getRandomValues?
<kaepora> rbarnes: It's not in Firefox yet :/ but it's in Chrome/Safari/Webkit
<rbarnes> it was getting pulled over from WHATWG; has it landed in a W3C spec, or might it be useful to fold it into this one?
cjkula: when you call generate keys, to what degree can you specify the parameters and also the random number to generate the keys ?
<arun> rbarnes, I would like this group to take on the standardization of window.crypto.getRandomValues...
<vgb> rbarnes: that's why I was saying maybe we should incorporate it by value rather than reference
<kaepora> ddahl: Gogogo Firefox window.crypto.getRandomValues!
<rbarnes> kaepora: standardization, not implementation
cjkula: for example if you had generated your own random number from, say, mouse movements
<arun> rbarnes, there's presently some IDL-wrangling that needs to be done (e.g. Fx has window.crypto.random etc.)
<Ms2ger> kaepora, it's on dvcs.w3.org
cjkula: perhaps the application has access to some better random number than the platform
<Ms2ger> rbarnes, I mean
<rbarnes> ms2ger: i know, i see it here https://dvcs.w3.org/hg/domcrypt/raw-file/tip/Overview.html
<ddahl> kaepora, we jut need 1 super review
vgb: effectively asking for PRNGs that you can seed however you want
... interesting, but not widely applicable. Hard part is finding the entropy
<rbarnes> my question was whether it had been incorporated into the standards process, either html5 or something else
vgb: don't see this as a core requirement that many people will have
... platform is supposed to make use of all the entropy it can find. It would be hard for the application to do better.
... key generation is not just random number generations
<Ms2ger> rbarnes, the plan is that this WG will publish that spec, aiui
vgb: we should be clear that the purpose of an RNG API is for ancilliary values - nonces, challenges etc.
<rbarnes> ms2ger: lol, ok, then what are we debating?
wtc: suggestion is for the application to provide additional seeding material for the underlying PRNG
<Ms2ger> rbarnes, not sure :)
cjkula: and for the ability to provide arbitary parameters for the key generation
ddahl: that opens it up to much - that would be more than PKCS#11 even
arun: what is the status of window.crypto.getRandomValue ? also some inconsistency in implementation
hhalpin: need to ask Mike for status from HTML WG
<ddahl> hi Ms2Ger
<Ms2ger> Hi ddahl :)
arun: we may as well take over this API form HTML
<wseltzer> ACTION: Harry to find out status of getrandom in HTML5 [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action08]
<trackbot> Created ACTION-23 - Find out status of getrandom in HTML5 [on Harry Halpin - due 2012-08-01].
<Ms2ger> That's going to be fun
virginie: summary - we will refer to this existing feature and possible work in improving the specification
<ddahl> Ms2ger, wtc was explaining about the weakness of RC4
<Ms2ger> The HTMLWG is one of the most dysfunctional groups at the W3C
<Ms2ger> If you want to get work done, do it in your own WG or in WebApps
<Ms2ger> There's nothing about window.crypto in any HTMLWG spec, is there?
<rbarnes> ms2ger: that's my point
<Ms2ger> Does someone want to change that?
<wseltzer> ACTION: Wan-Teh to add section to the draft on random number generation [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action09]
<trackbot> Created ACTION-24 - Add section to the draft on random number generation [on Wan-Teh Chang - due 2012-08-01].
<ddahl> Ms2ger, we were talking about referring to the WHATWG Crypto spec, but then were confronted with the reference to RC4
<Ms2ger> What WHATWG Crypto spec?
<hhalpin> it freaked people out Ms2ger :)
<rbarnes> ms2ger: this one: http://wiki.whatwg.org/wiki/Crypto
<Ms2ger> rbarnes, I moved that into https://dvcs.w3.org/hg/domcrypt/raw-file/tip/Overview.html
asad: been looking at how external token use-cases are supported by the API
<Ms2ger> Hence the link at the top of http://wiki.whatwg.org/wiki/Crypto
<hhalpin> aha
asad: APIs have been designed around keys and key handles and their attributes
<hhalpin> good move ms2ger, we're now working in this space:
<ddahl> Ms2ger, oh! cool.
<rbarnes> ms2ger: understand. but that page still has content, so it looks like a whatwg spec
<hhalpin> http://www.w3.org/2012/webcrypto/WebCryptoAPI/
asad: two attributes of particular interest (1) where is key stored (browser memory, external token etc.)
... (2) where is the actual processing of the algo taking place
<ddahl> so a new action will be to subsume that Crypto spec into our new draft
asad: some wording in the scope says the APIs must be generic enough to allow UAs to expose keys stored in external tokens (for example) without the application having to know about where the key us stored
... would it make sense to allow the application to dictate (or prefer) that key be stored in or taking from external token
... maybe application behaviour depends on whether they key is in a token or not
... so, should the application have some say on where the key is stored/taken from and where the processing is done ?
arun: good question. We can't stop web developers doing things like storing keys in local storage
... API by design should presume a UA key store
... might have to punt on different key stores such as tokens
... or at least not expose that - just seen as extension of browser key store
... shouldn't encourage storing of keys in indexdb, for example
asad: depends on whether applications need to be aware of key storage location
<Ms2ger> http://www.w3.org/2012/webcrypto/WebCryptoAPI/ <"File a bug" link and "W3C public CVS server" link are broken
arun: web application could be agnostic about key storage location. Probably shouldn't build that into the API
virginie: what is the impact of your comment on the API design ?
arun: API should presume a single logical key store
... not sure how we can prevent apps creating their own key stores
cjkula: make the API we define good enough that people will want to use that
ddahl: key generation API currently doesn't allow access to keying material
... perhaps add a flag to allow access but that should not be the default
arun: storing even public keys in some ad hoc place for later use should be a really bad pattern
sdurbha: agree with arun. Don't see the value for the application to know where the key is except for lookups
<arun> arun: specifically, we should discourage the pattern of use where IndexedDB or localStorage are used to store keys (as strings, ArrayBuffers, JSON objects, etc.)
sdurbha: may need an API to trigger key load from external tokens if the key load is expensive
... if key is in external storage so will the operation
cjkula: an onkeyload event could help when it takes some time for keys to load. Get a notification when the key is loaded.
... may be the responsibility of the user agent to do the loading
sdurbha: may depend on the application to decide when keys need to be loaded
wtc: windows.crypto.keys idea isn't really fully specified on mailing list and has several problems
... we should focus on KeyQueryList API
... allows us to discover token add/removal events
... second point: keys usually strongly linked to the crypto provider at the location where the key is stored
... don't need to worry about separation of key storage and location of operation
vgb: other specs work this way (PKCS#11, MS etc.)
virginie: do we need to explain this in our specification ?
vgb: don't need to explain to user of our APIs how underlying APIs work
wtc: this is why we don't need to expose crypto provider concept because it is implicit in key handle
vgb: two problems: usage - already have the notion of queries. When you query a key that is implicit bound to notions of storage and processor. Not clear what it means to say take a key from one store and operate on it elsewhere
... should set aside usage part and let it be implicit as it is today
... second question is generation: can I ask for a generated key to be put in a specific place ?
... feels like complexity of introducing crypto providers isn't worth the limited benefit
... we should stay away from excessively constraining interaction of UA with user
... e.g. app dev may not know that directing a key to a specific place triggers user interaction
sdurbha: crypto providers: previously thought this was just internal to browsers but now not so sure. Example: Set Top Box has a crypto provider provided by the device manufacturer
... API needs to enable application to ask for key from that specific provider
vgb: difference is between generation/import and lookup. Lookup is fine: browser searches all providers
... but for generation and import it's more difficult
karen: key attributes included storage and operator. There is confusion between crypto provider and operator.
... if key is on smart card, for example, crypto operation should be performed by that smart card
... was thinking of the case where you get a key from a smart card and process the key in the browser
... but this is probably not a main use case
... crypto provider is more often to refer to different libraries
vgb: actually each library has within it a notion of crypto providers
hhalpin: smart card question has been looming for a while. Charter excludes specific smart-card functionality
... but have this notion of uniform API across different key stores
... karen - seems you agree with wtc that this is how it should be done
karen: agree
hhalpin: only other thing is the operation issue and generation aspect that vgb brought up
... this becomes an argument in favour of KeyQueryList
wtc: targetted key generation should be out of scope but we should be able to use keys that are on smartcards
karen: key itself can carry attribute of where it came from
... user agent can determine whether it has a key from a smartcard and will know that operations with that key will occur on the smartcard
selfissued: UA may not have writable persistent key store
wtc: e.g. browser in private browsing mode
virginie: so, do we need a storage attribute associated with a key ?
vgb: often you only have a provider name - you don't necessarily have the information about where it is stored
sdurbha: often you do know the location or would like to specify it in a lookup
virginie: need to clarify there is a single logical keystore which may be backed by multiple different containers
vgb: action is to document the existence of and properties of the persistent key store in our specification
sdurbha: need to say how this is to be used in the API. For lookup how do we specify that, for example, we want keys that have a certificate chain ending at some particular root
asad: if you limit scope of lookup the application is now controlling where the keys are
... application is saying you can use any key as long it is in the app-specified storage
wtc: only key location information we have is provider name and we have decide not to expose providers
... so we have to use other information for lookup, keyid etc.
vgb: what are we trying to solve ? If a key is in secure storage but it was injected by an attacker do we still trust it ?
... good practice to be able to describe which keys you do or don't trust
... because this trust does not come from the cryptographic processes - it comes from external processes
<rbarnes> i mean, maybe there's some benefit to the key being on the card for portability...
<wseltzer> [freeze the discussion; lunch until 1pm Pacific]
<wseltzer> [back to the meeting]
<wseltzer> scribe: vgb
<wseltzer> scribenick: vgb
<wseltzer> ACTION to formalize that when we have a key handler, operations on the key should apply on the source of the key
<trackbot> Sorry, couldn't find user - to
<wseltzer> ACTION Wan-Teh to formalize that when we have a key handler, operations on the key should apply on the source of the key
<trackbot> Created ACTION-25 - Formalize that when we have a key handler, operations on the key should apply on the source of the key [on Wan-Teh Chang - due 2012-08-01].
markw: we should think differently about pre-provisioned keys. You can't trust what the browser says about storage or crytpo providers. Trust comes from the fact that the server knows the key in an out-of-band way.
... so there's no value to knowing provider for pre-provisioned keys but only for generation
karen: may the UA also show a prompt asking the user to select a key?
... maybe D-H is a use case for knowing where a key lives?
markw: even in the DH case, the trust is gained from the server knowing out-of-band
sdurbha: 2 cases: as an attribute of a key and as a parameter to key query
markw: even in that case, the browser is assumed untrusted
<arun> (My questions were answered at lunch)
karen: discussed crypto provider (storage + operation) already with wtc and action created
<Ms2ger> Unminuted? Tut tut :)
<ddahl> Ms2ger, what is the problem?
<ddahl> wseltzer, ^^
vgb: asking Karen to clarify why we should have UA display a list of keys for user to select. This seems like an admission of failure by the app.
Karen: similar to selection dialogs today
... (e.g. IE asking for client auth certs)
<arun> Ms2ger, I had a question about key lookup in smartcards, and how this should ideally proceed. wtc and vgb both think it should *just work.*
<Ms2ger> Just working sounds good
<ddahl> arun, are we perhaps talking about a similar assumed 'filepicker-style' UI?
<ddahl> arun, that is not really all that defined
<ddahl> in the spec
vgb: yes, IE does that but it is not a good model to follow. We should not write such UI requirements into the API spec either.
<arun> Ms2ger, ddahl -- basically, what happens if a SmartCard contains a key or cert that you want a web app to pick up on? Well, after the SmartCard is connected, the KeyQueryList is inclusive of the SmartCard.
Karen: so from this WG perspective, if we agree that ambiguous queries return a list of keys to the user, we should add informational text about that
<arun> Don't think we need a FilePicker-style UI, although upon reflection, maybe there's something there :)
cjkula: should we have events for key arrival (e.g. smart card inserted)?
Karen: no, we should allow for lazy evaluation by UA
<rbarnes> so just have like a "there may be more keys available for you" event
<rbarnes> which fires when a smart card shows up
ddahl: maybe we should have onkeyadded events?
<rbarnes> then the app can go check if there's actually a key for it
sdurbha: maybe we should include it because of timing effects?
vgb: IMO KeyQueryList should only ever make one callback with a list of keys found, or none (if nothing was found)
<wseltzer> ISSUE: Concern around KeyQueryList being synchronous
<trackbot> Created ISSUE-6 - Concern around KeyQueryList being synchronous ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/6/edit .
hhalpin: Maybe we can go to FPWD with tihs issue open since it's a secondary issue
ddahl: no, it's more general
Karen: wtc, vgb and Karen had a discussion at lunch about how to represent properties of a symmetric key (similar to certificate for asymmetric)
<wseltzer> ACTION vgb to review state of the art on symmetric key properties
<trackbot> Created ACTION-26 - Review state of the art on symmetric key properties [on Vijay Bharadwaj - due 2012-08-01].
<kaepora> Base64 all the things
<ddahl> kaepora, not the cipher data!:) binary please!
<wseltzer> virginie_galindo: All, please review security considerations http://www.w3.org/2012/webcrypto/WebCryptoAPI/#security
<wtc> Use Cases wiki is at http://www.w3.org/2012/webcrypto/wiki/Use_Cases
virginie_galindo: let's discuss use cases briefly and see if we can go to FPWD with this
wtc: Use case doc was written by Channy and wtc made a pass for proofreading and English things
... could add a few new use cases that have since been brought up.
... Another suggestion was to go through use cases and detail how they work with the proposed APIs.
... But not sure if we should go over the use cases in detail here.
virginie_galindo: what about the helpcrypto use cases?
... we should have a look at them and incorporate if needed
wtc: we should also consider JOSE a use case
virginie_galindo: how do you treat that as a use case?
selfissued and rbarnes: it should be possible to implement JOSE with this API
<rbarnes> http://tools.ietf.org/html/draft-barnes-jose-use-cases
wtc: member companies should also review the draft and bring up any missing use cases
virginie_galindo: for FPWD we should have a use case summary in the API draft but don't need the full doc done by then
wtc: how much detail is needed?
arun: did it for fileAPI - no requirement, can make it pretty short
<arun> ACTION: add primary use cases to the specification, assigned to arun [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action10]
<trackbot> Sorry, couldn't find user - add
<wseltzer> ACTION: Arun to add primary use cases to the specification [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action11]
<trackbot> Created ACTION-27 - Add primary use cases to the specification [on Arun Ranganathan - due 2012-08-01].
Karen: about smart card use cases, had sent email long time ago but current draft appears to cover them.
... but for the existing use cases it would be good to add text saying that a secure element such as smart card may be involved.
virginie_galindo: was already an action to JimD for that
wtc: that is the 4th use case
... in section 15
<wseltzer> Section 15: http://www.w3.org/2012/webcrypto/WebCryptoAPI/#requirements
<wseltzer> Karen's use cases: http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0012.html
Karen and wtc: it is important for use case doc to note that we do support using keys on smart cards
sdurbha: asking about encrypted web apps and "signed by a party other than the author" (use case in Wiki)
wtc: may be out of scope in its current form
hhalpin: might come because there was interest in that space during charter discussions
... but may have goen away due to resourcing (Facebook?)
vgb: isn't that just signature verification, which is supported?
ddahl: it's really "signed script"
arun: we already cater to this, and we can always just punt to secondary
<hhalpin> "Cryptographic primitives can help check source integrity before executing Javascript code previously stored in local storage."
<hhalpin> http://www.w3.org/2011/11/webcryptography-charter.html
hhalpin: not entirely sure where it came from but this is the summary in the charter
<hhalpin> I think that came from Facebook
arun: should we care that this is code and not any other data being verified?
Karen: what's the difference?
arun: need to think about it.
ddahl: execution would have to happen after the verification. that is out of scope of our charter, it is more a Javascript engine thing (that already exists)
cjkula: is there a case for running signature verification on a page element?
markw: you can do that with XHR to retrieve the element and add it to DOM. So still covered.
hhalpin: okay with dropping it. If anyone thinks it is interesting they should take it over.
cjkula: interested, will follow up offline
ddahl: resource may be different from script
Karen: signed JS has been talked about for years, so may be interesting
ACTION Chris to follow up with Facebook on signed code use case
<trackbot> Sorry, couldn't find user - Chris
ACTION cjkula to follow up with Facebook on signed code use case
<trackbot> Sorry, couldn't find user - cjkula
ACTION Christopher to follow up with Facebook on signed code use case
<trackbot> Created ACTION-28 - Follow up with Facebook on signed code use case [on Christopher Kula - due 2012-08-01].
virginie_galindo: now to discuss how to proceed with tests
hhalpin: every WG does testing different
maybe arun can talk about FileAPI
scribe: every WG needs 2 interoperable implementations, but tools are up to WG
arun: webgl may be a better example. each implementation checked in common tests and then launched it all using a test harness.
<hhalpin> http://www.khronos.org/webgl/wiki/Testing/Conformance#WebGL_Conformance_Test_Suite
<hhalpin> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
arun: so we might also want to ask for implementers to contribute tests
wtc: when you specify the API, do you also generate a document describing desired tests?
arun: no
... test suite grows organically with implementations
wtc: maybe we should write a doc enumerating desired tests
hhalpin: maybe use selenium?
cjkula: could do both - describe desired tests and grow that with implementers' tests
<hhalpin> or WebDriver, which I haven't used.
hhalpin: implementers should drive this using any of the common test harnesses
cjkula: maybe use jasmine as a driver and use hooks so we can run the suite in any browser
virginie_galindo: maybe we should canvass the implementers
cjkula: SenCha has experience in this area
ACTION Harry to follow up on tools with Jarred and/or others
<trackbot> Created ACTION-29 - Follow up on tools with Jarred and/or others [on Harry Halpin - due 2012-08-01].
virginie_galindo: do we need a dedicated editor for test cases?
hhalpin: WGs do this differently
ddahl: was planning on working on this
... can at least help with technology side
virginie_galindo: how to validate algorithms? and which ones to test:
markw: should be tests for everything
hhalpin: you can differentiate these - can clearly specify optional vs required/recommended and could reflect that when reporting interop results
arun: closest to that was seen in XHR.
hhalpin: W3C only cares about 2 interoperable implementations
virginie_galindo: to summarize, everything specified (optional or not) must have associated tests
Karen: could use NIST test vectors where they exist
wtc: can do
virginie_galindo: to clarify, security considerations are not tested
various people: yes
wtc: sections 8 through 14 are the ones that need to be tested
virginie_galindo: schedule - when do tests have to be ready?
hhalpin: need to be demonstrable by 11/2013
... but last call was scheduled for 2/2013 so it would be better to have tests sooner
... technically the deadline is late in the game but realistically we'd like to have something by 8/2013 so we can feel comfortable
... you often discover stuff in writing the test suite, so should start sooner
cjkula: when can we say something about how we expect vendors to work with us?
hhalpin: hopefully late this year (maybe at TPAC?)
virginie_galindo: test suites don't need to be at public draft?
hhalpin: no
wtc: do we know of anyone doing a pure JS implementation? that may be much faster than in a browser.
rbarnes: starting work on one.
wtc: that would make writing tests a lot easier
Karen: could we generate skeleton code (from something like an executable specification?)
... using GWT?
rbarnes: not sure how useful that would be
... implementations of various algs already exist, just need to collate
ddahl: tricky part is events, which aren't easy with polyfill
... maybe use my DOMcrypt extension
<wseltzer> [break: 20 minutes]
<wseltzer> scribenick: sdurbha
<wseltzer> scribe: sdurbha
virginie: let us take a quick look at the action items that are currently open
... I will revisit yesterday's discussions to see if any new action items need to be created
<virginie> http://www.w3.org/2012/webcrypto/track/
virginie: Action 10: assigned to Ryan, still open?
WTC: Ryan sent an email earlier this week or last week on this action item
virginie: we need to update the status then
WTC: I think some other people also commented on this action item
virginie: let us mark Action 10 as pending
WTC to send a link to the email exchange
<ddahl> virginie
virginie: Next action item: 12, allocated to Jim
... currently still open, some contributions to be clarified
vgb: Jim said at some point in the email threads that it was covered by all other use cases, but I cannot find the reference
virginie: all other actions (not the ones we created in f2f) are not open,
... let us go to the Issues
Arun: we resolved #4
Harry: we resolved mandatory issue
Arun: we need an action item for that
virigine: yes
virginie: Issue #5...
... status: it is raised
... issue #6: status raised
Markw: if there are no keys, it should not come back, question on the origin bound keys - it may not be a privacy issue
... not sure if that is a separate issue. Particulary if it is an HTTPS origin, there may not be a privacy issue
wendy: one privacy issue could be across sessions
dave: are you talking about synchronous?
markw: no
vgb: it is question of ....
... current API is asynch
markw: that api is not documented currently
vgb: your question is on the absence of negative signal, currently there is no timer to indicate end of search
markw: in origin bound cases, we may need to give the notification
vgb: may be we need a timeout parameter
markw: what I am saying that in the origin bound case, we get a response immediately - no entries
virgine: let us create an action item
dave: I see what you are saying
virgine: general comment: i used to issue take-away after each call, now I think we have an action/issue management, so do we still need the take-aways?
dave: I am using it;
arun: I like it
<wseltzer> +1
harry: it is useful for people who missed the meeting
virginie: OK, may be not for the f2f, but for conf calls I will continue to issue take aways
dave: Q: Can we refer to line #s in the IRC?
hhalpin: little complicated,
dave: To virginie, may be you can use IRC as quick reference
<hhalpin> So here's an example
<hhalpin> http://www.w3.org/2012/07/24-crypto-minutes.html
virginie: let us clarify timelines, and what we are going to do over next few months
<hhalpin> is reflected in text here:
<hhalpin> https://www.w3.org/2012/07/24-crypto-irc.txt
<wseltzer> [unfortunately, today's minutes aren't logging automatically]
<hhalpin> so you can refer to line numbers
virginie: let us cancel next week's
consensus: all agree
<wseltzer> RESOLVED: No teleconference next week.
virginie: do we want to have 1 hr conf call to discuss the draft?
... next draft 20th of August
WTC: yes, that is correct (20th August)
virginie: can we have the meeting on the 17th?
... q: is it too aggressive (to WTC)?
WTC: No, the date is good
hhalpin: every body should read the draft by 17th
virginie: the goal is to give comments by 20th, and by 27th, we actually call to go public
... this is just a suggestion, if we want we can go to September
dave: let us determine the date of publishing on Aug 20th
virginie: it is not going ot be September, but something like 27th of Aug
markw: key entreis are going to be key generation, table of algorithms
... there are lot of details we have to look at for both key gen and table of algos
wtc: is the version of cvs published on the web site?
... the question was: is the version in CVS visible to public?
dave: yes
virginie: so, we decide on 20th
hhalpin: why do not we collect the names of the reviewers?
virginie: do you actually want to write the names in the wiki?
hhalpin: we can
...question: may be we can go round to see if anyone can think of potential reviewers; I can think of NIST
<hhalpin> tim polk, john kelsey in NIST
dave: we should consider not just crypto / security people, but JS people should be included in the review
(IETF was also mentioned)
Arun: I agree
<hhalpin> Sean Turner and the IETF security ADs
Arun: we should include library people (jquery)
hhalpin: first baked will be the initial draft
... second bit baked will be ...
(academic community was mentioned)
virginie: for the reviewer list, we should include the ones that are serious about reviewing, not encourage last minute reviews
hhalpin: invited experts vs actually participating: not a good percentage. So, may be it is worthwhile to give a warning that they need to participate/review lest their status changes
... we should ping members individually as well
virginie: I do not want to look like we are targeting people
... when we have a good reviewable doc, we can send out these emails
... about service providers, we have netflix/cablelabs, any others?
hhalpin: paypal may be interested
virginie: do we look at other W3C members?
hhalpin: all comments should be made through the mailing list
... Bugzilla is a little bit more complicated, not formal
virginie: do we have a specified delay?
hhalpin: there is not formal rule
... you get a comment, it is editor's responsibiltity to respond
... I have never seen a particular time frame used
... emphasis is on responding, not answering
... if they did open an issue and the issue is resolved, one responds to the originator
virginie: I am trying to see if the group spirit, what are we expecting by the TPAC meeting?
... are we expecting all comments to have been addressed?
... we have 2 months to collect comments (Sept, Oct)
... what is our target by end of those 2 months ?
hhalpin: We will not have everything resolved by Nov
... as long as the issues are being tracked
... it will be great to have 'internal' issues being not open by Nov
virginie: the Nov meeting is important and will be great if we can have everyone attend
hhalpin: heartbeat requirement, every 3 months, 1st draft by end of Aug, 2nd draft by end of Nov (TPAC), so on
... it is worthy pushing earlier than later
<kaepora> I am a cat :3
<kaepora> ^--- important topic
<kaepora> Meow meow conference call
virginie: do we want conf calls in the mean time (before Aug 17th)?
Aug 6th: we keep the meeting
Aug 13th: we keep it as well
vgb: can we keep the conf calls for 60 minutes?
virginie: OK
that is the end of f2f
thank you Mozilla!
<kaepora> This was a very purr-fect location
<kaepora> A meowgical meeting
<kaepora> I hope we have cat-apulted our work forward
<wseltzer> Thanks all!