Web Cryptography Working Group

25 Jul 2012


Virginie_Galindo, Wan-Teh_Chang, David_Dahl, Mark_Watson, Chris_Kula, Asad_Ali, Seetharama_Durbha, Vijay_Bharadwaj, Karen_Lu, Mike_Johes, Harry_Halpin, Wendy_Seltzer, Arun_Ranganathan, Richard_Barnes, Nadim_Kobeissi
Virginie Galindo
cjkula, markw, vgb, sdurbha


<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


<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

Key import, random generation

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].

Random generation

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].

External tokens

<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

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]

Review open issues

<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!

Summary of Action Items

[NEW] 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]
[NEW] ACTION: add primary use cases to the specification, assigned to arun [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action10]
[NEW] ACTION: Arun to add primary use cases to the specification [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action11]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: Harry to find out status of getrandom in HTML5 [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action08]
[NEW] 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]
[NEW] ACTION: vgb and cjkula to describe key import/export functionality [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action07]
[NEW] 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]
[NEW] ACTION: Wendy to return with report on XMLSec PAG [recorded in http://www.w3.org/2012/07/25-crypto-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/07/25 23:04:50 $