See also: IRC log
<trackbot> Date: 24 April 2013
<rsleevi> scribenick: rsleevi
markw: Key Discovery API focuses specifically on named, pre-provisioned keys
... keys were placed there by somebody else - not the web crypto API / origin
... origin-specific and were placed there for a specific origin
... Use case is CE devices / TVs
<virginie> Web Crypto Key Discovery API editors draft https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html
markw: draft is trying to be generic as possible, staying within the scope of named, origin-specific, pre-provisioned keys
... keeping origin-specific is important as a way to address the many security concerns that might otherwise arise
... privacy considerations are largely adapted from web storage
... couple comments from the list, response is "If it's good enough for web storage, it should be good enough for us"
... very similar to cookies, except someone else put them there
... Define a subclass of Key - NamedKey - with two attributes - name and ID
... name identifies key within the same origin/device
... id uniquely identifies keys among all key sets. Essentially can be a device ID
... This is part of the use case. Netflix's use case has business rules that rely on knowing exactly what device is accessing the service
vgb: Do you only care about symmetric keys?
markw: There's no assumption about the type of key here. Should work for both
vgb: So does that mean if I have a key pair, I would have to look up both the public and private key pair separately
markw: yes
mountie: Is this only applicable to pre-provisioned keys? Is this available to all UAs
markw: It's only applicable to pre-provisioned keys
rbarnes: Pre-provisioned doesn't necessarily mean device keys
markw: Correct. It might have been provisioned by other means. eg: each time an origin asks for a key, a new key is provisioned for that origin using some key generation
mountie: The possibility of device IDs are being looked at in sysapps
... when users look at whether this API is useful for them, if there isn't coverage in UAs, then it's not really useful for them
... (discussions trying to clarify Mountie's point)
vgb: I think mountie's question is basically if I have a new application that wishes to use such pre-provisioned keys, how does it go about provisioning keys on existing devices
markw: That's a problem for applications to solve independent of this API
michaelh: Presumably the same name would be used for public / private
markw: that is something that's vague in the spec that we need to make a decision about
<scribe> ACTION: markw to clarify how public/private key pairs are retrieved with respect to naming [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action01]
<trackbot> Error finding 'markw'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<scribe> ACTION: watsonm to clarify how public/private key pairs are retrieved with respect to naming [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action02]
<trackbot> Error finding 'watsonm'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<scribe> ACTION: mark to clarify how public/private key pairs are retrieved with respect to naming [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action03]
<trackbot> Created ACTION-91 - Clarify how public/private key pairs are retrieved with respect to naming [on Mark Watson - due 2013-05-01].
karen: Why is the name important? If we restrict to the same origin, and we just say "getKeys", and specify some other attributes (like usage or type), why not just do that as a general API
markw: There are not that many attributes on keys, our assumption was you could just get those keys back by name and iterate
karen: So that means you need to have a way to define the uniqueness of names
mountie: origin specific keys can be exposed via DNS attacks
markw: This is no different than cookies or localStorage, if you're doing over HTTP. HTTPS origins are harder, but surely possible
virginie: Did we finish the previous point?
markw: No, the assumption is there's some unspecified method to pre-provisioned keys, and it's no stretch to say there's some assumption that it's also capable of provisioning names
... the person who wants to use the keys has to know about the pre-provisioning method
... in the specific example of TVs, we say put the key in the TV, and give it this name
... in the example of some generic provisioning method, the provisioner would say we provision keys "A", "B", and "C", and thats what you use
karen: I'm wondering why we can't have a more generic API
... so you provision your key, a secret key, which you know is specific for use by Netflix (or some other provider)
... and when the Netflix UA & application and is running, just says getKeys() and searches by some attribute
markw: In general, theres no reason we can't add things to the API
... but I'd be reluctant to add things to the API without a use case
... if there is a use case, I'd like to see a use case
... in your example, you have multiple keys that may match the properties, so you still need a way to distinguish them
karen: But isn't that the usage
markw: we have at least those two - but in principle, you could have multiple keys with all the same properties
karen: Ok, so you have a name, so you can say getKeys and say name as a generic attribute
markw: The question is why don't have have a "getKeys" and then you have to search them all
michaelh: why don't you have a SQL query where you just say get keys with some query
hhalpin: There's been very little discussion of key discovery on the mailing list
... even less outside review
... as a process point, we should just devote a day to key discovery
... so we have this potential problem where every telecon someone brings up smart cards
... I would suggest we do an ACTION to just handle a key discovery telecon
<hhalpin> i.e. we may not have time to do a thorough key discovery discussion
jimsch: I'm a little bit worried about potentially the process for key tainting
... it's not a particular issue for you because you're in hardware
<nvdbleek> had a close look at the spec hoping it would solve our use case, but it turned out not to be useful for our use case
<hhalpin> also we have lots of possible privacy issues, matching to smartcards and other use-cases, etc.
jimsch: but in software, you may want to change the modes at some later point
<hhalpin> you could easily go for a whole day on just key discovery :)
jimsch: so we potentially need some way to modify that
<Zakim> rsleevi, you wanted to respond to Karen
rsleevi: Wholly support Mark's specific narrowing of scope to just this
... think that any other use cases like hhalpin was suggesting should also be accompanied by spec proposals
... attempts to describe generic query APIs in the web has generally been a big failure and overly complex (CSS media queries, IDB)
mountie: Raises the social issue that UAs may deny applications this API, it's not a technical issue
vgb: I'm gonna do a sort of +1 to Mark and Ryan here. I would much rather see a simpler API that meets the use case that we have today
... which is searching a small set of pre-provisioned keys
... I think it's OK to say we don't solve everyones problem, but we solve some of the peoples problems
... I'd be very uncomfortable complicating this API at this point
... One thing might be making name optional, so that you can get all the keys when you don't specify the name
karen: I think we need to separate the definition of the API versus the implementation of it
<markw> @mountie: UAs/devices could support a generic online provisioning system that would provide a key or keys for any origin - this would make this API useful for any site, not just the big players
karen: if we agree we have getKeysByName, and then somebody else comes out with a use case
... then we'll have getKeysByKeyUsage, getKeysByAlgorithm, getKeysByKeyType
... so for each attribute we end up with a specific attribute
markw: Why? What for?
karen: You have a use case for name. get key by attribute
markw: A use case isn't that someone wants a key by attribute. A use case is why they want to do so
karen describes a situation where you want to use a signing key, and the application wants to say get signing key
virginie: It sounds like you still need to convince the group, and write down a use case
<scribe> ACTION: karen to write use case description describing the use case [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action04]
<trackbot> 'karen' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., klu, kodonog).
<markw> @karen: what if two keys with usage = sign come back ? Which do I use ? How do I know which one is the one to be used for the tax return and which one should be used for the medical document ?
<vgb> @karen i think these considerations matter if there are hundreds of pre-provisioned keys per origin - not clear when that would be. otherwise get all keys is fine.
<arun> note that Key Discovery puts origin restrictions, too, karen_, I'm not sure your use case is origin-constrained.
<wseltzer> action-80?
<trackbot> ACTION-80 -- Karen Lu to write up use case for the pre-provisioned key discovery use case -- due 2013-04-30 -- OPEN
<trackbot> http://www.w3.org/2012/webcrypto/track/actions/80
<markw> @karen_, @vgb I expect there to be just a handful of keys per origin
<inserted> [Next steps, dedicated call on Key Discovery, action-80 to develop use cases]
<rbarnes> @markw: then let's just expose one big dictionary of them
<vgb> @markw i agree
<hhalpin> Notes that testing will be 10:30-11:30 with Robin from HTML WG
<vgb> @rbarnes - this was my motivation for suggesting making the name optional
arun: I think it's a good thing when the WG says "please provide a use case"
<rbarnes> @vgb - right. i would be even more extreme, and just skip the method call -- window.crypto.keys[name]
arun: That the current use cases document which has key discovery and the api in the same documents was at first a bit awkward
... because as a browser vendor, pre-provisioned keys can be a bit hard to swallow
<virginie> Web Crypto WG use cases https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html
arun: the current use cases were largely taken up from the use cases wiki, not necessarily the spec
... including use case from tobie at Facebook, which in retrospect, may not be an appropriate security model
... another use case is browser ID
... another use case is OTR, if we actually want to take that seriously. Following up with nadim to discuss this
... other use cases that we extracted from the wiki included encrypted communications
... this came from a discussion with tantek over IRC, which is the extraction of whatever-you-might-use in your PGP key and then using it in a webmail application
... since it was given, it was documented
... It's worth noting that there are actively bad use cases, that we should try to block
selfissued: bad in what sense?
arun: we've seen back and forth discussions on the listserv of things you should or shouldn't do. You CAN do it, but that doesn't necessarily mean you should do it
... eg: supercookie
... or implementing TLS atop ws:// instead of using wss://
<nvdbleek> Could we consider https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/UseCases#document-signing as a use case for a future version of the spec?
arun: I wouldn't want to be a person who fabricates use cases in a glass house and say "Hey, this is a use case"
... want actual real world use cases
... questions about whether a high-level API is actually a use case
... we should get back to really good crypto use cases
... some of this is just cleaning up
... still kept the model of checking code sanity, but removed some of the threat model
... there's been some back and forth with mountie about the banking use case
... I think you're considering what actually happens in Korea today, but that doesn't necessarily 1:1 match what we're doing here
... but I think we may be able to come up with a credible scenario that doesn't exactly match what's done today, but that can address the use case
... I intend to add the BrowserID use case
... if there are any other additions, like to ask the group to submit them
karen: I will write a use case. How would you like me to write it
<markw> @vgb: we need the getKeys ... method to be asyncronous, so window.crypto.keys[name] doesn't work
(arun and karen discuss how to submit use cases)
arun: It's not that I have generated use cases out of the void. They're based on real world
<arun> Here is the document as it stands: https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html
rbarnes: arun, you mentioned OTR, I'd like to suggest we instead focus on XMPP
... I've got some additional use cases for demo apps that I've been playing with polycrypt
arun: I would argue that the simple, tangible use cases are the good ones
selfissued: Is the ability to build the JOSE implementation one of the existing use cases
<rbarnes> polycrypt hello world example: http://demo.polycrypt.net/hello
rsleevi: It's not in the use cases doc, but IS in the main document. Need to align those
<rbarnes> polycrypt self-signed certificate generator: http://demo.polycrypt.net/x509
nvdbleek: Yesterday we were discussing use cases for future versions. Is that something we want to document, or just focus on what we have today
<rbarnes> (and it wouldn't be hard to build a CA from the self-signed cert generator)
arun: I would prefer we focus on use cases that are enabled by the API or that can be accomplished by smaller changes. Can you provide an example?
nvdbleek: Example of using smart card signatures
<hhalpin> do we need to determine if use-cases that are *only* partially addressed should be included? I'm still not sure what the edges are.
virginie: Process clarification - since you're going to be getting use cases that may be about new features, what do we do with them
... can we park use cases in the wiki, and then keep the use cases document aligned
arun: Sounds like a good idea
mountie: will you prepare use cases with other WGs in combination
arun: Can you give an example
mountie: Working with WebAppSec for using/enhancing CSP
arun: Is your question will I combine webcrypto API with best security practice on the web?
mountie: Not just focusing on security
... for example, your previous use case is trying to protect JS source
arun: (refers to email) I think I've updated the spec to reflect your mail
... it seems like useful practice to provide sample code to go with the use cases. It's something I just did to show how you might use the API
... it should also of course not show bad things
... in the context of the use case of the code Tobie gave me, it did use eval()
... which isn't all that good
hhalpin: Clarifying point: There are use cases that are only partially addressed by webcrypto
<virginie> https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html#banking
hhalpin: what's the status on those? eg: the banking use case
... do those stay?
arun: But the banking use case makes no pretense of addressing the specific Korean use case
hhalpin raises points of secure remote password and eid, bits that may not be addressed entirely
hhalpin: Possibility of including primitives *not* included by webcrypto, but meant to be addressed elsewhere
arun: I think that'd be a distraction to include that stuff
... Do you think it'd be helpful to include a note at the end of the use cases to the wiki
hhalpin: We keep getting use cases to the list that we go back and forth where we're not trying to cover all use cases
arun: I guess the question is how do we make clear what we're not doing as a WG
virginie: action for arun to clarify what is and isn't covered in the spec?
arun: Well, we already do that.
<hhalpin> call out in a "red" font or "blue" font about primitives in use-cases that we can't cover, and then note for those use-cases we can't provide full JS examples obviously
karen: to echo what harry was saying, we need to clarify
... for example, the banking use case. In Europe, you have a banking card which is a smart card
<hhalpin> knowing what primitives we don't cover could be useful for future W3C and IETF WGs
karen: the keys aren't generated the first time you sign in, the keys are on the smart card
... a lot of the banking use case is pre-provisioned key
<hhalpin> and also explicitly redirect people away from keeping requesting these
karen: perhaps you can state we don't have a pre-provisioned key support within the spec
<virginie> use case for eID http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0177.html
arun asks for clarification on pre-provisioned keys. smart cards are pre-provisioned, but not necessarily origin-constrained
karen: If you want to use your banking ID to address the banking use case, you can't
israelh: One question I had from the use cases providing real code - is it real code we're trying to provide, or the pseudo-code?
... some of the comments you have are as useful or more useful than the code itself
arun: I agree. It would be nice to find a better way to proceed
israelh: I don't think you want to update the document every time the API changes
arun: I agree
rsleevi: I have to disagree with hhalpin about decomposing into primitives such as those we won't address
... seems like committing to a set of design choices that may not be appropriate or fully understood at the time we're documenting
... would prefer to see the use cases doc cover the cases we do, and leave to the wiki the partial cases
<hhalpin> Looking at charter, I'm trying to figure out the process for clarification on "secondary" features: http://www.w3.org/2011/11/webcryptography-charter.html
<MichaelH> Just say it cannot be met by the current API; but not why
arun: I'm not sure the best way to match the way to say No to the use cases we won't be addressing
nvdbleek: I think the test cases should reflect the use cases - that means a more concrete set of use cases
hhalpin: to be clear, the reason why I said we want to document the stuff we're not doing
<hhalpin> control of TLS session login/logout, derivation of keys from TLS sessions, a simplified data protection function, multiple key containers, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption.
hhalpin: for example, the secondary features from our charter
... one way to be clear about that is to say in the use cases document that we're not covering it
... for example, use cases that rely on those secondary features aren't addressed
... one way is to not include them in the use cases doc, and leave em in the wiki
... another way is to include them in the doc, but then say why we're not including them
... Want to avoid polluting the main spec of saying all the things we're not doing
<arun> ACTION: arun to add JOSE use case [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action05]
<trackbot> Created ACTION-92 - Add JOSE use case [on Arun Ranganathan - due 2013-05-01].
<hhalpin> Route 1): All use-cases that aren't completely covered we don't let in use-case document, we cover in wiki. Then we add some text in use case document that clarifies what secondary features we aren't covering as a WG
<arun> ACTION: arun to add caveats showing that web crypto WG is only addressing a subset of some use cases [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action06]
<trackbot> Created ACTION-93 - Add caveats showing that web crypto WG is only addressing a subset of some use cases [on Arun Ranganathan - due 2013-05-01].
israelh: a possible solution would be to add a note to a use case (eg: banking use case) is to state that we're not trying to cover the entire use case (such as the Korean banking use case), only a subset
<hhalpin> Route 2): Use-cases are allowed in use-case document that have bits we don't cover, but we explicitly mark those bits in some fashion and map those to things that are out of scope or in non-covered secondary features
<hhalpin> Either is fine I think!
arun: I've treated wrap/unwrap with great optimism that we will accomplish within the API
<arun> ACTION: arun to add BrowserID use case to use cases document [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action07]
<trackbot> Created ACTION-94 - Add BrowserID use case to use cases document [on Arun Ranganathan - due 2013-05-01].
20 minute break
next up: testing framework
<arun> I'm giving myself another action, namely to document a robust crosss-origin use case.
rberjon presenting
<arun> ACTION: arun to document a cross-origin use case for webcrypto [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action08]
<trackbot> Created ACTION-95 - Document a cross-origin use case for webcrypto [on Arun Ranganathan - due 2013-05-01].
rberjon: Testing is important
... especially for interop
... a growing collection of tests on the github repository
... repository is meant to be the centralized testing repository for all the web platform technologies going in to browsers
... once CSS is incorporated, close to 0.5GB of tests
... all tests use the same test harness
... If you want to ship your specs, write tests.
... Fairly easy to add tests. Fork the repository. Add new tests. Submit a pull request.
... Standard github workflow. If you're familiar with github, easy. If you're not, there are thousands of tutorials to help you, and we can too
... tests published to github are made available via the W3C test page
... adding infrastructure to run specific tests, all tests, etc. Similar to caniuse, browser support, etc
... in order to add tests, simple review process
... when a pull request is submitted, we want it reviewed by someone who isn't the person who submitted the test
... doesn't matter same company, same team, as long as they're different people.
virginie: What are the best practices for the WG in writing tests. Should we have one test leader, everyone else contributes?
rberjon: Depends on how your WG wants to work
israelh: How does this compare to other testing efforts? MSFT has submitted a lot of tests in the past through different means. Does that mean we go through github now?
rberjon: Yes.
rberjon provides context and limitations of the old way of handling tests in the W3C
scribe: ex: when looking for duplicated tests (between submitted & approved), found ~2000 duplicated files from people forgetting to move stuff from submitted -> approved
... in this system, the repo contains all/only approved tests. pull requests handle the submitted
... In other WGs, we've handled it where we're all test writers and test reviewers
ddahl: How does the test handle inter-origin pieces?
rberjon: w3c-tests.org has multiple open ports and domains, if you need to deal with inter-origin bits
... but does webcrypto need multiple origins?
israelh: Interesting to think about tests. Would we have a test encrypt then decrypt something, and make sure it gets the same output?
... or would we need to have inter-origin where someone sends you a key and then tells you what to expect?
rberjon: It depends on what your spec says normatively
... there's a difference in publishing a really really good test suite that you need to test interoperability
... and a test suite that you need to exit CR, which may be of a lower quality
... if you're confident that you can ship something that is (roughly) interoperable, then ship it, and continue to working on tests
arun: Is there any test suite that you think is particularly exemplary that you think we should emulate?
rberjon: interesting question
arun: Or at least more mature
(rberjon and arun discussing IndexedDB - turns out a bad pull/merge)
rberjon: Each HTML file is not necessarily a single test
... you may wish to group a series of logically related tests together into a single file
... you may wish to also split up tests (eg: for mobile, running 20,000 tests might run out the battery)
virginie: Question - how much support can we expect from you? Do you have a special line (laughter)
rberjon: If it's at a decent time... there's also a mailing lists called public-tests-infra@ - that's the right place to go for support in general
... that's the right place to ask questions. It'll probably be me answering, maybe tobie or ms2ger
hhalpin: Anyone else have github IDs that wish to be added to the repo?
<nvdbleek> https://github.com/nvdbleek
virginie: How much time does it take to develop tests?
<hhalpin> I'll add folks *now* if you put your Github nick i IRC
rberjon: It depends. For some simple specifications, we were done in a day or two
... beyond that, it depends on two things - the quality of the spec writing. A well written spec is easily tested
... it also depends on how things interact together
... eg: if you have user interaction or some other hardware/device
... If you want to write tests fast, you need to be in a sort of translation mode
... A user agent MUST do this... then translate that into a test to test that
nvdbleek: Isn't there a document that is meant to help specification writers write good specs for testing
<ddahl> also, using test harness: http://darobin.github.io/test-harness-tutorial/docs/using-testharness.html
<nvdbleek> http://www.w3.org/TR/test-methodology/
rbjeron: Yes, there's a test methodology doc that explains how to write good testable assertions and how to encode testing pieces within your specification
... very important for specification writers to read the advice in that specification, because it's very precise in how it describes writing a conformance assertion
... when specs are written that way, you can sort of translate them mentally into tests very easily
israelh: Is it fair to say you're reliant on submissions of tests - you're not going to write the tests yourselves, right?
rberjon: Yes, based on funding and priorities
... you don't necessarily have to be amember of the W3C to make test submissions. You do have to agree to the license
<hhalpin> For movement to CR, we will write something like this:
<hhalpin> based on the test-suite
israelh: Still not seeing movement for some of the older submissions from MSFT
rberjon: Yes, we're still catching up. New submissions are making it through quicker
<hhalpin> http://www.w3.org/2001/XKMS/Drafts/test-suite/CR-XKMS-Summary.html
<nvdbleek> http://www.w3.org/MarkUp/Forms/2008/XForms11ImplReports/results.htm ;)
<hhalpin> Aha, much nicer interop report:
<hhalpin> http://dev.w3.org/2006/waf/widgets-vmmf/imp-report/
israelh: Just because the tests aren't needed until exiting CR, doesn't mean you shouldn't write tests early
rberjon: Also notes about Test the Web Forward events to get involved with the community to help write tests
URL is http://testthewebforward.org/
rsleevi: Would postpone writing tests until the next public working draft
... the API should stablize there
... lots of algorithm specifications needed in order to be able to use algorithm KATs
... wrap/unwrap also brings in a dependency on JOSE test suites
markw: Just on JWE wrapped JWKs
rsleevi: But that's still a large set of tests, MTI algorithms, etc
<rbarnes> big set of test vectors: http://demo.polycrypt.net/
markw: But you'd have that regardless of the wrapping format
ddahl: +1 to waiting until we have a Futures API
israelh: while we can't say anything, naturally, when we look at implementation details and implementing specs, we like to have a test suite to go with it to show our conformance
ddahl: question for rbarnes, do you see polycrypt evolving with the spec changes
rbarnes: Yes. We try to match the API
israelh: Discussed with rsleevi briefly, worked on a proposal last night for a way to decouple the DOM dependency for server-side approaches
... so that we can discuss futures for their own merits, independent of the server side concerns
(israelh prepping slides to present)
gist of IDL modifications is to make CryptoOperation no longer derive from EventTarget
israelh: ... in the context of a server environment
... also replace the event functions with VoidFunction?, so there isn't a need to dispatch events
... ex: "attribute VoidFunction? onabort"
... thinking is that this sort of IDL can go into a non-normative section for the server environment
... from a programatic perspective, your code is more or less the same
... ex: operation.encrypt(...).oncomplete = function() { var myResult = this.result; }
... this sort of behaviour independent of new capabilities/new language approaches, gives you a way of expressing/dealing with constraints for the server environment
... gets you the same value (re-usage of code patterns) without having to bring in elements like capturing, bubbling, etc
arun: This seems to simplify things for your implementation (in the server), it doesn't really change the shape of the API
israelh: Right. That's the goal - we can just fit this in without going too radical
arun: Futures is pretty radical
israelh: One of our concerns is on the dependency on futures and the stability of it
... at least this is a programming model understood by developers
... it's unclear about what the powers may be may have
... at least wanted to separate out the server dependency from the discussion
rbarnes: Does this require changing anything in the base specification? Would this code actually work against the base spec? Don't you have to say event.target.result
israelh: No, you can still write this code
virginie: What's the action here?
israelh: I think we need to know the path forward - if we're going to go Futures, when do we say go / no go
vgb: I think the point is if we're not going to go futures, this piece of non-normative text would be sufficient to address the use case
arun: I actually think Futures are eating APIs and consuming them one by one
... i expect it won't be long before people approach me for File API and suggest we divorce it from eventtarget
... i think futures is taking over the web APIs. If we're going to divorce ourselves from EventTarget, futures are probably going to be it
... I don't think futures is too much heavy lifting. We should reconcile ourselves with it
israelh: If I look at TPAC 2 years ago, promises was the thing
arun: So you're afraid it's a fad?
israelh: Yes. That's our fear. We embraced promises in our Win8 Web APIs, and now we're here talking about Futures
... we've seen the conversation change over time, but we still have EventTarget and DOMEvents
... as we look at an implementation side, and getting stuff out in our release cycles, the less churn we have, the easier it is to get these things and push them through
virginie: Once Ryan come back with a Futures API, what's going to be the discussion within the WG to go forward with it?
rsleevi: I would suggest the decision will be coming from script-coord and TAG
... which is where I'm getting push for this
arun: To be fair, your TAG rep is the progenitor of Futures
rsleevi: True, but we are seeing the push for this from others.
virginie: So when we discuss futures. we'll need to get the input from everyone
mountie: The proposal looks at performing certificate management operations - issuing, updating, revoking, and validating certificates
<virginie> Freshly spueezed spec on Certifiate management http://mountielee.github.io/webcertapi/webcertapi_draft.html
mountie: certificate management API based on RFC 4210
(mountie discussing use case from draft)
sangrae: in charge of project to replace ActiveX control
(sangrae demonstrates how Korean banking works today)
sangrae: demo of integrating a CMP library into Firefox
arun: Is that using <keygen>
sangrae: No, this is using our CMP library
... requestCert API generates a CMP CertMessage request
... which you send to the CA server, which then processes it
... and sends back a CertMessage, which the UA calls handleResponse
... handleResponse returns a certResult message
... finally, UA then calls genConfirm to send a final confirmation to CA server that the operation is complete
michaelh: shouldn't your second arrow be a CertResult?
sangrae: No, its a CertMessage
... We have a RequestType to support alternative request messages - cmp, cms, pkcs10
... requestCert, updateCert, handleResp, genConfirm
... genConfirm is only used for CMP - if you're using PKCS#10, it's not necessary
vgb: Am I understanding correctly that requestCert is really generateCertRequest?
mountie: Yes, it generates the cert itself
vgb: And revoke is the same way, right? it's really generateRevocationRequest?
sangrae: Yes
karen: What about validation? Normally if you're doing revocation, it's because you're validating
jimsch: This is self-report - reporting your certificate should be revoked
mountie: discussing validation API
... security considerations: would like to disable the same origin policy for some aspects
... private keys, certificates, CAs
... want exceptions without user consent or UI
... certificate key storage should be interoperable with existing TLS key storage (not sure what it's called)
(mountie reads section 5.2 of draft)
scribe: if you're using TLS key storage, you can potentially use PKCS#11
vgb: The same origin exception sounds to me like you're saying let's just not do same origin
... the three bullet points I see applies to basically any certificate issued by any public CA
... this isn't a narrowly scoped exception, it seems like if you have any key for a certificate, lets just not do same origin
... which is a ... departure... from our existing security model
sangrae: If you have a certificate that's "trusted" from some CA, then you can use that key with any webpage
vgb: Without getting into a definition of what "trusted" means, you're really talking about all of them
mountie: let me get into the use cases
vgb: No no, I agree that you can do good things with this API
... but you can also do a lot of bad things with the API
... and our goal when designing a security API, you should not be able to do bad things
rbarnes: What are the bad things you can see?
vgb: If you take away same origin, a lot of bad things
... you're basically saying any origin has access to keys
mountie: But isn't that true for TLS key storage?
rsleevi: No. In those cases you have a trusted application (user agent) doing very specific things and performing a very specific operation
... your proposal gives full access to the key
jimsch: There is no reason that I know of that the protocol can't provide a list of origins as part of the protocol
... ex: you could send back a list of origins as part of CMP
mountie: TLS login and logout as a way of dealing with certificate auth
vgb: I think when the charter talks about TLS session disconnect, we're talking about a clearing TLS state
mountie: But what about TLS login
vgb: ... I think this was a different discussion
... I think we need to be careful with certificates and around the trust model
... For example, if you take the three bullet points [scribe note: From section 5.1]
... When I get a TLS private key, all I get is a statement that the holder of this private key has these statements
... I don't get the ability to use it silently
mountie: let me answer that - I didn't say silently
... to access private key, we need some sort of UI
... that is dependent on the user agent
... have the UI let the user choose what certificate they want to use and then enter some pin
<vgb> rsleevi: i'm struggling to separate the API proposal from the underlying requrement
<vgb> ... implementing CMP in a browser is a lot to bite off.
<vgb> ... also reiterate security concerns - this api would permit supercookies, do bad things with TLSnkeys, etc.
<vgb> ... Speaking for Chrome and Mozilla, CRLs and OCSP are not supported to the extent you need here.
<vgb> ... Need to distill this down to a small kernel of browser capabilities, and polyfill the rest
mountie: I think we need to open the certificate pandora's box. Many people are waiting for something with certificates
... generating PKCS#7 formatted messages, ASN.1 encoding/decoding, certificate validating/issuing
... our requirements up to CMP, and then PKCS#7 formatted signatures
... and how we verify certificates
... it would be beneficial for many users who have experience with certificates
sangrae: in Korea we currently use ActiveX controls, but there are many security problems with this
... certificates and private keys are normally stored in the OS store that we can use
... but if we had certificate management functions, we could resolve many of those security problems
mountie: if we had web standards, we could resolve those security concerns for those users
MichaelH: First of all, I like it, trying to support certificates
... to mitigate the security concerns, can we have some sort of registration
... where the provider registers an origin, exports the key, then brings it in
... so we still have same origin protection
... on the security issues, you're not really mitigating the issues
... you're just moving them from the plugin into the browser
... but they're still ultimately there
karen: your use case is similar to the use cases I've been talking about
... such as the eid use case
(discussing government issued ID)
scribe: with the proposal itself, I think if we want to have this kind of management
... we'll have to address the sort of access control
... for example, when you issue a certificate, it might not be the users decision, it might also be the issuer's decision
... for example, mobile device using something like ISIS
... ISIS is an example of who has control over the keys. the UCIC has controls over who has access to the keys
sangrae: In the Korea case, every private key is protected by password
ddahl: A little bit of background on this would be helpful
... has the Korean government actually looked at the same origin policy
... and decided this wasn't acceptable?
... it seems like you're driving in the wrong direction for years with this
rbarnes: In agreement with rsleevi here - what are the things you cannot do in the browser
... certificate management protocols are almost certainly not in that domain
... it seems to me that the critical thing is being able to control what certificate and private key can be associated with a TLS connection
... dealing with that might be much better than trying to figure out how to address all of the legacy stuff
arun: The more I think about this, it seems useful to have a hallway conversation with rsleevi on how to address this with cross-origin communication
... two flies in the ointment
... how to deal with key storage
... and in a way that's disconnected from TLS
<hhalpin> notes that if its just associating keys with TLS sessions is similar to Steve Farrell's key derivation from TLS session ideas way back at origin of WG
@hhalpin: No. Entirely different thing.
nvdbleek: It seems that the issue is the need to access keys outside of the scope of the origin (eg: on smart cards or other devices)
<Zakim> arun, you wanted to ask about certs via JavaScript
michaelh: it seems like what's missing is the "client side user" case - the current keys only deal with "web app" keys
Break for lunch. Following lunch, high level API discussion
and key agreement
registry of algorithms
bignum
and wrapup
<arun> ScribeNick: arun
Virginie: the Web Crypto API generated some comments such as "this is too technical, difficult to use, etc."
... High Level API seemed to generate some interest.
... some developers expressed a mitigation of their criticism if there's a High Level API
Virginie shows some slides and examples of Twitter commentary about the existing WebCrypto API
Virginie shows slide illustrating notions discussed on the WG regarding High Level API.
Virginie: should we put this on the REC track?
HHalpin: my take on it is that it is a myth that a High Level API will be easy to use.
... given that, it does make sense that higher level shims will be developed.
... shims happen. Should the market develop it, or us?
... if we do push out a High Level API, it might be rushed.
... market might develop a better High Level API
... we might present something like a shim. If there was some sort of a useful API that's high level, should it be normative or informative?
... right now we can't do either. We don't have enough person power.
HHalpin cites Keyzsar and NaCl
HHalpin: Keyzsar looks fairly sane; NaCl aims for Box/Unbox simplicity
... NaCl's focus is clearly public-key authenticated encryption
HHalpin shows a slide illustrating code snippet
<rbarnes> keyczar has defualts!
HHalpin: KeyCzar has a JSON/JOSE-ish format that they use.
... they hide the raw key format.
... on some level, since there's more key management built in, KeyCzar may be more complex than WebCrypto API.
... and then there's ddahl's draft...
... which is more simple than NaCl and KeyCzar
... not a lot of scrutiny on it, which may mean it's perfect.
... then there's rbarnes' work.
Virginie: there are several directions -- an informative document, limited High Level API, or solicit web dev needs.
... I would like to hear the prefered options.
... I would like comments on how to treat this topic in the WG.
... I'm not looking for one API being better than the other.
... e.g. comparing KeyCzar vs. NaCl
DR: I mentioned at TPAC that developers didn't know what they were doing, e.g. breaking SSL libraries, etc.
... your average developer knows about some of the properties of what they want to secure, but .... [not much].
... if there's a high level abstraction, that might be a good thing.
... I kind of agree with Harry. This is predicated on having the low level API in the first place.
... The question about use cases, I'm not sure whether we can specifically define use cases. All we're trying to do is enable developers to create whatever use case they want.
... e.g. I want to send something to someone confidentially.
... Box/Unbox is nice. However, you can get into trouble. Suddenly you end up with a complex high level API. O
... Or you're making recommendations. Because we consider them to be secure.
... I think we already have collected developer needs. Whether W3C is the right place has a question mark on it.
DDahl: I echo drogersuk
... my naive use case was 'zero knowledge' on servers, etc.
... I've learned a lot. The implementation of a high level API, howsoever imperfect, is still going to require 60-80% of the engineering effort, comparable to the low level API.
... What do other browser vendors thing? I'm not sure what MSFT thinks. I'd like to learn more. Are you willing to put forth a statement?
... I think that when you come up with a high level API, you're going to need more than one shim. I can see a shim for safe defaults, for messaging, signing, etc.
... a shim for OTR, for example.
... What I want to do, in parallel with test driving, is set up a Git hub for use cases and shims.
... Let's get the players involved, and put together a nice project, get wide review.
... We might have a grass routes collection of shims.
Mike: I think it's important for a lot of reasons to work in high level API. Both as drogersuk was saying, to help devs make better choices, and solve actual use cases.
... I was puzzled by hhalpin's comment about it potentially being rushed.
HH: doubtful about it being on the same timeline.
... another timeline, OR not make it REC track.
Mike: Process aside, coming to it from an eng perspective, work on a high level API that outputs the JOSE format, and consumes it, would be a value to the community.
... it becomes a test case that the low level stuff willl do the job, and the high level stuff is validation for the low level implementations.
... this is a resource question, not an interest question
... I'll have to go back to Redmond to find a JS expert to do this.
<hhalpin> arun: it should become
<rsleevi> arun: I was wondering whether it was a good idea to treat the high-level API as a use case of the low-level API
<karen_> arun: treat a high level api as a use case of a low level api
<rsleevi> ... this means that the highlevel API is not a WG deliverable, but is secondary hack work on top of the low-level API
<karen_> ... as a secondary work
<rsleevi> selfissued: Not sure if it fills the need, or a step towards filling the need
<ddahl> arun: ben adida was saying this too - he would like to see a set of shims built
rsleevi: The issue with NaCl and with KeyCzar... is.... to be clear, the Twitter critics are the same 5 critics, and they are opinionated, but we should be careful.
<hhalpin> I think that's a proposal to add a "use-case: high-level API and see if we can built it"
rsleevi: there's lots of ppl with strong opinions on crypto, etc. We need to balance opinions.
... WHen I met with some of these critics, I could [assuage their worries].
... NaCl is not as simple as HHalpin described it. David was saying it exposes different functions, depending on what you're trying to do.
<hhalpin> I was pointing out the main difference is NaCl does have strong defaults
rsleevi: When you start thinking about High Level APIs, there are all sorts of different needs. Privacy vs. integrity are composable things that are essentially protocols.
... Nadim, for OTR, wants different guarantees than JOSE. And we just talked about XMPP. I echo Arun's comments that we don't have use cases that spell out "what I want."
... Let's not take it on as a WG item. Let's ask: what does doing it in the browser gain?
... if we talk about the average web developer not getting Crypto, well [yes there's the rub]. The average web developer doesn't do secure things, e.g. mixed content over TLS.
VGB: I'm going to take a different tack on the question. At the native level, we build high level APIs. But let's first define what High Level means.
... for those devs that just want to build out a private convo, ask them integrity protection needed? Might not know.
... I support doing this as a use case. But... it doesn't solve your problem. What you will have is a magic API that given data and a key, will spit out an encrypted chunk. That will lead to bad practice, e.g. hard-coded passwords.
... hardest thing about Crypto isn't Crypto. It's key mgmt.
... Hardest part isn't protect a piece of data. It's "to that recipient."
... I think if you take the view that I just want to cater to the naive developer, you're setting yourself up for failure.
<hhalpin> key management is hard: http://www.w3.org/TR/xkms/
VGB: The helper function might help, but it won't solve the problem. The "other question" is almost another WG in itself. The XKMS was [not as successful as originally anticipated] [given the intractibility of the problem].
... many WGs tasked with a high level API haven't gone anywhere.
IH: I think from the IE perspective, we have the same constraints as any other UA project.
... we're definitely going ahead with implementing the low level API first.
... Based on that, we'll look at the v2, and see what's next. We did this for IndexedDB, WebGL, etc.
... A lot of people are writing frameworks based on what they want to do.
... logically, this belongs in the community. NOT in a WG.
... There are many commonalities, maybe we take some of that into the WG.
<rsleevi> ex: Futures (promises) or Query Selectors (CSS)
IH: I think the pragmatic approach is to start with low level, and see if libraries emerge. A test case around this might be interesting.
... e.g. for IndexedDB, we coined an abstraction layer as proof of concept.
... we do have people that have built polyfills.
DR: We've heard from a few folks that that average web developer doesn't do things securely. This comes down to education piece. We might need developer guidelines.
... We're going to do some work on these pieces, talked to dschepers.
... there's a knowledge gap. Developers are being told to develop things securely, but aren't being given the help.
... I am hearing from the average developer that we want to do this more easily, but Crypto is hard.
... What they're actually doing is actually no security.
... Shims will ALSO be implemented insecurely. Maybe taking ownership on GitHub would be good, rather than let BAD SHIMS blossom.
<rsleevi> arun: Just looking through this and how default understanding even defaults are
<rsleevi> ... this is a hard problem
<rsleevi> ... I think we should double down on the low-level API
<rsleevi> ... eg: futures might make the API easier
<rsleevi> ... on use cases , I'm not sure if it makes sense for to separate out use cases for low level and high level API
<rsleevi> ... the sample code might differ, but the use cases are the same
HHalpin: again, of all the options on the board, it seems like the option that has the most support, is can't build High without Low.
... I'm not hearing anyone saying we should do active charter changes.
... I'm not hearing that, but on the other hand I do hear that it would be an interesting use case of the low level if we can build a shim on top of it.
... we probably want a shim before we hit rec.
... we should definitely see if that's possible.
... after the next public draft of web crypto is out, the question is can a high level shim be built on top.
... seeing if the shim can fit on some use cases? Or all? That would be interesting to determine.
<drogersuk> we should put a mention in the spec to the web platform site too
DR: I'm nervous about seeing this WG deliver a shim. Beyond all the political aspects of use cases, my concern is that you don't deliver shims. You deliver libraries people use.
rsleevi said the above ^^^
rsleevi: I'm nervous about this WG delivering a shim.
... I'm nervous about a formal engagement at the W3C level as a work item with making shims.
... I'm nervous about the harm this will do. Throwing code over the wall has the risk of being dangerous.
IH: I think that one thing that might prove useful is a set of patterns, that we can point people to. Here's the webcrypto set of commands that does specific task, usable for particular things.
DR: if you go to the web platform site, it's guidance and patterns.
<rsleevi> http://www.webplatform.org/
<rsleevi> which is a W3C effort
<drogersuk> Link to web platform: http://docs.webplatform.org/wiki/Main_Page
<drogersuk> ;-)
IH: we need to make sure we don't oversell things, including Futures.
... Let's not undersell what's in use today.
Mountie: My opinion is we don't need a High Level API.
MH: The low level API could use more code snippets.
<rsleevi> arun: The need for a high-level API can more or less be said for any API from the web
<rsleevi> arun: People always want something simpler
<rsleevi> ... we've successfully punted these issues in the past to libraries like jQuery
<rsleevi> ... not sure we need an explicit use case in the doc for high level
HHalpin: Depending on how much energy develops around the shim, pointing out to the best of breed might be a good activity for the WG.
MJ: when we met at Mozilla a while back, we proposed a high level API. I don't think the High Level API should be rec trac.
... Issues seem to be resourcing issues.
<rsleevi> (israelh and rsleevi shaking heads at that)
<virginie> ?
MJ: Ideally, I'd like to see a high level API, that calls the low level API And then decide whether to make a spec.
DR: Web Crypto is a special case. That aside, the proposal might be to put something in the spec that links to web platform, and then once we've got that note in the spec, proceed zealously with education.
IH: it sounds to me like the whole goal is that Web Crypto is built so that further abstractions can be built on top of it. on top of it.
HHalpin: could open an issue to see if shims blossom.
DDahl: I'd like to do a library, that does stuff with JOSE. I'm not sure that's WG items, or work that Mozilla, Google, MSFT, BBN, and others do.
... hopefully, like jQuery, it could take a life of its own.
... it's not just one shim. It could be a series of these.
IH: we should definitely try and partner with library folks.
... even talk to the jQuery guys.
... there are things we can close today.
... one that's not controversial. Let's put a goal in the spec., saying layering abstraction is a goal.
... We need Low Level first, and then evaluate that again.
... The only thing is that we can work on libraries, even within Microsoft, and bring those back to the WG.
<hhalpin> I actually think the ACTION would be "Build at least one working sample shim(s)/library that addresses one common use-case". If it does exist we point at it from the WG deliverable use-case and Web Platform docs, great.
<hhalpin> My concern would be if we have to modify the charter.
IH: All of those are not controversial. We can close those.
<hhalpin> That is what we need to give W3C head's up on ASAP.
rsleevi: Rather than open an issue, let's close stuff. I want to make sure we have a response. And that we can give it to the community at large.
... so, huge +1 to IH
... and let's get back to work on the low level API>
Mountie: after 10 years labor, we're not sure about SHA-256, etc. If we give high level API, or use cases, that can cause a misreading.
... maybe people will start thinking SHA-256 is secure.
... a guide document, given the evanescence and tendency to obsolescence within Crypto, can be dangerous.
MJ: I mostly agree with what Israel H. said.
... as possible input to decide what next steps are, I'll search for a dev to help.
... This is inter-related with Key Wrapping.
... JWE to JWK might be a part of the use cases, and thus a party for consideration in high level API.
Virginie: I suggest we put as a goal to write down small use cases we want to address, if we go for a high level API.
<israelh> +1
<israelh> -1
HHalpin: I would be concerned if there wasn't a working shim by the time we hit rec.
<ddahl> which made it back into the browser later
Here is further example of IndexedDB causing problems with developers: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/
(view the comments)
DR: I don't see the dveloper docs as a mutually exclusive option.
... if we get an agreement that we'll do that, and put a note in it, we may be offset our detractors.
... by not saying anything to developers, well, that's an example of CRYPTO SNOBBERY
... the action here is to call out WebPlatform in the spec
<hhalpin> Getting Web Platform docs should be high priority as soon as we get next Public Working Draft
<rsleevi> ACTION: israelh to draft goal statement explaining a bit about the goals of being wrappable specific to use case [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action09]
<trackbot> Error finding 'israelh'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<rsleevi> ACTION: sleevi to include statement about web platform in the doc [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action10]
<trackbot> Created ACTION-96 - Include statement about web platform in the doc [on Ryan Sleevi - due 2013-05-01].
<rsleevi> ACTION: david rogers to add docs to webplatform [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action11]
<trackbot> 'david' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ddahl3, dmcgrew, drogers2, dhooley).
<ddahl> i am ddahl3
<rsleevi> ACTION: drogers2 to add docs to webplatform [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action12]
<trackbot> Created ACTION-97 - Add docs to webplatform [on David Rogers - due 2013-05-01].
<drogersuk> change that due date by 2014 ;-) ?
Virginie: on the shim aspect, any volunteers?
<selfissued> +1
<nvdbleek> +1
<MichaelH> future +1
<jmackay> +1
<hhalpin> The proposal is that Mike Jones, David Dahl, and Richard Barnes will work on a shim.
Virginie: call for volunteers for a special task force.
... this task force will focus on shims generated on top of the low level API
<ddahl> virginie: will we be issue uniforms?
<ddahl> +1
<rbarnes> +1
<hhalpin> ACTION: ddahl, selfissued, and rbarnes to develop a higher-level shim [recorded in http://www.w3.org/2013/04/24-crypto-minutes.html#action13]
<trackbot> Error finding 'ddahl,'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<mountie> -1
Now on break
<MichaelH> My future +1 was for The proposal is that Mike Jones, David Dahl, and Richard Barnes will work on a shim. not volunteer
<jmackay> http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/att-0029/CryptoAPI.j_
I am scribing
ScribeNick; arun
??: For better or worse, JavaScript is the language moving forward.
jmackay: While what you've done to date solves the 90% use case e.g. RSA, encryption, signing, we work on pushing the cutting edge of crypto tech
??: We'd like to really push the boundaries of what we can do.
jmackay: we need fast math in order to push the boundary: groups, rings, fields. JS is not ideal for that.
... the proposal submitted to the listserv is a strawman
... First, use cases from our perspective.
... UProve, which is a selective disclosure protocol. For example, if I have a driver's license, I can only show you my age, or only proof that I'm 21+, without revealing my age.
... Unfortunately, it requires client crypto
... It's worth nothing that the EU is looking at UProve in the ABC4Trust project.
JM: This has real application for the EU's potential standards.
... Other interesting things: Helios, and other voting protocols, using the browser as the client.
... You can develop pairing libraries on top of elliptic curves.
... Attribute based encryption, another big use case.
... Non-interactive authenticated key agreement schemes, BLS short signatures, hyper-elliptic curve cryptography, lattice-based cryptography (not broken by quantum computers),
... Tolga from Intel mentioned Shamir's Secret Sharing algorithm. This was posted on the mailing list.
... Due to the use of doubles, as the only numeric type, we're limited to using 16bits for BigNum calculations. That means we have up to 8 times as many digits.
<rsleevi> notes that the # of digits available is 'technically' dependent on the JS engine. Most engines give you up to 26-28
JM: For an O(N^2) algorithm, the "N" the number of digits is far larger in JS because we have to take bigger slices. This can be thousands of times more slow.
... Bit operations have to be cast from a double to an integer, for the bit operation performed, back and forth to double. This is slow.
... Another potential problem is jsut allocation in JS, very slow by measurements. 256-bit addition takes 7 nanoseconds in native, 10x slower in JS Chrome.
... Allocating an array to take the result takes a microsecond.
... Another potential problem is if you implement in JS a NIST-Prime, we can do many more optimizations.
... Side channel or memory attacks, e.g. trying to keep keys safe. If we design BigNum API, memory can at least be cleaned up.
... That's not always a problem, but with secrets, it might be.
... Why not JS language support? My sources say that this is very unlikely to materialize.
... Even if it did, it would not be optimized for Crypto Math.
... What we'd really like are cryptographically optimized routines.
... If we have RSA and other things, then the OS must have some kind of math.
... There are certainly open source impls of these things.
... Implementing it is not that hard.
<rsleevi> arun: one reason to make sure it was minuted accurately was to make sure it can be taken back internally to Mozilla
<rsleevi> ... have had threads going on with people at Mozilla (brendan eich, ben adida, others) to understand this
<rsleevi> ... Question: Do you think you can make your performance data public?
<rsleevi> jmackay: I will need to ask
<rsleevi> arun: It'll be helpful for discourse. We've seen developments like emscripten, asm.js, Native client, etc
<rsleevi> ... can we evaluate those, look at what the performance overheads are
<rsleevi> ... there are probably use cases here that can't be addressed by JS alone
<rsleevi> ... You also mentioned because we have RSA already, somewhere we must have a place to do the math
<rsleevi> ... not necessarily true. We may only have access to the algorithm, and it encapsulates the math internally
<rsleevi> ... You also mentioned that TC39 won't take on this work. That's both true and not true
<rsleevi> ... they are taking on BigNum work, that's the untrue part
<rsleevi> ... but it might be true that they are not taking on crypto math
<rsleevi> ... ex: they are taking on int64
<rsleevi> ... they are taking on operations, so while it may not be that they're taking on crypto math, they are taking on operations
<rsleevi> ... which might be a path to crypto math
<rsleevi> ... speaking for myself, not for mozilla, I'm thinking this might be better addressed at the language, not the interface
<rsleevi> ... not necessarily trying to interface out the bignum math
<rsleevi> ... I suspect if I were a betting man, Mozilla might say better to do this at a language level
rsleevi: Gave a general +1 to arun, but trying to clear out JS and dealing with memory is NOT a WebCrypto WG action.
... other aspect is trying to find the right balance of API. How low? How high? There's a lot of work on optimizers. If we can see numbers, that would be good.
... can we do things in the engine to make this better?
<rsleevi> arun: mentions public-script-coord@ as the place for the liasing of TC39 and the Web API folks
<rsleevi> virginie: At MSFT, did you look at other places to bring the API? Why this group?
JM: we want to do crypto in our browsers, but can't.
... I have two XBox teams asking me for crypto in JS, but we can't cater to it.
... The reason we came here was to see if there's interest from other folks about doing this.
... from our perspective, we start with the numerics.
... it makes sense to us to build the numerics.
rsleevi: ONe of the other elements that arun touched on, that I want to echo, is having worked with a wide variety of crypto APIs, one of the things you do is draw a boundary around the API.
... You don't get access to the internal implementation.
... The CNG API is not a publicly accessible one.
... MOST browsers, while they have this, STILL draw boundaries for regulatory reasons.
... Another challenge this group faces is while we're a web crypto WG, Crypto is SO huge that we can't be everything.
... We have TLS libraries, we have crypto, .... we're trying to find the right balance between generally applicable and specific exposed stuff.
... I'm having a hard time understanding wha you've described as the 90% and the 10%.
MJ: MSFT brought this proposal here because this is math specialized for doing cryptography. It is math over finite fields, specialized for cryptographic purposes. MultiplyMod, etc. are core of crypto operations, but not "other" BigNum math.
Mountie: I'm not an implementor. As a user, it may conflict.
... I think opens the possibility to all users. I give my +1.
JM: Someone mentioned Korea.
... could this solve that?
Karen: You mentioned your use cases. With modern secure element, like smart cards, support BigNum.
... Identity based encryption is all inside smartcard technology.
... consider smartcards.
VGB: Why did TC39 take this on?
rsleevi: What's coming out in ES6 is partial support for arbitrarily defined types.
... ES6 partially introduced support for this.
... ES6 --> ES7 will really implement these. Brendan Eich has already prototyped this.
... this has 64 bit registers, etc.
... The ES6 spec extended types, and attributes of types.
... ES7 put the final patches on this. Repeatedly during these discussions, BigNums were seen as part of the reason for this.
... This got us away from the hell of using doubles everywhere.
<rsleevi> Promised links:
<rsleevi> http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies
<rsleevi> and Brendan's patch https://bugzilla.mozilla.org/show_bug.cgi?id=749786
arun: BigNum *alone* won't solve Korean banking, but it MIGHT allow implementation of proprietary algorithms.
VGB: maybe an action would be to release our perf data
JM: It might not change the course of things, but hopefully implementors will look at allocataors
... what we need is for these expensive operations to have efficient implementations.
arun: Mozilla will likely consider this a language feature, and NOT an interface within an API
karen: this looks like a language feature.
JM: Yes, the interface feature was the cheapest option.
Karen: Korean banking case can be generalized to a non-US banking case.
MW: Why would TC39 consider such a specialist API, for crypto only, to be taken on as a work item?
rsleevi: well, in other languages, you can go to the metal pretty fast. But on the web, you go to an API group, or the JS language group.
MW: I like finite fields
TLR: You have algorithm identifiers. What happens when this group ends? How should they live 10-15 years from now?
... from that perspective, we could use URIs as identifiers. We could use registries. We could maintain a registry in the form of an RFC.
... if there is resistance, how can we square the circle and [mitigate it].
... is there a way we can articulate the issues? How expensive is it to use an algo as an extension point?
... what is the likelihood of change, and rate of change? Can we figure out a mechanism that fits into the three variables? Briefly, there are a number of options. We've been known to run free for all registries. We've had some working groups known to have a Wiki. We also have the ability to figure out an IANA registry.
... With that range of options, can we talk about rate of change, desirable cost of change, and policies that might match that.
rsleevi: We have an extensible API, that wasn't designed for extensibility.
... we talked about window.crypto.RSA, window.crypto.AES. The fact that we have identifiers that are extensible, is a plus, but like other APIs, like WebGL, etc., the best approach is to use a WG to build consensus between implementors and users.
... it's important for browser vendors to get together and discuss how to behave.
... a free for all registry is scary. It's like vendor prefixing.
... if going through standards and rec track, the same way that indexedDB extends navigator, that's how an algo should be added and extended.
... what do we do when we have lots of algos? Where do we list all that?
... could be webplatform.org.
... it's more important to have a consensus process.
... that's the opinion from UA side. Other side -- server side -- could have different concerns.
... Like Netflix, not looking for a web browser user agent. But from the browser side, I want to see rec track WG action to see how this looks.
TLR: The long term implications of saying "you may support other algos, but others don't."
... has arbitrary implications, and security implications.
... is a consequence of names being too hard to get into the agreed upon list.
... having an open extension point seems more dangerous than a free for all registry.
... I partly agree with REC track.
rsleevi: Treating it like we treat other rec tracks is the right course of action.
rbarnes: I think you're exagerating the complexity and need for consensus.
... This has been done in other contexts.
... in the IETF, have a lot of experience with registries with varying levels of control.
... I would think an expert review process would be appropriate.
... This group could set guidelines.
... An expert can then follow guidelines.
VGB: I agree with Thomas that the open extensibility point is more dangerous than the free for all registry.
... The open extension point without that control is bad.
... REC track might be MORE than essential. If I look at the way algos function, it's not that it springs up for the first time in a W3C group.
... *gives examples* Given that, doing this document, we pretty much took things from spec. and slotted them in, and called it done.
... If a new algo comes along, here's how you support it.
... A REC track document might be over-kill.
arun: who else does this?
TLR: nobody exactly, but XML Security.
<rbarnes> and XML security should be considered an anti-pattern for everything :)
TLR: XML Security was done 10 years ago, and was done differently than this. Don Eastlake volunteered to maintain a list of URIs for this work in an Internet draft. It was effectively a registry.
... the registry existed in a document.
... Another cautionary tale -- some folks wrote an RFC about how to encode keys. They had no clue about the limitations of XML Schema.
... That was a useless case of extending the API.
... Folks with clues about the implementation environment need to look at this stuff.
... The WG as an institution won't be around indefinitely, so at some point there has to be something in place. AES, SHA, etc. will evolve. At that point what's the cost, and what happens
... Can we try to explore writing down a slightly more formal version of the criteria for inclusion, something like the Don Eastlake role?
... There are plenty of ways to do this badly. But these shouldn't stop us from doing some things well.
rsleevi: my comments to respond to vgb -- algorithms have inputs in their spec not always exposed to the API to implement them. We'd object to treating this as different from any other web apps API.
<hhalpin> We might what to extend this discussion.
rsleevi: the choice of algos and extensions are fundamental to the web api.
<hhalpin> Can wrap up take 30 minutes rather than one hour?
rsleevi: what you've described doesn't match what WHATWG and WebApps does.
TLR: one distinction -- we're dealing with a space in which algos replace others, which is different than other API specs.
<hhalpin> Notes that you have extensibility points in HTML5 - think of rel link registry in the WHATWG for wiki.
VGB: SHA-3 is out. Might we have a test case that explores how to expose SHA-3?
<hhalpin> s/retire/extension
VGB: SHA-3 is about to arrive. How to include SHA-3 is a good test case.
s/retire SHA-3/include SHA-3
rsleevi: SHA-3 has aspects that aren't ready e.g. params
<jimsch> Try with GOST, SEED, Camilia, Aria, Clief
TLR: I'm happy to help, but I don't want to design a process that nobody uses.
<rbarnes> ISSUE-36?
<trackbot> ISSUE-36 -- Semantics for key generation versus key derivation -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/36
<rbarnes> ISSUE-43?
<trackbot> ISSUE-43 -- Separate method for key agreement -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/43
rsleevi: one point to add to rbarnes' proposal is key agreement is actually key agreement protocols, with multiple stages.
<rbarnes> rbarnes: propose to handle key agreement in the same action as derivation / generation
rsleevi: I wanted to say this might be similar to multi-stage key derivation, but we'll need to address multi-stage things in the API.
VGB: are you talking multi-stage as in Diffie-Hellman or as in MQV?
rsleevi: that's what we need to clarify.
/me thanks rsleevi :)
Virginie: we may address a round of comments on the cert aspect. Summer will be the period for tests. Will the commando team make progress on shims?
... and, progressing on the security documentation?
... After, go for last call in October.
... meet in the summer?
Mountie: Korea would host a meeting. We need some motivation to get folks interested in Crypto API.
Virginie: have a meeting close to IETF meeting.
... Then there's the November TPAC meeting.
... show of hands, who will meet in summer?
Some hands go up in the room.
rsleevi: What issues would warrant a f2f in summer? Wrap/Unwrap might be one.
Virginie: Testing and shim might warrant a meeting.
DDahl: Testing might want one.
NVDB: Going to last call without a meeting -- isn't that risky?
Virginie: Every two weeks we have a conf. call.
Virginie concludes enough traction for F2F summer.
<hhalpin> The main issue with a f2f this summer would be collocating near IETF JOSE WG meeting to make sure all open issues related to JOSE are finished.
<rsleevi> hhalpin: Possible issues are wrap/unwrap and short names, which will likely require liasing with JOSE to work through
<rsleevi> scribenick: rsleevi
hhalpin: Possibly a side-trip to Korea to investigate the certificate case, before/after TPAC
virginie: Scheduling for meeting, close to IETF timing
kodonog: Possibly co-locating with IETF the days right before the IETF meeting (in Berlin)
Dates for IETF 87 are July 28 - Aug 2
http://tools.ietf.org/agenda/87/
kodonog: talking 25/26 (Thur/Fri) before IETF
<mountie> in Korea?
virginie: We have two options - before IETF or after IETF
... need to secure hosting afterwards if we're going after
... will finalize by e-mail
virginie: Currently meeting at 20:00 UTC every other week
... proposal for 19:00 UTC
... consensus for keeping it at 20:00 UTC
Reminder: No telecon next Monday
<hhalpin> Let's just say keep it at 20:00 UTC
jimsch: 27 of May may need to be shifted (US holiday?)
<hhalpin> We've ignored other holidays in the past :)
virginie: Next call is May 6
<wseltzer> tlr: Thanks to PayPal
<wseltzer> [applause]
<wseltzer> trackbot, end teleconf
<wseltzer> trackbot, end meeting