IRC log of crypto on 2012-08-20

Timestamps are in UTC.

18:55:23 [RRSAgent]
RRSAgent has joined #crypto
18:55:23 [RRSAgent]
logging to
18:55:28 [asad]
asad has joined #crypto
18:56:46 [Zakim]
+ +1.410.290.aabb
18:57:08 [rbarnes]
rbarnes has joined #crypto
18:57:09 [virginie]
zakim, this will be webcrypto
18:57:09 [Zakim]
I do not see a conference matching that name scheduled within the next hour, virginie
18:57:37 [emily]
emily has joined #crypto
18:58:07 [saerd]
saerd has joined #crypto
18:58:43 [virginie]
zakim, this will be webcrypt
18:58:43 [Zakim]
I do not see a conference matching that name scheduled within the next hour, virginie
18:59:24 [virginie]
zakim, this will be sec_webcrypt
18:59:24 [Zakim]
I do not see a conference matching that name scheduled within the next hour, virginie
19:00:02 [ddahl]
virginie: i see that it was started by Zakim
19:01:10 [rbarnes]
i'm on the phone
19:01:21 [ddahl]
virginie: ddahl is on the phone
19:01:59 [virginie]
agenda ?
19:02:09 [emily]
zakim, who is on the phone?
19:02:09 [Zakim]
I notice SEC_WebCryp()3:00PM has restarted
19:02:10 [Zakim]
On the phone I see +1.512.257.aaaa, +1.410.290.aabb, ddahl, emily, virginie, Google, saerd, [Microsoft]
19:02:14 [markw]
markw has joined #crypto
19:02:18 [vgb]
vgb has joined #crypto
19:02:22 [Zakim]
19:02:26 [Zakim]
19:02:31 [rbarnes]
zakim: i am aabb
19:02:36 [rsleevi]
rsleevi has joined #crypto
19:02:41 [rsleevi]
Zakim, who is on the line?
19:02:41 [Zakim]
I don't understand your question, rsleevi.
19:02:43 [vgb]
Zakim, I am [Microsoft.a]
19:02:43 [Zakim]
ok, vgb, I now associate you with [Microsoft.a]
19:02:44 [rbarnes]
don't think that worked
19:02:46 [asad]
+1.512.257.aaaa is asad
19:02:53 [Zakim]
19:02:59 [selfissued]
selfissued has joined #crypto
19:03:12 [markw]
Zakim, Netflix has markw
19:03:12 [Zakim]
+markw; got it
19:03:16 [rbarnes]
zakim, i am +1.410.290.aabb
19:03:16 [Zakim]
+rbarnes; got it
19:03:18 [selfissued]
selfissued is Mike Jones
19:03:25 [vgb]
Zakim, who's here?
19:03:25 [Zakim]
On the phone I see +1.512.257.aaaa, rbarnes, ddahl, emily, virginie, Google, saerd, [Microsoft], [Microsoft.a], JimD, Netflix
19:03:27 [Zakim]
Netflix has markw
19:03:27 [Zakim]
On IRC I see selfissued, rsleevi, vgb, markw, saerd, emily, rbarnes, asad, RRSAgent, virginie, hhalpin, JimD, ddahl, timeless, tl, Zakim, trackbot, wseltzer_away
19:03:30 [wtc]
wtc has joined #crypto
19:04:03 [arunranga]
arunranga has joined #crypto
19:04:08 [hhalpin]
Zakim, what's the code?
19:04:08 [Zakim]
the conference code is 27978 (tel:+1.617.761.6200, hhalpin
19:04:31 [Zakim]
19:04:37 [hhalpin]
Zakim, ??P18 is hhalpin
19:04:37 [Zakim]
+hhalpin; got it
19:04:55 [timeless]
RRSAgent, draft minutes
19:04:55 [RRSAgent]
I have made the request to generate timeless
19:05:26 [timeless]
s/zakim: i am aabb//
19:05:39 [Zakim]
19:05:57 [ddahl]
scribe: ddahl
19:06:09 [hhalpin]
PROPOSAL: is the correct minutes
19:06:12 [ddahl]
hhalpin: is that the right command?
19:06:23 [JimD]
I believe they are public
19:06:29 [hhalpin]
they become public as soon as meeting is over
19:06:35 [hhalpin]
see web-page for records of previous meetings
19:07:05 [hhalpin]
ACCEPT: is the correct minutes
19:07:22 [ddahl]
virginie: Begin with presentation of the draft API
19:07:29 [hhalpin]
not really, but it won't take into account any minor errors we tend to make and fix with s. If you really want to watch the minutes live, go for it.
19:07:58 [ddahl]
rsleevi: A lot of the changes were in wordsmithing, still a lot of boilerplate to fill in
19:07:59 [virginie]
19:08:00 [hhalpin]
topic: Presentation of new Web Crypto API update from editors
19:08:10 [hhalpin]
scribenick: ddahl
19:08:53 [virginie]
19:09:06 [zooko]
zooko has joined #crypto
19:09:08 [ddahl]
rsleevi: tried to describe how this api would work in a PKCS#1 mode
19:09:11 [timeless]
RRSAgent, make logs public
19:09:14 [Zakim]
19:09:38 [timeless]
RRSAgent, draft minutes
19:09:38 [RRSAgent]
I have made the request to generate timeless
19:09:46 [ddahl]
... wanted to point out the importance of the keyStorage interface
19:09:53 [asad]
zakim, i am +1.512.257.aaaa
19:09:53 [Zakim]
+asad; got it
19:10:18 [ddahl]
rsleevi: types of keys and what origins authorize them
19:10:36 [timeless]
s/+1.512.257.aaaa is asad//
19:10:53 [timeless]
s/I believe they are public//
19:10:57 [timeless]
s/they become public as soon as meeting is over//
19:10:59 [rbarnes]
19:11:01 [cjkula]
cjkula has joined #crypto
19:11:03 [timeless]
s/see web-page for records of previous meetings//
19:11:08 [ddahl]
... the key interface is mainly describing the metadata around the keys themselves not how it is initialized etc
19:11:13 [timeless]
s/not really, but it won't take into account any minor errors we tend to make and fix with s. If you really want to watch the minutes live, go for it.//
19:11:30 [ddahl]
... spec'd diffie hellmen, but not ECC
19:11:46 [rbarnes]
19:11:55 [Zakim]
19:12:18 [ddahl]
... if implementors have a preferred format for additional key types, feedback is very welcome based on the template provided in the spec
19:12:45 [ddahl]
... key import was also tackled here, thanks to vgb for his notes in the mailing list
19:13:39 [rsleevi]
for (i = 0; i < window.crypto.keys.length; ++i) { window.crypto.keys[i]; }
19:13:41 [asad]
19:13:43 [markw]
19:13:47 [ddahl]
rbarnes: key storage stuff looks good, is there a richer way to label the keys? metadata- > name, etc?
19:14:39 [ddahl]
rsleevi: perhaps raise an issue on this - numeric getters and symbolic names are used in localStorage, perhaps we do the same?
19:14:57 [Zakim]
+ +1.303.661.aacc
19:15:13 [rsleevi]
19:15:15 [vgb]
19:15:22 [sdurbha]
sdurbha has joined #crypto
19:15:36 [ddahl]
rbarnes: meta question: can I refer to a key in a persistent way? not clear if these indexes are persistent?
19:15:55 [ddahl]
rsleevi: key object has a keyID and this is fully persistent
19:16:30 [vgb]
19:16:33 [ddahl]
... symbolic name vs numeric index? does this matter?
19:16:50 [rsleevi]
19:17:11 [ddahl]
virginie: did you specify the persistence of each key?
19:17:23 [ddahl]
rsleevi: still need to do that - add language to clarify
19:17:36 [selfissued]
19:17:49 [rsleevi]
ACTION: sleevi to add explicit language to clarify that Key object attributes are persistent to keys. the is consistent between browsing contexts
19:17:49 [trackbot]
Created ACTION-34 - Add explicit language to clarify that Key object attributes are persistent to keys. the is consistent between browsing contexts [on Ryan Sleevi - due 2012-08-27].
19:17:54 [ddahl]
asad: followup: can we indicate a source once we have the key ID?
19:18:21 [ddahl]
... certain operations would be tied to a specific provider
19:18:49 [ddahl]
... is the binding of the key ID to the corresponding source known to the web app?
19:19:16 [ddahl]
rsleevi: if an implementation is going to expose providers, it is an implementation detail
19:19:38 [hhalpin]
i.e. "custom attribute"
19:20:21 [ddahl]
asad: if a user selects a key, it is up to the browser to make sure the operations are executed within the specific source?
19:20:59 [ddahl]
rsleevi: yes, but there will be additional discussions on this - [reference to a recently closed issue]
19:21:04 [virginie]
19:21:16 [virginie]
ack asad
19:21:22 [ddahl]
... this provider issue is in the secondary use cases
19:22:01 [ddahl]
markw: where would we put the global Id for a pre-provisioned sym key?
19:22:59 [ddahl]
rsleevi: there should be some kind of foreknowledge of the key's meta data that might be stored in localStorage, etc
19:23:08 [ddahl]
... need to raise an issue here
19:23:40 [ddahl]
markw: do we need a couple of key IDs to help locate symmetric keys?
19:23:57 [ddahl]
... one global and one in the origin
19:24:52 [ddahl]
rsleevi: pre-provisioned attrs should help here
19:25:45 [rsleevi]
ddahl: The (closed) query issue was ACTION-16
19:26:24 [ddahl]
markw: most of the attributes are user attributes seem to carry less weight than needed for unique IDs for symmetric keys
19:26:58 [ddahl]
(ddahl note: that last bit was hard to scribe)
19:27:17 [ddahl]
__markw: was that accurate?
19:27:56 [virginie]
19:28:05 [ddahl]
rsleevi: there have been a few actions that did not have a wide consensus before closing them
19:28:12 [virginie]
ack markw
19:28:30 [ddahl]
markw: the GUID for sym keys issue needs more discussion
19:29:11 [hhalpin]
either way of dealing with it is actually fine!
19:29:16 [hhalpin]
perhaps its more of an open ISSUE
19:29:19 [hhalpin]
than an action.
19:29:28 [hhalpin]
19:29:31 [hhalpin]
19:29:38 [ddahl]
virginie: action 16 was closed, but probably needs postponement instead
19:30:02 [markw]
just to be clear, a globally unique identifier for pre-provisioned symmetric keys needs more discussion (it's been suggested that the id field on the key - which is a local identifier - might actually be a GUID)
19:30:14 [ddahl]
rsleevi: need to build better consensus on mailing list
19:30:55 [ddahl]
selfissued: Need to touch on the relationship between JOSE and W3 web crypto - and how we will use JOSE
19:31:00 [rsleevi]
19:31:25 [ddahl]
selfissued: need to have new paragraph on this topic in the spec
19:31:37 [ddahl]
virginie: there is something in the draft
19:31:43 [ddahl]
... to that effect
19:32:12 [ddahl]
hhalpin: if someone has taken an action and cannot fullfil it - we need to open an issue to help keep track of it
19:32:25 [rsleevi] / ISSUE-17 is tracking the discussion on attributes
19:32:31 [ddahl]
... or if consuensus cannot be reached
19:33:08 [markw]
19:33:17 [ddahl]
hhalpin: JOSE was only being referenced in key import/export
19:33:21 [virginie]
ack selfissued
19:33:35 [hhalpin]
ack hhalpin
19:34:02 [ddahl]
... we are working on a lower-level API that may not support JOSE directly, however, later a high-level design may better support JOSE directly
19:34:28 [ddahl]
selfissued: are you looking to get these new JOSE formats created?
19:34:53 [rsleevi]
19:34:59 [ddahl]
hhalpin: does the working group feel that it is something to discuss now
19:35:03 [ddahl]
19:35:44 [ddahl]
selfissued: we need to understand the use cases to make sure it makes sense to support JOSE, some use cases seem to exists just to support JOSE
19:35:58 [rsleevi]
q+ to respond about JOSE
19:36:11 [ddahl]
virginie: if we ask JOSE for new formats - private keys, etc, how long will it take to spec?
19:36:42 [ddahl]
selfissued: we could have a draft in weeks, making it part of the spec may not happen until IETF ATL in 3 months
19:36:48 [arunranga]
I don't think we need a "spec benediction" to start using it.
19:36:50 [hhalpin]
I think the use-case is "key import/export" in the secondary features of the charter,
19:37:14 [hhalpin]
We have about a year to reach total stability on our spec, so timing should be relatively easy here
19:37:57 [rsleevi]
virginie: There's an ISSUE ;)
19:38:00 [ddahl]
markw: unique ID thing is functional and may need a separate issue
19:38:11 [virginie]
19:38:12 [ddahl]
virginie: let it be so!
19:38:23 [virginie]
ack markw
19:38:45 [ddahl]
rsleevi: importing og JWK public keys seems like a very useful thing
19:39:20 [ddahl]
... exporting private keys may require some custom operations with polyfills etc in mind
19:39:38 [ddahl]
... exposing this kind of thing for RSA with OEAP will be tricky
19:39:58 [ddahl]
... is there a WEBIDL or JWK format that will allow this
19:40:01 [ddahl]
19:40:42 [ddahl]
... we could create a WebIDL for this operation
19:41:16 [ddahl]
selfissued: we should see if we can get IETF to also spec this format
19:41:38 [rsleevi]
ack rsleevi
19:41:38 [Zakim]
rsleevi, you wanted to respond about JOSE
19:41:45 [ddahl]
rsleevi: the overhead of ASN.1 parser is part of this ongoing issue
19:41:53 [markw]
19:42:11 [ddahl]
markw: want to understand how the DH will work?
19:42:22 [rsleevi]
19:42:36 [ddahl]
... 2 operations, KeyGen and KD - do you use the KD to derive the key?
19:43:38 [ddahl]
rsleevi: yes, 3 phases, 1. key gen, export key so we can get either side of key, then KD operation. Phase 2: derive shared secret
19:43:53 [ddahl]
... can an application polyfill? maybe, or we should specify this
19:43:55 [virginie]
19:44:07 [virginie]
ack markw
19:44:15 [ddahl]
markw: we might have a generic key exchange API that makes the algorithm an argument
19:44:29 [ddahl]
rsleevi: strong case to keep this operations spearate
19:45:05 [ddahl]
rsleevi: fairly common to separate these ops in most crypto APIs
19:45:20 [ddahl]
markw: would like to have less specific key exchange API
19:45:29 [ddahl]
... less specific to alg
19:46:06 [ddahl]
rsleevi: where do we draw the boundry between low and high level apis
19:46:30 [ddahl]
... looking for input for the preferred form here
19:46:59 [hhalpin]
+1 re slipperly slope, we do have time limits!
19:46:59 [ddahl]
virginie: markw: can you provide an example here?
19:47:06 [ddahl]
markw: yes
19:48:04 [ddahl]
virginie: we have some issues in the draft that do not appear in our issue tracker, should we add them?
19:48:23 [ddahl]
rsleevi: yes, the intent was to get more input from WG members
19:48:36 [ddahl]
rsleevi: we will convert them all over to real issues
19:49:37 [ddahl]
virginie: there is still some heavy debate on the mailing list on various issues
19:50:01 [ddahl]
vgb: the import export has made it into the draft, still need more feedback
19:50:15 [virginie]
19:50:21 [ddahl]
virginie: we should cover the open actions
19:51:22 [hhalpin]
ACTION-13 WTC and Arun to add missing use-cases [CONTINUES]
19:51:58 [hhalpin]
ACTION-17 Review key generation and propose a way for user agents to expose unique IDs as first class [CONTINUES]
19:52:10 [hhalpin]
19:52:12 [ddahl]
rsleevi: need to clarify action ?? to help with the understanding of issue 34
19:52:40 [ddahl]
virginie: getRandomValues issue needs clarification
19:53:01 [hhalpin]
ACTION-23: wseltzer return with report on XMLSec PAG [CONTINUES]
19:53:01 [trackbot]
ACTION-23 Find out status of getrandom in HTML5 notes added
19:53:04 [ddahl]
wtc: discussed this with ifette, just copied this from the whatwg site
19:54:13 [ddahl]
hhalpin: unclear to me about each implementation
19:54:23 [ddahl]
wtc: implemented in Chrome and Firefox
19:54:43 [ddahl]
hhalpin: will the IE team be interested in implementing it
19:55:34 [ddahl]
NOTE: the Firefox implementation is not landed in Firefox nightly yet, waiting on some DOM hackers to look at it. it is implemented in patches:)
19:56:01 [ddahl]
vgb: IE team COULD easily implement this, however I do not speak for them:)
19:56:30 [ddahl]
hhalpin: changes to the verbiage to make it more clear how this ended up in the spec
19:56:36 [ddahl]
wtc: i can clarify this
19:56:53 [rsleevi] - current text
19:57:07 [ddahl]
virginie: need commentary on the current draft from WG members
19:57:22 [hhalpin]
ACTION: hhalpin to talk to adrian bateman re IE implementation of getRandomValues
19:57:22 [trackbot]
Created ACTION-35 - Talk to adrian bateman re IE implementation of getRandomValues [on Harry Halpin - due 2012-08-27].
19:57:23 [rsleevi]
+1 to proposals, and not just issues ;)
19:57:24 [ddahl]
... comments plus proposal are needed
19:57:29 [asad]
19:57:30 [ddahl]
19:57:31 [emily]
19:57:32 [virginie]
19:57:32 [hhalpin]
19:57:35 [arunranga]
19:57:35 [rbarnes]
19:57:38 [cjkula]
19:57:38 [vgb]
19:57:41 [wtc]
19:57:45 [sdurbha]
19:57:47 [JimD]
+1 but we may need to comment on comments as well
19:58:15 [ddahl]
virginie: need to go find the participants we may not have heard from to get feedback from them
19:58:18 [arunranga]
Notes that the synchronous question is an important one which we didn't really discuss.
19:58:40 [hhalpin]
thus the editors get a well-deserved vacation!
19:58:47 [ddahl]
arunranga: i think the synch version should follow other existing DOM apis that do this
19:58:50 [hhalpin]
as people get a week for comments
19:59:07 [ddahl]
virginie: try to get as much feedback in by this Friday
19:59:31 [hhalpin]
19:59:32 [markw]
19:59:41 [virginie]
ack virginie
20:00:14 [ddahl]
rsleevi: some specs are barebones, some are fully spec'd with implementations, we have a number of open issues and actions yet, how far do we wnat to go before we feel like we have a publishable spec?
20:00:30 [ddahl]
virginie: we can have many open issue before we publish FPWD
20:01:14 [hhalpin]
ack hhalpin
20:02:05 [ddahl]
hhalpin: some APIs just document what browsers already do, the nature of this API does want each issue to be well-documented
20:02:23 [ddahl]
... current draft is in good shape
20:02:55 [ddahl]
markw: before FPWD we need each functional piece documented in the spec or in an open issue
20:03:20 [ddahl]
markw: the identity piece is not well defined
20:03:21 [hhalpin]
20:03:34 [hhalpin]
ack hhalpin
20:03:41 [ddahl]
virginie: propose comments until next monday instead
20:04:26 [ddahl]
rsleevi: comments may just be "here is an issue..."
20:04:29 [hhalpin]
please send *exact* text if possible to the editors on the mailing list!
20:05:26 [ddahl]
rsleevi: please propose text and raise issues, but at least raise issues
20:05:48 [zooko]
20:05:51 [Zakim]
20:05:52 [Zakim]
20:05:52 [Zakim]
20:05:53 [Zakim]
20:05:53 [Zakim]
20:05:54 [Zakim]
- +1.303.661.aacc
20:05:54 [Zakim]
20:05:56 [Zakim]
20:05:57 [ddahl]
virginie: meeting over amd thanks ryan!
20:05:58 [Zakim]
20:06:00 [Zakim]
20:06:02 [Zakim]
20:06:04 [Zakim]
20:06:07 [Zakim]
20:06:08 [Zakim]
20:06:10 [Zakim]
20:07:40 [virginie]
zakim, bye
20:07:40 [Zakim]
leaving. As of this point the attendees were +1.512.257.aaaa, +1.410.290.aabb, saerd, ddahl, emily, virginie, Google, [Microsoft], JimD, markw, rbarnes, hhalpin, arunranga, zooko,
20:07:40 [Zakim]
Zakim has left #crypto
20:07:43 [Zakim]
... asad, cjkula, +1.303.661.aacc
20:08:29 [virginie]
rrsagent, draft minutes
20:08:29 [RRSAgent]
I have made the request to generate virginie
20:08:55 [virginie]
rrsagent, make log public
20:09:13 [zooko]
Hm, who is 303.661?
20:09:18 [zooko]
Because that's also my area code. ☺
20:09:49 [virginie]
rrsagent, byerrsagent, bye
20:09:49 [RRSAgent]
I see 2 open action items saved in :
20:09:49 [RRSAgent]
ACTION: sleevi to add explicit language to clarify that Key object attributes are persistent to keys. the is consistent between browsing contexts [1]
20:09:49 [RRSAgent]
recorded in
20:09:49 [RRSAgent]
ACTION: hhalpin to talk to adrian bateman re IE implementation of getRandomValues [2]
20:09:49 [RRSAgent]
recorded in