Web Cryptography Working Group Teleconference -- 14 Nov 2013

<trackbot> Date: 14 November 2013

<virginie> hello malaclyps

<virginie> do you wanna join us on the teleconference ?

<malaclyps> nope, i'm fine! i just hang out on the IRC channel

<virginie> oki, just tell us if there are special stuff you would like us to address

<virginie> (by the way, good to see you have some interest in our work :))

<hhalpin> we can hear you

<virginie> hello Jyates, we will redial with other credentials

<virginie> (as the call was wrongly scheduled for one hour)

<virginie> can u hear us joanne ?

<rbarnes> trying to dial in over Zakim

<rbarnes> what's the passcode?

<jyates> I can hear a bit, Should I try calling in again?

<jyates> I used 26633

<virginie> to joanne : i think that is fine

<virginie> to remote attendees, please mute your phone, we hear you :)

<wseltzer> rsleevi, zakim wants a ?

<jyates> OK

<jyates> I'll call back in in 15 or 20 mins.

<rbarnes> btw, it's lat-ish here, 5pm. obviously it will be pretty late by the time we're done for the day

<jyates> It is 8:00 pm here

<virginie> really thnaks the motivated person attending remotely the call

<jyates> I won't be able to listen for more than an hour or two.

<virginie> that already something !

<virginie> to all remote and present attendees, we will start in 5 minutes

<rbarnes> eke and i are in the room here

<rbarnes> s/eke/ekr/ DYAC

<rbarnes> ekr

<rbarnes> audio is very fragmentary

<rbarnes> and very echoey

<hhalpin> Scribenick: hhalpin

<jyates> agree--audio is echoey and fragmentary

Intros

Samsung

<ekr> audio is truly useless

Tencent

Anders, PrimeKey

Karen, ISOC

Michael Hutchinson, Gemalto

LG Electronics

Israel, MS

sangrae, jin from ETRI

Kbit

Pozitron

Anne, Mozilla

<ekr> hhalpin: can one of you try something in the voip area.

<jyates> better now

<rbarnes> much better

<ekr> much much better

virginie: 55 participants, 26 orgs, 1.5 years running
... realistically, about 15 contributors on 3 specs
... API, Use-cases, and Key Discovery

<rbarnes> slide link?

<rsleevi> er, wrong copy/paste

<rsleevi> http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda

virginie: objective is to stabilize and go for Last Call after this meeting

note that I'm not suggesting, that's what the charter says

Once we got to Last Call, we'll be there till June and then CR

virginie: make sure we answer any comments and review

<rbarnes> would like some time to talk about WebRTC and how they want to use WebCrypto

rbarnes: Time for how WebRTC will use WebCrypto

<ekr> zakim: who is here?

rbarnes: Will send an email comparing the specs

<rsleevi> http://www.w3.org/2012/webcrypto/wiki/images/5/5c/W3C_Web_Crypto_WG_status_tpac2013.pdf

rsleevi: do we recharter to take on Web Certificate API, given that its on the milestones?

thinks that a Certificate API would likely require re-chartering

virginie: It's just a possible objective, we can discuss

<rbarnes> virginie: you don't need to *shout* :)

<channy> is certificate API included in Secondary API Features?

And test-suites, we have to do test-suites and interop report before exiting CR

It's after CR that things tend to slow down dramatically

virginie: Web Security breakout feedback
... lots of people, more than 40 people in session
... AOB?

Web Crypto API

rsleevi: feedback from implementers
... lots of new issues from implementing in WebKit
... want to hear issues from MS who also implemented
... hopefully no more design issues, more ambiguity in wording spec
... hopefully next version can fit all these implementers in
... in the bugs, things are moving well

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=---

<rsleevi> there's the bug list for those following at home

virginie: any news on more implementers?

rsleevi: On Chromium and Blink side, which will bubble up to Opera
... we are in process of implementing

<rsleevi> http://msdn.microsoft.com/en-us/library/ie/dn265046(v=vs.85).aspx

<rbarnes> can't hear

<rsleevi> ^ MSFT implementation

israelh: We are implementing, Netflix uses our implementation
... lots of internal people asking about it
... polyfilling promises and catching up to the new version
... based on events currently

<rbarnes> PolyCrypt team is working on implementing in Firefox, including some variant that provides access to smart card functions

virginie: Mozilla?

israelh: lots of TPM requests

<rbarnes> we also made a Firefox extension that uses some horrible hacks to do webcrypto using NSS https://addons.mozilla.org/en-US/firefox/addon/foxycrypt/

<annevk> (I don't know the details with respect to Mozilla's implementation.)

rsleevi: would like feedback from MS on Apple's comments

notes that INRIA is also doing a polyfill and is likely to do an analysis of the API

<rsleevi> http://www.w3.org/2012/webcrypto/track/issues/open

<rsleevi> ISSUE-9?

<trackbot> ISSUE-9 -- what will be the mean to integrate in the API the fact that key usage may need user consent ? -- open

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

rsleevi: in our very first f2f does our spec need to make any guidance?

<rbarnes> +1 to closing

israelh: do we need to keep track of this for v2.0?

<rbarnes> i think we can re-open a new issue if/when we get around to key stores that will require it. the question will come up anyway

rsleevi: would prefer to close these issues

<rbarnes> israel is not audible

israelh: one suggestion to a link to a list of issues for future versions

we should just make a wiki page for v2.0

and then close the issues

<rsleevi> ACTION: hhalpin to create wiki to track V2 next [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action01]

<trackbot> Created ACTION-123 - Create wiki to track v2 next [on Harry Halpin - due 2013-11-21].

also, note that in last call we might create new bugs/issues, the goal here is to close all issues/bugs brought up by the WG itself so far.

mountie: this is an implementers issue re UI

rsleevi: we are discussing v2.0 issues, we can just add those to future version issues

MichaelH: We need a mechanism for passing authentication through the API
... i.e. something happens in a GUI so that an App or UA does it, but we need some way to pass it through

rsleevi: similar to MS smartcard implementation
... none of that is covered in the spec right now
... the smartcard issue is more in version 2
... we will need to solve that for future forms of key storage
... but we havne't heard from any UA implementers re providing this

virignie: we should close issue but address topic in version 2.0

israelh: do we have in current spec, a UA-defined UI?
... doesn't seem to be?
... unless we have very concrete use-case, I'd prefer to avoid UI/UA
... we ask for consent in IndexedDB?
... that's a UI from the UA?
... we want to store key
... we want to show a UI for accessing that key managed by the UA
... not sure if I understand the scenarios

mete: I don't think spec should make UI recommendations
... but we will need some kind of authentication to use the keys
... not thinking of smartcards, I'm thinking of any kind of key storage like ordinary software keychains
... directly related to implementers role here, is there a way to securely enter something like a PIN?
... this increases usability of API

