See also: IRC log
<virginie> hello mountie
<virginie> looks like we have no conf call booked, let me see what i can do...
<mountie> am I wight time?
<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> Let me change the booking time so the code works properly next time.
<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?
<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> April 7-11th 2014
<hhalpin> WebCrypto Next Steps Session
<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: 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
<trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open
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
<trackbot> ISSUE-28 -- Short-names for algorithms -- open
<trackbot> ISSUE-35 -- Handling of wrap/unwrap operations -- open
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> sory 43
<trackbot> ISSUE-43 -- Separate method for key agreement -- open
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
<trackbot> ISSUE-44 -- Require creation of random IVs by default for CBC, CFB, GCM -- open
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
<trackbot> ISSUE-46 -- Optional algorithm parameters must have default values -- open
<kodonog> I just pinged richard… he is coming now
virginie: Another situation where discussed with richard but not concrete solution
<trackbot> ISSUE-59 -- Promises Programming Pattern Verification -- closed
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
<virginie> > *Bug **24427* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24427>
+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
<virginie> Bug 24444 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24444>
@israel: Yeah, all failures async. This also will require some prose regarding the WebIDL conversions
virginie: What is the suggested resolution?
<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
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
virginie: BUG 24457
<virginie> Bug 24457 <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.
... 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
... 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: 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
<kodonog> -1 previous commitment conflicts
<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
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?
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/via/to/ Succeeded: s/mountine/mountie/ Found ScribeNick: rsleevi Found Scribe: Ryan Sleevi WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Apple IPcaller Microsoft Netflix P25 P7 aaaa active conferences drew hhalpin https israelh jimsch jimsh jyates jyates_ karen karen_ karen_oDonoghue kodonog malaclyps markw mountie rbarnes richard rigo rsleevi sangrae scribenick tantek terri trackbot virginie You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 10 Feb 2014 Guessing minutes URL: http://www.w3.org/2014/02/10-crypto-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]