SV_MEETING_TITLE -- 10 Feb 2014

<virginie> hello mountie

<mountie> hello

<virginie> looks like we have no conf call booked, let me see what i can do...

<mountie> am I wight time?

<virginie> yes

<mountie> ok

<mountie> is the conference code is 27978# or 26632#?

<virginie> problem is that no bridge has been booked

<virginie> i am sending new details for the call

<mountie> aha. ok.

<virginie> lets join under +33155015500 (french number)

<virginie> with the code : 83693450#

<mountie> I will

<virginie> hi all

<virginie> anyone wanting to join the discussion about web crypto WG is invited to join on +33155015500 with access 83693450#

<virginie> hello sangrae anyone wanting to join the discussion about web crypto WG is invited to join on +33155015500 with access 83693450#

<mountie> hi. sandrae

<virginie> (apologize for badly managing the call booking)

<sangrae> I tried to call that number. but didn't ask me access code.

<virginie> can u hear us ?

<mountie> I can hear you

<virginie> sangrae, can u hear us ?

<virginie> sangrae, did we loose u ?

<virginie> Mark status on web crypto API : http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0027.html

<virginie> anyone wanting to join the discussion about web crypto WG is invited to join on +33155015500 with access 83693450#

<hhalpin> virginie, did anyone join?

<virginie> Bug 24457 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24457>* - AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long

<hhalpin> it appears Zakim has it booked in 30 minutes.

<hhalpin> I'll send adminreq a message correcting so we start an hour earlier.

<virginie> (to harry, yes we have sangrae, mountie and kishan from typhone

<hhalpin> Excellent!

<virginie> )

<hhalpin> Let me change the booking time so the code works properly next time.

<virginie> http://www.w3.org/2012/webcrypto/wiki/WG_Future_Work

<hhalpin> ok, correction sent

<hhalpin> So next time, the code should work.

<hhalpin> Quick update - W3C is discussing Asian presence at WWW2014 in W3C developer track, I'd like to dial-in briefly to discuss.

<hhalpin> We'd like to discuss Korean use-cases in particular at the track in terms of scoping future work.

<hhalpin> mountie: we don't know how private keys are protected and managed

<hhalpin> ... we are trying to set some guidelines

<hhalpin> ... maybe not normative, but at least guidelines

<hhalpin> virginie: is use-case hardware token or software

<hhalpin> mountie: both

<hhalpin> ... who owns the key?

<hhalpin> ... does it belong to the provisioner?

<hhalpin> .... if we really accept hardware tokens or secure element, the key owner belongs to the user

<virginie> thanks harry for scribing

<hhalpin> ... some concerns can we match those requirements

<hhalpin> virginie: clarify two things, the way the credentials are secured

<hhalpin> ... way they are managed by the ownership

<hhalpin> ... can you write down the requirements?

<virginie> http://www.w3.org/2012/webcrypto/wiki/Deliverable_web_certificate_API

<hhalpin> the asian call is prior to the US call.

<hhalpin> virginie: on issue of key ownership, how would you implement that?

<hhalpin> ... keys that work cross-origin, would you provision the authorized origin to deal with the key?

<hhalpin> mountie: if the key is combined with a certificate, we set exceptions to same origin policy

<hhalpin> mountie: we also need some form of user-consent, password, pin, biometrics

<hhalpin> ... for use or access of the key

<hhalpin> virginie: access whatever key plus certificate, with no limitation up to user for final version

<hhalpin> ... or more of a whitelist or blacklist

<hhalpin> hhalpin: whitelists are usually safer

<hhalpin> folks should look at how CORS works

<hhalpin> mountie: key genreated by site A, but can be accessed for signing data in different websites

<hhalpin> CORS basically gives you a whitelist-like mechanism

<hhalpin> mountie: Not so much people agreed

<hhalpin> You may also want to approach the questions re CORS to the WebApp and WebAppSec WG

<virginie> harry suggesting to look at CORS and see how to use it for local ressources

<virginie> and communicate with the WebAppSec after CORS/Web Crypto API go to Last Call

<hhalpin> Off top of head, CORS is best bet, although they won't have the UA stuff you want.

<hhalpin> mountie: exceptions would be best, postMessage would be second-choice

<hhalpin> happy to do quick intro over CORS

<hhalpin> www2014.kr

<hhalpin> April 7-11th 2014

<hhalpin> WebCrypto Next Steps Session