<rsleevi> +1 to close ISSUE-9

<mountie> 1+

<rbarnes_> +1

<mete> +1

<rsleevi> PROPOSAL: Close ISSUE-9

<mountie> +1

<israelh> +1 to close ISSUE-9

<kodonog> +1

<Anders> +1

<sangrae> +1

<jinsh> +1

<slightlyoff> +1

<rsleevi> RESOLVED: ISSUE-9 to be closed

<rsleevi> ACTION: MichaelH, mete, and Mountie to work on V2 use case wiki to discuss UI (and UA UI) for handling smart card authentication [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action02]

<trackbot> Error finding 'MichaelH,'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.

<rsleevi> ACTION: Michael, mete, and Mountie to work on V2 use case wiki to discuss UI (and UA UI) for handling smart card authentication [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action03]

<trackbot> Error finding 'Michael,'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.

<rsleevi> israelh: There might be differing characteristics when discussing different types of key storage

<rsleevi> ... that is, some keys may be long lived

<rsleevi> ... need to keep in mind the lifetime of the key based on the mechanism used to store them

<MichaelH> * At URL Michael Hutchinson MichaelH

<rsleevi> ... ex: with IndexedDB, most UAs have the ability to clear these databases

<rsleevi> ... If you reset the IndexedDB, you may find content is no longer available

<rsleevi> hhalpin: Users have different expectations with regards to private key material

<rsleevi> ... developers may have different expectations

<rsleevi> israelh: there are different security boundaries based on where you create keys

<rsleevi> ... we should document at the UA level when we expect different things to be obfuscated

<rsleevi> ... this is likely to be per-UA specific, but there may be common patterns

<rsleevi> hhalpin: Some people may be coming to the application with the expectation that when you create a key, and then try to use the key, there should be UI

<rsleevi> ... I think a lot of issues we have open right now are related to different mental models of how the API is working

<rbarnes> i think i agree with ryan. the nature of key storage is currently out of scope, and adding guarantees as to how keys are stored would be a major scope increase

<rsleevi> hhalpin: ex: of Dr. Boneh's comment - if you say nothing about the storage of key material, there will be different expectations about how the key is stored

<rbarnes> the keying material is available as defined in the specification -- pretty much available to the user, only available to the server/JS through the API

<rsleevi> virginie: on ISSUE-9, we are done

<rsleevi> mountie: For key material, whether key material is accessible to user or server, both are correct

<rsleevi> ... need some consideration from the server side about password policies, two factor, etc

<Anders> comment: key material storage is not addressed by <keygen> or "CertEnroll" either so this question goes beyond WebCrypto

<rsleevi> ... need to also consider other security requirements for protecting key storage

<mete> +1 to mountie's comment in general

<rsleevi> ISSUE-10?

<trackbot> ISSUE-10 -- Making sure our API is usable with pure js environement -- open

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

<rsleevi> rsleevi: This issue was originally raised with a concern over DOM events

<rsleevi> ... broadly speaking, the question is whether or deliverable must consider environments like node.js

<rsleevi> PROPOSAL: Close ISSUE-10

<rbarnes> +1

<israelh> +1

<slightlyoff> +1

<sangrae> +1

<jinsh> +1

<rsleevi> israelh: Agree that this issue can be closed; Promises should address this

<rsleevi> +1

<mountie> +1

<kodonog> +1

<mete> +1

<rsleevi> RESOLVED: ISSUE-10 to be closed with no further changes to the spec

<rsleevi> ISSUE-12?

<trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open

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

<wseltzer> trackbot, close issue 10, no change

<trackbot> Sorry, wseltzer, I don't understand 'trackbot, close issue 10, no change'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<trackbot> Closed issue-10.

<trackbot> Closed issue-9.

<annevk> FYI, KeyUsage[] keyUsages = [] needs to be sequence<KeyUsage> keyUsages

<rbarnes> q for rsleevi: the current spec does not require encrypt() to verify that key.algorithm matches algorithm (the method argument). is this deliberate

<MichaelH> http://lists.w3.org/Archives/Public/public-webcrypto/2013Oct/0029.html

<rbarnes> this is related to ISSUE-12

<rbarnes> if the comparison needs to happen...

<rbarnes> then the dictionaries need to be comparable

<rbarnes> currently key.algorithm is generation stuff

<rbarnes> algorithm the argument is operation stuff

<rbarnes> { name: "AES-CTR", length: 128 }

<rbarnes> vs. { name: "AES-GCM", "iv": "...." }

<rbarnes> yep, that's right

<rbarnes> question: is the intent to allow a CTR key to be used for GCM? or to prevent this

<rbarnes> good, i like that answer. nodding here

<rbarnes> so then the spec needs to have a comparison of algorithms

<scribe> Scribenick: hhalpin

<rbarnes> and there needs to be a spec for how the algorithms are compared

virginie: Are you OK to close this issue?

rsleevi: sounds like bugs to be opened against spec
... these 1) operations need to check if the algorithm matches the key-type
... 2) needs to be clarified if the name or parameters used for the key
... RSA-PSS, generating a key with SHA-1 with intended hashing, but then using it to sign re SHA-256

<rbarnes> right, (1) do the comparison (2) how to do the comaprison

<rbarnes> that accurately captures my concern

<rbarnes> i will open these bugs if you want me to

<rbarnes> yep, will do

<rsleevi> ACTION: rbarnes to file bugs following this discussion [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action04]

<trackbot> Created ACTION-124 - File bugs following this discussion [on Richard Barnes - due 2013-11-21].

mete: I think I understand re parameters
... for me, I'd separate the keys and operations
... even if it is the case for current algorithms that if we combine the params, it would be not that confusing, this may not hold for future algorithms

rsleevi: let's say you are using AES encrypt
... should we have IV in algorithm
... is it current value or does the IV get dropped entirely so we make sure we get a new one when we start?
... but we don't have that right now, we just have data and parameters

mete: it's still confusing but I think we get your point

rsleevi: with promises approach, we avoid lots of these problems

<virginie> Time management --> note that we are 3 minutes away from the break

israelh: one of the fundamental concerns is that this is fine for one part, but not for multi-part.
... I think promises addresses his concerns

rsleevi: regardless of asymmetric or symmetric, we always get a key
... parameters like IV are not used for all forms of encryption, not all forms
... like asymmetric doesn't use IV, so the IDL needs to represent signature for different algorithms
... not different signatures per algorithm

<rbarnes> the rationale ryan is citing is why i proposed separation out (1) parameters that define an algorithm (e.g., name, mgf) from (2) parameters that define an instance of the algorithm (e.g., iv)

<kodonog> +q

rsleevi: all parameters are optional in WebIDL, that's historical

