<wseltzer> me trackbot, prepare teleconf

<trackbot> Date: 04 March 2013

<mountie> zakim aaaa is mountie

<virginie> agendda?

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

Welcome

minutes of previous call

<virginie> http://www.w3.org/2013/02/18-crypto-minutes.html

<wseltzer> scribenick: johnsim

no objection - minutes are approved

web crypto api

call for action on whether we need to get IANA registration

<hhalpin> Its not a requirement, but its a discussion that we need to take seriously

<hhalpin> we would *not* do it without a WG decision.

any comments?

Ryan: strong objections. some of the fundamental objections is chartered purpose - web browsers versus generic API

hhalpin: algorithm agility - other working groups have had similar problems - face to face or a separate phone call for this issue

thx

<rsleevi> Registries: Good for protocols, bad for APIs

Virginie: would like to understand how this should work - perhaps dedicated call to get common terminology would be fruitful

<hhalpin> I think it depends. For example, one way to get around is to use URIs for algorithms, which is what XML-DSIG does.

Virginie: joint working group - ? or better face-to-face?

hhalpin: others have had this problem - a discussion between me and ryan - different positions - be careful before closing issue down

<rbarnes> we need to clarify (1) what properties we need to get out of the process for managing algorithms, (2) what the concrete proposed processes are for adding algorithms are, and (3) how they perform relative to the requirements

<hhalpin> Given that lots of other WGs and W3C staff are at Paypal, that makes sense.

virginie: set up call for appropriate people?
... one call before f2f meeting
... harry - ACTION - one call dedicated to that
... comments?

<hhalpin> Like I said, I'm OK for not having a registry, but Thomas Roessler W3C brought that up when there was an internal review and still wants to see a wider discussion.

<wseltzer> ACTION hhalpin to schedule call about registry, due 4/15

<trackbot> Created ACTION-76 - Schedule call about registry, due 4/15 [on Harry Halpin - due 2013-03-11].

Virginie: next idea of this call - different proposals - harry mentioned we did not close previous action

hhalpin: issue 18 we should go for consensus now

<virginie> PROPOSAL : close ISSUE-18 on the basis that the WG is not going to adress this feature

<wseltzer> ISSUE-18?

<trackbot> ISSUE-18 -- Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics? -- closed

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/18

<hhalpin> PROPOSAL: Close ISSUE-18 - Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics?

<rbarnes> +1

<virginie> +1

<hhalpin> +1

<mountie> +1

<ddahl_> +1

<wseltzer> +1

<rsleevi> +1

<hhalpin> There are no proposals, thus it should be closed.

<hhalpin> CLOSED: ISSUE-18 - Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics?

Virginie: next one related to ISSUE 40

<wseltzer> ISSUE-40?

<trackbot> ISSUE-40 -- How should we define key discovery, noting asynchronicity -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/40

Virginie: Wide issue and key discovery API was solving it.

Watson: thought this should be closed.

<hhalpin> However, have we thought through the privacy and security implications enough?

<virginie> PROPOSAL : Close ISSUE-40 -- How should we define key discovery, noting asynchronicity

<markw> +1

<rsleevi> +1

<virginie> +1

<ddahl_> +1

<hhalpin> I have brought those up, there was concerns from the cryptographic and security community here.

<hhalpin> -1

<rbarnes> +1

+1

<wseltzer> +1

<mountie> +1

<hhalpin> Actually, there's not consensus :)

<scribe> CLOSED: Issue 40

Review the crypto API and there is concerns about security boundaries, import/export, as long as we can discuss new and different ways to address these concerns

hhalpin: happy to close the issue with the caveat that we get a proper review
... before going to last call

Ryan: i am going to suggest that we close these issues. we should not be keeping broad issues open.

<hhalpin> i.e. there were concerns re security boundaries and the possibility of "super-keys"

Virginie: issue 40 is broad, and does not mention the privacy concern you are highlighting, and open an action about the review related to privacy aspects.

<rsleevi> strongly disagree re: UX

hhalpin: happy to close but object to closing issue 9 without proper review

Virginie: could you write down so we have an action as you have described - also problem of user action - is that linked?

Hhalpin: user action is one way of dealing with it. Issue 9 is appropriate to hold the problem

Virginie: process point. do we need to go again to the voting? or do we say working group after discussion agreed

<hhalpin> So, thus I say: I change my vote to +1 given that we keep ISSUE-9 open.

<hhalpin> And thus,

<hhalpin> CLOSED: ISSUE-40

<wseltzer> ISSUE-37?

<trackbot> ISSUE-37 -- Method naming -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/37

Virginie: next issue - that could be discussed - proposed to be closed - Issue 37

<virginie> PROPOSAL: Close ISSUE-37 - Method Naming

hhalpin: relates to JOSE working group

<rbarnes> yes, this is not jose

<rbarnes> that's later :)

ryan: this issue has nothing to do with JOSE, just API naming

<hhalpin> Ah, that's fine.

ryan: resolved since our draft 2 - nothing to do with JOSE

<rsleevi> +1

<hhalpin> PROPOSAL: Close ISSUE-37 - Method Naming

<hhalpin> +1

<rbarnes> +1

<ddahl_> +1

<virginie> +1

<mountie> +1

