Web Cryptography Working Group Teleconference -- 02 Jul 2012

<hhalpin> trackbot, start meeting

<trackbot> Date: 02 July 2012

<drogersuk> I'm on irc only at the moment

<hhalpin> \me "Zakim, aaxx is my_name"

<asad> aaaa is asad

<JimD> Having phone issues, will be on in just a bit

<Karen_> Zakim: 3964 Karen

<virginie_galindo> Zakim aabb is virginie_galindo

<rsleevi> Zakim: aabb is virginie_galindo

<Karen_> 512

<Karen_> Zakim: 512.257.xxxx Karen

<rsleevi> Skype is likely P7

Zakim P7 is arunranga

<drogersuk> Erm?

<drogersuk> No not yet

<hhalpin> Samuel from Nexus Technology is an observer

<drogersuk> Will be about 15 mins

<Karen_> Zakim: I didn't hear calling me

<hhalpin> Jim?

<hhalpin> scribenick: arunranga

<hhalpin> chair: virginie_galindo

<hhalpin> scribe: arunranga

Convene Meeting July 2nd 2012

<hhalpin> PROPOSED: Meeting minutes from last meeting are accurate - http://www.w3.org/2012/06/18-crypto-irc.html

<hhalpin> Any objections?

<virginie_galindo> http://www.w3.org/2012/06/18-crypto-minutes.html

<hhalpin> RESOLUTION: Meeting minutes from last meeting are accurate - http://www.w3.org/2012/06/18-crypto-irc.html

Welcome – 5’

Use Cases

<hhalpin> Channy volunteered but we haven't had the training yet

VG: Harry will train Channy on different topics.
... (editorial topics)

JD: I was assigned to edit some minor use cases; happy to continue.

<Karen_> Zakim: I just want to make sure you know I am on line. I didn't see you +karen nor hear name call

<hhalpin> ACTION: JimD and Channy to edit use-cases [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action01]

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

<rsleevi> Muted ^

<sdurbha> ??P11 is me, I guess

<hhalpin> Nexus Technology

VG: we received use cases from Nexus Technology.

<virginie_galindo> http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Jul/0000.html

VG: We might have to take these into account.

<hhalpin> public-webcrypto-comments@w3.org is the place for public comments

HH: The public-webcrypto-comments list is public, and others should be encouraged to comment

Use cases – 5’

<virginie_galindo> Editor’s Draft API http://www.w3.org/2012/webcrypto/WebCryptoAPI/ --> No change since our last call

<hhalpin> Also, the co-editor WTC from Google is on vacation :)

<virginie_galindo> Our garage on on github https://github.com/daviddahl/web-crypto-ideas --> No change since our last call

VG: There is a github which we should look at on a regular basis.

<hhalpin> so we are waiting for him to get back to do another editors training re WebIDL

VG: Most of the activities during the last two weeks were related to Ryan's contribution on the low-level API

Draft API review – 40’

<virginie_galindo> Low level API related discussions were intiated by Ryan Sleevi contribution http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0117.html

VG: There were technical discussions about Blob vs. ArrayBuffer, etc.

DD: I wanted to commend Ryan for API contribution. I think that after more discussion, we should think about adding RS stuff to our draft.
... Ryan's proposal is better suited for low-level API. When I originally wrote mine, it was with an eye to a higher level API. Even though what's there is a bit lower level than I even realized.
... you can access private key material… but you have to when creating that key specify it at that point.

VG: we have to make sure the different elements we're discussing are present in this API
... (refers to key access, key specification, etc.) We had a discussion about the naming of the algorithm.

RS: I am not particularly vested in short names, or algorithm objects. I think we can map short names.
... So we can change the API to take a string or a dictionary. Short names are incredibly useful.
... My concern with short names is the ability to express parameters that don't fit within the name.
... I gave examples (in listserv traffic).
... Short names make a lot of sense. My core contention is if we go with an object as a default, and go with short names as aliases, we may be able to get more functionality.

VG: Think you can formulate this and make proposal?

<rsleevi> ACTION: Update the API proposal to reflect support for short names [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action02]

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

<rsleevi> ACTION: rsleevi to update the API proposal to reflect support for short names [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action03]

<trackbot> Created ACTION-3 - Update the API proposal to reflect support for short names [on Ryan Sleevi - due 2012-07-09].

SD: I just wanted to comment on the mandatory list. I wanted to say that in the standards space, anyone implementing specs, at least in the first implementation, can more or less skip through all the optional requirements.
... If we don't have a list of mandatory requirements, implementors may do different things.

<hhalpin> +1 sdurbha, we should probably specify some minimum mandatory requirements, lest test-cases and compliance are difficult

