Web Cryptography Working Group Teleconference -- 27 Aug 2012

<trackbot> Date: 27 August 2012

<selfissued> selfissued is Mike Jones, Microsoft

<wseltzer> Chair: Virginie_Galindo

<wseltzer> scribe: zooko

<wseltzer> scribenick: zooko

LEt's see... everything I type in here becomes part of the scribed record, right? Except for things I prefix with something/

<virginie> http://www.w3.org/2012/08/20-crypto-minutes.html

<hhalpin> PROPOSED: Approve meeting minutes of Aug 20th - http://www.w3.org/2012/08/20-crypto-minutes.html

<hhalpin> RESOLVED: meeting minutes of Aug 20th are approved - http://www.w3.org/2012/08/20-crypto-minutes.html

Web Crypto Draft API

Nothing changes since the previous version. Everyone waited until this morning to start giving feedback.

There is a lot of good feedback

Ryan said that. --^

rsleevi: No changes since the previous version. Everyone waited until this morning to start giving feedback. There is a lot of good feedback.

thanks, hhalpin.

Did "" just go into the scribe record?

rsleevi: the plan is to incorporate all the feedback into another draft. If people can get their feedback in today, it would be reasonable to use it for the next version.

asad: the draft is good. There are a few things that need to be polished.
... in the past we had some sample code. I don't see it now.
... I fear that when we talk about the scope of this API, we mention secure elements and smartcards, but it is not in the right light.
... It is out of scope how to generate the keys or mandating that smartcards be used, but for applications where those are required we
... should at least mention the relevant features, within the scope.
... Please look at the email that I sent out this morning.

virginie: two proposals: add sample code, and add mention of relevant features

markw: we need to be clear on which things are still open issues.

<markw> I said that there are issues we've been discussing on the mailing list and I wanted to be sure these were properly documented in the specification before it goes to FPWD

rsleevi: if there are issues you want to raise, use the bug tracker or the mailing list to make it clear what are the issues or bugs.
... I'm not sure at what point we start using bugzilla to trac bugs.
... I want to make sure that everyone's opinions on these are getting captured.

<hhalpin> We can kill Bugzilla if users prefer W3C Tracker

<hhalpin> different working groups hae different styles

markw: the issue tracker is fine so long as issues are linked from appropriate parts of the specification.

<hhalpin> we can link to chromium, mozilla bug trackers perhaps

virginie: does anyone feel that there are issues that are not tracked at the moment?

<hhalpin> not sure if IE has a bugtracker per se or public open issue list, does it?

<rsleevi> @harry: I didn't mean Chromium/Mozilla bugs, bug the W3C bug tracker

<rsleevi> *meant bugs in the W3C bug tracker

karen: the application needs to know that this key is indeed from the smartcard.
... for example, a banking application may allow a different kind of transaction or higher or lower limit depending on which key is used.

<hhalpin> @rsleevi: I'm suggesting we remove the W3C bugzillas unless we plan to use them, and include links to the bugzillas of implementations instead

<hhalpin> but not right now, since we aren't in implementation mode yet

karen: I would suggest that we talk about the key storage.

<rsleevi> hhalpin: I was meaning to use the bugzilla to track bugs in the spec, which leads to ISSUES (points of discussion) or ACTIONs (resolutions for bugs)

virginie: we need to create an issue, because we don't have explicit discussion of this question of the application knowing where the key is coming from.

<wseltzer> ISSUE-16?

<trackbot> ISSUE-16 -- Definition for Key Expiration -- raised

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

@@: this is Issue 16, which is closed and resolved as something that we're not going to do.

<rsleevi> sorry

<rsleevi> 11

<wseltzer> ISSUE-11?

<trackbot> ISSUE-11 -- Is there a need for a storage attribute, indicating storage in a hardware token -- closed

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

rsleevi: sorry, ISSUE-11

<hhalpin> it is possible to re-open issues, but we prefer not to

karen: How is this use case resolved?

<hhalpin> in general

<virginie> http://www.w3.org/2012/webcrypto/track/issues/11

<asad> Issue 16 is for key expiration not for the source of key, right?

karen: How does an application -- a banking application -- know that a certain key satisfies its requirement?

<asad> Ok thanks.

<JimD> It's one thing to say smart cards are out of scope, but it's another thing to create an API that prohibits

<JimD> That prohibits smart card use

virginie: How to allow an application to make sure that a key is in a secure element, without prohibiting any type of technical solution to this.

karen: We don't have to use an attribute, as long as there is a way for an application to make sure that a key is coming from where it desires.

