<ttaubert> hey

<hhalpin> So we're going to hold a few minutes to let Virginie and MarkW join

<hhalpin> pesent+ ttaubert

<markw> joining now

<scribe> scribenick: wseltzer

test suite

engelke: test suite is in good shape. Haven't heard from Jim recently
... Chrome has very good coverage; a few places throws the wrong error
... Firefox has errors based on an earlier version of the spec
... Edge often works for encrypt, decrypt, generateKy, often throws the wrong error

hhalpin: ttaubert are you the FF person?

ttaubert: yes

engelke: I'll report bugs to bugzilla

hhalpin: another concern, service workers support
... Does FF still plan to support webcrypto in service workers?

engelke: most of the tests run in workers

ttaubert: planning on it

hhalpin: so let's keep service workers. Remaining issue is SPKI/PKCS support

<ttaubert> (it actually already works, we just don't have test coverage yet)

<hhalpin> either jim or ryan? the PKCS/SPKI support

hhalpin: has anyone heard from JimSchaad or Ryan?

<hhalpin> We probably need a backup plan.

<hhalpin> 1) Keep them in the spec, but not as normative and mark them explicitly as possibly non-interoperable

hhalpin: two general paths: we can keep them in the spec, non-normative
... or remove entirely from the spec, as a large rewrite

<hhalpin> 2) Remove from spec entirely - large rewrite, Ryan Sleevi's preference

hhalpin: we could re-run question on the ML

@@: Do we have any quantification of the scope fo the problems?

scribe: both chrome and FF do imports

<hhalpin> I think it that they exported ones that were not well-formed

hhalpin: I think their exports were not interoperable
... and algorithm names differed
... edge cases around DER/BER
... it does seem people get value

markw: we're using these features
... a core set of features
... I'd hope we can identify the subset of what works

<hhalpin> wseltzer: We could have the text not specified as normative, we'd prefer to have them not removed if they are useful.

hhalpin: we may not be able to get to the middle path, wellq-

@@: better to get the API to handle them

<hhalpin> engelke: If they are not in the API, people will have to do in the Javascript, that seems less than optimal

hhalpin: I'll send a CfC to mark text as non-normative

<hhalpin> Will send a CfC yet again with the option Wendy outlined of keeping them in but marking as non-normative

<hhalpin> no formal objetions have that as Plan B specify that we'll try to get as much interop as possible given time constraints

markw: I had three lists of items

<markw> https://github.com/w3c/webcrypto/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22needs%20input%22

^ issues needing inptu from the group

hhalpin: does anyone on the phone volunteer to review these issues?

https://github.com/w3c/webcrypto/issues/111

ECDSA import does not specify the hash algorithm #111

<hhalpin> Seems like Jim's suggestion is right, i.e. just set the hash alg in the params

<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.

<markw> https://github.com/w3c/webcrypto/issues/111

markw: issue 111
... for ECDSA, we don't provide hash on import, whereas for other algos, we do.
... Jim suggests we do the same for ECDSA

@@: makes sense to match RSA and ECDSA

markw: I'll implement
... issue 110, HMAC Sign and Verify algorithms do not support trucated HMACs
... should we allow truncation?

<markw> https://github.com/w3c/webcrypto/issues/110

hhalpin: it would need testing

<hhalpin> I assume that would *not* work in tests but I think Jim motivated it well, i.e. the COSE use-case

<hhalpin> Charles - can we add a test for this?

markw: Issues 85, 87, 88. I just put up a PR, so revisit later
... issue 66. Jim suggests always return false if error or fail

<markw> https://github.com/w3c/webcrypto/issues/66

hhalpin: agree with Jim
... that's the safest

markw: does that mean all errors should return false?
... or type error on input ok?

hhalpin: padding oracle was the attack issue

markw: we can align RSA, ECDSA

<hhalpin> keep it as false except for typing error, correct?

markw: reject this PR and make a new one

<hhalpin> That's the right move

markw: issue 62

<markw> https://github.com/w3c/webcrypto/issues/62

markw: propose wontfix

<engelke> I agree with wontfix

markw: currently, you have to support all 3. do we want to keep that?
... we've left freedom for RSA, not AES

<hhalpin> In theory, browsers might want to 'future proof' and allow larger in the future without revisiting the spec.

<hhalpin> I think a minimum or suggested keys size makes sense.

markw: I'll close this issue, then open a new one re minimum required values for RSA parameters

hhalpin: we can look at test suite for minimum

<markw> https://github.com/w3c/webcrypto/issues/30

markw: issue 30

hhalpin: most of these have been removed
... I can check after the call

<markw> https://github.com/w3c/webcrypto/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22needs%20review%22%20

markw: ^ Needs Review
... outstanding PRs, please make comments, LGTM
... most are straightforward

hhalpin: I'll review
... often, it was problems with references

<markw> https://github.com/w3c/webcrypto/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20no%3Alabel%20no%3Aassignee%20-milestone%3AVNext

markw: ^ floating items

<hhalpin> "Normatively, the spec only be used with secure origins."

<hhalpin> (although implementations may do otherwise)

<hhalpin> So MS and Moz do of course support secure origins :)

wseltzer: we can Recommend secure origins, even if some implementations will operate in insecure or secure

<hhalpin> I think Richard Barnes was the one previously unhappy with requiring secure origin.

@@: seemed consistent with other specs to require secure origins

<hhalpin> (I can't remember the details of Richard's use-case)

hhalpin: any objection to requiring secure origins?

@@: I favor it

<hhalpin> OK, we'll let's make it normative - use with secure origins. MarkW - can you make that change?

hhalpin: sounds as though we're leaning toward secure origins as normative

markw: that should get a CfC on the list

<hhalpin> Wll write that CfC

hhalpin: I'll send one

markw: which version? you can require the document be secure, or look at top-level browsing context

<engelke> I think a secure iframe, even in an insecure document, is okay and useful.

engelke: I think webcrypto in an iframe is ok, useful

markw: then you can make a plugin in the iframe that exposes entire webcrypto API to the outside insecure page
... defeating the secure origin requirement

hhalpin: let's put the stronger one to the list, see if there's push-back

<hhalpin> Let's put the stronger constraint to the list.

hhalpin: we'll update the algo interop table when we finish the test suite

markw: I'll keep issue list updated with needs review tags
... please review/ give input

Timing

hhalpin: WG charter expires soon
... we want to get transition to PR out
... close out all the CfCs July 25
... then make a transition request, to W3C Director to go to Proposed Rec

<hhalpin> We *will* definitely have another on July 25th to deal with the CfCs and double-check closed issues

hhalpin: next meeting, July 25

<hhalpin> I'll try to draft a CR->PR request hit by CfCs July 25th

<hhalpin> So we'll try to definitely get out to PR by end of July at earliest, more likely sometime in August.

[adjourned]

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: wseltzer
Inferring Scribes: wseltzer
Present: wseltzer hhalpin David ttaubert engelke RobTrace markw
Found Date: 11 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/11-crypto-minutes.html
People with action items: