webcrypto -- 30 Oct 2014

<virginie> Meeting:webcrypto

<virginie> Note : slideware to introduce the meeting is available here [pdf] https://www.w3.org/2012/webcrypto/wiki/images/2/2b/Web_Crypto_WG_F2F_Meeting_TPAC_2014_v1.pdf

<scribe> scribe: kodonog

Virginie: introductions around the room
... agenda plan

https://www.w3.org/2012/webcrypto/wiki/F2F_santa_clara_Oct2014

Virginie: Objectives for this F2F
... finalize webcrypto API
... trigger next phase
... general discussion (no decision) on next charter
... News from W3C blog, Jeff Jaffe says security is top priority
... W3C security activities on a http://www.w3.org/Security/wiki/Main_Page
... intro slides https://www.w3.org/2012/webcrypto/wiki/images/2/2b/Web_Crypto_WG_F2F_Meeting_TPAC_2014_v1.pdf
... Web Crypto Discovery API has been unchanged for months, what do we want to do with it (technical note, recommendation, next charter)

markw: I was expecting it to go to Last Call soon
... it doesn't have the same implementation status as desktop browers, but applicable for some devices

Virginie: that finishes my intro, now moving onto the webcrypto api

<markw> s/laptop browsers/the main api as it's not applicable to laptop & desktop browsers/

rsleevi: missing 25972 (secure origin)

<rsleevi> 25972

<harry> lets kill some bugs that we may otherwise forget

markw: the proposed list are the ones that I thought we could make good progress on

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25198

markw: minor implications either way

rsleevi: historical context, originally working around a promise webidl type of bug, the language has been fixed in the webIDL spec

<israelh> Preasent+ Israel_Hilerio

rsleevi: the main argument for doing it as an enum is making it more consistent with webidl
... if we take it on we are going to be taking on more spec maintenance
... would anyone be concerned with changing to enum

Israelh: so you are talking about using enums as strings

markw: no change as far as the user of the api is concerned
... may have a minor impact on errors

Virginie: there are no objections so we will change to ENUM, what is the timeframe for this change

markw: minor implications either way

<virginie> PROPOSAL: Resolve 25198 by changing the things we changed to DOMString back to enums (KeyFormat, KeyType, KeyUsage)

<rsleevi> +1

<rbarnes> +1

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26322

Virginie... 25198 is resolved

rsleevi: explanation: this is messy internal details, issue from tag review, how we expose java script objects without impacting internal processing
... two solutions under discussion
... goal is to not have it be visible

<israelh> q

markw: explained third option

<rbarnes> FWIW, in the current Firefox webidl, we have: [Cached, Constant, Frozen] readonly attribute sequence<KeyUsage> usages;

<nvdbleek> Can you see the internal internal slots in the debugger?

<rsleevi> You can neither see internal slots nor 'internal' internal slots

markw: what we store in the internal slot be what we expose in the ECMA script

<nvdbleek> hmm, it is going to be really confusing if you can’t access the ‘real’ internal values

<markw> Options 1) Store a frozen JS object in the existing internal slot

<markw> Option 2) Store a non-frozen JS object in a new internal slot, this is the one returned to script

<markw> Option 3) Store a frozen JS object in a new internal slot

<virginie> thanks mark for option reminder/clarifying

<markw> IIUC, Mozilla [Cached, Constant, Frozen] annotation is equivalent to option 3

israelh: this doesn't seem unique to us,

rsleevi: two dimensions to discussion, codify the internal slot in the spec and javascript can't mess with that,
... other dimension is that read only is a lie, frozen more aligns with what you expect from read only

israelh: we are adding more complexity, read only is a bigger problem,

markw: ideally webIDL would have solved this for us and we would use that solution

<virginie> note : the chair would like to poll : please type your favorite option in the irc in the form of 'I prefer option X' based on markw description

rsleevi: in the presence of this webIDL bug, we need to address it in some way
... we should just solve it in the spec,

harry: probably better to do the right thing then to continue a lie

israelh: to the extent that implementators aren't going to change their behavior, how much value is there to put this into the spec

rsleevi: TAG would prefer some discussion in the spec

markw: text problem at the moment is that the text isn't clear
... we could modify the existing text, we could also add a note that we are expecting webIDL to codify it in the future

israelh: everybody is modifying the objects

rsleevi: this is not what normal programmers expect but it is what web programmers expect
... draft proposal: don't freeze the attributes, ensure that the same ECMAscript object is returned

<virginie> PROPOSAL: 1) Don't freeze the attributes 2) Return the same ECMAscript object each time (aka [Cached])

<rsleevi> Correct, [Cached] but not [Frozen]

Virginie: seeing no objection, we will close the bug

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26741

rsleevi: we should check with the original submitters

markw: summarizing https://www.w3.org/Bugs/Public/show_bug.cgi?id=26741

<rbarnes> 1+

markw: this type of operation should be delevated to cryptographic libraries, do the libraries validate on import?
... given that libraries do, we should validate the public keys on import

<rsleevi> rsleevi: NSS didn't, but it does now

<joesteele> a/delevated/delegated/

