W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

W3C WebCrypto meeting minutes

From: Harry Halpin <hhalpin@w3.org>
Date: Mon, 24 Sep 2012 22:51:43 +0200
Message-ID: <5060C7DF.3060009@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 24 September 2012 20:52:19 GMT