See also: IRC log
<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[End of scribe.perl diagnostic output]