See also: IRC log
<trackbot> Date: 24 February 2014
<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
<hhalpin> wseltzer has been promoted!
<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: Still some gaps - DH
not yet committed and key derviation functions not done
... 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?
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: concluded on the list -
there is no effiecnet way to do this and can do it with cbc or
... suggest close as won't fix
<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: AES CFB - parameter on the
... 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
virginie: resolution to rename is ok.
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
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
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
... 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
... 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
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
... jim says for good security reasons need x9.42
... is enough to suport PKCS#3 or need x9.42
<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?
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
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
... 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]
<hhalpin_> its April 10-11th.
scribe: please type +1 if you would be willing to meet in april
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
... future work - sent a proposal to the mailing list about secure token
... discussions with wendy and harry - check if appropriate workshop
<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[End of scribe.perl diagnostic output]