Asad: I looked at Ryan's proposal for the low level API. I think it's a good proposal. It's a nice set of APIs. I like the consistency … regardless of what the algo is, we should use the same call signature and get back a crypto stream.
... I was wondering whether we should add a cancel. Because if the crypto algo is taking too long, application can backtrack. Another option might be a reset.
... A reset may come in handy for building hashes.

HH: My quick point would be we can use the general steam Ryan proposes, but for compliance, it would not be [a bad idea] to stipulate a core set of algorithm objects, alongside optional ones.

RS: As far as mandatory, they weren't mandatory for image, video, etc. For better or for worse. I don't know how "webby" it is to do that. In 5 years, what does spec. compliance mean?

<hhalpin> or a new version of the API is possible

RS: If some algo is flawed -- e.g. PKCS2 -- if we remove something, an implementation is then non-compliant. So new user agents need to deprecate, OR an old implementation isn't able to update.

<hhalpin> if there are major changes in the crypto landscape

RS: there's going to be a core set of algos (with exact spec) but I wonder if there's a way to address that as a supplement, and not core spec.
... with respect to cancelation and cloning, I don't know if theres's a way to reasonably implement cancel.
... There's not a real way to cancel the operatoin.
... Beyond removing all references to the object, and letting it be handled by the JS garbage collection model.

<JimD> Well said, RS

RS: As we start defining more of the spec., we can probably address this with the JS clonable model. If you have a hash object, and you clone it, internal state is replicated. That might be a way to support duplication.

SD: The issue of listing requirements in any spec is not new; that's why we have versions. Implementations can be called out as being compliant with version 1.x etc.
... I don't see a big problem in identifying which implementation is identifying what, etc.

JD: I don't know if we allowed for external objects, e.g. smart cards.

VG: We did say a smart card would be a possible means of adding an algorithm.
... Speaking of mandatory vs. optional, what I would like to have, because Harry is pushing us to use Tracker, etc., we should have two actions.

<scribe> ACTION: Ryan Sleevi to come back with a description of naming algorithms. [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action04]

<trackbot> Created ACTION-4 - Sleevi to come back with a description of naming algorithms. [on Ryan Sleevi - due 2012-07-09].

<hhalpin> ACTION: rsleevi a discussion to have a proposal for mapping strings to algorithm ojbects [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action05]

<trackbot> Created ACTION-5 - A discussion to have a proposal for mapping strings to algorithm ojbects [on Ryan Sleevi - due 2012-07-09].

HH: A process for subtracting algorithms, may avoid the problem of creating new versions of the specification.

<hhalpin> but I'm having trouble imagining what compliance means if we don't have a minimal set, or at least one :)

<hhalpin> +1 comments

Karen: I think the API should specify a call list. If we don't specify a required list, how do you give developers confidence that they can write an app against that specification (algo)?
... I don't see a problem of list changes.

+1 to hhalpin's suggestion of exploring a subtraction mechanism

Karen: For the API itself, it should not have anything to do with the smart card. That can be an implementation.

<JimD> +1 to black list

Eric: I don't think it's a disaster if there's no mandatory implement. That indicates to developers what they might do or not have to do. If browser vendors can't agree on what algorithms to implement, probably not going to do them anyway.

<hhalpin> although I might point out not having a mandatory video codec is something that W3C is trying to fix :)

Eric: notion that algos change might not be as important as people think. Many crypto algo has not changed for 20 years. I don't think we need a mechanism for removing them.

<ekr> The mandatory video codec thing is incredibly controversial, as you know.

RS: Simllar to what Eric said, problem with web platform, is you have UAs that live on for decades. And so the concern with mandatory route, web applications are going to have to do discovery or checking. They're still going to have to check.

<ekr> I concur that robustness and discovery are important

RS: I don't think that a mandatory list will necessary improve the interoperability. You'll find old versions of the UA. And web applications will still have to be designed with robustness in mind. All the things we mark as mandatory will probably be implemented anyway.

<drogers> ..and integrity of the list of algorithms and browser version...

<ekr> It might be nice to have a list somewhere on the site that described who had implemented what.

<drogers> (my two thoughts!)

<hhalpin> ISSUE: should we have mandatory algorithms?

<trackbot> Created ISSUE-1 - Should we have mandatory algorithms? ; please complete additional details at http://www.w3.org/2012/webcrypto/track/issues/1/edit .

RS: we may just use "mandatory" for testing.

Karen: There's an alternative: we don't say mandatory, just say recommended.
... all new applications should not be using MD5, for example.

<ekr> I think that's confusing recommendations to Web site vendors with recommendations to UA implementors.

Karen: the world moved forward. We should recommend folks to use better algorithms. Some cloud providers recommend you don't use SHA-1, instead use SHA-256
... even if we don't go mandatory route, we should do recommended.

<JimD> Or "objective" and "threshold" requirements if we're concerned about syntax

<ekr> There are good reasons why I might need to use MD5 (e.g., I need to interop with someone who is using MD5). Why is it the browser's job to tell me I can't?