<rsleevi> rsleevi: OpenSSL/BoringSSL do, CNG does. Unclear on Apple

<rsleevi> PROPOSAL: Validate EC keys are valid points on the curve during import, and return DataError if not

Virginie: no object, bug will be closed, clarification in the spec

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26903

markw: summarizing https://www.w3.org/Bugs/Public/show_bug.cgi?id=26903
... we don't know what granularity of errors you will get back from various cryptographic libraries, we are trying to normalize the errors
... distinction between errors where the raw data is wrong, or the web crypto parameters are incorrect values
... our definition of syntax errors includes out of range
... question is should we switch to ??? for all these range type of errors

rsleevi: this is really a debugging aide,

rbarnes: one exception is not supported error

israelh: we struggle with this alot, we don't believe that web developers look at the error types
... you can get better analysis of how things are failing, we could spend alot of time doing this for very little value

rsleevi: there is one thing that web developers do that reports general errors back to the server
... changes to the spec in this area don't affect site compatibility

israelh: this isn't necessarily the case, we are doing things that are borderline

rsleevi: you lie about who else you are, but you are also honest about who you are

markw: our previous decision on enum will have an effect of moving a number of these to type errors

<rsleevi> PROPOSAL: Take a sweep through and find any other issues that should be converted to TypeError

<JeffH> bug # ?

<virginie> to jeffH https://www.w3.org/Bugs/Public/show_bug.cgi?id=26903

<rsleevi> PROPOSAL: Take a sweep through and look for out of range issues that were previously SyntaxError and convert to TypeError

Virginie: no objection, resolved by proposal

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25619

markw: summarizing https://www.w3.org/Bugs/Public/show_bug.cgi?id=25619
... we don't have text on this, we could won't fix this

<markw> https://github.com/w3ctag/spec-reviews/issues/3#issuecomment-41521737, second bullet

vijay: why do we have to go around fixing

rsleevi: for implementors and users this is not an essential definition,

<rbarnes> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#scope-operations

<markw> "Although the API does not expose the notion of cryptographic providers or modules, each key is internally bound to a cryptographic provider or module, so web applications can rest assured that the right cryptographic provider or module will be used to perform cryptographic operations involving that key."

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#scope-operations

vijay: maybe we should just remove instances of cryptographic provider,

rsleevi: we added this paragraph on the TAGs request
... I'll take the action to delete text

<rsleevi> PROPOSAL: rsleevi to reword the section to remove much of the text

Virginie: 25619 closed with Ryan's text

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

Harry: can someone summarize the discussion

Virginie: Mark Nottingham could be on a case by case basis
... no general strategy from W3C

BradHill: in WebAppSec WG we had moved further towards requiring secure origin in more places
... no consensus yet at the W3C level

rsleevi: I will explain our position and rationale
... from the Chrome side we have restricted this to secure origin, there are at least 2 degrees of restrictions
... one restrict at the origin of the document or the top level of the origin of the document
... Chrome has implemented the first scenario, we believe that any web crypto delivered over http won't provide any security guarantees

<nvdbleek> rsleevi: What about localhost and protocols different from http(s) (more specfic on mobile where you can have hybrid applications)

virginie: google has an implementation and it would be hard to sum up

<rsleevi> nvdbleek: See http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features for our current context

markw: there are 2 distinct topics: 1) when is it appropriate to require a secure origin as a part of a new feature
... 2) does it make any sense to use webcrypto over http or are any security benefits that you think you might have just an illusion

<nvdbleek> rsleevi: thank you this totally answers my questions and I personally don’t see any problems with the secure origins proposal

markw: we (netflix) have derived some security benefits from this
... test on secure origins, and test on insecure origins (either all pass or all fail)

virginie: mark would be willing to make it allowed for UAs to restrict to secure origins based on the google approach of the restriction is on the document and not the top level document

mountie: for many years i have request exceptions for some options, ihow do we accept exceptions for secure origin

virginie: is this question out of scope

<rsleevi> rsleevi: Same Origins Policy changes are out of scope

<harry> That's whats in the charter

<rsleevi> but the (Chrome) proposal recognizes https, wss - but also localhost, 127.0.0.0/8, ::1/128, file, extensions, etc

virginie: this is for future discussion

rsleevi: does the current spec allow you to restrict origins today, google's view is "yes"
... another dimension, if we require https for algorithms ...
... we could do this on an algorithm by algorithm basis and normatively require secure origin for some algorithms and not others

harry: we are moving towards a strawman consensus
... do not require normatively but strongly encourage and list some use cases where it might be ok

rbarnes: our implementation does not enforce any secure origins for webcrypto
... our rationale was that there are some use cases where this makes sense
... obvious case is digest

<rsleevi> rbarnes: If your view is that passive attackers are the concern, webcrypto over HTTP is just fine

rbarnes: this helps for the passive attcker case but obvious not MITM

<rsleevi> scribenick: rsleevi

<virginie> thanks rsleevi

<kodonog> yes thanks rsleevi

rbarnes: it seems that unless you restrict on top level documents, people will work around any restrictions
... someone could stand up https://webcrypto.io and offer a pass-through that would avoid things like same origin restriction
... seems like restricting to origin without restricting top level will end up in a worse world