<wseltzer> +1

<markw> +1

<karen1> +1

<hhalpin> No text changes required, current editors draft is sufficient.

<scribe> CLOSED: Issue 37

<rsleevi> ISSUE-33?

<trackbot> ISSUE-33 -- Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/33

<virginie> PROPOSAL: Close ISSUE-33 - Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario

<rsleevi> +1

<markw> +1

<virginie> +1

<rbarnes> +1

<mountie> +1

<ddahl_> +1

<hhalpin> Can someone specify what we are doing to close the issue? It seems to be informative text

<rbarnes> nothing, afaict

<rsleevi> We're acknowledging that the current text is sufficient

<hhalpin> The working group thinks key tainting should be allowed and no informative text is necessary to warn people or WebApp developers around key tainting.

<hhalpin> Does that capture the resolution?

<hhalpin> +1

<scribe> CLOSED: Issue 33

<rsleevi> ISSUE-31?

<trackbot> ISSUE-31 -- Problems with keys attribute of the Crypto interface -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/31

Virginie: next item - ISSUE-32

key discovery API - concerns raised with original draft 1, no longer an issue in key discovery draft

<virginie> PROPOSAL: CLOSE ISSUE-31 -- Problems with keys attribute of the Crypto interface

<rbarnes> +1

<rsleevi> +1

<virginie> +1

<mountie> +1

<markw> +1

hhalpin: addressed and closed or moved to the key discovery draft?

<hhalpin> i.e. moved and closed

<hhalpin> or just moved

<hhalpin> The issue tracker is for multiple documents

<rsleevi> moved and closed (as the organization that raised it, I can confirm our concerns have long since been addressed)

<hhalpin> So, its not relevant for the key discovery API.

<hhalpin> +1

<scribe> CLOSED: Issue-31

<rsleevi> ISSUE-29?

<trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/29

Virginie: next issue is last one, so to have chance to discuss high level api

decided to continue to treat them as independent algorithms.

<virginie> PROPOSAL : Close ISSUE-29 -- Handling of block encryption modes and padding

<rsleevi> +1

<mountie> +1

<virginie> +1

<markw> +1

<ddahl_> +1

<karen1> +1

<wseltzer> +1

<rbarnes> +1, if you're ok with the combinatorial explosion :)

<hhalpin> +1

<scribe> CLOSED: Issue-29

Virginie: pay attention to the high level API

High level API

David: i do have a draft, basically, something easier and safer to use for web app developers - still think this is not a counter proposal to low level API but an additional API
... don't want to put forward a proposal that another browser provider would not implement

<hhalpin> I think the W3C would like a high-level API, as that was in our charter as well, under "Mission".

hhalpin: concern some in w3c - can we get a reasonable high level API across different browsers?

<hhalpin> and can we do a timeframe that makes sense?

virginie: spoke with different developers - for the crypto-educated people, sounds usable, but those unfamiliar - it is a problem - so i support a high level API

Ryan: i have been meeting with crypto community on this issue
... i strongly believe any high level API will have to be done by serious cryptographers - and we have none in this working group
... if we embark on a high level API, it requires very concrete use cases and threat model

<mountie> I agree with Ryan's opinion

Ryan: Same level as low level API

rbarnes: regardless high or low level, it will be handled by unskilled developers

<rsleevi> That's like saying WebGL will be used by people who don't understand 3D. Sure, they're not the target of the API. It's a false premise to think you can deliver secure code without having to think about security.

<rbarnes> ack

virginie: i hear that we don't have the right people in the working group, so we should bring them in
... second, we will need appropriate use cases for designing the api

<rbarnes> rsleevi: the difference is (1) when your webgl code doesn't work, it's obvious, and (2) when your webgl code is wrong, you don't expose sensitive information

virginie: harry - you have been offering to try to organize some calls with people designing other high level api - still something you can do?

Ryan: i think you have the steps wrong - first step is use cases and then getting right people on board for security

<hhalpin> My concerns are even the people who want the use-cases aren't here.

<hhalpin> But they may nonetheless be very valid use-cases for a high-level API by ordinary web-developers

Virginie: end of conference call - no decision from this discussion - but clear direction - make use cases clear and get right people to join the working group

wseltzer: administrative manner - European and US clocks go out of sync for next three weeks

<rbarnes> jose on wednesday: http://tools.ietf.org/wg/jose/agenda?item=agenda-86-jose.html

<virginie> and thanks to simon fro scribing :)

<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/@@/hhalpin/
Found ScribeNick: johnsim
Inferring Scribes: johnsim
Default Present: +82.22.14.0.aaaa, Wendy, mountie, +1.512.257.aabb, virginie, +1.408.540.aacc, markw, +1.707.799.aadd, rsleevi, emily, ddahl, +1.703.284.aaee, rbarnes, +1.512.257.aaff, John_Simmons, karen, hhalpin, Arun_Ranganathan
Present: +82.22.14.0.aaaa Wendy mountie +1.512.257.aabb virginie +1.408.540.aacc markw +1.707.799.aadd rsleevi emily ddahl +1.703.284.aaee rbarnes +1.512.257.aaff John_Simmons karen hhalpin Arun_Ranganathan
Found Date: 04 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/04-crypto-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.