Web Cryptography Working Group Teleconference -- 04 Feb 2013

<trackbot> Date: 04 February 2013

<virginie> who is on the call ?

<tantek> greetings

<tantek> (from AZ CSSWG mtg)

<ddahl> hi tantek

<virginie> who is on the call ?

<wseltzer> [agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2013Feb/0009.html ]

<hhalpin> its a very exciting telecon today, closing issues and a new draft document!

<hhalpin> emily?

ok!

<virginie> http://www.w3.org/2013/01/21-crypto-minutes.html

virginie: progress on low-level API thanks to ryan...
... closing a bunch of issues, also some discussion about high-level presented by David
... any objection to approving minutes?

<hhalpin> RESOLUTION: approve minutes of last meeting http://www.w3.org/2013/01/21-crypto-minutes.html

virginie: now we go through different proposals made by ryan

<wseltzer> [Issues are collected at http://lists.w3.org/Archives/Public/public-webcrypto/2013Feb/0009.html ]

virginie: can mark issues to be addressed in next version or different revision

<hhalpin> there's also the "product" way of closing issues.

mike: request from 3 different people at microsoft to defer decisions on closing issues until adequate time to review them
... proposal made only 2 business days ago

harry: want some time limit to how long reviews go on for but it should be reasonable
... can still go through ryan's suggestions today
... can associate issues with specs in bugzilla

<selfissued> Thanks. I think that giving people until the next call to review the issues being proposed for closure is reasonable.

ryan: was not intending for this to be agenda of call

<hhalpin> Features that are unimplemented won't go to Rec status :)

ryan: intending to get us focused on making forward progress
... identify serious gaps that need to be resolved in this version
... as opposed to "I want a pony" issues

<hhalpin> I think a quick walk-through would be great

rsleevi: open issues with no progress for 6+ months is no good

wseltzer: tracker has "postponed" status as well as closed

virginie: can postpone or allocate issues to another product
... discuss proposals on next call in 2 weeks

<rsleevi> Right: I want to make a distinction between "What we are working on", "what we need to work on", "what we plan to work on", and "what we want to work on" (since they may all be different)

<hhalpin> The difference is a CLOSED issue is generally not talked about any more, and attempts to revisit it can be replied with "we already closed that" while POSTPONED is less strong and allows re-visiting.

hhalpin: w3c typically doesn't run registries, it might be better to have IANA run the registry
... WG runs registry during lifetime, but don't want it left hanging after close of WG
... IANA ok with running it
... separate discussion about modifying registration process to make it harder or easier

rsleevi: registry is bad for web
... registry notion only comes up b/c of string identifiers

<hhalpin> Which requires re-opening the Working Group :)

rsleevi: requires active collaboration of multiple user agents
... need specs that require consensus to have interoperable web

rbarnes: not going to have universally implemented set of algorithms
... devs are going to have to deal with algorithms being absent
... can separate availability/implementation from naming
... useful to have a common set of names

<rbarnes> ack

virginie: we'll have to make our own list of identifiers anyway
... might reuse other identifiers that are used elsewhere
... can defer the decision
... richard had volunteered to maintain document of different identifiers

rbarnes: can pull out names from current spec into separate document

<hhalpin> I'd like to clarify the registry concept :)

rsleevi: concern is about process associated with document

<hhalpin> No, the algorithms remain in the current spec.

<rbarnes> hhalpin: oh, maybe i misunderstood the concept

hhalpin: not as concerned about registry maintenance, because algorithms dont change very often, more concerned about process of defining algorithms than exact ownership

<rbarnes> rsleevi: any IANA registry comes with an admission policy

hhalpin: wasnt suggesting that current algorithms get removed from spec
... have to demonstrate interoperability to go through w3c process
... keep algorithms that we have and do test cases for them
... difficult once spec has gone through process to change it without reopening WG
... algorithms in registry would not go through rigorous review process, but wouldn't have to reopen WG for minor changes

rsleevi: doesn't require review or IPR agreement, dangerous to open web

<tantek> (delayed) hi ddahl and wseltzer!

rsleevi: different user agents might define algorithms differently
... patent and IPR concerns associated with algorithms
... don't want to see crypto enforcing vendor lock-in

<hhalpin> Yes, but we need to make progress on this issue Virginie.

<hhalpin> So I request I make a quick modification based on rsleevi's point.

<hhalpin> which I generally agree with.

rbarnes: strong consensus at f2f that no mandatory-to-implement algorithms

<hhalpin> Well, IANA takes a while :)

<hhalpin> I think my point would be

rbarnes: can address IPR concerns within IANA

<hhalpin> that we *can* update test-suites continually

