- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Mon, 04 Mar 2013 16:24:51 -0500
- To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Draft minutes below and at
http://www.w3.org/2013/03/04-crypto-minutes.html
--Wendy
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Cryptography Working Group Teleconference
04 Mar 2013
See also: [2]IRC log
[2] http://www.w3.org/2013/03/04-crypto-irc
Attendees
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
Regrets
Chair
Virginie
Scribe
johnsim
Contents
* [3]Topics
1. [4]Welcome
2. [5]minutes of previous call
3. [6]web crypto api
4. [7]High level API
* [8]Summary of Action Items
__________________________________________________________
<wseltzer> me trackbot, prepare teleconf
<trackbot> Date: 04 March 2013
<mountie> zakim aaaa is mountie
<virginie> agendda?
<wseltzer> [agenda
[9]http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar
/0017.html ]
[9]
http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0017.html
Welcome
minutes of previous call
<virginie> [10]http://www.w3.org/2013/02/18-crypto-minutes.html
[10] 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> [11]http://www.w3.org/2012/webcrypto/track/issues/18
[11] 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> [12]http://www.w3.org/2012/webcrypto/track/issues/40
[12] 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> [13]http://www.w3.org/2012/webcrypto/track/issues/37
[13] 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> [14]http://www.w3.org/2012/webcrypto/track/issues/33
[14] 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> [15]http://www.w3.org/2012/webcrypto/track/issues/31
[15] 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> [16]http://www.w3.org/2012/webcrypto/track/issues/29
[16] 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:
[17]http://tools.ietf.org/wg/jose/agenda?item=agenda-86-jose.ht
ml
[17] http://tools.ietf.org/wg/jose/agenda?item=agenda-86-jose.html
<virginie> and thanks to simon fro scribing :)
<wseltzer> trackbot, end teleconf
--
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/ +1.617.863.0613 (mobile)
Received on Monday, 4 March 2013 21:24:53 UTC