<virginie> http://www2014.kr/

<hhalpin> 90 minutes maybe 180 minutes

<hhalpin> We are considering Sept 2014 in Washington DC

<hhalpin> Will send emails out

<virginie> [IPcaller] is me

<jimsch> zakrim, ipcaller.a is me

<scribe> scribenick: rsleevi

<scribe> scribe: Ryan Sleevi

<virginie> wg members to have a look http://www.w3.org/2012/webcrypto/track/actions/open

virginie: WG members should take a look at the open ACTION items
... if there are any items that should be closed, just close your ACTION item. No need to go through the WG before doing so
... in the same spirit, there's also a set of open ISSUEs

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

virginie: specifically those related to the Web Crypto API
... Going to LC requires that there be no open ISSUEs, but we have some still open. There has been some discussion on the mailing list for closing/resolving some, but it seems there remain some items

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

rsleevi: vgb sent a mail to the list several weeks (months?) ago suggesting he didn't really have any concrete proposals
... I suggest we close this issue. There's some small tweaks related to the status update, but as a whole, we don't have any good proposals for such a large API change

ISSUE-28?

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

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

ISSUE-35?

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

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

markw: I think we've addressed these in the latest ED. I think we can close this issue

<israelh> I closed ISSUE-59 : http://www.w3.org/2012/webcrypto/track/issues/59 based on the conversation at the F2F in China.

+1 to closeing ISSUE-35

<jimsch> 35

<jimsch> sory 43

ISSUE-43?

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

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

rsleevi: This is another one that I believe we resolved on the mailing list
... The main people who raised concern expressed acceptance with the API for deriveKey/deriveBits

virginie: Will suggest on the mailing list to close ISSUE-43

<jimsch> 44

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: Contacted rbarnes to attempt to gather more information. We discussed during the F2F, and then rbarnes was silent on this.
... attempt to contact richard one last time, and then close this

ISSUE-46?

<trackbot> ISSUE-46 -- Optional algorithm parameters must have default values -- open

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

<kodonog> I just pinged richard… he is coming now

virginie: Another situation where discussed with richard but not concrete solution

ISSUE-59?

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

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

rbarnes: Will take a look in the next few days and continue discussion on the list

virginie: Just a reminder that we need to have 0 ISSUEs open before LC

<virginie> status by the editor : http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0028.html

markw: Briefly, I took the 15 bugs that we identified as required for last call as Pre-LC

virginie: In this mail, there were some further discussions, correct?

markw: The ones that are open are the ones that we could spend time discussing here if we think we can resolve here
... JWK format, raw AES access, and adding an additional curve to the named curve registry
... also a discussion on making all method failures asynchronous

+1 to making all failures async, in case it wasn't clear

jimsch: In addition to specifying whether failures should be asynchronous, should we also specify failures should be constant time

<markw> rsleevi: Dpn't believe we need to make any statements about constant time

<markw> ... it would be a quality of implementation issue for the algorithm-specific stuff

<markw> ... can't really interop test it

<markw> ... an it doesn't necessarily invalidate an implementation if it is later discovered that it is not constant time

<markw> ... also, it's not clear how we would defined an interop requirement

<rbarnes> +1 to rsleevi

<markw> ... for example, for RSA, there are quality of implementation issues around the quality of the primes etc.

+1 to adding to security considerations ( I think we did already )

virginie: So is your proposal jimsh that we add it to security considerations

jimsch: I'll have to think about it, but I think that sounds right

virginie: Can raise that discussion on the mailing list

markw: Bug 24444

israelh: Just really quickly on the previous bug, are we suggesting to do all the failures asynchronous

@israel: Yeah, all failures async. This also will require some prose regarding the WebIDL conversions

virginie: What is the suggested resolution?

<israelh> I

<israelh> I'm back

<jimsch> +1 on not including

rsleevi: My feeling is that this curve is actually not widely implemented (eg: CNG, nor CSSM I believe). I addressed this on the list that unless we here from implementors requesting it, it would be better to leave it off for now

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

markw: I would rather we decide something, either way, and close it

<rbarnes> my inclination is to include it, just because identifiers are cheap, and developers are going to have to check for support anyway

<rbarnes> but i don't feel that strongly

@rbarnes: It affects our ability to move the spec to REC, regarding compatible implementations

@rbarnes: Thats why I suggest we defer until implementors actually request it / suggest implementing it

