<virginie> anyone else on the call ?

lets give people 5 minutes to arrive

there's been some progress on issues and tests

there's only 12 issues left

so we could walk through - there is still the localhost issue in WebAppSec

Is Charles on the phone?

scrive: hhalpin

<scribe> scribe: hhalpin

test status

virginie: charles is not here

hhalpin: He did wrap/unwrap and import/export
... I think the coverage is basically complete in principle although the tests could cover all sorts of negative cases

WebCrypto issues

<virginie> issues to be reviewed : https://github.com/w3c/webcrypto/issues

23 total issues

markw: A few more recent ones on top I haven't covered yet

<virginie> 6 requiring implementation : https://github.com/w3c/webcrypto/issues?q=is%3Aopen+is%3Aissue+label%3A%22needs+implementation%22

markw: we know what we want to do, but we need a textual change for those
... 'needs review' means we have text just need double-checking
... 'needs input' needs more group review

<virginie> need input : https://github.com/w3c/webcrypto/issues?q=is%3Aopen+is%3Aissue+label%3A%22needs+input%22

virginie: 4 issues require input

since we have tim, rob, and vgb makes sense to get input now!

<vgb> what is the blocked issue?

<vgb> i thought that issue is no longer relevant after PR #16?

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

issue 111: Hash algorithm specification for ECDSA

scribe: we set hash at time of operation
... but there is opposition to changing it
... so the proposal is to close as won't fix
... looking for JimSch
... and today he said it's OK
... so no changes needed in implementation

issue 85

<virginie> https://github.com/w3c/webcrypto/issues/85

markw: WebIDL find which global object to get
... boris notes we need to specify the global, but no opinions on what it should be
... tim and rob, do you attach WebCrypto to a global object?

tim: No strong opinion, but happy to take a look at it

virginie: over the coming week?

markw: What do browsers currently do? We'd want to specify what they currently do

<scribe> ACTION: ttaubert and RobTrace to determine what global object ot attach WebCrypto state to [recorded in http://www.w3.org/2016/08/29-crypto-minutes.html#action01]

<trackbot> Created ACTION-159 - And robtrace to determine what global object ot attach webcrypto state to [on Tim Taubert - due 2016-09-05].

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

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

<virginie> issue 28 is about secure origin

markw: Some commenters arguing against secure origin
... the argument could have prevented are invalid, confidentiality against passive observation although no protection against active attacker

I think Eric Roman adds that its just SubtleCrypto attached to secure contexts, seems sensible

what about localhost?

vgb: The only thing I feel sad about it losing hashes
... I think SHA-256 shouldn't require a secure origin
... but if you want to separate key material by origin, you need to say what origin is.

markw: Let's collect opinions - we can do that CfC

<wseltzer> https://w3c.github.io/webappsec-secure-contexts/#localhost

engelke: 127.0.0.1 should be secure

<markw> https://github.com/w3c/webappsec-secure-contexts/issues/43

" Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances. Given that uncertainty, this document errs on the conservative side by special-casing 127.0.0.1, but not localhost.?

markw: Let's follow webappsec document

I agree

virginie: So we seem confident we will follow WebAppSec decision

You could do a CfC binding to WebAppSec doc and attaching subtlecrypto

(i.e. random numbers are fine)

<virginie> Proposed resolution : we resolve that the subtleCrypto will require secure context, and endorsing any decision related to local made by web app sec WG

<virginie> +1

<markw> +1

+1

<engelke> +1

<vgb> +1

<RobTrace> +1

markw: Looks like just editorial work left

<wseltzer> RESOLVED (subject to confirmation on mailing list) the web crypto API will require secure context, and endorsing any decision related to local made by web app sec WG

<virginie> Lets switch issue 26 : https://github.com/w3c/webcrypto/issues/26

<virginie> recent discussions about JWK : https://lists.w3.org/Archives/Public/public-webcrypto/2016Aug/0036.html

engelke: There was a number of issues, OpenSSL would leave off leading byte
... thus, issues accpeting
... these have been open issues for a long time
... not WebCrypto-specific
... so I think we should accept these formats
... the output is always interoperable
... the main issues is some libraries accept malformed input
... I'd leave it as normative

virginie: I hear its interoeprable, some corner-cases
... I will do a CfC

to keep all formats as normative?

vgb: I've heard libraries are permissive
... so we input BER but output DER
... algorithm oids were an other issue
... these are the two issues

engelke: These are two I know about

vgb: So solution is you can accept any oid and must output in an interoperable manner

I think the issue ryan was most concerned about was the algorithm ids

<virginie> virginie : recommends that we keep the normative description of the different format, but welcome any suggestion refining the text to map with the reality

but if output->input round-tripping works, seems like we're fine even if input can be more permissive

vgb: I'll look one more time at this

Ideally, we want CfCs out by next week

vgb: Happy to do look this week

ack

markw: Sounds fair

another call in two weeks?

vgb: issue 42

<virginie> https://github.com/w3c/webcrypto/issues/42

markw: No longer blocked

CFRG accepted doc, just a few new attacks to be added and then doc updated

lets get CfCs out by end of first week of Sept if possible

26th of Sept everything should be closed

wseltzer: Group charter expires end of Sept.
... what proposed extension would be reasonable?
... requiring process wants us to do PR

[I would ask for 2 months to be safe]

[3 is better, just in case]

virginie: 3 is good, 6 would be better

wseltzer: 3 months end of Dec, 6 months into end of March
... Will see what we can get
... we're not anticpating 6 months of work

virginie: AOB
... If folks are at TPAC, we could meet informally
... Anyone at TPAC?

<virginie> +1

+1

<engelke> I won't be there.

<RobTrace> +1 - Tuesday, Wednesday

<wseltzer> all week

<vgb> +1 - Tuesday, Wednesday

<markw> I will be there

I'd say Tuesday lunch or Wednesday during breakout sessions?

virginie: Tuesday lunch?

<virginie> +1

<markw> Sure

Tuesday lunch informal WebCrypto meeting

<wseltzer> +1

virginie: will socialize it during AC

wseltzer: W3C is happy to highlight the good work you have all done

virginie: breakout session would help
... just one? or multiple breakouts

<virginie> ackws

next meeting in 2 weeks

trackbot, end meeting

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)

Succeeded: s/web crypto API/subtleCrypto/
Succeeded: s/CRG/CFRG/
Found Scribe: hhalpin
Inferring ScribeNick: hhalpin
Default Present: wseltzer, virginie, Tim, Rob, hhalpin, vgb, markw, engelke
Present: wseltzer virginie Tim Rob hhalpin vgb markw engelke
Found Date: 29 Aug 2016
Guessing minutes URL: http://www.w3.org/2016/08/29-crypto-minutes.html
People with action items: robtrace ttaubert