<joesteele> -q

israelh: for us, one of the big concerns of starting to restrict some things in general is enterprises / intranets
... we do see some people who want to use different capabilities inside of their firewall/organizations, and we want to provide them some flexibility

<harry> In my personal opinion, restriction to secure origin makes sense for the 99%.

israelh: while we see value in this, we think it's up to corporations to set their policies and what sort of environments they want to support

<harry> That being said, making it normative in the spec - I'm not sure how that will change things if at least one or two vendors have real use-cases they will use this API that they won't change.

israelh: and we see this for some of the adhoc development in enterprises where someone is given a project and told to go implement, it's difficult for them to stand up an HTTPS server

<harry> In general, the text should be aimed at Web developers to make sure they do *not* use non-secure origins

israelh: from our perspective, it's OK to leave it up to the people who use this stuff to understand their policies

<harry> Enterprise and the Netflix case is a bit odd.

<harry> but they do exist

virginie: Clarification on which you'd prefer

israelh: informative text

vgb: I'm not sure what we would require in a spec to get this
... we have windows features where only certain hosts can be accessed over IPSec w/ source authentication
... by the time we're done listening the matrix of what should be done, we're adding lots of complexity
... I'm suggesting there's so much nuance here that we shouldn't try to express the nuance

rbarnes: I think you can put some things in the security considerations

<wseltzer> rsleevi: to address israel and vijay, that file origins and chrome extensions are treated as secure origins

<wseltzer> ... you've also made choices, e.g. Internet zone

<virginie> thanks wseltzer

<wseltzer> ... and other zoning; these policies already differ from global web-wide

<wseltzer> ... regarding concern for developers, that it's hard for a single dev to stand up an HTTPS server, what consititutes a secure origin is left to the browser

<wseltzer> ... Browsers already have policies, e.g. webgl limits

<wseltzer> ... So browser can have policy "treat this http page as secure origin"

<wseltzer> israelh: We tried hard not to continue path we took before, not to separate internet/intranet

<wseltzer> ... even to the detriment of intranet sites running on IE7

<wseltzer> ... we despise the notion of fragmenting the Web Platform at the API level

<wseltzer> ... I agree we should enable policies that people and corporations can manage

<wseltzer> ... caveat, that doesn't make normative changes to the spec

<wseltzer> ... maybe a note, that agent should enable global policies to be set

rbarnes: I'm gonna catch on the other half
... where we can say secure origin and wave our hands
... seems sort of developer hostile
... it may have loose fringy edges but it needs some solid core for developers
... I think we're largely thinking in an HTTP/1.1 world
... where you can deliver HTTP schemed origins over HTTPS connections
... it seems like you might be able to get more security for origins than you think

virginie: Options: mandate secure origins
... include in the spec in a normative way as an option
... option 3: have informative text
... option 4: do nothing
... Please express preferences in IRC about which options you prefer

<vgb> 3

rsleevi: Option 1

<markw> 3 or 4

<rbarnes> 3

<israelh> 3

<wseltzer> virginie: Who would object to mandating secure origin?

virginie: Show of hand objection, who would object to Option 1

<vgb> +1 for the reason that it would be hard to precisely define

<markw> +1

<israelh> Same as vgb

<mountielee> can not choose

<markw> for the reason that webCrypto is still useful on insecure origins

<wseltzer> rsleevi: We'd have issues; it does no one any favors

<wseltzer> ... doesn't give developers a clear expectation

<wseltzer> ... a security consideration that shoudl be obvious to the web

<wseltzer> ... For implementors, the "MAY" doesn't address any interop concerns

<wseltzer> ... vijay raised the concern that it's difficult to express secure origins

<wseltzer> ... that convo is happeniing in several groups, eg. svc workers, which has clear security concerns

<wseltzer> ... Q: If there was a suitable def of secure origin, would you go with option 1?

<wseltzer> @@

<wseltzer> rsleevi: for chrome, svc workers, you don't get it over http unless you open dev tools

<wseltzer> ... for developers, expectation you won't be able to throw it on an http site and use it

<wseltzer> ... but enterprise policy lets you set an exception

<wseltzer> vijay: I see how leaving it to implementers is a cop-out, but don't see how it's worse than policy-based bypass proposal

<wseltzer> ... since all the telemetry I've seen, when you give users a prompt, they say "yes, get work done"

<wseltzer> israelh: you never see a prompt

<wseltzer> [10 minute break]

virginie: Based on the discussion, I don't think there's any consensus to go forward with secure origin
... I see in other working groups there will be more urgent requests for a definition for secure origin (e.g. service worker)
... putting a dependency on secure origins may be nonproductive
... based on that, I'd go with informative text on secure origin

<virginie> q.

<wseltzer> rsleevi: I think it's important for this group to have the technical discussion

<wseltzer> ... is the objection to option 1 that we don't have a good enough def of secure origin?

<wseltzer> ... or are there other concernce?

<wseltzer> ... I'd prefer not to make the decision today without that discussion