<rbarnes> @rsleevi: i thought we had already agreed that we would not have requirements for specific algorithms / curves ?

<rbarnes> looooong ago

karen: I think that particular curve is not in NIST

<jimsch> curve 25519 is the current hot curve to adopt in the IETF at the moment

<rbarnes> jimsch: let's not go there

rsleevi: Part of SEC 1 / NIST, not part of Suite B

<jimsch> rbarnes: that is why I said don't adopt

<rbarnes> jimsch: that's different; djb has a whole different point representation etc

virginie: Sounds like from the discussion the answer is "no" but we'll wait to hear back from israel

israelh: My guess/vote is "no" - less is more

<rbarnes> i'm not hearing a lot of "yes'

<terri> +1 to closing pending more info

markw: We can close this with NEEDSINFO, with the info needed being implementors wanting to implement it

<rbarnes> +1

virginie: BUG 24457

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

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

richard: Is this a result of JOSE choosing the simpler form of key wrap

jimsch: There was some discussion of this on the mailing list. On the mailing list, the discussion was "If it's not 8*n bytes long, you can't use it. Tough"
... the choice of IV was fairly arbitrary and not based on security decisions, it just needed to be a constant
... the question I have for Mark is, we did have a conversation about this, what more is desired

markw: That's correct, that resolution is fine for the AES-KW case. The thing I pointed out on the bug is that it's possible for implementations to generate a JWK that is aligned to 8*n bytes - by using additional whitespace or additional members with junk data, for example
... based on that, Ryan made some comments that the flexibility just described (the non-canonical nature of the JSON) raised concerns regarding the security properties of AES-KW being based on being a canonical representation
... so there's no question about reversing the previous decision, the question is just whether there's a fundamental security question with wrapping JWKs with AES-KW as opposed to AES-GCM

virginie: Let's have a follow-up on the mailing list on this bug

jimsh: no security considerations that I can think of

<virginie> https://www.w3.org/2002/09/wbs/54174/February2014/

virginie: Because there has been very short notice regarding this F2F, it would be good to know who will be able to be in attendance

markw: If we would be able to spend a portion of the time resolving issues and making sure the spec is ready for LC, I think I could justify attending, but if it's just going to be discussion future work, it's harder to reason

virginie: It's harder because this is an informal meeting

markw: I don't think formal or informal matters much, since we close things by reaching consensus, and we reach consensus by talking about things, and we can talk informal or formal. If informal, we can just reach formal consensus on the mailing list

-1 for attending

<virginie> +1

<rbarnes> +.8

<israelh> -1

<drew> -1

<karen_> 0

<jimsch> -1

<kodonog> -1 previous commitment conflicts

<terri> -1

<jimsch> have to leave

<rbarnes> just me and virginie!

virginie: It seems like there will be very few people attending. May be worth considering cancelling. Going to reach a "last call" of sorts on the mailing list this week

markw: An alternative would be to consider a longer call to deal with the issues going towards LC

virginie: So for example a 2 hour call for the next two calls

<virginie> +1

israelh: What about a special meeting that goes 2 hours (only one) that just identifies all the issues we should go through and make sure that everybody that needs to be there can be there

rsleevi: next call (2 weeks) is when markw and I are supposed to deliver "LC-ready" spec. Following call the WG will vote on adopting it as LC
... So first call being 2 hours will allow markw and I to discuss and debrief about any open issues or questions, then following call can allow WG members to discuss issues seen

israelh: Would it make more sense to have 1 hour call in two weeks for debrief, and then a following week have a 1 hour call to discuss issues, then follow with another 1 hour call for debrief

virginie: What about a 2 hour call for our next call, followed by a 1 hour call the next week, followed by the regular call

+1 to 2,1,1 plan (if I understood correctly)

and also 2,1,2 if necessary

<rbarnes> rsleevi: yeah that's sounds find to me

virginie: Plan was 2 hours call in two weeks, 1 hour call week following (which may conflict with IETF), followed by 2 hour call
... reminder for people that we will potentially have a workshop in September, potentially in Washington DC, to discuss hardware tokens
... still need to send out a strawman proposal for the workshop
... Next meeting will be 24 of Feb. will ask W3C staff to make meeting a 2 hour meeting.

<rbarnes> starting at the same time?

- DRAFT -

SV_MEETING_TITLE

10 Feb 2014

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output