19:59:42 <RRSAgent> RRSAgent has joined #crypto
19:59:42 <RRSAgent> logging to http://www.w3.org/2016/07/11-crypto-irc
19:59:44 <trackbot> RRSAgent, make logs public
19:59:44 <Zakim> Zakim has joined #crypto
19:59:46 <trackbot> Zakim, this will be CRYPT
19:59:47 <ttaubert> hey
19:59:47 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:59:47 <trackbot> Date: 11 July 2016
19:59:48 <Zakim> ok, trackbot
19:59:56 <hhalpin> hhalpin has changed the topic to: WebCrypto July 11th meeting
20:00:15 <wseltzer> zakim, code?
20:00:15 <Zakim> I have been told this is CRYPT
20:00:41 <wseltzer> zakim, you're wrong
20:00:41 <Zakim> I don't understand 'you're wrong', wseltzer
20:01:52 <wseltzer> zakim, this is webex 643 244 026 http://www.w3.org/2012/webcrypto/password.html
20:01:52 <Zakim> got it, wseltzer
20:02:44 <wseltzer> present+ wseltzer
20:02:51 <wseltzer> present+ hhalpin
20:02:53 <hhalpin> So we're going to hold a few minutes to let Virginie and MarkW join
20:02:54 <wseltzer> present+ David
20:03:01 <hhalpin> pesent+ ttaubert
20:03:22 <markw> markw has joined #crypto
20:03:24 <hhalpin> present+ ttaubert
20:04:40 <_avian> _avian has joined #crypto
20:05:31 <markw> joining now
20:05:47 <hhalpin> chair: hhalpin
20:06:00 <wseltzer> scribenick: wseltzer
20:06:08 <hhalpin> topic: test suite
20:06:17 <wseltzer> present+ engelke
20:06:38 <wseltzer> engelke: test suite is in good shape. Haven't heard from Jim recently
20:06:39 <RobTrace> RobTrace has joined #crypto
20:06:53 <wseltzer> ... Chrome has very good coverage; a few places throws the wrong error
20:07:03 <wseltzer> present+ RobTrace
20:07:15 <wseltzer> ... Firefox has errors based on an earlier version of the spec
20:07:20 <markw> present+ markw
20:07:38 <wseltzer> ... Edge often works for encrypt, decrypt, generateKy, often throws the wrong error
20:08:00 <wseltzer> hhalpin: ttaubert are you the FF person?
20:08:05 <wseltzer> ttaubert: yes
20:08:15 <wseltzer> engelke: I'll report bugs to bugzilla
20:08:24 <wseltzer> hhalpin: another concern, service workers support
20:08:38 <wseltzer> ... Does FF still plan to support webcrypto in service workers?
20:08:46 <wseltzer> engelke: most of the tests run in workers
20:09:15 <wseltzer> ttaubert: planning on it
20:09:35 <wseltzer> hhalpin: so let's keep service workers. Remaining issue is SPKI/PKCS support
20:09:35 <ttaubert> (it actually already works, we just don't have test coverage yet)
20:09:56 <hhalpin> either jim or ryan? the PKCS/SPKI support
20:10:06 <wseltzer> ... has anyone heard from JimSchaad or Ryan?
20:10:27 <hhalpin> We probably need a backup plan.
20:11:03 <hhalpin> 1) Keep them in the spec, but not as normative and mark them explicitly as possibly non-interoperable
20:11:07 <wseltzer> hhalpin: two general paths: we can keep them in the spec, non-normative
20:11:20 <wseltzer> ... or remove entirely from the spec, as a large rewrite
20:11:21 <hhalpin> 2) Remove from spec entirely - large rewrite, Ryan Sleevi's preference
20:11:45 <wseltzer> ... we could re-run question on the ML
20:12:04 <wseltzer> @@: Do we have any quantification of the scope fo the problems?
20:12:18 <wseltzer> ... both chrome and FF do imports
20:12:27 <hhalpin> I think it that they exported ones that were not well-formed
20:12:30 <wseltzer> hhalpin: I think their exports were not interoperable
20:12:37 <wseltzer> ... and algorithm names differed
20:12:58 <wseltzer> ... edge cases around DER/BER
20:13:33 <wseltzer> ... it does seem people get value
20:13:41 <wseltzer> markw: we're using these features
20:13:54 <wseltzer> ... a core set of features
20:14:08 <wseltzer> ... I'd hope we can identify the subset of what works
20:14:09 <wseltzer> q+
20:14:22 <hhalpin> q+ wseltzer
20:15:02 <hhalpin> wseltzer: We could have the text not specified as normative, we'd prefer to have them not removed if they are useful.
20:15:07 <wseltzer> hhalpin: we may not be able to get to the middle path, wellq-
20:15:13 <wseltzer> q-
20:15:26 <wseltzer> @@: better to get the API to handle them
20:15:32 <hhalpin> engelke: If they are not in the API, people will have to do in the Javascript, that seems less than optimal
20:16:06 <wseltzer> hhalpin: I'll send a CfC to mark text as non-normative
20:16:15 <hhalpin> Will send a CfC yet again with the option Wendy outlined of keeping them in but marking as non-normative
20:16:42 <hhalpin> no formal objetions have that as Plan B specify that we'll try to get as much interop as possible given time constraints
20:17:06 <wseltzer> markw: I had three lists of items
20:17:11 <markw> https://github.com/w3c/webcrypto/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22needs%20input%22
20:17:35 <wseltzer> ^ issues needing inptu from the group
20:18:17 <wseltzer> hhalpin: does anyone on the phone volunteer to review these issues?
20:18:53 <wseltzer> https://github.com/w3c/webcrypto/issues/111
20:18:58 <wseltzer>  ECDSA import does not specify the hash algorithm #111
20:19:14 <hhalpin> Seems like Jim's suggestion is right, i.e. just set the hash alg in the params
20:19:57 <wseltzer> zakim, code?
20:19:57 <Zakim> I have been told this is webex 643 244 026 http://www.w3.org/2012/webcrypto/password.html
20:20:13 <engelke> I'm fine either way. It would be more consistent. Arguments against it would probably be just as strong for taking it out of RSA.
20:21:53 <markw> https://github.com/w3c/webcrypto/issues/111
20:21:55 <wseltzer> markw: issue 111
20:22:16 <wseltzer> ... for ECDSA, we don't provide hash on import, whereas for other algos, we do.
20:22:29 <wseltzer> ... Jim suggests we do the same for ECDSA
20:22:47 <wseltzer> @@: makes sense to match RSA and ECDSA
20:22:52 <wseltzer> markw: I'll implement
20:23:18 <wseltzer> markw: issue 110, HMAC Sign and Verify algorithms do not support trucated HMACs
20:23:44 <wseltzer> ... should we allow truncation?
20:23:49 <markw> https://github.com/w3c/webcrypto/issues/110
20:24:05 <wseltzer> hhalpin: it would need testing
20:24:22 <hhalpin> I assume that would *not* work in tests but I think Jim motivated it well, i.e. the COSE use-case
20:24:30 <hhalpin> Charles - can we add a test for this?
20:25:20 <wseltzer> markw: Issues 85, 87, 88. I just put up a PR, so revisit later
20:26:10 <wseltzer> ... issue 66. Jim suggests always return false if error or fail
20:26:14 <markw> https://github.com/w3c/webcrypto/issues/66
20:26:22 <wseltzer> hhalpin: agree with Jim
20:26:53 <wseltzer> ... that's the safest
20:27:01 <wseltzer> markw: does that mean all errors should return false?
20:27:09 <wseltzer> ... or type error on input ok?
20:27:17 <wseltzer> hhalpin: padding oracle was the attack issue
20:28:13 <wseltzer> markw: we can align RSA, ECDSA
20:28:49 <hhalpin> keep it as false except for typing error, correct?
20:29:37 <wseltzer> markw: reject this PR and make a new one
20:29:56 <hhalpin> That's the right move
20:30:12 <wseltzer> markw: issue 62
20:30:49 <markw> https://github.com/w3c/webcrypto/issues/62
20:30:57 <wseltzer> ... propose wontfix
20:31:25 <engelke> I agree with wontfix
20:33:00 <wseltzer> markw: currently, you have to support all 3. do we want to keep that?
20:34:00 <wseltzer> ... we've left freedom for RSA, not AES
20:36:25 <hhalpin> In theory, browsers might want to 'future proof' and allow larger in the future without revisiting the spec.
20:38:22 <hhalpin> I think a minimum or suggested keys size makes sense.
20:38:39 <wseltzer> markw: I'll close this issue, then open a new one re minimum required values for RSA parameters
20:38:58 <wseltzer> hhalpin: we can look at test suite for minimum
20:38:59 <markw> https://github.com/w3c/webcrypto/issues/30
20:39:04 <wseltzer> markw: issue 30
20:40:31 <wseltzer>  hhalpin: most of these have been removed
20:40:44 <wseltzer> hhalpin: I can check after the call
20:41:08 <markw> https://github.com/w3c/webcrypto/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22needs%20review%22%20
20:41:17 <wseltzer> markw: ^ Needs Review
20:41:27 <wseltzer> ... outstanding PRs, please make comments, LGTM
20:41:42 <wseltzer> ... most are straightforward
20:42:20 <wseltzer> hhalpin: I'll review
20:42:53 <wseltzer> ... often, it was problems with references
20:43:17 <markw> https://github.com/w3c/webcrypto/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20no%3Alabel%20no%3Aassignee%20-milestone%3AVNext
20:43:25 <wseltzer> markw: ^ floating items
20:45:26 <wseltzer> q+
20:45:37 <hhalpin> ack wseltzer
20:46:37 <hhalpin> "Normatively, the spec only be used with secure origins."
20:46:44 <wseltzer> q-
20:46:48 <hhalpin> (although implementations may do otherwise)
20:47:00 <hhalpin> So MS and Moz do of course support secure origins :)
20:47:15 <wseltzer> wseltzer: we can Recommend secure origins, even if some implementations will operate in insecure or secure
20:47:22 <hhalpin> I think Richard Barnes was the one previously unhappy with requiring secure origin.
20:47:34 <wseltzer> @@: seemed consistent with other specs to require secure origins
20:47:41 <hhalpin> (I can't remember the details of Richard's use-case)
20:48:06 <wseltzer> hhalpin: any objection to requiring secure origins?
20:48:32 <wseltzer> @@: I favor it
20:48:46 <hhalpin> OK, we'll let's make it normative - use with secure origins. MarkW - can you make that change?
20:48:57 <wseltzer> hhalpin: sounds as though we're leaning toward secure origins as normative
20:49:04 <wseltzer> markw: that should get a CfC on the list
20:49:14 <hhalpin> Wll write that CfC
20:49:15 <wseltzer> hhalpin: I'll send one
20:50:10 <wseltzer> markw: which version? you can require the document be secure, or look at top-level browsing context
20:50:44 <engelke> I think a secure iframe, even in an insecure document, is okay and useful.
20:51:13 <wseltzer> engelke: I think webcrypto in an iframe is ok, useful
20:51:32 <wseltzer> markw: then you can make a plugin in the iframe that exposes entire webcrypto API to the outside insecure page
20:51:42 <wseltzer> ... defeating the secure origin requirement
20:53:01 <wseltzer> hhalpin: let's put the stronger one to the list, see if there's push-back
20:53:06 <hhalpin> Let's put the stronger constraint to the list.
20:53:54 <wseltzer> hhalpin: we'll update the algo interop table when we finish the test suite
20:54:14 <wseltzer> markw: I'll keep issue list updated with needs review tags
20:54:19 <wseltzer> ... please review/ give input
20:54:35 <wseltzer> topic: Timing
20:54:40 <wseltzer> hhalpin: WG charter expires soon
20:54:50 <wseltzer> ... we want to get transition to PR out
20:55:02 <wseltzer> ... close out all the CfCs  July 25
20:55:33 <wseltzer> ... then make a transition request, to W3C Director to go to Proposed Rec
20:55:37 <hhalpin> We *will* definitely have another on July 25th to deal with the CfCs and double-check closed issues
20:55:39 <wseltzer> ... next meeting, July 25
20:55:50 <hhalpin> I'll try to draft a CR->PR request hit by CfCs July 25th
20:56:12 <hhalpin> So we'll try to definitely get out to PR by end of July at earliest, more likely sometime in August.
20:56:42 <wseltzer> [adjourned]
20:56:42 <hhalpin> RRSAgent, draft minutes
20:56:42 <RRSAgent> I have made the request to generate http://www.w3.org/2016/07/11-crypto-minutes.html hhalpin
20:56:51 <wseltzer> zakim, list attendees
20:56:51 <Zakim> As of this point the attendees have been wseltzer, hhalpin, David, ttaubert, engelke, RobTrace, markw