virginie: My issue is we're trying to finalize the spec, and we're trying to deliver something
... I feel like there's no consensus on this new feature, and it would take ages (months) to address the issues
... and there's only one company requesting for secure origin
... which is why I'm cutting the debate. I'm more interested in shipping something

israelh: one thing I'm not even sure if it's in our charter to figure out what this secure origin is
... I think it's a great thing to do, but I don't think it's necessarily our focus
... at some point you need to make the best decision based on the knowledge you have

rbarnes: One of the points raised in the pervassive monitoring was that it'd be useful to have a broader perspective on what it means

<wseltzer> rsleevi: it will take years to change course, once we ship

<wseltzer> ... look at geolocation, EME

<wseltzer> virginie: are you saying we need to stop the web now?

<wseltzer> ... or can come to conclusion quickly?

<wseltzer> ... 2 weeks vs months?

<wseltzer> markw: Broader project to migrate all of web to https, that will take years

slightlyoff: You will continue to get static from the TAG if you make this decision

virginie: I discussed with another member from the TAG regarding secure origins and it did not seem like this was consistent with the TAG
... what would you recommend for the specification?

<wseltzer> rsleevi: normative text on secure origin, configurable through policy

<wseltzer> ... 2 qs, what to users expect, what do devs expect?

<wseltzer> ... if you set a minimum expectation, then that this policy may be extended, enhanced

<wseltzer> ... goal, be clear for devs, what user should experience when visiting their site

<wseltzer> ... interop concern on algos, if it's not clear to devs what users will have

<wseltzer> ... baseline expectation: if a user, frshly installed browser, comes to the site, what should they see

<wseltzer> ... then we can allow for carve-outs, e.g. local sites, developer options

virginie: If you can come back in the afternoon as to what the changes to the specification would be

israelh: I think it's clear / we have enough information to know what's proposed

markw: We've heard that this is supposed to be a case by case basis
... and the rationale here is different than say geolocation
... and that argument does not apply to webcrypto, since we see there are generally useful things that we can do
... so this is being used as a stick to push people to HTTPS

<slightlyoff> Spec text is necessary but not sufficient

<wseltzer> rsleevi: I was trying to understand, is this an opposition on definition, or on reasoning?

<wseltzer> ... if it's a definitional issue, I can work on the definition

<slightlyoff> And without necessary improvements, you don't get the outcomes you want

<wseltzer> ... if it's a purpose issue, then that's a longer conversation

<wseltzer> vijay: it seems to be a purpose issue

<markw> last part of my comment was that moving the web to HTTPS is a larger project in which spec mandates of this kind are not helpful

vgb: it seems like a statement of philosopical purpose in a normative portion of the spec is not an appropriate thing

<virginie> Resolution : https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 to be closed with option 3 or 4 (as decribed earlier)

<rbarnes> +1

<markw> +1

<vgb> +1

<mountielee> +1

<israelh> +1

<sangrae> +1

<jin> +1

<mdwood> 0

<wseltzer> virginie: can we get proposed informative text?

<wseltzer> ... for discussion this afternoon

<wseltzer> rsleevi: @@ the may restrict is unnecessary

<wseltzer> ... unclear what option 3 proposes

<wseltzer> virginie: Discuss this afternoon

virginie: We will come back and revisit what Option 3 is proposing in the afternoon

rsleevi: (minuting my remarks earlier) saying a UA MAY restrict to a secure origin in the spec is unnecessary, as that's true for all specs. It's unclear whether what is being proposed is that the spec recommends that UAs SHOULD restrict to secure origin, or if it's something else. The spec already lists in security considerations for authors that they

SHOULD _use_ secure origins

<hhalpin> It's likely SHOULD for 99% uses

<npdoty> scribenick: npdoty

Web Crypto bugs

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972

<harry> hi everyone!

virginie: scenario regarding secure origin
... clarify behavior or recommend usage of a secure origin
... 2 options:
... 1) write some text or 2) do nothing
... already written a requirement for using HTTPS

rsleevi: currently, text is a recommendation to use https in the security considerations

<harry> Security consideration text: "

<harry> While this API provides important functionality for the development of secure applications, it does not attempt to provide a mitigation for existing threats to the web security model, such as script injection or hostile intermediaries. As such, application developers must take care to ensure applications are secured against common and traditional attacks, such as script injection, by making use of appropriate existing functionality such as Content Security Poli

<harry> cy and the use of TLS. "

rsleevi: the question is whether to add a requirement for UAs to the specification

<virginie> as a reminder our morning minutes are : http://www.w3.org/2014/10/30-crypto-minutes.html

thoughts?

harry: what would the text look like?

rsleevi: point to existing specifications, like Service Worker, that normatively require TLS
... but a recognition that policy always exist in the Web platform, and specs don't address it, because policy is policy

<harry> From Service workers: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#security-considerations

rsleevi: say, effectively, that UAs will expose this feature on HTTPS but not on HTTP

<harry> Key sentence is "Service workers should be implemented to be HTTPS-only. "

rsleevi: already have a number of specifications that don't mention policy

<harry> Then there's some discussion:

<harry> "The reasons for SSL-only support include:

