18 Jun 2012

See also: IRC log




<hhalpin> Convening Web Crypto June 19th 2012

<hhalpin> chair: virginie_galindo

<hhalpin> scribe: emily

<hhalpin> Scribenick: emily

<virginie_galindo> aagg is virginie_galindo

<self-issued> Mike Jones

virginie_galindo: role call of delegates

<sdurbha> I guess ??P18 is me, sdurbha

virginie_galindo: several new participants this week from Microsoft, Red Hat, David Rogers
... any other topics to discuss besides what's on the agenda?


virginie_galindo: hhalpin, do we need a resolution to approve previous minutes?

<hhalpin> PROPOSAL: We approve the minutes of the last call as correct

<hhalpin> APPROVED: last week's minutes are correct

use cases update on wiki


virignie_galindo: people felt that there was a lack of use cases, so use cases have been enriched
... contributions from groups for identity and crypto

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

virginie_galindo: use cases separate primary and secondary features, use cases collected from survey participants
... if you didn't have time to look at use cases, have a look and propose suggestions, improvements, new use cases
... still under construction
... any questions on use cases?

Editors draft API (no change)

Editors Draft API

ddahl: things are under construction in github repo
... trying to design what a key id, public key might look like

garage under github

ddahl: ArrayBuffer might hold data that translates into JWK object

<ddahl> https://github.com/daviddahl/web-crypto-ideas/blob/master/key-ids.js

ddahl: still discussing what this will look like
... questions inline on the github page, would be nice to figure out issues right in that repo
... but either that or email is fine
... also trying to nail down algorithm discovery

<virginie_galindo> https://github.com/daviddahl/web-crypto-ideas/blob/master/algorithm-discovery.js

PhilipG: algorithm discovery or key discovery?

ddahl: algorithm discovery, discovering what algorithms supported by api or implementation

PhilipG: smartcards mean algorithm list could possibly change, might want notification on algorithm change
... algorithms are tied to module, sub-component, that can come and go which could make it messy

<drogersuk> (not me speaking)

<zooko> Hello folks! Sorry I'm late. Going to call in now.

PhilipG: smart card might support some flavor of ECC that the browser does not

virginie_galindo: the secure element or smart card might be a means to store the key, but actual operation would not happen inside the smart card?

PhilipG: can't export key from smart card, so operations have to be done on card

JimD: smart card has to be available for algorithm list, since can't retrieve the key

jbradley: point of smart card is that private key can't be exported, so type of key and algorithms that operate directly on the key go in and out of crypto suite with the card

<zooko> Zakim: +1.902.44.aakk is me.

rsleevi: my take is that smart card provisioning, authenticating/locating keys that are stored on secure elements, those discussions are out of scope, but use of keys is in scope
... e.g. RSA key with OAEP or PSS, shouldnt be used with PKCS 1.5, so which one you use will depend on what you've used it with before
... so algorithm discovery still applies even with smart cards out of conversation

hhalpin: to remind people, potentially infinite number of operations one could perform, maybe should think about it as if we want to allow an extensible number of operations
... standardize core operations that we hope will perform across all browsers, and should move forward on this

virginie_galindo: operation that happens in smart card will have to be discovered

<hhalpin> just pointing out discovery can happen without smartcards

<hhalpin> but that this is a somewhat hard problem

<hhalpin> and thus, maybe try to move forward on rsleevi's low level proposal

ddahl: could have an event, not sure yet

rsleevi: for discovery, there are two types (could I ever possibly support X, and could I support X with this type of key)
... do these two types meet needs, or are there other types needed?

<zooko> I either need to think about it or I am happy with your proposal.

<hhalpin> multiple keystores are in secondary features BTW :)

jbradley: the real issue is whether keystores can by dynamically added and removed

<rsleevi> jbradley: The KeyQueryList might be able to accomplish this

jbradley: there may be times when dynamic keystores may affect discovery results, since you would have different keys
... should try and differentiate between smart cards (where processing happens on card), or just plain keystores

drogersuk: how reliable do we expect information to be?
... theoretically, could maybe execute attack on false discovery information, data is not assured