hhalpin: we're supposed to give feedback by today.

rsleevi: Editors are supposed to use this feedback and put a new document by September 4.
... And then the document is basically done.
... And then we'll have a formal go-around and ask for objections.

And by "rsleevi" I mean harry.

<hhalpin> sample code can go into a primer

<hhalpin> or even the use-cases, and link to the spec.

rsleevi: might be early for sample code since the API is still changing rapidly
... an attribute is problematic, but the goal is not to prevent smartcards or secure elements.
... origin-generated vs. origin-authorized
... The current spec isn't against smartcards.
... We need to work out some new mechanism.
... On the mailing list.
... If you could send your concerns to the mailing list along with what proposal you'd like to see.

<Zakim> rsleevi, you wanted to reply to asad's use case concern

<hhalpin> good idea, and that is what folks were supposed to do last week :)

vgb: It sounds like there are people proposing open issues that think they're being misunderstood.

<rsleevi> +1 to vgb, that's what I was asking for :)

<wseltzer> ACTION on mark to write some non-normative text about pre-shared keys

<trackbot> Sorry, couldn't find user - on

<wseltzer> ACTION mark to write some non-normative text about pre-shared keys

<trackbot> Created ACTION-38 - Write some non-normative text about pre-shared keys [on Mark Watson - due 2012-09-03].

<rsleevi> er, sdurbha :)

sdurbha: maybe we need a method of searching for a key based on the type of key

<sdurbha> zooko: I think that will be good idea too

asad: +1 whoever indicates -- at this late stage of the game -- that the text needs to be changed should provide the proposed new text.

<sdurbha> k

asad: once the user has selected the key, the application should be made aware of that.

virginie: just to try to clarify, when you say "what key" do you mean the specific identifier -- which has been heavily discussed.

asad: it is basically the source -- if it is coming from local storage or from a smartcard.

@@: we've had a week to do what we've talked about -- send notes about open issues and proposed changes.

hhalpin: given that we're moving the next telecomm to Sept 4, that we give people basically until the end of tomorrow to do that.
... And if they do it afterward, fine, but it may not get into the first edition of the working draft.
... If the discussions carry on to the end of the week it will be too late to get it in.
... For this *particular* round of publication, I'm suggesting that we give people until the end of tomorrow to submit whatever proposed changes that they want.

<hhalpin> its a short deadline, but we need to have a hard deadline somewhere for this FPWD

<hhalpin> EOD tomorrow

<Zakim> rsleevi, you wanted to reply to asad

<hhalpin> PROPOSAL: All comments for FPWD have to be in Tuesday tomorrow evening.

<virginie> +1

<hhalpin> Remember, we can *keep* changing things after the FPWD

rsleevi: issues should be as specific as possible -- if you have a use case that requires three things, it might be better to put it as three issues.
... We are talking about keys that are either generated by the application, or provided by some out of band means -- pre-shared, pre-provisioned.
... What has not been discussed yet is authorizing keys.
... Key authorization is like multi-origin access, which has a number of challenging security issues.
... If it doesn't make it into the first public working draft, that doesn't mean that we're not going to work on it, but be prepared...

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0186.html

virginie: Does anyone have a vision of what they want the next step after the working draft

rsleevi: If we have a clear semantic description of how origin-authorized keys work... pre-provisioned keys should be very similar.
... I would expect a lot more discussion about import/export, wrap/unwrap and key representation.

vgb: there's another bundle of issues around certificates that's awaiting us.
... One of the problems that I see with the way we're currently doing things is that we have loads of open issues and things don't get closed and stay closed.

<hhalpin> any of those is fine after FPWD, but in the beginning the main issue is to explore the space of issus.

@@: once you have one public working draft, then the public review goes on for the next almost year.

scribe: The public can send feedback at any time up until last call.
... After last call we do not accept feedback from the public, although the working group can still changes things up until lTer.

<hhalpin> we can focus existing calls as well, as has been suggested

virginie: I would prefer to dedicate one of our regular conference calls to a specific problem.
... Not to increase the level of required work -- it is already kind of tough.

<rsleevi> Last call for new issues; Tuesday evening. New draft target is Friday, for review over the weekend & Monday

<wseltzer> trackbot, end teleconf

<hhalpin> Trackbot, end meeting

- DRAFT -

Web Cryptography Working Group Teleconference

27 Aug 2012

Attendees

Contents

Web Crypto Draft API

Summary of Action Items

Scribe.perl diagnostic output