<harry> Better to protect end users from man-in-the-middle attacks

<harry> Do good by encouraging HTTPS adoption

<harry> Existing "playground" services (e.g. github.io) now work with HTTPS

<harry> HTTPS is coming across much more of the web quickly

<harry> Devtools can loosen the restriction for development (file://, localhost, etc.)

<harry> "

rsleevi: and of course policy overrides specifications, because policy is about configuring to do something other than originally expected

israelh: already discussed. what about option 3?
... like a non-binding note to user agents

virginie: could take the example from service worker, but informative rather than normative

harry: seems like Web Crypto should be implemented to be HTTPS-only in user agents
... might be different for Web Crypto rather than other api's
... could have a SHOULD instead of a MUST
... would be clearer as a note to developers
... so that the standard web case should be over TLS, but could have some alternative environments

<rsleevi> npdoty: I don't have a particular view on the view of normativity

<rsleevi> ... it seems like we need to have a better definition, perhaps authenticated origins

<rsleevi> ... a term from the Mixed Content Specification

<mountie> +1

<harry> Rather easy to reference that spec

rsleevi: yes, have a definition in normative language and an algorithm to evaluate it, addresses edge cases

<rsleevi> Mixed Content specification: https://w3c.github.io/webappsec/specs/mixedcontent/

rsleevi: willing to write up the proposal, although I would prefer MUST to SHOULD

virginie: follow up in email

<rsleevi> including https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features

virginie: 16 minutes left before test session
... list of bugs to address
... more to do on errata extension?

markw: done.

virginie: security recommendations, expecting something from IETF CRFG

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607

harry: received a response, with expectation of decision by early December
... don't think that actually influences us right now
... we have a clear errata process if we need to change it later

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=2561

<markw> @rsleevi, regarding https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features, I don't think we have agreed that WebCrypto is a "powerful feature" - at least we have not really discussed that

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25619

rsleevi: addressed this morning.

26322 already addressed

27137 just editorial, has been fixed

24944 pubrules

markw: need to be consistent about reference to normative/informative references
... isn't there a bug about interoperability?

rsleevi: we've floated different proposals, but not closed

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

harry: we have a game plan

rbarnes: game plan is to see what's implemented and perhaps have a common core

virginie: milestones
... before the new W3C Process was endorsed, following 2005 Process
... Candidate Recommendation, Proposed Recommendation and then Recommendation

harry: could have small changes based on a decision we could make after CR

virginie: try to put some dates to these Rec track steps
... determine when are we going to re-charter?

harry: CR will depend on the test suite situation
... could be fairly quickly, in a few months
... PR and Rec are more of a phase about patent commitments more than anything else, little for the WG to do
... workload for the WG will lighten after CR
... want to finish the test suite, and then re-charter
... likely to be over the winter, but could be variable so don't need to settle those dates in a new charter right now

virginie: harry to prepare the transition request
... need the editors to have a very clean response to all bugs. when will bugzilla be empty?

markw: could be early next week

harry: can start pubrules once you send me an email

<harry> once all the text is completed.

<harry> in terms of substantial comments.

Tests and Tools

harry: for a spec for which you have a few different implementations, can you explain the testing and toolset?

jgraham: basically, there's a certain existing infrastructure for testing
... a harness for writing tests: testharness.js
... documented on testthewebforward.org
... server-side component
... a repository of web platform tests
... pull down the server as well as all the tests, a complete locally available test environment
... a couple of tools for running the tests: in-browser runner, one page after another
... reports of different implementations, produces JSON output and tables
... wbtrunner: run the tests externally and run them in various different browsers
... state of the infrastructure

virginie: don't have any tests yet, but do have implementations, don't have anyone in charge of tests
... what's your advice for making the testing phase efficient?

jgraham: not sure historically we've been that successful about getting all the tests, but we're getting better
... some WGs have appointed a czar as responsible for the tests
... make sure people are actually submitting tests, getting others to review, etc.
... giving someone responsibility may be quite helpful

berjon: it's work
... some groups have had test-oriented meetings

<markw> There are some Jasmine tests in the web folder here: https://github.com/Netflix/NfWebCrypto/tree/master/

berjon: a f2f meeting where people code, maybe just 5 people all-day for two or three days
... good for momentum

rsleevi: question on licensing expectations for tests

jgraham: typically dual licensed, W3C Test Suite License, but for all other purposes are BSD licensed

rsleevi: there are a ton of tests in Chromium, which is already BSD licensed
... just might be a matter of importing them
... WebKit also has tests, but not sure about translating them or the license

rbarnes: Mozilla has tests that could be moved over as well

jgraham: problem isn't about license, typically, but about time to convert

markw: also have tests we could contribute, and don't have time to convert

<rbarnes> the moz tests: http://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=path%3Adom%2Fcrypto%2Ftest&redirect=true

israelh: without a test team/restructuring recently

harry: just wanted to check about MSFT. anyone else with tests?

<rsleevi> https://code.google.com/p/chromium/codesearch#chromium/src/content/test/data/webcrypto/ as test data with https://code.google.com/p/chromium/codesearch#chromium/src/content/child/webcrypto/test/

harry: just finding someone to do the conversion of Chrome, Mozilla, Netflix tests

berjon: coordinating test-writing, could have been more efficient to just use the open source testing in Web Platform

rsleevi: but unit tests are easier/closer to run for a particular product during development

virginie: how do we know when we're happy about test coverage?

berjon: we've tried to build heuristics in the past. parse the spec, detect a conformant statement, and then expect a certain number of tests
... without doing the human work of comparing the spec and the tests
... job of the test czar
... never get to Rec without a good test suite

jgraham: looking at the tests posted in IRC. Mozilla tests are something you can start from -- written in JavaScript in the Web browser, not about a specific implementation

markw: Netflix tests also include tests that run in the browser

virginie: who wrote the nice tests?

<rsleevi> Apple's is http://trac.webkit.org/browser/trunk/LayoutTests/crypto

<rsleevi> which are all JS as well

jgraham: would like to avoid different test formats, which requires maintaining an ever greater number of test formats/harnesses

virginie: anyway interested in investing in the tests, in order to advance to Recommendation

harry: I'll take an action about trying to make a more compelling reason for Test Czar or TTWF event
... maybe there's funding available for events
... make it more enticing

berjon: #testing is a friendly channel for getting advice

thanks from and to the testing folks

Implementations

harry: good with promises?

israelh: yeah

<rbarnes> detailed firefox status: https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing

virginie: microsoft, google, mozilla, apple, netflix plugin

rsleevi: netflix tests passed in Chrome
... similar status on algorithms to Firefox
... not adding new algorithms to NSS-based implementations
... moving all of our platforms to BoringSSL
... will have algorithms that appear differently in different versions as we move to BoringSSL
... a penalty of a decreasing number of cryptographic libraries
... not planning to implement AES-CMAC or CONCAT
... if people have use cases, let us know
... ECC is also going into BoringSSL soon
... depending on platform

rbarnes: spreadsheet https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing#gid=1
... as of Firefox 35 in early January, all algorithms will be there
... turning on WebCrypto by default in November-ish
... ECDSA and ECDH, likely to come in January
... not seeing demand for CFB
... not planning on CONCAT or HKDF

rsleevi: differences in the specification of CONCAT?

vijay: CONCAT is fine

virginie: for the group, how are we going to document? interoperability bugs will require us to describe the implementations and interoperability tests
... should we keep track of different implementations?
... level of implementation should be documented

harry: with the test suite

rsleevi: focus on the test suite, and answers not just whether the vendor announces support but empirically whether it does

<rsleevi> npdoty: Do we have any site that will tell us the implementation status for different browsers

<rsleevi> hhalpin: That's generally covered by tests (Test the web forward)

harry: haven't seen that automated, though maybe it was interest

israelh: behind a flag?

won't be behind a flag or isn't behind a flag

<harry> To be clear, there was interest and I think it would be a good idea but doesn't exist yet

Web Crypto Next Workshop

<rbarnes> in safari, it appears to be window.crypto.webkitSubtle

<harry> heh webkitSubtle :)

