<virginie> hi mountie, welcome in the Web crypto WG, the call will start in 8 minutes

<trackbot> Date: 13 August 2012

<JimD> Hmmm... need a new topic. Still saying "no call Monday"

<virginie> sure, need to revise my IRC/Zakim basics to do so...

<mountie> setname <Mountie Lee>

<JimD> ok?

<hhalpin> \me everyone dial back in

<wseltzer> virginie: Technology Nexus is an observer (not yet a member)

<hhalpin> if you need any help with membership or IE forms, ping me!

<hhalpin> no worries!

+1

<ddahl> +1

<mitchz> is there a scribe tutorial somewhere?

<hhalpin> https://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html

<JimD> and also http://www.w3.org/2008/04/scribe.html

<wseltzer> scribenick: vgb

[virginie] welcome Mountie!

scribe: Please review Editor's Draft and Harry's email regarding FPWD process

<mountie> Hi. I'm Mountie from KR

Action and Issue Review

scribe: actions review

<virginie> http://www.w3.org/2012/webcrypto/track/

<virginie> http://www.w3.org/2012/webcrypto/track/actions/open

scribe: lots of discussion on mailing list, let's go down the list of actions

<hhalpin> wtc And Arun to add missing use-cases

<hhalpin> I think wtc finished that

wtc: action 13 will need a bit more time, still working on it. the current version should meet minimum requirements though.

<hhalpin> wtc And Arun to add missing use-cases [CONTINUES]

wtc: will take another week's time

virginie: ok

arunranga: agree we need more time, but what Ryan put into the spec regarding support for the use cases may be seen as supplementing this work as well

<hhalpin> ACTION-14: Change naming scheme to use a "createX" approach rather than just "X"

<trackbot> ACTION-14 Change naming scheme to use a "createX" approach rather than just "X" notes added

rsleevi: regarding action 14 (renaming APIs to createX instead of X) haven't gotten to it yet

<hhalpin> ACTION-14: [CONTINUES]

<trackbot> ACTION-14 Change naming scheme to use a "createX" approach rather than just "X" notes added

rsleevi: maybe by next draft, probably will make proposals on mailing list

ddahl: action 15 will do something this week

<hhalpin> ACTION-15: [CONTINUES]

<trackbot> ACTION-15 Insert in "right place" a description of high-level example notes added

rsleevi: action 16 keyQueryList is not in the draft yet though it was discussed in email list a few weeks ago, will incorporate in next draft

<hhalpin> ACTION-16: [CONTINUES]

<trackbot> ACTION-16 Add the key query mechanism to editors draft, checking in with ddahl's edit notes added

mitchz: action 17 (key generation) depends on rsleevi finishing up other actions

<hhalpin> ACTION-17: [CONTINUES]

<trackbot> ACTION-17 Review key generation and propose a way for user agents to expose unique IDs as first class notes added

rsleevi: we should start a deeper discussion around key attributes in email
... first class attributes are exposed in WebIDL and second-class are those that are opaque to API

<mitchz> +1

<mountie> +1

rsleevi: question is whether unique ID or other attributes be first or second class?

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-KeyAttributes = "Second class"

<mitchz> -1

rsleevi: action 18 (key generation) ongoing regarding key gen algorithms - other issues like tainting have also come up

wseltzer: XMLsec PAG awaiting report publication
... ETA next week or so

virginie: action 20 strawman for testbed, any comments?

<rsleevi> +1 to Harry's text, with some slight editorial tweaks

hhalpin: sent out email - will not mandate any algorithms but will define testing for all algorithms

virginie: will close issue with this text unless objections

<hhalpin> ACTION-20: Pending Review for a week

<trackbot> ACTION-20 Write a straw-man proposal re: incorporating "recommended" table and description of test suite notes added

ddahl: action 21 did some research today and will do this week

<hhalpin> rsleevi, just take editorial license and do those tweaks!

vgb: action 22 sent out email today

hhalpin: action 23 getrandom status will do today

rsleevi: suggest sending email to HTML5 or WHAT WG

wtc: only problem w/ current spec is citing RC4 as example of strong PRNG

<hhalpin> removing RC4 in the example makes sense

wtc: just remove that and we're good
... action 24 will add subsection or note to section 12 on getrandomvalues

vgb: action 26 state of art on symmetric key properties will do this week

wtc: action 25 will be part of next draft

arunranga: action 27 add primary use cases - may need more time on this

<hhalpin> there is overlap here with wtc's action, so lets just remove this action

arunranga: will work with editors to add by next week's draft

hhalpin: could delete this as it may be a duplicate

wtc: think action 27 may have been resolved

<hhalpin> yep, rsleevi added use-cases to spec

virginie: action 28 signed code use case chris not on call

<mountie> signed JS code?

hhalpin: action 29 follow-up on tools talkde to other WGs and general feeling was that testharness.js was the way to go. Talked to cjkula and he seemed to volunteer for that.

rsleevi: no objections to using testharness

hhalpin: maybe a training session in a few weeks

<rsleevi> mountie: http://www.w3.org/2012/webcrypto/track/actions/28 / The proposal is to remove http://www.w3.org/2012/webcrypto/wiki/Use_Cases#Signed_web_applications

virginie: maybe in October?

hhalpin: definitely after FPWD

rsleevi: action 30 update draft based on issue 11 will be addressed in next draft

<hhalpin> yes, we should discuss the origin issue on this call

