See also: IRC log
<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
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
^ 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: ^ Needs Review
... outstanding PRs, please make comments, LGTM
... most are straightforward
hhalpin: I'll review
... often, it was problems with references
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
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:[End of scribe.perl diagnostic output]