virginie: 70 people, 44 papers, actors from several industries

<harry> it's a subtle fad

<scribe> ... new friends -- lots of w3c non-members

UNKNOWN_SPEAKER: discussion of new features: algorithms, key storage/secure storage, etc.
... authentication and access to services in secure token

<mountie> please post the link of report

UNKNOWN_SPEAKER: secure elements, TPM, trusted execution environment
... scheme for authentication, similar to FIDO alliance or PKI-based challenge-response
... discussion of government authentication
... report available

<harry> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html

UNKNOWN_SPEAKER: followed-up on Web Security IG mailing list, a public discussion (not to interrupt Last Call)
... next step is to find a place for new features to land
... charter or re-charter as necessary. could be in Web App Sec, or Web Crypto
... both potentially re-chartering now
... captured a list of use cases or new features

Authentication API: medium support

Algorithm Discovery: medium support

Key Discovery: high support

Device Discovery: high support

Hardware tokens in scope (including Platform-held keys): unanimous support

Attestation of provenance: high support

Discovery with access control: medium support

Multi-origin support: medium support

User-owned keys: medium support

Origin and attested signatures: medium support

Local authentication binding with key usage: high support

virginie: harry organized a show of hands for rough count
... high numbers for hardware tokens (lots of those vendors in the room, but interest from others too)
... any questions?

harry: to clarify, W3C doesn't do workshops just 'cause, but rather because of interest of Members
... maybe sooner than necessary. heterogeneous group
... but try to get consensus at least from the members who would be in the WG
... do people show up? do they agree at all?

<virginie> note : raw notes of the workshop https://www.w3.org/Security/wiki/IG/webcryptonext_workshop

harry: capabilities for accessing hardware-bound tokens would be useful
... not necessarily agreement for a single technical approach

virginie: if I stay as a chair, don't want work in the charter that people won't contribute to
... pushing hardware vendors to join if they want to see that work done

rbarnes: very valuable for me in seeing all the hardware work out there
... problem of supporting secure hardware, but not a crypto problem
... might be better in a different WG, rather than just a Crypto approach
... open to discussing other topics

