IRC log of crypto on 2012-06-18

Timestamps are in UTC.

18:53:43 [RRSAgent]
RRSAgent has joined #crypto
18:53:43 [RRSAgent]
logging to
18:54:31 [virginie_galindo]
Zakim, this will be Crypto
18:54:31 [Zakim]
I do not see a conference matching that name scheduled within the next hour, virginie_galindo
18:54:44 [virginie_galindo]
Zakim, this will be WebCrypto
18:54:44 [Zakim]
I do not see a conference matching that name scheduled within the next hour, virginie_galindo
18:54:47 [wseltzer_transit]
zakim, this will be CRYPT
18:54:47 [Zakim]
ok, wseltzer_transit; I see SEC_WebCryp()3:00PM scheduled to start in 6 minutes
18:56:17 [virginie_galindo]
18:56:40 [hhalpin]
hhalpin has joined #crypto
18:57:07 [Zakim]
SEC_WebCryp()3:00PM has now started
18:57:11 [JimD]
JimD has joined #crypto
18:57:13 [hhalpin]
18:57:15 [Zakim]
18:58:05 [virginie_galindo]
agenda+ Welcome
18:58:18 [Zakim]
+ +1.773.939.aaaa
18:58:25 [hhalpin]
Zakim, what's the code?
18:58:25 [Zakim]
the conference code is 27978 (tel:+1.617.761.6200, hhalpin
18:58:37 [virginie_galindo]
agenda+ use cases update on wiki
18:58:50 [Zakim]
18:58:55 [drogersuk]
zakim, ??P0 is drogersuk
18:58:55 [Zakim]
+drogersuk; got it
18:58:56 [hhalpin]
Zakim, ??P3 is hha;pin
18:58:56 [Zakim]
+hha;pin; got it
18:59:00 [virginie_galindo]
agenda+ Editors draft API (no change)
18:59:13 [hhalpin]
Zakim, hha;pin is hhalpin
18:59:13 [Zakim]
+hhalpin; got it
18:59:20 [Zakim]
+ +1.707.799.aabb
18:59:25 [ddahl]
ddahl has joined #crypto
18:59:29 [virginie_galindo]
agenda+ garage under github
18:59:30 [hhalpin]
Zakim, pick a scribe
18:59:30 [Zakim]
Not knowing who is chairing or who scribed recently, I propose +1.707.799.aabb
18:59:38 [emily]
zakim, aabb is emily
18:59:38 [Zakim]
+emily; got it
18:59:43 [markw]
markw has joined #crypto
18:59:45 [Zakim]
18:59:47 [Zakim]
+ +1.978.936.aacc
18:59:49 [virginie_galindo]
agenda+ group life
19:00:13 [PhilipG]
PhilipG has joined #crypto
19:00:13 [Zakim]
+ +1.978.652.aadd
19:00:29 [hhalpin]
Convening Web Crypto June 19th 2012
19:00:43 [hhalpin]
chair: virginie_galindo
19:00:48 [hhalpin]
scribe: emily
19:01:18 [hhalpin]
Scribenick: emily
19:01:20 [Zakim]
+ +1.415.867.aaee
19:01:31 [Zakim]
+ +1.650.214.aaff
19:01:31 [markw]
Zakim, aaee is markw
19:01:33 [Zakim]
+markw; got it
19:01:39 [Zakim]
+ +
19:01:44 [Zakim]
+ +1.202.470.aahh
19:02:40 [rsleevi]
rsleevi has joined #crypto
19:02:51 [Zakim]
+ +1.510.387.aaii
19:02:53 [hhalpin]
Zakim, aaff is wtc
19:02:53 [Zakim]
+wtc; got it
19:02:57 [virginie_galindo]
aagg is virginie_galindo
19:02:59 [hhalpin]
Zakim, aaff has rsleevi
19:02:59 [Zakim]
sorry, hhalpin, I do not recognize a party named 'aaff'
19:03:05 [hhalpin]
Zakim, wtc has rsleevi
19:03:05 [Zakim]
+rsleevi; got it
19:03:14 [hhalpin]
Zakim, who's on the phone?
19:03:15 [Zakim]
On the phone I see drogersuk, +1.773.939.aaaa, hhalpin, emily, [Microsoft], +1.978.936.aacc, +1.978.652.aadd, markw, wtc, +, +1.202.470.aahh, +1.510.387.aaii
19:03:15 [Zakim]
wtc has rsleevi
19:03:34 [Zakim]
19:03:36 [hhalpin]
Zakim, aaaa is ddahl
19:03:36 [Zakim]
+ddahl; got it
19:03:39 [JimD]
Zakim, aadd is JimD
19:03:39 [Zakim]
+JimD; got it
19:03:45 [self-issued]
Mike Jones
19:03:46 [sdurbha]
sdurbha has joined #crypto
19:03:58 [hhalpin]
Zakim, aacc is PhilipG
19:03:58 [Zakim]
+PhilipG; got it
19:04:07 [hhalpin]
Zakim, is JimD
19:04:07 [Zakim]
I don't understand 'is JimD', hhalpin
19:04:17 [wtc]
wtc has joined #crypto
19:04:18 [hhalpin]
Zakim, aagg is virginie_galindo
19:04:18 [Zakim]
+virginie_galindo; got it
19:04:54 [hhalpin]
Zakim, aahh is JohnBradley
19:04:54 [Zakim]
+JohnBradley; got it
19:05:16 [hhalpin]
Zakim, aaii ChristopherKula
19:05:16 [Zakim]
I don't understand 'aaii ChristopherKula', hhalpin
19:05:20 [hhalpin]
Zakim, aaii is ChristopherKula
19:05:20 [Zakim]
+ChristopherKula; got it
19:05:47 [hhalpin]
19:05:55 [hhalpin]
Zakim, who's on the phone?
19:05:55 [Zakim]
On the phone I see drogersuk, ddahl, hhalpin, emily, [Microsoft], PhilipG, JimD, markw, wtc, virginie_galindo, JohnBradley, ChristopherKula, ??P18
19:05:57 [Zakim]
wtc has rsleevi
19:06:03 [emily]
virginie_galindo: role call of delegates
19:06:04 [christopherkula]
christopherkula has joined #crypto
19:06:12 [virginie_galindo]
virginie_galindo has joined #crypto
19:06:26 [Zakim]
19:06:37 [hhalpin]
Zakim, who's on the phone?
19:06:37 [Zakim]
On the phone I see drogersuk, ddahl, hhalpin, emily, [Microsoft], PhilipG, JimD, markw, wtc, JohnBradley, ChristopherKula, ??P18
19:06:39 [Zakim]
wtc has rsleevi
19:06:59 [Zakim]
19:07:01 [sdurbha]
I guess ??P18 is me, sdurbha
19:07:05 [Zakim]
19:08:26 [Zakim]
+ +
19:08:35 [hhalpin]
Zakim, [Microsoft] has self-issued
19:08:35 [Zakim]
+self-issued; got it
19:09:23 [saerd]
saerd has joined #crypto
19:10:27 [emily]
virginie_galindo: several new participants this week from Microsoft, Red Hat, David Rogers
19:12:53 [emily]
virginie_galindo: any other topics to discuss besides what's on the agenda?
19:13:04 [hhalpin]
Zakim, next agendum
19:13:04 [Zakim]
agendum 1. "Welcome" taken up [from virginie_galindo]
19:13:43 [emily]
virginie_galindo: hhalpin, do we need a resolution to approve previous minutes?
19:13:51 [hhalpin]
PROPOSAL: We approve the minutes of the last call as correct
19:14:30 [hhalpin]
APPROVED: last week's minutes are correct
19:14:42 [hhalpin]
Zakim, next agendum
19:14:42 [Zakim]
agendum 2. "use cases update on wiki" taken up [from virginie_galindo]
19:14:46 [hhalpin]
topic: use-cases
19:15:23 [emily]
virignie_galindo: people felt that there was a lack of use cases, so use cases have been enriched
19:15:39 [emily]
... contributions from groups for identity and crypto
19:15:48 [virginie_galindo]
19:17:07 [emily]
virginie_galindo: use cases separate primary and secondary features, use cases collected from survey participants
19:17:47 [emily]
... if you didn't have time to look at use cases, have a look and propose suggestions, improvements, new use cases
19:17:55 [emily]
... still under construction
19:18:09 [emily]
... any questions on use cases?
19:18:44 [hhalpin]
Zakim, next agendum
19:18:44 [Zakim]
agendum 3. "Editors draft API (no change)" taken up [from virginie_galindo]
19:18:48 [hhalpin]
topic: Editors Draft API
19:19:13 [jbradley]
jbradley has joined #crypto
19:19:18 [emily]
ddahl: things are under construction in github repo
19:19:59 [emily]
ddahl: trying to design what a key id, public key might look like
19:20:03 [virginie_galindo]
Zakim, next agendum
19:20:03 [Zakim]
agendum 4. "garage under github" taken up [from virginie_galindo]
19:20:15 [emily]
... ArrayBuffer might hold data that translates into JWK object
19:20:19 [ddahl]
19:20:49 [emily]
... still discussing what this will look like
19:21:18 [emily]
... questions inline on the github page, would be nice to figure out issues right in that repo
19:21:26 [emily]
... but either that or email is fine
19:22:01 [emily]
... also trying to nail down algorithm discovery
19:22:20 [virginie_galindo]
19:22:23 [emily]
??: algorithm discovery or key discovery?
19:22:35 [emily]
ddahl: algorithm discovery, discovering what algorithms supported by api or implementation
19:22:55 [emily]
??: smartcards mean algorithm list could possibly change, might want notification on algorithm change
19:23:08 [emily]
... algorithms are tied to module, sub-component, that can come and go which could make it messy
19:23:14 [emily]
19:23:16 [hhalpin]
19:23:27 [Zakim]
19:23:42 [rsleevi]
19:23:54 [zooko]
zooko has joined #crypto
19:23:56 [drogersuk]
(not me speaking)
19:23:59 [hhalpin]
19:24:10 [zooko]
Hello folks! Sorry I'm late. Going to call in now.
19:24:13 [Zakim]
19:24:15 [emily]
PhilipG: smart card might support some flavor of ECC that the browser does not
19:24:41 [emily]
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?
19:25:01 [emily]
PhilipG: can't export key from smart card, so operations have to be done on card
19:25:16 [emily]
JimD: smart card has to be available for algorithm list, since can't retrieve the key
19:25:41 [emily]
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
19:25:42 [Zakim]
+ +1.902.444.aakk
19:25:44 [virginie_galindo]
19:25:58 [zooko]
Zakim: +1.902.44.aakk is me.
19:26:39 [emily]
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
19:27:20 [emily]
... 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
19:27:38 [emily]
... so algorithm discovery still applies even with smart cards out of conversation
19:28:58 [emily]
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
19:29:31 [emily]
... standardize core operations that we hope will perform across all browsers, and should move forward on this
19:30:00 [emily]
virginie_galindo: operation that happens in smart card will have to be discovered
19:30:16 [hhalpin]
just pointing out discovery can happen without smartcards
19:30:22 [hhalpin]
but that this is a somewhat hard problem
19:30:31 [rsleevi]
19:30:35 [hhalpin]
and thus, maybe try to move forward on rsleevi's low level proposal
19:30:37 [hhalpin]
q- hhalpin
19:30:41 [emily]
ddahl: could have an event, not sure yet
19:31:27 [virginie_galindo]
q- virginie_galindo
19:31:28 [emily]
rsleevi: for discovery, there are two types (could I ever possibly support X, and could I support X with this type of key)
19:31:40 [emily]
... do these two types meet needs, or are there other types needed?
19:32:03 [rsleevi]
q- rsleevi
19:32:21 [zooko]
I either need to think about it or I am happy with your proposal.
19:32:40 [hhalpin]
multiple keystores are in secondary features BTW :)
19:32:46 [emily]
jbradley: the real issue is whether keystores can by dynamically added and removed
19:33:01 [rsleevi]
jbradley: The KeyQueryList might be able to accomplish this
19:33:18 [emily]
... there may be times when dynamic keystores may affect discovery results, since you would have different keys
19:34:32 [drogersuk]
19:34:36 [emily]
jbradley: should try and differentiate between smart cards (where processing happens on card), or just plain keystores
19:34:56 [emily]
drogersuk: how reliable do we expect information to be?
19:35:36 [emily]
drogersuk: theoretically, could maybe execute attack on false discovery information, data is not assured
19:36:18 [emily]
virginie_galindo: we know that security's not perfect, so we have to make some assumption about how far we trust the platform
19:36:35 [emily]
... here it's up to the browser makers to tell us if the answer is something we can trust or not
19:36:36 [zooko]
19:36:40 [drogersuk]
19:37:11 [rsleevi]
19:37:32 [hhalpin]
19:37:33 [hhalpin]
19:37:37 [hhalpin]
q- q+
19:37:40 [emily]
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
19:37:53 [hhalpin]
q- zooko
19:38:49 [ddahl]
rsleevi ++
19:38:56 [emily]
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
19:39:07 [emily]
... that's one possibility that could maybe improve trustworthiness of API
19:39:36 [emily]
... ddahl raised point about trying to make weak security hard to use. still trying to figure out what csp can bring
19:39:46 [rsleevi]
19:40:06 [ddahl]
19:40:54 [emily]
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
19:41:18 [emily]
virginie_galindo: we've been discussing about key discovery, so you are suggesting that dynamic keystores might be secondary features?
19:41:53 [emily]
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
19:42:34 [emily]
... or if someone has a very concrete suggestion about exactly how discovery would work that would satisfy smartcard use cases, that would be good
19:43:40 [rsleevi]
hhalpin: I think the KeyQueryList might be a concrete solution that we can use as a strawman
19:44:20 [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.
19:44:46 [hhalpin]
Agreed, I don't see why in principle why that wouldn't work over smartcards, but I'm not a smartcard expert
19:45:18 [ddahl]
19:45:18 [emily]
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
19:45:25 [zooko]
ddahl: good point!
19:45:27 [hhalpin]
19:45:33 [ddahl]
zooko: thx:)
19:46:10 [hhalpin]
If the editors feel the KeyQueryList is good enough, they can add that to the Editors Draft
19:46:50 [emily]
virginie_galindo: coming back to how keys should be identified, key lifetime, so I'll summarize this discussion
19:47:03 [emily]
... group agreed that keys should be created with associated algorithms
19:47:14 [emily]
... discussion about whether key should be ephemeral or persistent
19:47:26 [emily]
... discussion about whether key will be extractable or not, the group decided that it will be both
19:47:41 [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.
19:48:53 [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.
19:49:11 [emily]
... extractable or not, can be used one or several services, ephemeral or persistent
19:49:35 [emily]
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
19:49:50 [emily]
... as an optional argument. Default maybe would be that private key is not accessible to content
19:50:00 [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.
19:50:04 [emily]
... again, still a lot of details to work out. What's in github is not quite the latest thinking
19:50:04 [virginie_galindo]
... a key is -Shaped for a specific usage (algo, padding, …)
19:50:10 [zooko]
That sounds good to me. It would satisfy my desires, and seems good for the other kind of use case as well.
19:50:39 [emily]
virginie_galindo: any questions on key identification, etc.?
19:50:40 [rsleevi]
ddahl: That is in line with what I was thinking, and I think covers most use cases
19:51:10 [ddahl]
rsleevi: thanks for sending that proposal!
19:51:11 [emily]
virginie_galindo: very recent mail from Ryan proposes low-level API
19:51:50 [emily]
rsleevi: KeyQueryList needs to be revisited. Low-level API assumes you have a key, doesn't cover derivation or generation
19:51:56 [emily]
... yet
19:52:05 [virginie_galindo]
... a key has a Lifetime stamped – ephemeral or persistent, not sure it leads to a specific property
19:52:26 [Zakim]
19:52:31 [virginie_galindo]
... a key is Extractable or not (to be exchanged with external world, or manipulated directly and only by webapp)
19:52:44 [emily]
... One of the design goals is keeping API names meaningful but short, since they can't be minified or compressed
19:53:04 [virginie_galindo]
...... a key is Named uniquely (by service provider scheme, by browser scheme)
19:53:09 [emily]
... Interface sees commonality between digesting, MACing, sigs, verification, enc/decryption, modeled after File API
19:53:24 [emily]
... messaging, file transfer, exchanges should be supported
19:53:25 [Zakim]
19:53:48 [virginie_galindo]
... a key is Reusable or not by other service (linked with same-origin, or multiple origin)
19:53:52 [zooko]
That sort of streamy common interface is used in the Crypto++ library, for what it is worth.
19:54:11 [hhalpin]
19:54:18 [virginie_galindo]
... a key is Invoked (by properties, by name, by usage, …)
19:54:29 [emily]
rsleevi: not sure whether to proceed with discussion via email or github, or w3c mercurial, whatever chairs/editors feel is best
19:55:20 [JimD]
JimD has joined #crypto
19:55:23 [emily]
hhalpin: editors ultimately decide what goes in w3c space
19:55:32 [emily]
... beneficial to publish quick and early with open issues list
19:56:33 [virginie_galindo]
19:56:38 [wtc]
hhalpin: your proposal sounds good to me.
19:56:39 [hhalpin]
q- hhalpin
19:56:59 [emily]
virginie_galindo: summary of what I feel our API should contain
19:57:11 [emily]
... should draft the way we use keys
19:57:15 [emily]
... should have discovery mechanism
19:57:24 [emily]
... should have the way that keys are named/identifier
19:57:27 [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 space next week for draft approval in July.
19:57:41 [wtc]
19:57:48 [virginie_galindo]
19:57:53 [emily]
wtc: the next big missing piece is key management
19:57:57 [markw]
19:58:05 [emily]
... personally think discovery mechanism is not as important
19:58:17 [emily]
... developers will quickly figure out what commonly supported algorithms are
19:58:35 [self-issued]
Mike Jones / Microsoft signing off - I have another commitment at the top of the hour.
19:58:41 [emily]
wtc: key management means the operations that actually produce key handles (generate, derive, find, delete keys)
19:58:42 [Zakim]
19:59:03 [Zakim]
- +
19:59:37 [emily]
virginie_galindo: its up to us to decide what goes in public draft
19:59:39 [rsleevi]
markw: Is the Editors Draft going to reflect rsleevi's proposal, ddahl's github work, or something else?
19:59:45 [emily]
markw: closing all open issues in the next week is ambitious
19:59:51 [hhalpin]
20:00:01 [hhalpin]
I am stating we publish *with* open issues.
20:00:09 [hhalpin]
We do not have to resolve all open issues
20:00:35 [ddahl]
hhalpin ++
20:00:41 [wtc]
20:00:47 [emily]
virginie_galindo: a lot of issues will probably be resolved at f2f meeting
20:01:07 [markw]
20:01:21 [emily]
hhalpin: just to clarify, it's completely fine to have open issues in working draft
20:01:27 [emily]
... often advantageous to do so
20:02:03 [emily]
usually, first public working draft is some sort of strawman, fairly comprehensive exploration of options in the design space
20:02:57 [abstractj]
abstractj has joined #crypto
20:03:00 [Zakim]
20:03:04 [hhalpin]
I'd suggest everyone look closely at rsleevi's proposal closely over the next week!
20:03:24 [emily]
virginie_galindo: everyone should look at Ryan's proposal and ddahl's github
20:04:39 [emily]
... 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
20:05:06 [emily]
... I reported what we were doing and that we care about privacy, and how we can improve privacy
20:05:35 [emily]
... anyone who feels we should speak more with IETF, should tell us
20:05:41 [hhalpin]
I suggest folks join the WebSec IETF mailing list
20:06:06 [hhalpin]
20:06:14 [hhalpin]
Is a good list for co-ordination with the IETF
20:06:37 [emily]
virginie_galindo: f2f meeting is at end of July
20:06:59 [emily]
... 18 votes, mountain view is winner
20:07:31 [emily]
... any comment, july 24-25th in mountain view?
20:08:19 [emily]
... Another f2f in october or november, where we'll work on comments from public.
20:08:39 [emily]
... if you're planning to attend f2f in july, tell ddahl (who is organizing it) that you're attending
20:08:45 [emily]
ddahl: meeting at mozilla office, more details to come
20:09:22 [hhalpin]
RESOLUTION: Informal f2f July24-25th Mountain View
20:09:41 [hhalpin]
20:09:47 [emily]
virginie_galindo: no call next week, next meeting in 2 weeks
20:09:51 [emily]
... end of June
20:10:16 [emily]
hhalpin: if people are interested, editors could use that time to go over bureaucracy of w3c publishing
20:10:37 [virginie_galindo]
next meeting will be on 2nd of july
20:11:07 [hhalpin]
No, informal meeting
20:11:42 [hhalpin]
RRSAgent, generate minutes
20:11:42 [RRSAgent]
I have made the request to generate hhalpin
20:11:51 [zooko]
Buye folks!
20:11:57 [hhalpin]
Thanks everyone!
20:11:59 [hooley]
hooley has left #crypto
20:59:06 [tl1]
tl1 has joined #crypto
21:18:20 [tl]
tl has joined #crypto
23:17:11 [ddahl]
ddahl has joined #crypto