See also: IRC log
<trackbot> Date: 04 February 2013
<virginie> who is on the call ?
<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!
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
... 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
... 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
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
... 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: 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?
<rsleevi> PROPOSAL: 6 month extension
<hhalpin> PROPOSAL: 6 month extension to charter
<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
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
<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
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/zakim wseltzer_cpdp is really wseltzer// No ScribeNick specified. Guessing ScribeNick: emily Inferring Scribes: emily WARNING: No "Topic:" lines found. Default Present: Wendy, jyates, nvdbleek, +1.408.540.aaaa, rsleevi, Scott_Kelly, virginie, ddahl, emily, +1.617.873.aabb, rbarnes, selfissued, hhalpin, arunranga, karen, +1.510.387.aacc, cjkula, mountie Present: Wendy jyates nvdbleek +1.408.540.aaaa rsleevi Scott_Kelly virginie ddahl emily +1.617.873.aabb rbarnes selfissued hhalpin arunranga karen +1.510.387.aacc cjkula mountie Regrets: Asad_Ali Seetharama_Durbha Mark_Watson Found Date: 04 Feb 2013 Guessing minutes URL: http://www.w3.org/2013/02/04-crypto-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]