rsleevi: have a similar position
... w/r/t rechartering, likely not interested beyond potential algorithmic changes
... Google interested in hardware token, part of FIDO, not a crypto problem
... not very interested in a general API for hardware tokens
... unless we see a set of proposals that already look valuable
... for proposals that want to explore/propose something valuable, could use a Business Group or Interest Group
... model that FIDO has used is a good example. got a set of use cases and requirements and then an API, and now have a completed set for discussion
... includes platform-bound keys, which can be privacy-invasive, so will require a lot of discussion

harry: uncomfortable chartering new work unless we have a clear input submission or submissions with agreement
... having a blank slate in the WG (as we kind of did with this one) makes for more work
... FIDO work and key discovery would be the non-blank-slate one
... if people want to look at those sets of drafts here, if we have the time
... quicker to recharter than to start a new WG, but totally possible to charter new WG if we have committed
... could try to convince webappsec

virginie: webappsec has a poll for potential features for rechartering

nickv: they already went through their list of ten

selfissued: to take a contrary position on scope of rechartering
... two of the work items we're considering are about extending/using webcrypto capabilities
... using webcrypto operations with platform-held keys rather than browser-held keys
... not a big extension
... colleagues will present a concrete suggestion on how that could happen
... very in scope of this group to enable the use of more keys
... if we decide to take on the BigNum work, it's a clear extension of the WebCrypto work

<rsleevi> We have zero interest in the current BigNum proposal.

selfissued: it's not generic BigNum, but for field mathematics for cryptographic applications

vgb: broadly, +1 to rsleevi rbarnes

<rbarnes> i also don't have a strong feeling one way or another on bignum

vgb: shouldn't start with a blank slate, but a clear idea of what to do
... access to hardware is not primarily a crypto problem
... if we can break off the crypto part of that problem, if we can do that concretely, that would be good
... but don't want mission creep, away from our core competency

virginie: if the function is implemented in a hardware token

vgb: what should the interface be at a crypto level, rather than the device driver aspect

virginie: send to the WG members a poll, as webappsec has done, maybe in a few months

rsleevi: that said, we have been exploring APIs through extensions
... especially around security concerns regarding the hardware tokens
... before we would be willing to do that for the Web
... but have an extensions API, as encouragement for vendors to explore
... for platforms with extensions, a way to balance the functionality with security concerns
... in the near term, based on current discussions, not optimistic about a proposal. if there is a really good proposal, we'd support re-chartering
... work with the same set of people in the room, that might eventually make it into an API proposal

Certificate & Key Management

israelh: what's the minimum core set of capabilities that extend crypto
... users to be able to manage their certificates and keys independent of transactions
... not always associated with the domain of origin
... hardware-bound certificates or keys
... user-selection of certs and keys
... be able to generate new certs and keys as part of their workflow
... out of scope: dealing with writing certs/keys back to external devices
... existing capabilities
... ... provisioning certificates, processing operations, storage
... ... polyfills already provided
... ... server-side, updating and revoking certificates
... capabilities not already covered:
... ... generating keys
... ... get a key and sign with that key
... ... create an API so that a developer can get a key, but from anywhere
... what are the boundaries where we need to provide an API?

<rsleevi> Chrome extension documentation - https://developer.chrome.com/extensions/enterprise_platformKeys

israelh: using Pre-Provisioned Keys from External Devices
... can select a prompt that leads to an OS-provided interface for choosing a key and entering a PIN
... and only then return the key to the web api
... acquiring a new key from the Web
... going to a Visa site, creating a certificate, and then immediately return to the other page with that key/cert
... iframe collaboration / postMessage

<rbarnes> oh look, OAuth!

israelh: proposes two new methods on the SubtleCrypto interface
... signExt and generatekey

vgb_: origin-bound keys is almost everything, but want to bring in keys that exist but aren't origin-bound, like Smart Cards
... use user consent as the vehicle
... newly-generated keys will be origin-bound
... how do you know that the thing you signed is what the user thought they were signing?
... show this to the user and bind it together with the hash/signature
... primitive for a hash that is signed combined with what the user was shown to be signed
... useful and not a huge addition

israelh_: key metadata for querying a key at a later time
... "issuer" and "subject" for querying certificates later
... have an aggregated list of keys for the developer, rather than particular URIs
... always only get one key, the key that the user selected
... if the key is domain-bound, don't have to ask the user, already in the circle of trust

vgb_: having a relatively heavy-weight selection process. sites can clone the key, but users can clear with their browsing history
... preserves at least some of the user expectation of privacy

israelh_: [generate key example]
... [getKey example]
... rely on the user agent to bring up the UI, to look very different, full-screen system UI
... make it more difficult to be spoofed

questions?

vgb_: an early strawman, not a finished API draft
... detail of what we think a minimal, concrete proposal would look like

mountie: this covers the multiple topics discussed at the workshop, key discovery, multiple origin support, user provided keys
... +100