virginie: action 31 added today to clarify whether keys and attributes may be stored separately

rsleevi: maybe this should be an issue?
... i believe we have a consensus, but should put it to the group
... depends on whether we have a generic key-value store or something else

hhalpin: can test for consensus on calls if you like

<hhalpin> yes, its an ISSUE

virginie: will transform to issue, seems like rsleevi has a clear view

rsleevi: don't think attributes have to be stored
... in the same location as the keys

<rsleevi> +q

<hhalpin> vgb: there will always be times like smartcards

<hhalpin> ... where you can't just add arbitrary attributes

<hhalpin> ... maybe the difference is between secure and non-secure custom attributes

rsleevi: threw out a hypothetical strawman of a user with multiple browsers - maybe if both use OS key store the browsers should be able to share/agree on these

<hhalpin> +1 coupling them together, but not sure how

rsleevi: but in practice it may not be possible in all cases. Maybe browsers should make a best effort but it shouldn't be scoped or speced.

wtc: for example start and end date attributes are not supported natively by all underlying libraries, so we will have to do something specific to the platform and maybe different browsers will reach different solutions

markw: understand that we don't want to create new key-value stores, but we should still have room for attributes that are associated with the key but are not set by app

rsleevi: not proposing a both-and solution, proposing either-or
... if you want to pre-provision then you can also pre-provision an indexDB set of values
... if we use an existing key-value store then the key should not have its own attribute store

markw: asking about other specific things like whether the key is exportable

rsleevi: existing draft provides a model for the key object, and those are exposed. the other attributes not listed here may not be supported
... in a key store

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#key-interface

markw: things like GUID should be exposed as well?

virginie: will migrate this to issue and we'll check back in a week

<virginie> http://www.w3.org/2012/webcrypto/track/issues/raised

<rsleevi> @virginie: The issues I raised while editing are things I believe should be addressed post-FPWD, when we get feedback from the wider community

virginie: mandatory algs issue will be closed with text frmo harry

rsleevi: feel like we are drifting towards having a public key and private key object

virginie: should discuss on mailing list

rsleevi: issue 6 keyquerylist will discuss on email list and will incorporate in next draft

virginie: high level API will leave open
... no discussion on key neutering

rsleevi: arun raised some comments and discussion ongoing
... several issues here will remain in FPWD for wider community to comment on

vgb: issue 12 per-operation parameters sent out email

virginie: issue 13 lots of discussion and seems to be consensus on keeping JOSE as a higher-layer thing

hhalpin: sent email to JOSE WG and so we will use ASN.1 so the issue is closed

rsleevi: want to make sure we have consensus on both formats and algorithm IDs. Had the feeling that since we are headed to low-level it is not essential to expose JOSE IDs.

hhalpin: we are going to be more expressive than JOSE
... so we can't use the same format

rsleevi: somewhat contingent on issue 12

virginie: representation of raw key material there was some email - linked with issue 13

rsleevi: yes but seems to be some consensus around ASN.1
... will send out proposed text

<rsleevi> ACTION: Ryan to propose text/API to the mailing list to address ISSUE-14 [recorded in http://www.w3.org/2012/08/13-crypto-minutes.html#action01]

<trackbot> Created ACTION-32 - Propose text/API to the mailing list to address ISSUE-14 [on Ryan Sleevi - due 2012-08-20].

virginie: certificate lookup postpone to after FPWD
... issue 16 began discussion but no conclusion
... issue 17 no consensus yet
... issue 18 also postpone
... issue 19 discussion around origin properties needed

markw: current draft says ID is origin-specific
... this implies that all keys are origin-specific
... this may conflict with the idea that any origin may use any key

<wtc> I just asked Adam Barth to remove "such as RC4" from http://wiki.whatwg.org/wiki/Crypto.

rsleevi: let's take to mailing list but the intent is that the same key can be used but may have different IDs to differnt origins

virginie: running late, so need to wrap up

<hhalpin> thanks wtc

<mountie> GUID is better than different IDs

hhalpin: Do your "civic responsibility" of reading FPWD.

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0082.html

hhalpin: everyone needs to complete open actions this week
... then editor proposes moving to FPWD
... each member of WG then needs to read and provide comments
... mark comments as major or minor
... in ~2 weeks we will do informal consensus and then get it published

<hhalpin> next week: New Version of editors draft, complete all open actions

<hhalpin> week following: members of WG review draft

<hhalpin> August 20th: Have a new draft

<hhalpin> August 27th: One week to comment

<hhalpin> August 27thy->Sept 3rd, get formal consensus to publish

virginie: end of call. see you next Monday.

<wseltzer> trackbot, end telecon

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)

Found ScribeNick: vgb
Inferring Scribes: vgb
Default Present: +46.7.02.69.aaaa, hhalpin, +1.617.715.aabb, wseltzer, virginie, Netflix, +1.415.736.aacc, JimD, ddahl, saerd, Google, +1.415.294.aadd, +1.303.543.aaee, rsleevi, zooko, vgb, arunranga, +1.303.661.aaff
Present: +46.7.02.69.aaaa hhalpin +1.617.715.aabb wseltzer virginie Netflix +1.415.736.aacc JimD ddahl saerd Google +1.415.294.aadd +1.303.543.aaee rsleevi zooko vgb arunranga +1.303.661.aaff

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 13 Aug 2012
Guessing minutes URL: http://www.w3.org/2012/08/13-crypto-minutes.html
People with action items: ryan