<hhalpin> after lifetime

rbarnes: can set policy at registry creation
... policies can require levels of consensus

<hhalpin> of Working Group, so thus we could do require test-cases to be maintained for new algorithms.

<rsleevi> @rbarnes: There's a distinction between the UA (correctly) gluing up with the OS/crypto lib and between having multiple definitions ("aes-gcm", "aes-gcm1", "aes-gcm-like-the-others-but-different")

<rsleevi> @rbarnes: I view it as a separate issue from MTI

hhalpin: with no IANA registry, would have to keep WG open forever or reopen for every change

<hhalpin> That's a fairly important point.

<hhalpin> We also do need to take a decision as regards extension to the charter

<ddahl> https://dvcs.w3.org/hg/webcrypto-highlevel/raw-file/tip/Overview.html

<virginie> https://dvcs.w3.org/hg/webcrypto-highlevel/raw-file/tip/Overview.html

ddahl: still feel pretty strongly about having a high-level API
... want it to be very simple, allows for public-key and symmetric encryption

<hhalpin> We need to discuss the extension to charter issue today.

What's the rationale for removing sign/verify?

ddahl: redundant with encryptAndSign

<rsleevi> @ddahl: It seems like the primitives are (secret key) encrypt/decrypt, (private key) sign/verify and (private key) encrypt/decrypt [which implies sign/verify]

<rsleevi> @emily: ^ sound right?

@rsleevi, @ddahl: but there's no way to sign using the high-level API without also encrypting?

<hhalpin> @everyoneabove, it seems useful to have the ability to sign without encrypting

virginie: proposal to switch milestone for finishing low-level api by 6 months

<rbarnes> @emily: as i understand it, all high-level API calls effectively send a message from a key pair to a public key

<ddahl> emily: that is a possible drawback as it may be confsuing

<hhalpin> The suggestions were 6 month, 8 month, or 12 month extension

<hhalpin> but we have to file before end of Feb.

<wseltzer> Any objection to a 6-month extension of charter and dates?

<arunranga> +1 ddahl, I was muddled up by that.

<rbarnes> i would be fine with 6, 8, or 12

<ddahl> arunranga: yeah, i removed sign/verify based on some feedback from Adam Langley

<rbarnes> rsleevi: yeah, either way

rsleevi: want small extension and a burndown of current issues with spec

<hhalpin> +1 6 months, I'd live with 8 months, 12 months makes me worried.

<selfissued> +1 for 8

rsleevi: don't understand motivation for 8
... advancing to candidate rec is where netflix feels comfortable implementing

<hhalpin> We can always go to CR *before* schedule.

<hhalpin> i.e. if we close all our issues ahead of schedule, we're fine.

<rsleevi> If we can't advance within 6 months, I think we'll have failed as a WG :)

<rbarnes> no objection here

virginie: any objection to 6 month extension?

<virginie> +1

<rsleevi> PROPOSAL: 6 month extension

<rbarnes> +1

<rsleevi> +1

<ddahl> +1

<cjkula> +1

<hhalpin> PROPOSAL: 6 month extension to charter

<hhalpin> +1

<nvdbleek> +1

<selfissued> +1

<mountie> +1

<rsleevi> RESOLUTION: 6 months extension will be pursued

hhalpin: april 23-24, paypal headquarters in silicon valley

<jyates> In San Jose?

hhalpin: could do joint WG session with webappsec

<rsleevi> @jyates: yes

hhalpin: could also try to overlap and do 24-25 but some concern with paypal

<hhalpin> The joint session would be the 25th in morning

<selfissued> +1

<virginie> +1

virginie: proposal for f2f april 23-24, joint session on 25th

<rsleevi> PROPOSAL: Face to face on 23/24 at PayPal HQ in San Jose

<rbarnes> +1

<mountie> +1

<ddahl> +1

<rsleevi> +1

<hhalpin> +1

<jyates> +1

<rsleevi> RESOLUTION: Next f2f on April 23/24

<hhalpin> It will also be good because we can have lots of f2f time with WebApps and HTML WGs over issues like test cases and even registries if needed.

<hhalpin> 2 weeks to read and discuss!

<wseltzer> ACTION hhalpin and wseltzer to prepare extension request for 6 months

<trackbot> Created ACTION-75 - And wseltzer to prepare extension request for 6 months [on Harry Halpin - due 2013-02-11].

<wseltzer> ACTION all participants to review proposals to close issues

<trackbot> Error finding 'all'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.

<wseltzer> trackbot, end teleconf

- DRAFT -

Web Cryptography Working Group Teleconference

04 Feb 2013

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output