rsleevi: this is very similar in many ways to the Chrome extension API that we've explored
... doesn't address all the use cases that people want for smart cards
... especially for Internet at large
... biggest concern, security concern
... exposing hardware tokens of any sort, is that these can be trivially postMessaged off to another origin
... hard or unlikely to make it not-postMessage-able
... need a stronger component for authorization
... FIDO binds in the origin, unspoofable because it comes from the UA
... scary if possible to get permanent access to a hardware token from an evil site

vgb_: isn't existing also vulnerable to postMessage off the origin?

rsleevi: particularly for hardware tokens

vgb_: mitigated if the sign-with UI is sufficiently good
... if the signature is only valid for the thing you thought you were signing, then you're okay
... bad guy gets a signature, but it's not good for anything

<virginie> to rbarnes, lets finish that exchange, if this is ok with you ...

rsleevi: an early proposal was similar to mozilla window.crypto.sign box
... down that road lies madness
... XML DSig or PDF -- the space is messy
... one suggestion was sign all the resouces on the page (to ensure not XSS)

rbarnes: Firefox has had a similar API to this for a while, generate new keypair, enroll a certificate
... API is disappearing shortly, for security concerns and lack of use
... would want a more general approach

<mountie> ㅂ+

rbarnes: general way of talking to applications on secure hardware, where crypto is just one application
... access-control story, including these sharing issues

nvdbleek: for our use cases, the proposal looks very promising
... regarding keys moving to different origins. for lots of hardware tokens, have to add an extra PIN for every operation
... so the key is unlikely to be stolen, because it requires that PIN every time

rsleevi: the experience is that PINs don't at all mitigate that concern
... FIDO has a user interactivity requirement, but even that is insufficient
... a PIN prompt when you have 20 tabs open ....

vgb_: should have a richer conversation offline

mountie: for TLS, a certificate is the baseline of security on the Internet,
... we already need the certificate at the application-layer
... many things we need to touch at the application-layer, like key discovery

JeffH: some looks very similar to what we've done in FIDO

<rsleevi> Notes regarding hardware access APIs my previous presentation from the Lyon F2F - http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/att-0022/Web_Crypto_Introduction.pdf

JeffH: addressed issues that rsleevi is raising
... token-binding which is presumed that wasn't discussed
... a layered approach: discussing the Crypto API by itself, may create problems when trying to address the cohesive whole
... the app id and facet stuff, aluded to, is aimed at preventing misuse of the signing operation by other entities
... doesn't necessarily fit in web crypto
... token-binding stuff already in IETF

vgb_: a single more holistic discussion?

JeffH: scary, sharp security problems might be more present when looking at a piece in isolation

bhill2: Brad Hill, Facebook, Web App Sec
... paper co-authored with JeffH and some FIDO folks
... key-usage and origin-binding
... people want to use them from mobile applications as well
... how do we build keys that can be used, generally, in the browser but also Android, iOS, Windows Phone
... keep that as a high-level use case to keep in mind

<bhill2> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_44.pdf

vgb_: Web Crypto has always been about web interfaces to platform capabilities
... what would be the platform capability to which this would correspond?

<JeffH> the position paper hillbrad was referring to: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_44.pdf

bhill2: existing Smart Card systems or PKI systems aren't already built around origin concepts

rsleevi: tension between Extensible Web Manifesto and low-level primitives
... and this holistic view
... platform-keys have historically had bad security properties
... emergent properties vs. high-level, FIDO-like API
... desire and pressure to move existing systems to the Web
... Web has changed in the past two years
... have an extension / USB API
... low-level prmiitive, scoped to signed applications, add low-level interfaces to experiment with
... bringing platform keys into web crypto can't deal with the holistic security issues, because Smart Cards alone can't do so
... slides from Lyon still relevant

israelh: not a secure model, in that the extension can be across origins and doesn't have the guarantees that we're worried about

rsleevi: not inherently more secure, but allows for experimentation
... that's a good way to iterate and implement in order to get a more firm proposal

<rsleevi> scribenick: rsleevi

virginie: so this story of new features and rechartering will happen in a few months
... few things about the WG life
... our current operation method is we don't have calls anymore, we treat stuff over the mailing list
... we do ad-hoc calls if necessary, and then any resolutions on the calls have two weeks on the mailing list
... we meet once a year on average

<rbarnes> more meetings in Lyon!

virginie: Wanted to confirm that this WG method is still workable

<rbarnes> ping

virginie: Next steps: We will be working over the mailing list to clean the Web Crypto API
... specifically editors / chair / staff contacts to deal with progressing on the rec track
... question raised by @@ on whether we want to have a day for testing
... Would the WG be willing to spend a day or two F2F to integrate testing
... is there AOB to address before we close?

@@: The Web Payments IG has started this week

scribe: the web payments is only an IG at the moment. Our plan is to start collecting use cases, authentication, access to a secure element
... in time we'll look for a WG that can handle this work

virginie: I think we can now close the meeting. Thanks to everyone for the very hard work
... thanks to everyone for coming and have a great end of the week

- DRAFT -

webcrypto

30 Oct 2014

Attendees

Contents

Web Crypto bugs

Tests and Tools

Implementations

Web Crypto Next Workshop

Certificate & Key Management

Summary of Action Items

Scribe.perl diagnostic output