<rbarnes> ironically, audio dropped out off and on while karen was relaying my comment ;)

<rbarnes> encrypt(algorithm, params, key, data)

<rbarnes> encrypt( { name: "AES-GCM" }, { iv: "..." }, key, data)

<rbarnes> so i think it's workable to separate, but am willing to live with it together

<slightlyoff> every army runs on its stomach ;-)

<virginie> proposed resolution : we keep the issue-12 open until we get feedback from vgb (microsoft) + resolve the 2 related bugs (having in mind we wanna adress it in the 2 coming weeks)

<rsleevi> rbarnes: Right, that was the 'double dictionary' approach I was mentioning earlier; not very common (I can think of no API that does it), and the need for it is less so because of the CryptoOperation.algorithm

virginie: let's keep issue with vgb

<mete> +1

<kodonog> +1

<rbarnes> +1

<Anders> +1

<jinsh> +1

<rsleevi> PROPOSA: Keep ISSUE-12 open. Resolve this in 2 weeks following feedback from rbarnes and vgb

<MichaelH> +1

<rsleevi> PROPOSAL: Keep ISSUE-12 open. Resolve this in 2 weeks following feedback from rbarnes and vgb

<israelh> +1

<rsleevi> +1

<mountie> +1

<sangrae> +1

<slightlyoff> +1

<rbarnes> rsleevi: not sure how CryptoOperation.algorithm addresses this/

<rbarnes> ?

<rbarnes> that's just the end of the line above :)

<rsleevi> RESOLVED: ISSUE-12 to be kept open.

<rsleevi> break; return in 40 minutes.

<rbarnes> have we started back yet?

<mete> not yet

<rbarnes> tsk tsk, not very punctual

<jin> Nick is changed from jinsh to jin

<rbarnes> hearing bits and pieces of audio

<rsleevi> ISSUE-28?

<trackbot> ISSUE-28 -- Short-names for algorithms -- open

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

<rsleevi> scribenick: kodonog

<virginie> hey, go back to work !

<rbarnes> i'm here

<rbarnes> and can hear you kind of ok

<virginie> which issue are we talking about ?

Issue 28: came from jose, propose a mapping from JWA algorithms to webcrypto algorithm

came from jose, propose a mapping from JWA algorithms to webcrypto algorithm

ryan suggests that there is an action for creating a mapping from JWA algorithms to web crypto algorithms, but not sure where this lands

<rbarnes> so if we close this as wont fix, does the "or DOMString" go away?

<rsleevi> no

<rbarnes> but it would be limited to something that would go in the "name" field

technical mechanics are in place and more a procedural item to describe where

<rbarnes> given that efforts to align WebCrypto and JOSE have pretty much been abandoned, i don't really see any value in standardizing a mapping table (it should be reasonably obvious)

<arunranga> +1 rbarnes

<rbarnes> of course, we have no process here for managing WebCrypto algorithms once this WG goes away....

<rbarnes> if someone wants a standard table, they could write a short RFC defining an IANA registry of mappings

if we are going to support JWK we are going to have to figure out what to do about JWA

<rbarnes> as long as there's no collision between "alg" parameters for JWE/JWS and "alg" parameters for WebCrypto, there's not an issue for JWK. of course, the question of how to ensure that is tied up in how the individual algorithm registries are maintained

<rbarnes> audio is kind of lossy, but i'm managing to mostly follow along

<rsleevi> ACTION: virginie to coordinate with W3C contacts and IETF/IANA about how this works [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action05]

<trackbot> Created ACTION-125 - Coordinate with w3c contacts and ietf/iana about how this works [on Virginie GALINDO - due 2013-11-21].

<rsleevi> Possible actions:

<rsleevi> 1) JOSE takes it as part of their JWA registry

<rsleevi> 2) WebCrypto takes it as part of their algorithm dictionary

<rsleevi> 3) new IANA registry to align the two - independent of the JWA registry or WebCrypto spec

<rsleevi> 4) Remove the feature

<rbarnes> one possible solution: JOSE has a "places where this token may appear" column in their algorithm registry. we could register algorithms there with a note that they may only appear in WebCrypto

<rsleevi> 1-3 all seem preferable, but 4 is an option of last resort

<rbarnes> (if we want to avoid conflict with JOSE)

<rsleevi> but if we want to support JWK, we need to figure out what it means for import

<rsleevi> ISSUE-28?

<trackbot> ISSUE-28 -- Short-names for algorithms -- open

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

<rbarnes> is the result of closing that there's no action w.r.t. the current spec? or is there a change?

<rbarnes> ok, so it's pending the ACTION. we can close, then, pending that

proposal: keep #28 open until the action #125 is done

<mete> +1

<mountie> +1

<israelh> +1

<rsleevi> PROPOSAL: Keep ISSUE-28 open until ACTION-125 is resolved.

<jin> +1

<MichaelH> +1

<sangrae> +1

<rsleevi> ISSUE-32?

<trackbot> ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open

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

ryan: recommends closing with no change

Israel: do we have anything in the spec that says this version of the spec doesn't apply to smart cards?

<rbarnes> IMO, the secure element API is going to be a pretty separate piece of work

rsleevi: yes, in a couple of places...

<rbarnes> FWIW, the approach we're taking in our experiments is something like window.crypto.tokens[i].<current API>

Israel: make a statement that we don't support or guarantee the lifetime of the keys

<rbarnes> yes, <current API> is the WebCrypto spec

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security-developers

rsleevi: last sentence of above reference is answer to Michael's question

<rsleevi> ACTION: israelh to make text proposal to provide clarification that the API provides no guarantees regarding key lifetime [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action06]

<trackbot> Error finding 'israelh'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.

<MichaelH> Q: Does the extractability attribute cause a problem if the key material is stored in plain file system

-q

<rsleevi> PROPOSAL: Close ISSUE-32 with no further action

<rbarnes> MichaelH: No, it doesn't. Extractability is just about visibility to JS, not to other things on the host.

<rigo> ACTION: Israel Hilerio to make text proposal to provide clarification that the API provides no guarantees regarding key lifetime [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action07]

<trackbot> Created ACTION-126 - Hilerio to make text proposal to provide clarification that the api provides no guarantees regarding key lifetime [on Israel Hilerio - due 2013-11-21].

<rsleevi> PROPOSAL: Close ISSUE-32 with no further action; postpone discussion of key storage to V2

<rsleevi> +1

<rbarnes> >>>PROTOCOL: I will prefix comments to be relayed with MIC. Everything else can be left as back-channel chatter

<MichaelH> +1

<mete> +1

<mountie> +1

<israelh> +1

<rbarnes> +1

<sangrae> +1

<jin> +1

<rsleevi> RESOLUTION: ISSUE-32 closed;