virginie_galindo: we know that security's not perfect, so we have to make some assumption about how far we trust the platform
... here it's up to the browser makers to tell us if the answer is something we can trust or not

zooko: web browser running on general purpose computer is a very common setup. to me, personally the most interesting use cases are about web browsers running on general purpose devices, without smart cards or auth tokens or anything else

<ddahl> rsleevi ++

rsleevi: one of the ideas we've been thinking about, as far as web app security goes, can a script alter the algorithms or lie or that sort of thing, content-security policy might be a condition for this API. maybe you have to have a CSP of some minimum criteria to prevent xss
... that's one possibility that could maybe improve trustworthiness of API
... ddahl raised point about trying to make weak security hard to use. still trying to figure out what csp can bring

hhalpin: from operational standpoint, have to prioritize browsers without smart cards. secondary features start to think about multiple keystores, discovery algorithms. be sure to document all these use cases

virginie_galindo: we've been discussing about key discovery, so you are suggesting that dynamic keystores might be secondary features?

hhalpin: multiple keystores/smartcard functionality is in secondary features. the discovery problem (high-level vs low-level API) is in primary features. until we have a concrete example of how discovery works, we might want to move on to low-level API
... or if someone has a very concrete suggestion about exactly how discovery would work that would satisfy smartcard use cases, that would be good

<rsleevi> hhalpin: I think the KeyQueryList might be a concrete solution that we can use as a strawman

<wtc> For smart cards, key discovery should be enough. If a smart card has a key, the smart card must be able to use the key. So the key implies the support of its algorithm.

<hhalpin> Agreed, I don't see why in principle why that wouldn't work over smartcards, but I'm not a smartcard expert

ddahl: as we come across additional ideas for browser features to help with the trust issues, we can enumerate them and keep them around for the future. No one here thinks that the API by itself is a silver bullet, but this API along with other features can provide much more secure environment

<zooko> ddahl: good point!

<ddahl> zooko: thx:)

<hhalpin> If the editors feel the KeyQueryList is good enough, they can add that to the Editors Draft

virginie_galindo: coming back to how keys should be identified, key lifetime, so I'll summarize this discussion
... group agreed that keys should be created with associated algorithms
... discussion about whether key should be ephemeral or persistent
... discussion about whether key will be extractable or not, the group decided that it will be both

<jbradley> harry: A key in a smart card may be discoverable, but you may not be able to extract it, only use it with the embedded algorithm processor on the card.

<jbradley> I agree that smart cards are not a priority for me. There are existing ways to use a PIV card that more or less work for people.

virginie_galindo: extractable or not, can be used one or several services, ephemeral or persistent

ddahl: some details haven't been worked out. as far as extractability, when a key is created, key would be flagged as extractable or not
... as an optional argument. Default maybe would be that private key is not accessible to content

<hhalpin> jbradley: we understand the extraction (not needed, but possible, see ddahl), the open question to me is if we want a "discovery" event that says the number of algorithms has been increased.

ddahl: again, still a lot of details to work out. What's in github is not quite the latest thinking

<virginie_galindo> ... a key is - Shaped for a specific usage (algo, padding, …)

<zooko> That sounds good to me. It would satisfy my desires, and seems good for the other kind of use case as well.

virginie_galindo: any questions on key identification, etc.?

<rsleevi> ddahl: That is in line with what I was thinking, and I think covers most use cases

<ddahl> rsleevi: thanks for sending that proposal!

virginie_galindo: very recent mail from Ryan proposes low-level API

rsleevi: KeyQueryList needs to be revisited. Low-level API assumes you have a key, doesn't cover derivation or generation
... yet

<virginie_galindo> ... a key has a Lifetime stamped – ephemeral or persistent, not sure it leads to a specific property

<virginie_galindo> ... a key is Extractable or not (to be exchanged with external world, or manipulated directly and only by webapp)

rsleevi: One of the design goals is keeping API names meaningful but short, since they can't be minified or compressed

<virginie_galindo> ...... a key is Named uniquely (by service provider scheme, by browser scheme)

