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
... 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
virignie_galindo: people felt
that there was a lack of use cases, so use cases have been
... contributions from groups for identity and crypto
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?
ddahl: things are under
construction in github repo
... trying to design what a key id, public key might look like
ddahl: ArrayBuffer might hold data that translates into JWK object
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
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
... 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?
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
... 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
<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> 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
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]