<trackbot> Date: 24 February 2014

<virginie> ok

<hhalpin> yes, for native speakers it was probably fine

<hhalpin> but we may need to send out separate reminders :)

<sangrae> hi everybody

<mete> no voice here, following on irc only

<hhalpin> trackbot, start meeting

<trackbot> Meeting: Web Cryptography Working Group Teleconference

<trackbot> Date: 24 February 2014

<terri> aabb is me

<terri> thanks!

<hhalpin> wseltzer has been promoted!

<hhalpin> http://www.w3.org/blog/news/archives/3482

<hhalpin> So I'll be attending the calls as Team contact.

<hhalpin> scribe: jimsch

virginie: review agenda
... cll for other items?

<hhalpin> markw can handle the presentation of recent bugs as he's been manning quite a bit of the editorial work.

virginie: markw: focusing on adding algorthm desription text

<virginie> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

virginie: Still some gaps - DH not yet committed and key derviation functions not done yet.
... sha1 may be visiable in current editors draft
... will notify as new things become available.
... Based on list disucssion, key wrapping descipritions are going to change
... methods ask if there is a wrap/unwrap - will use the encrypt opertion if it is not present.
... discussion on list is that second option should be removed.
... For some, the encrypt and wrap will be the same (AES-GCM) for others only wrap/unwrap my be defined (AES-KW)
... list of three to talk about.

virgine: Lets strt with three points that are raised.
... Any generl questions to the editor at this time?

Isereal: Would llike to put worker crypto interface at risk if noboy objects

<hhalpin> israel, do you have some reasoning?

<virginie> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#WorkerCrypto-interface

Isereal: From the worker pattern, because of other limitations we have not implemented some of the indexDB interfaces for them
... So deprioritizing some of the webworker interfaces
... Rather make sure that async senerios are right

virginie: How do we manage that - add editors note saying it is at risk
... as noone is challenging it - seems to be ok

<hhalpin> As long as its announced on mailing list so Chromium devs can respond

hhalpin: need to announce over the mailig list

virginie: start on technical discussion

markw: two of the three are housekeeping - shoud be able to close
... #1 32500 - support of raw AES

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

markw: concluded on the list - there is no effiecnet way to do this and can do it with cbc or counter -
... suggest close as won't fix

+1

<hhalpin> I think that comment came from Boneh, right?

yes it did

<hhalpin> Perhaps we should just respond to him directly

<hhalpin> to see if he agrees/knows about implementation

<hhalpin> I'm happy to email him the proposed change and see if he agrees

virginie: with no objections - will close bug - action to harry to inform Boneh
... if any problems will come back

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

markw: AES CFB - parameter on the shift size
... Nothing in the spec prior to now.
... Suggest we treat the diffrerent shift values as different algorithms
... Which shift values to be supported?
... Discussion says that it appers mostly be 8 bit shifts
... Propsoal - rename and support only the 8 bit shift size

virginie: If rename - then do we indicate we welcome others if people ask for them?

markw: reason for explicit naming is to show how to add new values in the future

+1

virginie: resolution to rename is ok.

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

markw: AES-KW requires 8 byte multiple on input
... More fundimental issue - because of lack of canonicaliztion - ryan thought this might be a secueity issue
... several people agreed with markw mailing list analysis that there is not a security problem
... don't need to say anything bout how to make it a multiple of 8 bytes in the current spec
... propsoal is to close as WFM

Isreal: would it make sense to add note about ability todo this in the serializer?

markw: Yes - Ryan may not accept it

virginie: suggest a note and see if Ryan agrees with note

+1

markw: have openned new bugs feom the reviews that have come in - need to check for pre-last call status

vgb: Question on the mailing list about optional password parameter

markw: have not reviewed the question yet

vgb: for PBKDF2 - how does the optional base key work if the UI is supposed to prompt for the password

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0125.html

vgb: hate to go last call if we don't know how to use the parameter

jimsch: the basekey would never be used - because the password is not there

vgb: understood the opposite
... understood if basekey was left null, then some implenttions would be able to prompt for a password
... need calarification on what the password parm means

markw: could think of a numbeer of ways to consetruct the API here
... would there be a question of a doing a derivation from a different method - say DH agree
... DOn't know if that mkes sense as a use case for PBKDF2
... maybe base key is always null

<hhalpin_> I'm in a train station :)

virginie: need to clarify the behavior
... create bug/action to get the clarification

vgb: sounds like no one knows what to currently do.

virginie: need to clarify or remove