<rsleevi> ISSUE-35?

<trackbot> ISSUE-35 -- Handling of wrap/unwrap operations -- open

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

<rigo> trackbot, close issue-35

<trackbot> Closed issue-35.

<rigo> trackbot, reopen issue-35

<trackbot> Re-opened issue-35.

rsleevi: issue created by Mark after first F2F,

<rigo> trackbot, close issue-32

<trackbot> Closed issue-32.

rsleevi: defer until Mark joins us, may want further discussion on the double wrapping case

<rsleevi> ISSUE-36?

<trackbot> ISSUE-36 -- Semantics for key generation versus key derivation -- open

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

concrete steps to closing this issue, get Mark's feedback on the concrete steps, may be satisfied with current solution

<rigo> issue-36?

<trackbot> issue-36 -- Semantics for key generation versus key derivation -- open

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

action for richard and vijay to come back with a proposal on how to resolve this, they did, a slightly different variant was incorporated into the current spec

<trackbot> Error finding 'for'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.

current solution is similar in spirit

<rbarnes> lost you guys!

<rbarnes> np

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-SubtleCrypto-method-deriveBits

proposed solution is in the spec as referenced by the above link

if you want to use the raw bits from some secret agreement, derived keys and derived bits as distinct

<rbarnes> MIC: i think that fixing this problem in general will require some fairly radical re-engineering, basically generalizing the concept of what can be inside the envelope beyond just keys to arbitrary octet sequences. keeping the current solution will cut off some use cases / protocols, but i would be ok with that for v1. it would be good if we could at least get a basic scenario to work, using pair-wise DH to get a symmetric key.

<rbarnes> rsleevi: closer to mic?

<rbarnes> thanks!

<rbarnes> net of all that, i'm ok with what we've got :)

<rigo> trackbot, ACTION: Richard Barnes and Vijay Bharadwaj to come back with a proposal on how to resolve ISSUE-36. Reference, they did a slightly different variant that was incorporated into the current Draft

<rigo> ok

<rbarnes> MIC: i need to review what's there. i think it's close enough that any deltas can be filed as minor new issues.

<rbarnes> ... and thus we can close this one. vgb might disagree

MichaelH: want to understand the security considerations

<rbarnes> closer to mic please

If a key that you are using for derivation supports both derived keys and derived bits, then derived bits will allow that...

<rbarnes> virginie is pretty clear now

<MichaelH> @rbarnes clear or loud?

Virginie: we could have a consensus to close ISSUE-36 pending review from vijay. Relative to derived bits, check that it is acceptable.

<rbarnes> there are some codec/loss issues, but net of that i think they're ok. louder helps overcome some of that i think.

<rbarnes> MIC: the one thing that's not immediately clear to me is how you would generate a long bit stream and slice parts into keys, IVs, nonces, etc

<rbarnes> MIC: ryan, is there a plan for this that i'm missing?

<rsleevi> ACTION: vgb to review proposal for deriveBits by Friday, November 15 [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action08]

<trackbot> Created ACTION-127 - Review proposal for derivebits by friday, november 15 [on Vijay Bharadwaj - due 2013-11-21].

that's what derived bits does. derived bits has a parameter a length,

<rbarnes> MIC: so if i wanted to get (key, iv, nonce) out of a derivation, i would deriveBits, slice, then re-import the key?

rsleevi: correct

<rbarnes> makes me kind of sad that the key has to leave the boundary, but i can live with it

<rigo> trackbot, associate action-127 with issue-36

<trackbot> action-127 (Review proposal for derivebits by friday, november 15) associated with issue-36.

up to the application to do whatever specific processing is required

<rsleevi> ISSUE-41?

<trackbot> ISSUE-41 -- Clean up algorithm normalization and support checks -- open

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

<rigo> issue-41

<trackbot> issue-41 -- Clean up algorithm normalization and support checks -- open

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

<rbarnes> i need to swap in state on this. next issue?

<rsleevi> ISSUE-43?

<trackbot> ISSUE-43 -- Separate method for key agreement -- open

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

<vgb> hi this is vijay

<vgb> noticed i now have new actions :)

<vgb> sorry, audio is choppy so i will follow along but won't try to talk...

rsleevi thinks derived bits should be the answer...

<rbarnes> ready for ISSUE-41 when you are

<rsleevi> ISSUE-41?

<trackbot> ISSUE-41 -- Clean up algorithm normalization and support checks -- open

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

<rbarnes> MIC The current text conflates the notions of "registered" and "supported". That is, it doesn't allow implementations that supprot un-registered algorithms (e.g., experimental or local algorithms). The proposal is to decouple these to notions.

<rbarnes> "If normalizedAlgorithm does not describe a registered algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm." <-- so if I support a non-registered algorithm, I can never execute it

<rbarnes> ^^^ that's the current text

<rbarnes> yes

registered and supported were meant to be equivalent terms

<rbarnes> MIC so you're saying that UAs MUST NOT implement algorithms that are not registered in this spec?

<rbarnes> then i'm confused :)

if the issue is we should use supported instead of registered that is fine, if registered then within the UAs implementation

<rbarnes> SHOULD NOT is fine

<rbarnes> i would like to see text

could we delete the word registered

<mountie> +1 for SHOULD NOT

<rbarnes> i think that's ok

<rbarnes> there were a couple of other edits in the bug, but maybe we can hammer those out offline

goal of language what should a UA do if it encounters an algorithm that it doesn't support

any UA that did not support that algorithm who have a defined behavior

<rbarnes> i would propose we keep this open for ryan to propose text

<rbarnes> here's what's proposed in the bug:

<rbarnes> If normalizedAlgorithm does not describe a recognized algorithm, throw an AlgorithmNotSupportedError exception and terminate the algorithm.

<rbarnes> If normalizedAlgorithm does not describe an algorithm that supports encryption, throw an OperationNotSupportedError exception and terminate the algorithm.

MichaelH: If you don't have an operation to perform you regurn an error.

possible interpretations 1) no idea what AES-CBR means; 2) knows what AES-CBR is but doesn't support it; 3) knows and supports AES-CBR

for each case, need to have a defined behavior for what the UA will do

<rbarnes> MIC: (1) and (2) are equivalent, AlgorithmNotSupportedError

Israel: can we not just follow the same pattern in the current spec. This is a natural equivalent ...

<rbarnes> understood & supported == win!

understood and not supported along with not understood and not supported have consistent behavior

<rbarnes> we could close right now if we just adopt the text in the bug :)

<virginie> proposed text : "If normalizedAlgorithm does not describe an algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm."

<rsleevi> +1

<rbarnes> i can live with that, but note that it still conflates "i don't know this" with "that algorithm can't encrypt"

<rbarnes> more of a DontWorkExcpetion