VG: Try to make the exercise to see if we can find a common set of recommended algorithms.

HH: we need change proposals for the spec. So actions should generate proposals. That might close the issue.

David: I can help out with a minimal set.

SD: I can help :)

<hhalpin> ACTION: drogers and sdurbha to draft a minimal set of mandatory algorithms, ideally compatible with the strawman proposal from rsleevi [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action06]

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

<hhalpin> ACTION: drogersuk and sdurbha to draft a minimal set of mandatory algorithms, ideally compatible with the strawman proposal from rsleevi [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action07]

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

<ekr> If I understand this proposal correctly, that is that this is a key attribute? Then I'm fine with it

<rsleevi> ekr: Correct

<ddahl> ekr: yep

rsleevi: The behavior of the .result is interesting. The ArrayBufferView or "type any" where the algo specifies the result. WTC raised the point that when doing streaming decryption, that result contains the full result. Similar to File API. His thought was should .result only contain the only result from a previous onprogress call?

<ekr> arunrunga: that was rsleevi

<ekr> Not that I would be embarassed to have rsleevi speak for me :)

<ddahl> ddahl: I felt that a good compromise for the issue of being able to access the private key material - by default, the private key material is not accessible, if , while creating the key, the caller specifies that the key should allow private key access, then the private material is available as a key attribute

Karen: It's a good idea to have this crypto object. However, for example, when I see a function called encrypt() I expect the function does the encryption for me. But instead, the output is a crypto stream.

<hhalpin> +1 private key material resolution, shall we try to add that to the spec?

Karen: it might be better to have a more explicit name from a programmer's perspective. Also why do we call it CryptoStream?

<ddahl> hhalpin: i think so

<hhalpin> ddahl: want to give it a shot in WebIDL?

<rsleevi> Karen_: CryptoStream/CryptoOperator I think are reasonable names. My original draft had called in CipherOp, but I wanted to highlight the fact that it was a streaming (in the sense of data) API

<ddahl> hhalpin: yes

<hhalpin> ddahl: wtc is on vacation till July 9, so I'd just give it a shot yourself

RS: the question is whether .result contains the accumulated result, or the most recent output based on inputs? The idea is that the JS behind doesn't maintain the entire data set in memory.

<ddahl> hhalpin: will do

<hhalpin> ACTION: ddahl to add to spec having an attribute for making private key material inaccessible with default being private key material being accessible [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action08]

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

RS: The exact semantics of when that .result is available depends….

<ddahl> hhalpin: does the action system need my w3 username?

<rsleevi> arunranga: ekr is speaking

Eric: Both encryption and decryption, there's always some latency.
... It's important to write this carefully. Just because data goes in, no guarantee that it comes out again.

RS: That's why in current proposal, .result has all the data.

<Karen_> Ryan: I see your point. May be CipherStreamOp? After all, it is an operator but not a stream itself.

Tools, edition, action and issues – 30 ‘

VG: Identification, Management, and Discovery are still three issues.

DD: from low level API, I don't think Ryan has attempted to work out key handling.

<hhalpin> who gets that action?

<rsleevi> ddahl is right, it's still stewing, putting together the different use cases & the different security requirements

DD: I'm happy to work on key identification. With Ryan's help, I'd be more than happy to continue working on that.

<hhalpin> ACTION: ddahl to produce a proposal for adding some key identification/handling methods to the API [recorded in http://www.w3.org/2012/07/02-crypto-minutes.html#action09]

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

tools, actions,issues

<hhalpin> https://www.w3.org/2012/webcrypto/track/

HH: one thing we'll be using from now on is Tracker.

<hhalpin> trackbot in IRC

HH: ^^

<ddahl> hhalpin: rsleevi: should we add another action where we add the low-level API proposal to the draft spec?

<hhalpin> http://www.w3.org/2005/06/tracker/

<rsleevi> ddahl: Yes, I believe so

Group Life – 5’

<ddahl> rsleevi: cool. do you have cvs access all configured for your account?

<rsleevi> ddahl: Yes

<ddahl> rsleevi: great

<hhalpin> http://www.w3.org/2005/06/tracker/email

<hhalpin> Title: "ACTION-42 meaning of life answered"

HH: (Explains Tracker, Action, and W3 Bugzilla)

<hhalpin> "ISSUE-MANDATORY some discussion notes for API"

VG: Please register for F2F.
... We will work on the F2F agenda. Submit contributions to agenda items.

HH: Book hotels ASAP.
... Hotels in MV are booking up already.

<virginie_galindo> https://www.w3.org/2002/09/wbs/54174/WebCryptoJulF2F/

<hhalpin> Meeting adjourned

<hhalpin> trackbot, end meeting

Thanks bye

- DRAFT -

Web Cryptography Working Group Teleconference

02 Jul 2012

Attendees

Contents