vgb: with reasonble symmantic - then should go forward and keep.

Some of this may be because we have not looked at PBKDF2 since we changed how deriveKey wors

virginie: should be able to go to last call if we clear out these issues

markw: Three more items possible to discuss, aslo need to fill n some import/export sections

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

markw: Import of JWK objects, with full detail could have model without passing in parameters from the script
... would cause a big refactoring in the specifications
... Implication is that one should know what i in the JWK to start with if no change
... What if algorithm has prameter s- i.e. HMAC hash function, JWK specifies the hash function - could default from JWK
... Currrently say -need to know what is going to import and thus need to know what algorithm/sub-parameters in the JWK are

<vgb> +1 to Mark's approach

markw: will get error if no match

<hhalpin_> Sounds reasonable

+1 (for now)

markw: Hot off the mailng list - DH discussion

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0113.html

markw: refering to PKCS#3 in the spec - also the X9.42 spec
... slightly enhanced wrt PKCS#3
... which shouldd we support
... Current status on mailing list

<virginie> recent discussion http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0132.html

markw: X9.42 is not as widly spread
... jim says for good security reasons need x9.42
... is enough to suport PKCS#3 or need x9.42

q

<hhalpin_> What precisely is needed for x9.42 compliance?

<hhalpin_> Thinking of the upcoming W3C Web Payments workshop...

jimsch: Certifictes come in the X9.42 version not the PKCS#3 version - need for SPKI

markw: respond to harry - X.942 has additional prameters
... these are used to check for specifying the privte key

<hhalpin_> adding order to base elements seems like it should be possible as an optional parameter, but x.942 is new to me :)

markw: jim will now correct me

jimsch: reallyt there to check that the genertor is created correctly

isreal: If accepting a small sub-group - then an issue
... Really more of a problem with static-static
... For ephermeal-ephermal, on need to mandiate x9.42
... Not clear that it should be required

markw: issue is that if we support x9.42 for import, then what do we do on export if implementation does not support?

isreal: then you can't do the export because it not legl

<hhalpin_> Obviously outlawing PKCS#3 will obviously not work

markw: suggesting onlything required is pkcs3 because it is what is supported
... what does an implementtion do if does not suport full parameters set

vijay: is that bad?

sorry

markw: currently nothing in terms of - is this format supported?

virginie: not sure we re going to make a decsiion now, without a concensus

markw: if we could great - if not then need to continue discussions

<hhalpin_> it seems that output formats should be supported in general rather than a query to see if a particular output format is supported.

markw: Put the pure #3 in the spec - and people could see what happens
... will give us an operatable to throw rocks at

virginie: any oher issues to discuss? - open issues

markw: these are the main issues for the open issues
... encourage people to review bug list and the document

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

viginie: COuld have a call next week if there are issues for disucssion

<hhalpin_> We've already booked the time so an intermediate discussion will probably be useful - re UTC time, it will be late on Monday post-IETF.

viginie: promised Q&A session
... avoids issues of poeple sayng I did not have tie to raise my point
... real decision on going to last call in two weeks
... have suggested that could have a F2F in the future -in april

<hhalpin_> [looking for precise dates]

+1

<sangrae> +1

<virginie> +1

<hhalpin_> its April 10-11th.

<israelh> +1

scribe: please type +1 if you would be willing to meet in april

<markw> +1

scribe: meeting is in california - think it was paypal orginizing

<hhalpin_> I have to be at WWW2014 on those dates.

<hhalpin_> i.e April 10-11th.

<hhalpin_> But a f2f would be useful regardless

virginie: First chance to look at last call comments
... AOB?
... future work - sent a proposal to the mailing list about secure token
... discussions with wendy and harry - check if appropriate workshop

<virginie> https://www.w3.org/2012/webcrypto/wiki/WG_Future_Work_hardware_token_workshop_2014

<hhalpin_> trackbot, end meeting

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/isreal/vijay/
Found Scribe: jimsch
Inferring ScribeNick: jimsch

WARNING: No "Topic:" lines found.

Default Present: +1.617.253.aaaa, jyates, markw, jimsch, virginie, vgb, hhalpin, +1.503.712.aabb, terri, [Microsoft], [IPcaller]
Present: +1.617.253.aaaa jyates markw jimsch virginie vgb hhalpin +1.503.712.aabb terri [Microsoft] [IPcaller]
Found Date: 24 Feb 2014
Guessing minutes URL: http://www.w3.org/2014/02/24-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