- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 24 Sep 2012 22:51:43 +0200
- To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Are available for review: https://www.w3.org/2012/09/24-crypto-minutes.html
Web Cryptography Working Group Teleconference
24 Sep 2012
See also: [2]IRC log
[2] http://www.w3.org/2012/09/24-crypto-irc
Attendees
Present
asad, cjkula, JimD, ddahl, [Microsoft], +1.303.661.aaaa,
markw, hhalpin, wtc, rsleevi, +1.303.661.aabb
Regrets
wseltzer
Chair
hhalpin
Scribe
asad
Contents
* [3]Topics
1. [4]FPWD
2. [5]Open issues
3. [6]f2f
* [7]Summary of Action Items
__________________________________________________________
<trackbot> Date: 24 September 2012
<selfissued> Microsoft is Mike Jones
<hhalpin> scribe: asad
<hhalpin> scribenick: asad
<hhalpin> APPROVAL: of minutes
[8]https://www.w3.org/2012/09/17-crypto-minutes.html
[8] https://www.w3.org/2012/09/17-crypto-minutes.html
<hhalpin> APPROVE minutes:
[9]https://www.w3.org/2012/09/17-crypto-minutes.html
[9] https://www.w3.org/2012/09/17-crypto-minutes.html
FPWD
rsleevi: Will try to summarize the things we see on the mailing
list
... underlying comments on the mailing list are that people
will no skills in crypto will be using the API so we should
address this
... creating a list of things that the API does
JimD: send a link to the API to my group and got a some
comments that the JS has one heap so it is possible for one
windows to get access to what happens in another window
hhaplin: Should mark the broken algorithms so that the
implementations do use them they should know that they are not
recommended
rsleevi: True, we should mention this, even it not broken, they
may not be safe to use.
... , something like, it is not safe to use but here it is,
just in case you want to use it.
... the wording will be tricky.
mike: ECB is critical and we should support it in low level
API.
<rsleevi> hhalpin: I can take the issue to clarify the set of
algorithms
hhaplin: Should mention that what is recommend in terms of algo
use should indicate that it is recommended as of today
... what happens in future, we can not predict.
<rsleevi> @hhalpin: Raised as
[10]https://www.w3.org/Bugs/Public/show_bug.cgi?id=18925
[10] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18925
<hhalpin> Do you want any help on that rsleevi?
<hhalpin> A new ACTION, or just keep it in Bugzilla?
sdurbha: our charter is to come up with API, and may be not to
recommend what to use in the context of the application
<rsleevi> @hhalpin: I think I have a good idea for it, will
propose text for further smithing
sdurbha: developers base their decision of what to use based on
other factors as well.
rsleevi: for low level API it is less critical what is broken
and what is not
... We should revisit the high level API, there is interest in
the cryptography community for this.
... by providing high level API we can also address the
discussion of what is good and what is not
... especially if unskilled developers use it, who have little
exposure to crypto
mike: for high level API we should point to JOSE as an example
<hhalpin> mike can you point to JOSE APIs?
mike: e.g. for what algorithms are to be supported.
<rsleevi> JOSE:
[11]http://datatracker.ietf.org/wg/jose/charter/
[11] http://datatracker.ietf.org/wg/jose/charter/
mike: should not do high level API just to get rhetorical
points
hhaplin: Yes should push the high level API work forward
<rsleevi> CFRG cipher catalog:
[12]http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog-0
0
[12] http://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog-00
ddahl_: How to trust the DOM? This is a major issue and until
that is solved practitioners will not trust the user agent
hhaplin: The intent of the comment is to see what users want to
see in the spec. From that point, all comments are good
comments.
... When we reference others specs through links, readers
generally do not follow the link
<hhalpin> ACTION: rsleevi to add text as regards security
considerations for algorithms [recorded in
[13]http://www.w3.org/2012/09/24-crypto-minutes.html#action01]
[13] http://www.w3.org/2012/09/24-crypto-minutes.html#action01
<trackbot> Created ACTION-52 - Add text as regards security
considerations for algorithms [on Ryan Sleevi - due
2012-10-01].
hhaplin: Should add more text on what the API is and is not
providing, to address David's comment.
... any one interested in writing CSP text for this?
<hhalpin> ACTION: hhalpin to write some text around CSP and Web
Security model [recorded in
[14]http://www.w3.org/2012/09/24-crypto-minutes.html#action02]
[14] http://www.w3.org/2012/09/24-crypto-minutes.html#action02
<trackbot> Created ACTION-53 - Write some text around CSP and
Web Security model [on Harry Halpin - due 2012-10-01].
<rsleevi> Right, I was talking about per-algorithm security
considerations
<rsleevi> inline with the alg
sdurbha: in security considerations, any worries about users of
API will make it less secure.
hhaplin: good point
<rsleevi> Right, in many cases the existing algorithm
specifications (eg: PKCS#1 v2.0/2.1) typically explicitly call
out security considerations (eg: RSA-SSA/RSAES shouldn't be
used for new apps)
<rsleevi> So we'd potentially be duplicating that
hhaplin: who reads the spec, users as well as developers.
... Ryan, would you like to add some user centric text for the
API
rsleevi: such security considerations will get sorted out as we
look deeper into these API
... and yes such text will be added.
<hhalpin> ACTION: hhalpin to blog post on w3.org about how the
API fits into the larger Web platform [recorded in
[15]http://www.w3.org/2012/09/24-crypto-minutes.html#action03]
[15] http://www.w3.org/2012/09/24-crypto-minutes.html#action03
<trackbot> Created ACTION-54 - Blog post on w3.org about how
the API fits into the larger Web platform [on Harry Halpin -
due 2012-10-01].
hhaplin: do we feel that we had had a good review on the public
draft
ddahl_: All commentary is good, even the negative one.
... I would still like to get more commentary, and hopefully
some more positive and constructive one.
rsleevi: People who have not that strong experience in
security, but have worked alot in javascript, we should reach
out to them.
<rsleevi> example discussion:
[16]http://news.ycombinator.com/item?id=4549504
[16] http://news.ycombinator.com/item?id=4549504
rsleevi: If people posting on blogs can redirect readers to our
page.
wtc: We are not getting too many commetns from JavaScript
users.
... There are people who will only do one review, so we are
waiting before engaging them so that API is more mature.
hhaplin: Is 6 months a good time for such a review?
rsleevi: Yes.
... e,g TPAC review
Open issues
<hhalpin>
[17]http://lists.w3.org/Archives/Public/public-webcrypto/2012Se
p/0162.html
[17] http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0162.html
hhaplin: For open issues should we move high level to medium
rsleevi: Should not prioritize the high level API without first
identifying what it is.
hhaplin: There are three threads on the mailing list related to
issues
... looks like no one has thought about these yet
rsleevi: Corrent proposal lists priority within the domain it
is in
<hhalpin>
[18]https://docs.google.com/a/ibiblio.org/spreadsheet/ccc?key=0
Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E#gid=0
[18] https://docs.google.com/a/ibiblio.org/spreadsheet/ccc?key=0Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E#gid=0
<hhalpin> Is Virginie's list
rsleevi: There can be issues with this since a high priority
issues within a domain may not carry that much weight since
that domain may not be that critical
hhaplin: everything related to keys is highly prioritized, and
all other things are lower priority
... We have been having a lot of discusion on ECB.
rsleevi: without implementing ECB we are only doing polyfilling
in java script
mike: we should ask that this issued be resolving in favor of
including it.
hhaplin: propose that we resolve it next time, since zuko is
not in attendence today.
<hhalpin> PROPOSED: Resolve in favour of ECB by next meeting
unless WG is convinced otherwise
hhaplin: Any one else on the phone who is against including
ECB?
none.
<hhalpin> crypto-ISSUE-18
<hhalpin> Should it be possible to perform CryptoOperations as
a 'streaming' operation with URI semantics?
<rsleevi> low-level
<rsleevi> [19]http://www.w3.org/2012/webcrypto/track/issues/18
[19] http://www.w3.org/2012/webcrypto/track/issues/18
hhaplin: Issuse 18 is a trickier issue
sdurbha: Is this high level or low level issue
rsleevi: Out standing issue with blob is padding, not sure if
any resolution will come out soon.
... there is an interest in allowing developers to push
everything into an array buffer.
... need to have some memory store backing an array buffer
<hhalpin> agree some kind of non-restricted blob would be great
rsleevi: WebApp WG is also looking at this, also compression
and de-compression.
<rsleevi> @hhalpin Sounds good
<rsleevi> @hhalpin webapps is mon&tues
hhaplin: This looks like a good common meeting we can have with
WebApp WG at TPAC.
<rsleevi> @hhalpin: In for the week, planning on attending web
apps
<markw> I will be there all week
<selfissued> I will arrive Wednesday afternoon
<cjkula> there all week
<hhalpin> ISSUE-36: The distinction between deriveKey and
generateKey is not currently well-defined. For purposes of
understanding where future algorithm definitions should go, it
would be helpful to know what the expected (generic) inputs and
outputs are for both methods.
hhaplin: next issue is distiction between generated and derived
keys
... what exactly is the difference?
rsleevi: key derivation and generation are both important
... we support both and the question is if you get an opaque
handle or raw bytes.
mitchz: Agree with ryan.
... exchanged emails with ryan related to exportability, we
need to firm up the API
hhaplin: Can we get text on these two issues to resolve them by
next week?
rsleevi: Not sure, may need more time to research to make sure
API is robust enough to handle these cases.
mitchz: We are doing key wrap and un-wrap to handle these
issues.
<hhalpin>
[20]https://docs.google.com/spreadsheet/ccc?key=0Atia00Ba4s7XdG
NtYTJBdTFELXV3eWZfMEVud09RV1E
[20] https://docs.google.com/spreadsheet/ccc?key=0Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E
<hhalpin> the proposed prioritizaton list
hhaplin: Should address these by TPAC and also get a wider
review
f2f
<hhalpin> Jan/Feb range
<hhalpin> RSA?
hhaplin: By this we should have most of the high priority
issues closed
<selfissued> I go to RSA always
<mitchz> RSA +1
sdurbha: if pushing to february, we could meet during RAS
conference.
<hhalpin> [21]http://365.rsaconference.com/index.jspa
[21] http://365.rsaconference.com/index.jspa
<hhalpin> trackbot, end meeting
hhaplin: not sure what caused the drop in attendence today. See
you next week.
Summary of Action Items
[NEW] ACTION: hhalpin to blog post on w3.org about how the API
fits into the larger Web platform [recorded in
[22]http://www.w3.org/2012/09/24-crypto-minutes.html#action03]
[NEW] ACTION: hhalpin to write some text around CSP and Web
Security model [recorded in
[23]http://www.w3.org/2012/09/24-crypto-minutes.html#action02]
[NEW] ACTION: rsleevi to add text as regards security
considerations for algorithms [recorded in
[24]http://www.w3.org/2012/09/24-crypto-minutes.html#action01]
[22] http://www.w3.org/2012/09/24-crypto-minutes.html#action03
[23] http://www.w3.org/2012/09/24-crypto-minutes.html#action02
[24] http://www.w3.org/2012/09/24-crypto-minutes.html#action01
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [25]scribe.perl version
1.136 ([26]CVS log)
$Date: 2012/09/24 20:01:11 $
__________________________________________________________
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[26] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 24 September 2012 20:52:19 UTC