<rbarnes> that's the reason for AlgorithmNotSupportedError vs. OperationNotSupportedError

<rbarnes> but i'm hungry, so i don't care that much :)

<rbarnes> at this point, i think we've got sufficient joint understanding that ryan can implement some text

rsleevi: but this is a perhaps a spec bug

<rigo> issue-41:proposed text : "If normalizedAlgorithm does not describe an algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm."

<trackbot> Notes added to issue-41 Clean up algorithm normalization and support checks.

close issue with proposed text and open a spec bug

<rsleevi> +1

<mete> +1

<rbarnes> +1

<israelh> +1

<sangrae> +1

<MichaelH> +`

<jin> +1

<MichaelH> +1

<Anders> +1

Mountie: one question before +1... are you willing to keep the list of algorithms in the spec

<rigo> issue-41: closed with the proposed text from bug tracker

<trackbot> Sorry, but I think you meant to close issue-41.

<mountie> +1

<rbarnes> yep, i'll be here after lunch

<rsleevi> Break for 90 minutes

<rigo> issue-41: agreement on the proposed text from bug tracker

<trackbot> Notes added to issue-41 Clean up algorithm normalization and support checks.

<rbarnes> ok, see you then

<jin> exit

<rigo> trackbot, close issue-41

<trackbot> Closed issue-41.

rsleevi: answer to mountie, that is a separate discussion

<nvdbleek> hi

<Bert> Scribe: Bert

<rbarnes> working on connecting

issue-46?

<trackbot> issue-46 -- Optional algorithm parameters must have default values -- raised

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

<rbarnes> it will be a couple of minutes, so maybe cover an issue that doesn't need me?

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=---

virginie: Wait for input?

ryan: We got VG's
... Over to bug list:

<rbarnes> ok, i'm on

ryan: File a bug against the spec!

<rbarnes> zakim i am aabb

<rbarnes> i have no shame, having filed several bugs :)

ryan: When you're reading something that isn't clear, best is to file a bug
... First bug:

<virginie> Reminder to the new attendees : the agenda is http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda

israelh: all issue have been taken care of?

<hhalpin> \me excellent

ryan: No, waiting for richrd to join phone

richard: I'm here

<rsleevi> ISSUE-44?

<trackbot> ISSUE-44 -- Require creation of random IVs by default for CBC, CFB, GCM -- open

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

<virginie> Reminder to everyone if you wanna queue, talk, standup, walk to the mic and talk

israelh: And vdb's issues?

ryan: ruchard filed issue 44
... Context is:
... 2 aspects, set of algos
... Random generated
... Make is eaiy for people
... by automatically generating.
... One argument is for better security.
... Other is that some guidelines, such as 40-2,
... require it.
... Is that correct, Richard?

richard: yes

ryan: IV param, and any that requies random, also should accept a string "random"
... That was a proposal.
... When we discussed that, how to get IV out,
... But in promises model we don't reflect that out.
... So th eproposal needs further work,
... Not saying it is impossible.
... We can potentially find a solution,
... But how important is it?
... SO maybe no action to be taken.

richard: I can update the proposal.
... It is a bit stale.
... I take an action?

virginie: When you say action, for V2 or for current spec?

rich: Current

ryan: or leave action as it is

MichaelH: Need a vote?

ryan: There have been neither positive nor negative feedback.
... fips 40-3 is revulating the requiremtn.

richard: Encouraging fresh IDs

israelh: In old world, we had instaces that return compound values.
... Sohave to resolve that anyway.

ryan: Say you ascpi operation,
... If you give explicit ID, no need to reflect it back.
... What would API look like when it doesn't require an IV (initialization vector).

richard: You can (scribe missed)

<mete> +q to ask if it could be better to handle these things in high level apis

ryan: We are currently handling dat ain general in the API.
... How do you copy, do you neuter. How make sure data is not mutated.
... We're getting to the point of always makin copies

israelh: With keyword, that optimises the pb.

ryan: You say if caller suplies IV, he gets data back; other wise he gets IV back.
... Related pb:
... Any authenticated data:
... That's a case of multiple outpiuts returned.

israelh: generalizes the whol pb, gives us scale.

virginie: There is n action?

ryan: Restate the proposal:
... In list of algos we talke about return values, araay bffer.
... Return would be dictionary type key-value.
... We may not need it for all algos, but for those that have IV.
... If you specify "auto" (...)

virginie: Potential action to richard

ryan: Propose that richard write proposal. israelh suggested a way.

<rsleevi> ACTION: Richard to update proposal for auto-IV proposal [recorded in http://www.w3.org/2013/11/14-crypto-minutes.html#action09]

<trackbot> Created ACTION-128 - Update proposal for auto-iv proposal [on Richard Barnes - due 2013-11-21].

mete: Understand generatibg IV randomly, but why in low-level API?
... This shoul dbe handled in higher API.
... This is relted to topic of operational params that VJ sent e-mail about.

<Zakim> mete, you wanted to ask if it could be better to handle these things in high level apis

<virginie> hello who is P15 ?

vj: API that a;llows API to cut and paste sample code.
... And get secure program that way.

<rbarnes> serious +1 to vijay on allowing cut/paste to be safe

<rsleevi> cut/paste is never safe :)

<rsleevi> use a high-level API ;)

vj: 1) If we'r egoing to have this behavior that sometimes you return IV with ciphertext,

<rbarnes> rsleevi: yeah, about that.....

vj: I dob't want to clutte rup the value.
... We have effectively separated out operation params
... Don't necessarily give (...) params to call.

israelh: You always get a value back, uou always get the same i/f back.
... Q is if there is an IV in it.

<rsleevi> { data: [...] } or {data: [...], iv: [...]}

israelh: If you pas this particular string, which is default,

<rsleevi> so you always result.data, but may not result.iv

israelh: that the Promise would look it up for you.

vj: I sthere any benefit to be had?

ryan: yes.
... The buffer input to webcrypto,
... in v.1 we are requing,
... either you freeze th einputs,
... an dprevent futher mutation,
... or requirte impl to always copy buffers.
... We would require imple to aways allocate new object.
... And even if that is just 16 bytes, it is a seriuous consideration.
... It is basically an optimization thing. And Webkit is interested in that.

vj: That is valid thing.

richard: What is arg agains neutering?

ryan: The freezing? That would be the first API that does this. Would require changes to WebIDL.
... Downsize with freezing is you force the caller to allways allcoate
... Else would allow sharing.

israelh: They are asynch calls by nature, makes it hartd.

virginie: Richard, want to add anythinh?

richard: support vj on general principles.

virginie: So we already put action on richard.

<rsleevi> ACTION-128?

<trackbot> ACTION-128 -- Richard Barnes to Update proposal for auto-iv proposal -- due 2013-11-21 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/128

virginie: It may req more discussion in WG

<vgb> rsleevi: in principle cut-and-paste is never safe, in practice most code is cut-and-paste :)

virginie: Stays open issue.

eric: From convenince of user, auto string may not be worth it.

<hhalpin> I am going to note the issue as regards randomized IVs is a well-known error that multiple reviewers have brought up

israelh: Question: is is possible to instead of passing a keyword, to just autmatically overload.

<rbarnes> in fact, that was my initial proposal!

israelh: So no need to pass anything.

<rbarnes> cf. ISSUE-46

ryan: Gets a little weird.

israelh: OK

vj: Eric's comment:
... "Why not just random values?"
... pb is that naive programmer has to know how long the IV has to be.

<rbarnes> var alg = { name: "AES-CCM", iv: "random-data" } vs var alg = { name: "AES-CCM", iv: "auto" }

vj: Theymay generate just x bits

ryan: Good argument!

virginie: OK, we'll come back to that later.

ryan: issue 12
... vgbust to restate:

<rbarnes> on the topic of safe parameter choice, there was a great paper at CCS a few weeks ago that found that roughly 10% of apps using crypto used static IVs

<rbarnes> http://www.cs.ucsb.edu/~chris/research/doc/ccs13_cryptolint.pdf

ryan: Came from fact that crypto algo hd param that reflected back what algo was craeted with.

<rbarnes> 88% of apps studied made some sort of bad parameter / algorithm choice

ryan: Could reuse params that you should not reuse.
... IN promises model, we are no longer reflecting algo back.

<virginie> issue under discussion in ISSUE-12 : http://www.w3.org/2012/webcrypto/track/issues/12

ryan: I do' tknow what advantage is of splitting algo and operation params.

<rigo> issue-12?

<trackbot> issue-12 -- Should the API distinguish between algorithm and operation parameters? -- open

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

ryan: Promise does not expose params.
... Programmers have to track the params anyway.
... vgb, your thinking?

vj: th eonly justification is syntactic sugar.

<rigo> issue-12: 88% of apps studied made some sort of bad parameter / algorithm choice

<trackbot> Notes added to issue-12 Should the API distinguish between algorithm and operation parameters?.

vj: I'm sympathetic to that argument.
... We have been trying for month, maybe just let it go.
... There is no good way to do it, so maybe just forget it.

ryan: So no further action on issue-12?

virginie: This morning we had two bugs to be opened for issue-12.
... For richard.

richard: other issues this morning...

ryan: 36

richard: Comparison
... we may yet have to clarify.

vj: Algorithm object?
... comparing normalized version. All that remians is finding normalized.

richard: "compare these and ignore the others"
... The keys that you compars.

vj: Taxonomy defining comparison. Is that in separate dictionaries? That is issue-12.

ryan: Do we expose that to user, or is it implementation?

virginie: So keep issue open.
... But we close issue and open bugs? Should it be other way round?

ryan: We agree what the reslution should look like.

hhalpin: Editor should (...)

israelh: vj said keep it as is.

ryan: spec bug

virginie: is everyone happy?

<rbarnes> the later it gets, the punchier i get :)

virginie: So action is to open a bug in order to "..."
... Any others on issue-12?

<mountie> +1

virginie: Put 1 on IRC if you agree.

<vgb> +1

<sangrae> +1

<jin> +1

<israelh> +1

<rsleevi> PROPOSAL: Close ISSUE-12 with no user-visible changes to the API; a spec bug regarding equality of algorithm dictionaries will be opened, if not already

<nvdbleek> +1

<MichaelH> +1

<rsleevi> +1

virginie: Editor is going ot asnwer the bug

<kodonog> +1

<mete> 0

<rsleevi> Bug is 23098

<rsleevi> ISSUE-36?

<trackbot> ISSUE-36 -- Semantics for key generation versus key derivation -- open

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

vj: I misse dmost of that due to audio pb

ryan: You and jim should put forward proposal.
... You added a new usage for secret agreement, that became derived bits.
... So question for you and riuchard is are you happy with that, does it meet use case?

<rbarnes> i'm still OK with this

vj; In MS crypto APIs is not possible to get out bits of value.

scribe: You can get one rerivation out of it. So it doesn't quite work.

ryan: What you described, sounds like do secret agreement and then get derived key out of that.
... But then you can de derived key to get key object.
... And then you can get derived bits.

vj: It is possible to represent the oepration that way.

ryan: but is it pretty...

vj: Can support it that way for DH.

virginie: Other comments?

vj: I sent a few in e-mail:
... One was about including key material in (...)

ryan: Yes, that is weird.
... Also is it an arry buffer or something else?
... API is inconsistent maybe.

<rbarnes> well, if it's an ArrayBuffer, then the application has to figure out what the text encoding is

vj: (scribe didn't understand)

<nvdbleek> +1 for me too

ryan: We can figure out what it should lok like on th elist.

vj: Other thing:
... Pseudo code for various methods that return an object don't say that it needs to construct an object.
... Most people would say result is a bunch of bytes.
... It doens't say you have to construct key object.

ryan: I take that as a spec bug. I need to inmprove the etxt.

<jmr> list

ryan: There is the den of the algo for derive dkey.
... ECDH example says this is the derivation.
... And says "here is the format."
... that was the intention.
... It is a language bug in my mind.
... Example of derived key returning something else than an obkect:
... Discussion on list was that this was weird.
... Need to keep keys within security boundary.
... Get four key handles back.
... generateKey sometime return key pair sometimes key object.
... If we do SSL case, we can return four key objects. Not saying that we should do that case.
... What obj is returned is similr for every other algo.
... Indiv algo says here is the result of signing th eobject.

vj: Fine with that.
... We generally agree in spirit, some wording to work out.

virginie: issue-36 this morning we agreed, nor vj is fine, so just this bug. Can close isse?

ryan: We created action for you to review. Can then close on next call.

vj: OK close on next call.

<nvdbleek> I'm fine with this too, but a note or other clarification would indeed be welcome, because a colleague of mine had the same problem (not knowing what is returned)

virginie: Everybody OK with 36 and 43 close at next call?
... Admin issue:

<vgb> +1

virginie: Now we have two systems for tracking.

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=---

<rbarnes> btw, the audio is working *very* well this session

virginie: Is everybdy following them?

ryan: Other groups have piblic list.
... I distinction between bugs and issues.

israelh: We have talked in last telcon about promsies model. Do we make an isse so we can close it?

ryan: On eof those design issues. Not just a spec bug.

israelh: I put some example code.
... Make an issue fo rthat?

virginie: Can you do that during the break?

israelh: OK

hhalpin: We have to close all issues for LC, but no need to close all bugs.

ryan: we are likely to open bugs and issues during LC.
... Bugs are quicker than issues to solve.

vj: I looked at doc in Mercurial:
... Is importKey and exportKey an open issue?

ryan: Largely an issue of typing to do.
... Jwk
... 90% is typing issues. No excuse :-)

israelh: Other thing for vj: we also postponed wrap/unwrap to tomorrow morning.

vj: I should be availabel tomorrow whole day.

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&product=Web%20Cryptography&resolution=---

<nvdbleek> on importKey and exportKey we should also agree for jwk if the jwk object is provided as arraybufferview or an object, implementations currently disagree on this

ryan: We have an old bug:
... back in Sep 2012
... Basically hwo we handle algo security stuff.
... What is a good building block?
... We discussed previously a giant algo table.
... With notes where to seek further input.
... We don't wan tto mainain that and update as cryptographer discover more.

virginie: So you propose to add some text?

ryan: Yes, I'll go through those bugs.
... One of the ongoing bugs withou rsoltion:
... raised by mark,
... support jwa algos that Jose does not want to support.
... Marks' language to add registration procedure.
... Discussion ongoing and may become an issue.
... Jose has usage Ink, all in a single param.

<virginie> sorry, which bug number are we dealing with ask the sleepy chair ?

ryan: How does webcrypto interpret this value? Do we need a 2nd value? And what if the values are inconsistent?

<MichaelH> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23796

ryan: If the value from caller is a subset, it succeeds, if in conflict, it fails.
... Spec is not clear yet, people are welcome to jump it on m-list.

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?list_id=29805&regetlastlist=29805

virginie: What bug #?

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?bug_id=18925%2C23796%2C20611%2C19416%2C21435%2C19705%2C22571%2C23013%2C23695%2C23096%2C23017%2C23779%2C23097%2C23159%2C23445%2C23499%2C23655%2C23051%2C23762%2C23729%2C23728%2C22992%2C23098%2C22598%2C23662%2C23660%2C23504%2C23503%2C23501%2C23500%2C23498%2C23496%2C23495%2C23242%2C23043%2C22546%2C22977%2C22860%2C22548%

<rsleevi> 2C22677%2C22639%2C22570%2C23786&list_id=29805&order=bug_id&query_based_on=&query_format=advanced

ryan: next is 19416
... Wrap oper should detect that key is allowed for wrap.

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?list_id=29805&regetlastlist=29805

ryan: spec has a bug that it doesn't say that. So text to write.
... 19705:
... Don't konw resolution.
... Spupply a list of defaults? Can you suply a safe list of defaults?
... If you suplly a usage that isn't supported, it should fail.
... Or people jst have to specify key usage *always" That seem sensible to me.
... I propose option b, key usage is moved aedad of other params and must be specified.

hhalpin: You can imagine distinguishing low-level and high-level API.
... Defaults might be problematic.

<mountie> +q

ryan: No that is not the issue here.
... Default here wa sjust syntactic sugar, not safer.

hhalpin: Even insecure code?

ryan: No, not really.

mountie: Extension has key usage with objective, is there consideration for when extension is aenabled for key usage?

ryan: Unrelated to this bug.
... This is just API semantics.

mountie: If reuse object ID...

ryan: Different discussion.
... You should file a bug for that.
... This bug is call-time semantics, no relation object ID.

virginie: is this going to be future-proff, certifcate.

ryan: Separate issue from what happens when you call (...)

virginie: 19705: other comments?

ryan: Next 20611
... Javascript side.

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20611

ryan: text encoding
... Array buffer withg a sequenc eof bytes, how do you interpret that?
... Should webcrypto interpet it as utf-8?
... It is underspecifed in spec.
... next is 21435

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21435

ryan: as* key length can be inferred from bytes.
... When importing a key do you have to say the length?
... I think it is similar to jwk.
... Caller not required to specify length, because can be inferred.
... In Jwk you can hopefully infer everythng.

vj: If caller specifiesa param and it conflicts?

ryan: Correct: then operation will fail.

vj: Agree. We should never ignore params.

ryan: 22546 was already fixed.

virginie: One more bug and then coffee break.

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22548

ryan: 22548:
... Couple of issues in WebIDL.
... Is "decrypt, decrupt, decrypt" same as "decrypt"?
... Duplicates not preserved, is the proposal

virginie: Comments?

MichaelH: is "decrypt, decrypt" legal?

ryan: yes
... Spec eithe rhas to say it is invalid or what it means.

MichaelH: Seems overkill to put in 3 decrypts.

ryan: yes, but oit has no implications.

MichaelH: Sort them alphabetical and compare?

ryan: does the sortin gmatter?

eric: in JS you can do "in" text

(scribe missed)

ryan: I don't think you can compare arrays directly.
... So have to do it with in-tests
... But it may be sotrted, I don't have preference.

virginie: break for 30 mins.

israelh: And go through the Promises issue?

<israelh> Promises issue 59: https://www.w3.org/2012/webcrypto/track/issues/59

<nvdbleek> I won't be able to attend the next session, tomorrow I will be on the call the complete afternoon

<virginie> ok, thxs vgb

<vgb> i'll be back, nick is leaving

<virginie> we will resume the meeting in few minutes

<MichaelH> +Wuzhou_East

<virginie> lets chase bugs...

<rsleevi> ISSUE-59?

<trackbot> ISSUE-59 -- Promises Programming Pattern Verification -- open

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

<rsleevi> scribenick: kodonog

describing promises issue that was just created

Israel providing overview of the issue

we've released the crypto spec that deals with events

in IE windows 7 and 8.1

sample code has been written

sample code retrieving a password that some enters

using different operations that someone enters

doing the basic promises model

in the first pass we are getting digest

passing the parameters

doing the import key and continue to get some random values

and ultimately encrypt

in this case, i've skipped the error handling part until the last

why do you care about the intermittent failures when you have the promises model

if the first digest failed, wouldn't you skip the exception.

Israel: no

<virginie> commenting the http://lists.w3.org/Archives/Public/public-webcrypto/2013Nov/att-0023/CryptoPromises.sample.txt

rsleevi: promises is trying to encourage a more idomatic approach for example 2
... what happens if promises 2 or 3 fail

israel: then promises 1 fails

all of the internal promises that fail are bubbled up to promise 1

rsleevi: the way that promises are supposed to work, you do a, then b, then

israel: there is a problem with that model, the first promise is the one you created by passing the parameters

how to pass parameters to the 2nd promise?

(discussion between ryan and israel on how promises work)

<rsleevi> digest.then(function (digestResult) { return importKey(... digestResult) }).then(function (importResult) { return encrypt(..., importResult) }).then(function (encryptResult) {});

<rbarnes> wc.digest(...).then(

<rbarnes> function(digest) { return wc.importKey(...); }

<rbarnes> ).then(

<rbarnes> function(key) { return wc.encrypt(...); }

<rbarnes> ).then(

<rbarnes> function(ciphertext) { return wc.importKey(...); },

<rbarnes> functionToHandleErrors

<rbarnes> )

Israel's example: have to do for an event model

Israel: if you think about multipart versus one part, we've agreed not to do multipart for v1

does the model still hold, because in a multipart model, are we looking for the dents to be automatically created?

<rbarnes> variant:

<rbarnes> wc.digest(...).then(

<rbarnes> function(digest) { return wc.importKey(...); },

<rbarnes> functionToHandleDigestErrors

<rbarnes> ).then(

<rbarnes> function(key) { return wc.encrypt(...); },

<rbarnes> functionToHandleEncryptErrors

<rbarnes> )

we can thing about multipart operation as a synthentic stream

tricky when you want to clone state

probably not address until v2

in the stream model, you may still hae to send out some events

webapps group is trying to figure out how they want streams to look

israel: i will retype my example for inclusion in Issue #59

Going back to the bug resolution discussion

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29805&order=bug_id&product=Web%20Cryptography&query_based_on=&query_format=advanced&resolution=---

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22571

rsleevi: we can add sorting (wrt bug 22548)

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22570

Bug 22570

relates to earlier conversation on random data

array buffer cipher text, array buffer tag

<virginie> hi richard

rsleevi: personal preference do nothing

israel: i've talked to implementors as well and gotten different feedback

rsleevi: I don't have a clear

vijay: unrap key takes the key format.

(vijay - can you enter your question... I missed it)

<rsleevi> vgb: for importKey/exportKey we can just define the format to define a serialization, right?

Bijay: for decrypt it might be better to just add an option for that. otherwise the programmer has to create a weird object

<rsleevi> rsleevi: Sure, but we have to solve the encrypt/decrypt data

Mark: you could say the last one in the sequence is the authentication tag.

rsleevi: pass some of the parameters in the algorithm,

there are alot of ways to do this

do you supply tag as part of the input or the parameters (for the encrypt/decrypt operations)

How do you feel about this in terms of concatenation.

We'll just have to try to various options and see what the sample code looks like.

rsleevi will propose something in the next rev of the spec

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22571

rsleevi: can't have a dictionary that is an attribute, this is correct and will be fixed in the next version of the spec

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22598

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22639

a variation on a previous bug, will be fixed in the next version of the spec

for 22639, this is just a language issue, will be fixed

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22677

raised by jim, today wrapped key is defined to call encrypt, unwrap calls decrypt , language issue

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22860

22860, copy past error

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22977

22977, will be updated to say promise

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22992

22992, webIDL bug

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23013

23013, there are a couple duplicates of this, assymetric key pair, what do usages mean, what do the extractable attributes mean

<rbarnes> i would support saying extractable = true for public keys always

-q

when you are generating a key pair, you would give the key usage, the signature would go with the private key, the would go with the public key

the next version of the spec, we have a consensus of what it should say, it just needs to be reviewed to ensure that it does say that

this is a normative requirement (not a non-normative note to implementors)

can't do a generic boiler plate because it is specific for each case

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23017

23017, adding webIDL syntactic sugar

Vijay: why does this bug matter?

<rbarnes> vgb sounds fine to me

vijay... type in the irc

<rsleevi> must be great firewall

<vgb> why does this bug matter?

<vgb> any implementation supports maybe 2-3 RSA key sizes

<vgb> if you can express a valid key size as a -ve number more power to you

webIDL says if you provide a negative number, convert to a positive

<vgb> no, i'm saying that it's hard to define a rule in the spec that works for all implementations

goal is to add to webIDL or to the prose the explicit typed system

<vgb> ok

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23043

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23051

23043, derived key type... some steps missing

23051, missing webIDL sugar

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23096

23096, dup of 23013,

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23097

23097, handling truncated signatures, HMAC-96, either API needs to specify how we support trunctation or say that we don't support truncation

plan is to specify how we support truncation

vijay: truncation causes security bugs, is anyone actually asking for this

rsleevi: there has been a request, people will do truncation either with or without API support

vijay: this is only relevant for operations that support truncation (HMAC)

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23098

23098, general issue, operation parameters and algorithm parameters

eric has put together a couple of proposals,

we will pick one of the options and go with it

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23159

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23242

23159, some parameters are bits and some are bytes, need to pick one

23242, no operation/algorithm support wrap/unwrap

next version will make it clear which operations/algorithms support wrap

which should?

RSA, RSA-ES, RSA-OAEP, are examples

why not AES-GCM?

if we define wrap/unwrap in terms of encrypt/decrypt why wouldn't any of the algorithms

vijay and rsleevi both shrug

put wrap/unwrap on them all and people can argue ones that shouldn't

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23445

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23495

23445, depending on whether the bug is correct or incorrect the spec will be changed

23495, measuring entropy is not relevant on desktop computers

if we are at a place of lacking entropy you are at a point of SSL breaking down as well...

hhalpin: process, we need to get Dr. Boneh's call

correction... get Dr. Boneh on a call

we shouldn't remove it from bugzilla until last call closes or he responds

next step: Harry will reping him regarding attendance on next call, resend Ryan's answers,

rsleevi: want to consider this issue closed unless we hear back.

are we going to separate the existing bugs from the new ones generated during last call?

Rigo: last call is a notice to other groups that we believe that we are done, shouldn't go to LC with open bugs
... further explanation of the LC process

two classes of bugs, spec is ambiguous or incomplete, feedback we get from the community (we may leave these open, include our response)

Mete: are we happy about the random number stuff or is this a version 2 topic

rsleevi: two aspects; get random values and ###

<vgb> also, getrandomvalues is sync, generateKey is async

<vgb> async methods can take as long as they want to return

vgb: in windows 8 we are constantly reseeding...

<rsleevi> Windows doesn't expose the amount of entropy available, correct?

vgb: internally we have an entropy estimate but we never surface it

rsleevi: this notion of entropy has a deep cryptographic challenge associated with it, there is no good cross platform way to say "do i have entropy or not?"

why would an api have a switch that says I'm ok with insecurity.

you don't want a webpage to drain your entroyp pool

point of entropy doesn't really make sense in this context.

Mete: regarding email I sent yesterday, HMAC-SHA1

rsleevi: I thought it was in the spec,

universally implemented

a bug will be filed by Mete

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23655

<rbarnes> i would be fine with [] == 0x00

23655, spec will be updated to make clear

<rsleevi> meet 9am (local), 5 pm pacific

- DRAFT -

Web Cryptography Working Group Teleconference

14 Nov 2013

Attendees

Contents

Intros

Web Crypto API

Summary of Action Items

Scribe.perl diagnostic output