WebCrypto -- 01 Aug 2016

<markw> Could someone post the call details

<virginie> +1-617-324-0000 Access Code: 643 244 026

trackbot, start meeting

<trackbot> Meeting: Web Cryptography Working Group Teleconference

<scribe> scribe: hhalpin

<scribe> chair: virginie

Introduction

virginie: major issues are the two open CfCs

test status

engelke: Nothing new
... that what I've added before

wrapkey and exportkey should be with ourselves

good if those tests were done by end of August

is that realistic?

engelke: Not really not sure if I can take those on
... I'd be starting from scratch

ack q+

wseltzer: He's just busy and then traveling again

hhalpin: We'll see if we can get some more resources on this
... also we're waiting for jimsch to review some of my tests, but someone else can do the review that would be great

virginie: I'll work on getting more contact from Jim and anyone else interested in testing

major issues

virginie: Secure Contexts, only question is the localhost

markw: I should be fine should simply be to add that tag to the IDL, so straightforward

hhalpin: It's OK, there was no disagreement so we should go forward and let the Editor make the changes

virginie: There seemed to be some difference over key formats

engelke: I'd prefer it be left normative, but the responses from Ryan that the same problem go to JWK
... we shouldn't make any changes

virginie: We will not have two interoperable implemenations?

engelke: I think we have these issues
... but my test suites use pkcs8 and spki
... without bugs

<virginie> see ryan answer on JWK https://lists.w3.org/Archives/Public/public-webcrypto/2016Aug/0007.html

wselzter: For normative, we need two interoperable implementations
... the tests I have work on both browsers

markw: I tend to agree with this approach, that if tests pass, leave it normative
... if ryan has tests that show that various corner cases don't work across browsers, then we can change our opinion, or we can say those particular aspects that fail should not be relied on
... it's reasonable for us to say 'there are some corner cases'
... and 'we can't solve those with this spec.'

<wseltzer> hhalpin_: we're leaving them normative where they interoperate; add a warning that there may be some corner cases

<virginie> harry suggests that we add an informative text on corner cases, reminding that what is in the test is interoperable

<wseltzer> ... proposal: keep all usages of keys as normative where interop has been shown by test suite

PROPOSAL: We keep all usages of keys as normative where interop has been shown in the test-suite but warn specifically in the Rec on any parts of the Rec where this isn't interop and put a general informative warning that this Rec does not throughly define interop between all key formats in the spec.

<wseltzer> ... but warn in rec about possible edge cases; general informative warning that the rec does not define interop between all key formats

engelke: I believe the problem is when prime orders are reversed, and there may a lot of cases to check
... its possible that some of the stuff that Jim is checking on is why it's difficult to test key import/export thoroughly

<wseltzer> hhalpin_: generate works; the problem is import and export

<wseltzer> engelke: I've written some import and export in my tests, and it interoperates

<wseltzer> ... though that wasn't the primary focus of my tests

we hvaen't tested the entire space of possible keys

(obviously!)

virginie: it's ok to add informative note?

PROPOSAL: Add informative text to spec around key testing and then note that everything is normative that is tested by the test-suite.

engelke: I can live with it

<virginie> +1

<markw> +1

hhalpin: It does seem fine for most developers, but some warning that we aren't requiring underlying library interop seems sensible

Reviews

virginie: Any reviews?

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

markw: I haven't checked too deeply, I've been working on EME test-cases
... against deadline of tomorrow

its only 6 issues

CR->PR

1) test-suite for all normative features

2) the fact that all formal objections been dealt with

3) All open issues from CR entrance are closed

<wseltzer> hhalpin_: working on a revision to the CFRG crypto considerations doc

IETF doc expired, were going to review with Karthik (he gave it a good review it all)

add a note to that in the spec, and then I think that's the main formal objection

<virginie> https://tools.ietf.org/html/draft-irtf-cfrg-webcrypto-algorithms-00

request to CR, requires Virginie meeting with the Director

and discussing

have another meetin August 15th and close all issues and hit repub on the CFRG doc

<wseltzer> hhalpin_: charter expires end of September

August 30th

<wseltzer> hhalpin_: if we go to PR by end of Septmber, then we'd need an extension to get the PR->REC

<wseltzer> virginie: we have 30 open issues

<wseltzer> hhalpin_: Eric Roman has been opening issues

<wseltzer> ... should we review them now?

<wseltzer> markw: I haven't reviewed the most recently raised issues

<wseltzer> hhalpin_: aim to close them out by August 15

<wseltzer> ... or Aug 30

<wseltzer> markw: this week is encrypted media, next week vacation

August 22nd?

<wseltzer> virginie: meet August 22 to review issues

virginie: issue review on August 22nd

viginie: Hopefully on August 29th we can then review going to Director

RESOLUTION: Meeting on August 22nd

and the other on August 29th

virginie: AOB?
... it does seem the browser vendors are following, but let's try to get them to review the last remaining opening issues
... thanks for attending call

trackbot, end meeting

- DRAFT -

WebCrypto

01 Aug 2016

Attendees

Contents

Introduction

test status

major issues

Reviews

CR->PR

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output