<ttaubert> hhalpin: I think that it might "just work", we have no tests for it so I can't say for sure. that's on the todo list

<hhalpin> excellent news ttaubert, we'll make a todo to add to the tests. That's the only large part of the spec at risk.

<jyates> Is there a meeting starting in a minute or so?

<ttaubert> jyates: yeah

<jyates> Thanks

<hhalpin> We're going to hold a few minutes for MarkW.

<hhalpin> scribe: wseltzer

<hhalpin> https://github.com/w3c/webcrypto/issues

markw: I've been going through issues in bursts

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

<hhalpin> is that a real use-case?

markw: is the idea that if you have only a prefix, you want to validate?

<hhalpin> https://github.com/w3c/webcrypto/issues/107

<hhalpin> WONTFIX?

<hhalpin> https://github.com/w3c/webcrypto/issues/88

markw: I can implement this one and 87
... I'll set to needs review

<hhalpin> https://github.com/w3c/webcrypto/issues/84

hhalpin: I think you're right, we don't want to enforce particular message
... wanted to get Graham Steele to double check the wrapping attacks
... it could be a problem if errors provided different response
... you can close the issue

<hhalpin> https://github.com/w3c/webcrypto/issues/82

markw: close 84, already implemented

hhalpin: I need to update the CFRG document, which was accepted

<hhalpin> Upate this https://datatracker.ietf.org/doc/draft-irtf-cfrg-webcrypto-algorithms/

<hhalpin> ACTION: hhalpin update CFRG doc, add pull request [recorded in http://www.w3.org/2016/06/20-crypto-minutes.html#action01]

<trackbot> Created ACTION-158 - Update cfrg doc, add pull request [on Harry Halpin - due 2016-06-27].

<hhalpin> https://github.com/w3c/webcrypto/issues/81

<hhalpin> https://github.com/w3c/webcrypto/issues/79

hhalpin: I'll take action on IANA considerations
... matching jwk makes sense

<hhalpin> https://github.com/w3c/webcrypto/issues/73 desire for streams is clearly v.Next

hhalpin: streams is clearly vnext

markw: it clearly a new feature, no one has tried it

<hhalpin> https://github.com/w3c/webcrypto/issues/72

markw: I have a pull request waiting for feedback
... basic validity checks
... recall discussions that some crypto libraries wouldn't check on import, only on key usage

<hhalpin> https://github.com/w3c/webcrypto/issues/72 (accept pull request and note this as test-case)

markw: my PR asked for validity checks on import; we can see whether browsers pass
... a test case

RobTrace: If we're talking about validating key, we're calling underlying OS APIs, not browser

markw: are you doing that validation at import?

RobTrace: I can take that back to ask

markw: there's a PR for 66; jimsch indicated not sure it's a good idea

hhalpin: safe thing to do is reject with fail

markw: jim's suggestion is never "reject", always return true or false
... My suggestion was to be consistent

<hhalpin> Jim's suggestion is more to the attacks.

markw: jimsch pointed out that some attacks could buidl on distinction between errors
... 62, wontfix

hhalpin: 48, odd wording

markw: someone else proposed a fix, I'll review

hhalpin: 45

markw: that's on me to implement

hhalpin: I'll ask Graham to review
... 43

markw: if it's new stuff, vnext
... I'll take off the needs-input
... 42, explicit salts, is blocked on 27

<hhalpin> 0https://github.com/w3c/webcrypto/issues/27

markw: people need to review jimsch's pull request

https://github.com/w3c/webcrypto/pull/16

hhalpin: be clear which spec we're followign
... 41
... does anyone know what it means?

markw: else close as wontfix

<hhalpin> https://github.com/w3c/webcrypto/issues/40

hhalpin: unhappy with unusual key wrapping behavior

<hhalpin> "Wrapped keys are exported and so only extractable keys can be wrapped. Thus, unwrapped key material is extractable and it not guaranteed that usages for a key have been preserved after the key have been wrapped."

<hhalpin> Test it!

<hhalpin> Graham was worried re losing usages earlier

hhalpin: we should test that
... do you have any wrapped keys we can use to t3est?
... adding a note in github
... 39

<hhalpin> https://github.com/w3c/webcrypto/issues/39

<hhalpin> RFC6090 -> Not SEC stuff

<hhalpin> Really old notes: https://github.com/w3c/webcrypto/issues/30

<hhalpin> https://github.com/w3c/webcrypto/issues/32

<hhalpin> If Jim's OK I'm OK.

markw: ok, wontfix

hhalpin: lots of the notes dealt with already

markw: secure origin is still open

<hhalpin> https://github.com/w3c/webcrypto/issues/28

<hhalpin> Chrome enforces secure origin, but if no one else does we can't keep it.

RobTrace: question, is there a valid use case for webcrypto on HTTP insecure link?

hhalpin: I think the answer shoudl be no

<hhalpin> Does anyone have actual use-cases here?

RobTrace: discussion about content encryption, apart from TLS channel

markw: if you're not a secure origin, code could be modified in transit to subvert any of webcrypto
... you couldn't protect against active attackers

hhalpin: mark it as recommended, if it's required in only one place

<hhalpin> Tell people they *REALLY* should use HTTPS if possible, but we don't require (so we can get out of Rec)

<hhalpin> https://github.com/w3c/webcrypto/issues/26

wseltzer: the important test is "does it work on secure origins" mroe than "does it fail on insecure," if implementors don't guarantee it will continue to work on insecure origins

hhalpin: 26

markw: from what I understand,the inconsistencies are in the weeds of optional features
... behavior for straightforward success cases is consistent

hhalpin: either strip out SPKI/PKCS, or adorn with a warning
... would a warning around ASN1 parsing work for Rob, Tim?

Rob: I don't have a strong opinion

ttaubert: I don't either; I wouldn't be too sad to see the formats go

hhalpin: can you confirm whether: remove, leave with a big warning, is preferable?

markw: we're using the subset where the behavior is consistent across browsers
... I'll check whether there's a big drawback to using JS libraries

hhalpin: 12, we'll do when test suite is done

<hhalpin> markw?

wseltzer: when do we meet next?

hhalpin: next week for check-in on test suite?
... looks as though we have good progress

<hhalpin> sound good - next week aim for reviewing tests, then skip 4th of July, then back on July 11th to editorial issues (double-check to see if MarkW's checked the open issues in)

<hhalpin> July 11th -> spki/pkcs would editorial, we'd want sooner rather than later if there's some preference.

hhalpin: Rob and Tim, let us know your reviews by July 11, if possible

<hhalpin> Meeting 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)

Succeeded: s/@@/RobTrace/
Succeeded: s/markw, are you rejoining us?//
Found Scribe: wseltzer
Inferring ScribeNick: wseltzer

WARNING: No "Topic:" lines found.

Default Present: wseltzer, ttaubert, markw, jyates, RobTrace, hhalpin
Present: wseltzer ttaubert markw jyates RobTrace hhalpin

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 20 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/20-crypto-minutes.html
People with action items: hhalpin

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report