rsleevi: Interface sees commonality between digesting, MACing, sigs, verification, enc/decryption, modeled after File API
... messaging, file transfer, exchanges should be supported

<virginie_galindo> ... a key is Reusable or not by other service (linked with same-origin, or multiple origin)

<zooko> That sort of streamy common interface is used in the Crypto++ library, for what it is worth.

<virginie_galindo> ... a key is Invoked (by properties, by name, by usage, …)

rsleevi: not sure whether to proceed with discussion via email or github, or w3c mercurial, whatever chairs/editors feel is best

hhalpin: editors ultimately decide what goes in w3c space
... beneficial to publish quick and early with open issues list

<wtc> hhalpin: your proposal sounds good to me.

virginie_galindo: summary of what I feel our API should contain
... should draft the way we use keys
... should have discovery mechanism
... should have the way that keys are named/identifier

<hhalpin> Proposal would be to look at low-level API over next week and check it into Github ASAP, and then we spend some time at an editors meeting to push it into an Editor's Draft in W3.org space next week for draft approval in July.

wtc: the next big missing piece is key management
... personally think discovery mechanism is not as important
... developers will quickly figure out what commonly supported algorithms are

<self-issued> Mike Jones / Microsoft signing off - I have another commitment at the top of the hour.

wtc: key management means the operations that actually produce key handles (generate, derive, find, delete keys)

virginie_galindo: its up to us to decide what goes in public draft

<rsleevi> markw: Is the Editors Draft going to reflect rsleevi's proposal, ddahl's github work, or something else?

markw: closing all open issues in the next week is ambitious

<hhalpin> I am stating we publish *with* open issues.

<hhalpin> We do not have to resolve all open issues

<ddahl> hhalpin ++

virginie_galindo: a lot of issues will probably be resolved at f2f meeting

hhalpin: just to clarify, it's completely fine to have open issues in working draft
... often advantageous to do so

usually, first public working draft is some sort of strawman, fairly comprehensive exploration of options in the design space

<hhalpin> I'd suggest everyone look closely at rsleevi's proposal closely over the next week!

virginie_galindo: everyone should look at Ryan's proposal and ddahl's github
... On topic of group life, privacy interests group, crypto working group, DNT might be able to help us with e.g. privacy problems that come up for us
... I reported what we were doing and that we care about privacy, and how we can improve privacy
... anyone who feels we should speak more with IETF, should tell us

<hhalpin> I suggest folks join the WebSec IETF mailing list

<hhalpin> https://www.ietf.org/mailman/listinfo/websec

<hhalpin> Is a good list for co-ordination with the IETF

virginie_galindo: f2f meeting is at end of July
... 18 votes, mountain view is winner
... any comment, july 24-25th in mountain view?
... Another f2f in october or november, where we'll work on comments from public.
... if you're planning to attend f2f in july, tell ddahl (who is organizing it) that you're attending

ddahl: meeting at mozilla office, more details to come

<hhalpin> RESOLUTION: Informal f2f July24-25th Mountain View

virginie_galindo: no call next week, next meeting in 2 weeks
... end of June

hhalpin: if people are interested, editors could use that time to go over bureaucracy of w3c publishing

<virginie_galindo> next meeting will be on 2nd of july

<hhalpin> No, informal meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/06/18 20:11:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/??/PhilipG/
Succeeded: s/??/PhilipG/
Found Scribe: emily
Found ScribeNick: emily

WARNING: No "Present: ... " found!
Possibly Present: APPROVED ChristopherKula JimD JohnBradley Microsoft P0 P18 P3 P4 PROPOSAL PhilipG Scribenick aaaa aabb aacc aadd aaee aaff aagg aahh aaii aajj aakk abstractj ddahl drogersuk emily harry hha hhalpin https inserted jbradley markw pin rsleevi saerd sdurbha self-issued virginie_galindo virignie_galindo wseltzer_transit wtc zooko
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 18 Jun 2012
Guessing minutes URL: http://www.w3.org/2012/06/18-crypto-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]