15:01:56 <RRSAgent> RRSAgent has joined #crypto
15:01:56 <RRSAgent> logging to http://www.w3.org/2014/09/10-crypto-irc
15:01:58 <trackbot> RRSAgent, make logs public
15:01:58 <Zakim> Zakim has joined #crypto
15:02:00 <trackbot> Zakim, this will be CRYPT
15:02:01 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
15:02:01 <trackbot> Meeting: Web Cryptography Working Group Teleconference
15:02:01 <trackbot> Date: 10 September 2014
15:02:30 <wseltzer> s/Meeting: Web Cryptography Working Group Teleconference/Meeting: Web Cryptography Next Steps Workshop/
15:02:43 <wseltzer> wseltzer has changed the topic to:  Workshop: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/
15:03:38 <wseltzer> Agenda: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule
15:03:53 <wseltzer> Chair: Virginie_Galindo, Harry_Halpin
15:24:33 <bascule> bascule has joined #crypto
15:41:08 <wseltzer> Harry: Welcome, thanks to Virginie for chairign
15:41:31 <wseltzer> ... Thanks to Microsoft for hosting, Tyfone and Google for sponsoring!
15:41:39 <wseltzer> s/chairign/chairing/
15:41:57 <wseltzer> ... A W3C workshop aims to set the basis for open standards
15:42:51 <wseltzer> ... W3C is a global consortium
15:43:22 <wseltzer> ... Royalty-free patent policy creates a common foundation for innovation on the Web
15:44:33 <wseltzer> ... We welcome opportunities to work with other standards organizations through liaisions
15:44:43 <wseltzer> ... W3C works by consensus
15:44:59 <wseltzer> ... We've been thinking for a long time about security and identity
15:45:27 <wseltzer> ... Started with "Identity in the Browser" workshop a few years ago, from which we chartered WebCrypto WG
15:46:21 <wseltzer> ... Now looking at where we can help develop the platform further
15:46:56 <wseltzer> Virginie: WebCrypto has been discussing the Crypto API, and beginning to discuss next steps
15:48:01 <wseltzer> ... crypto is a well-developed science, the challenge is bringing it to the Open Web Platform
15:48:25 <wseltzer> ... we're here to learn, share, and then reach conclusions tomorrow afternoon
15:49:12 <wseltzer> -> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule Agenda
15:49:24 <harry> harry has joined #crypto
15:49:36 <Karen> Karen has joined #crypto
15:49:46 <bhill2> bhill2 has joined #crypto
15:49:48 <kodonog> kodonog has joined #crypto
15:49:51 <Cathy> Cathy has joined #crypto
15:49:53 <lifewsky> lifewsky has joined #crypto
15:49:53 <sangrae> sangrae has joined #crypto
15:49:55 <schuki> schuki has joined #crypto
15:50:02 <nvdbleek> nvdbleek has joined #crypto
15:50:03 <KarenLu> KarenLu has joined #crypto
15:50:03 <bal> bal has joined #crypto
15:50:12 <engelke> engelke has joined #crypto
15:50:35 <mdwood> mdwood has joined #crypto
15:50:37 <gmandyam_> gmandyam_ has joined #crypto
15:50:41 <JeffH> I can help with this first session
15:50:47 <wseltzer> [Virginie introduces irc, scribing]
15:50:51 <ChrisW> ChrisW has joined #crypto
15:51:11 <adam_> adam_ has joined #crypto
15:51:16 <wseltzer> Virginie: Over to our sponsors
15:51:23 <ilhangurel> ilhangurel has joined #crypto
15:51:29 <keiji> keiji has joined #crypto
15:51:41 <JeffH> virginnie or you might want to emphasize the IRC facet of this meeting
15:51:43 <wseltzer> Tony_Nadalin: Welcome to Microsoft
15:51:47 <Axel> Axel has joined #crypto
15:52:23 <wseltzer> Dirk_Balfanz: Google is here because we're interested in secure authentication
15:52:27 <Anders_R> Anders_R has joined #crypto
15:53:12 <wseltzer> Siva_Narendra: Tyfone is a 10-year-old security company
15:53:54 <wseltzer> ... if we all do the right thing in the next couple of days, we can bring about an inflection point for hardware-based security in web standards
15:54:40 <wseltzer> ... We believe in the separation of church and state. We all have our views, but W3C is a neutral place for discussion.
15:55:12 <tarcieri> woo backchannel
15:55:21 <Sam_Srinivas> Sam_Srinivas has joined #crypto
15:55:31 <rbarnes> rbarnes has joined #crypto
15:55:58 <herve> herve has joined #crypto
15:56:01 <JeffH> wseltzer advertizes this public backchannel and note taking confab
15:56:13 <drew> drew has joined #crypto
15:56:19 <monz> monz has joined #crypto
15:56:25 <Sean_> Sean_ has joined #Crypto
15:56:43 <Pea> Pea has joined #crypto
15:56:43 <JeffH> Peter Cataneo is up
15:56:56 <JeffH> iCattaneo
15:56:58 <SeanWykes> SeanWykes has joined #Crypto
15:57:00 <MartinThiim> MartinThiim has joined #crypto
15:57:02 <Brunojav> Brunojav has joined #crypto
15:57:03 <JeffH> from Intercede
15:57:06 <Phil_Hoyer> Phil_Hoyer has joined #crypto
15:57:09 <jonas> jonas has joined #crypto
15:57:21 <rbarnes> is that what the "i" stands for?
15:57:28 <Detlef_Huehnlein> Detlef_Huehnlein has joined #crypto
15:57:39 <JeffH> :)
15:57:50 <Pea> Ok
15:58:01 <sep_of_church_state> sep_of_church_state has joined #crypto
15:58:18 <FaSo> FaSo has joined #crypto
15:59:07 <AdrianC> AdrianC has joined #crypto
15:59:10 <wseltzer> Peter_Cattaneo: We should make sure that existing credentials will work in the new environment
15:59:20 <JeffH> asks question "will whatever we do wrt 'identities' online work "with" existing meatspace and online creds ?
15:59:26 <Pea> where is the paper  tape.
15:59:31 <virginie> virginie has joined #crypto
15:59:33 <solar> solar has joined #crypto
15:59:55 <solar> hello irc
15:59:55 <sep_of_church_state> yeah....and floppy disk?
15:59:57 <solar> it’s been a while
16:01:04 <Rob_philpott> Rob_philpott has joined #crypto
16:01:17 <tkeiji> tkeiji has joined #crypto
16:01:18 <virginie> Note : communication on this workshop on social media can with #cryptonext hashtag
16:01:44 <JeffH> Peter_Cattaneo: notes there's a large deployed base and the need for  "credential lifecycle management"
16:03:36 <sep_of_church_state> 60 billion IDs
16:03:52 <sep_of_church_state> Just plastic is 30 billion
16:04:02 <nvdbleek> nvdbleek has joined #crypto
16:04:13 <rbarnes> http://upload.wikimedia.org/wikipedia/en/thumb/7/73/Billions_and_Billions.jpg/150px-Billions_and_Billions.jpg
16:04:57 <JeffH> Peter_Cattaneo: emerging issues:  user-managed/self-asserted 'identity' -- emerging standards -- privacy issues
16:06:05 <JeffH> key engagement points for W3C effort(s) to consider:  enable usage of existing identities;
16:06:13 <JeffH> ..support multiple cred stores
16:06:21 <JeffH> ..enable both closed and open sysstems
16:06:41 <JeffH> ..suitable for common use cases; optionally include cred mgmt
16:06:56 <sep_of_church_state> Nice intro from Peter!
16:08:14 <wseltzer> -> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_36.pdf rbarnes's slides
16:08:26 <JeffH> Richard Barnes -- Mozilla -- possibilities for hardware tokens in the web
16:08:48 <sep_of_church_state> Richard talking from Web API perspective....what are we trying to do here...as functions.
16:09:18 <JeffH> richard_barnes: passwords suck
16:09:18 <tarcieri> acceleration-- identity++
16:09:31 <tarcieri> Persona :(
16:09:39 <sep_of_church_state> Point solutions are Bazillions...and BAD!
16:10:51 <sep_of_church_state> Point solutions are Bazillions...BAD and creates barrier to entry / implementation...
16:12:07 <wseltzer> rbarnes: good design pattern, build a box to encapsulate functions we need
16:12:15 <wseltzer> ... then implementations plug in underneath
16:12:31 <wseltzer> ... e.g. WebRTC
16:12:42 <sep_of_church_state> and PKCS11
16:14:14 <sep_of_church_state> Lets not discuss SIM API, Smartcard API or FIDO API...it is NOT useful....think about how to find a box for baseline for the web
16:14:49 <bhill2> respecting Richard's caveats about not being experts in these technologies, FIDO APIs are functional APIs, not implementation-bound
16:15:07 <rbarnes> rbarnes has joined #crypto
16:15:15 <JeffH> +1
16:15:23 <sep_of_church_state> -1
16:15:49 <sep_of_church_state> Dirk speaking with Google and FIDO hats...
16:15:49 <AdrianC> AdrianC has joined #crypto
16:16:13 <martin_paljak> rbarnes: the message was right. although plumbing is neeed, functionality is what needs to be implemented.
16:16:17 <JeffH> Dirk_Balfanz: Device-Centric Authentication and WebCrypto
16:16:43 <rbarnes> i should have also mentioned: ther web is much more dangerous than typical token deployment environments. there are are a bunch of privacy risks that come up when you ponder exposing long-lived credentials to the web.  IIRC FIDO has some good concepts in this domain, might be a good starting point.
16:16:45 <wseltzer> Dirk: user authenticates to the device, make it the responsibility of the device to do something better than passwords
16:16:58 <harry> what's the right level of abstraction is the tricky question
16:17:28 <sep_of_church_state> the right level is something that will be branding independent....and point solution independent
16:18:10 <JeffH> Dirk_Balfanz: notes separa tion of 'user verification' and subsequent device-bound crypto authn  foils phishing
16:18:20 <drogersuk> drogersuk has joined #crypto
16:18:21 <rbarnes> yubikey™
16:18:56 <JeffH> Dirk_Balfanz: gives demo of FIDO U2F login
16:19:15 <sep_of_church_state> FIDO(TM)
16:19:41 <JeffH> Dirk_Balfanz: shows snippet of client-side webapp JS code effecting the U2F login
16:20:00 <sep_of_church_state> should be neither hopefully
16:20:08 <harry> we are trying to bring these communities and others together
16:20:53 <JeffH> Dirk_Balfanz: notes wishlist for client-side JS api  needs to effect this stuff
16:20:54 <sep_of_church_state> right...we should take smart card, sim card, tee, tpm, fido...and put a box on top of all of them
16:21:19 <martin_paljak> it is weird that they are mentioned separately, sim cards usually are smart cards...
16:21:28 <harry> dirk's likst 1) keys origin bound but outside browser 2) adds info to-be-signed data 3) bound to local authentication 4) attestation 5) key discovery of local authentication mechanisms
16:21:40 <harry> Again, the trick is finding right information flow and right level of abstraction
16:21:56 <rbarnes> sep_of_church_state: http://imgur.com/1ZAvBzd
16:22:11 <harry> we'll want to allow innovation both on hardware/middleware layers but they need to be able to communicate to webapps
16:22:45 <bhill2> sep_of_church_state: FIDO UAF already is a box on top of smart card, sim, tee, tpm, etc, as well as many types of local verification ceremony
16:23:15 <martin_paljak> bhill2: last time i checked there was no concept of certificates though ?
16:23:38 <sep_of_church_state> bhill2: yes, but has a trademark and certification...
16:23:40 <rbarnes> martin_paljak: seems like an optimization.  provide cert alongside sig/pubkey
16:23:56 <sep_of_church_state> pvt key pub key certs....without pki ...is well know...why a trademark?
16:24:02 <JeffH> Dirk_Balfanz: what's not on wishlist
16:24:43 <JeffH> ...1) an "authn" API   2) away to talk to UA re user accounts    3) a new UI that the UA needs to show
16:24:55 <sep_of_church_state> Dirk: Did a neat demo
16:25:16 <wseltzer> s/away/a way/
16:25:34 <harry> Not on Dirk's list - authentication API, making user choose account, etc.
16:25:45 <AdrianC> Agree that drawing UI should be left to the Web application. However, it could be useful to define guidelines to help users understand what they are doing.
16:26:51 <martin_paljak> at some stage you want "a bit more trusted" UI, meaning that there are elements of the UI that are not possible to change by the web application.
16:27:10 <martin_paljak> i fished PIN codes with simple javascript.popup("enter pin") once for a demo. worked.
16:27:13 <lifewsky_> lifewsky_ has joined #crypto
16:27:13 <nvdbleek> zakim, pointer?
16:27:14 <Zakim> I don't understand your question, nvdbleek.
16:27:24 <JeffH> is sep_of_church_state  Mr Siva Narendra ?
16:27:33 <sep_of_church_state> Yes JeffH
16:27:46 <wseltzer> q?
16:27:47 <nvdbleek> rssagent, pointer
16:27:54 <wseltzer> q+ Siva
16:27:58 <JeffH> dirkb queries rbarnes wrt 'what is a point soln' ?
16:27:59 <tarcieri> martin_paljak: "powerbox"
16:28:05 <virginie> q?
16:28:09 <nvdbleek> rrsagent, pointer
16:28:09 <RRSAgent> See http://www.w3.org/2014/09/10-crypto-irc#T16-28-09
16:28:28 <Ullrich> Ullrich has joined #Crypto
16:28:32 <wseltzer> q+ hannes
16:28:41 <brunojav> brunojav has joined #crypto
16:28:48 <Phil_Hoyer> q+
16:29:07 <virginie> q+
16:29:29 <JeffH> rbarnes: what is the function we're trying to achieve?  thinks there's several of the examples he cited are examples, and wants to craft a layer above them that generalizes them;  thinks dirk's wishlist is headed in that way, and PeterC's usecases are applicable, wants to find the meeting point of all that stuff
16:29:44 <wseltzer> ack Siva
16:29:58 <karenlu> karenlu has joined #crypto
16:30:06 <JeffH> ??? if we just state reqs, then we can "put them in the box"
16:30:16 <harry> s/???/Siva
16:30:17 <wseltzer> s/???/Siva_Narendra/
16:30:19 <nexus> nexus has joined #crypto
16:30:24 <Axel_> Axel_ has joined #crypto
16:30:29 <wseltzer> ack hannes
16:31:03 <SeanMichael> SeanMichael has joined #Crypto
16:31:04 <wseltzer> i/what is the function/Dirk: How do we identify "point solutions" to avoid?/
16:31:05 <brunojav> q+
16:31:08 <virginie> q?
16:31:20 <Axel_> Does it make sense to have irc on the screen instead of the hotel list?
16:31:23 <JeffH> HannesT: thinks jury is still out wrt webRTCs approach/success
16:31:59 <JeffH> HannesT: generalizing isn't going to be that easy
16:32:27 <sep_of_church_state> Jury is out all authentication mechanisms
16:32:31 <karenlu> q
16:32:34 <virginie> q?
16:32:35 <karenlu> q+
16:32:36 <JeffH> rbarnes: wrt new creds and existing deployed base -- thinks backwards compat is a question
16:32:40 <solar> yes - why don’t we put irc on the screen
16:33:05 <martin_paljak> another risk is over-generalization.
16:33:12 <public_screen> public_screen has joined #crypto
16:33:13 <solar> nice
16:33:33 <martin_paljak> something that many existing standards do - leave too many things "open for vendor choices"
16:33:38 <Ullrich> Ullrich has joined #crypto
16:33:49 <Nadalin> Nadalin has joined #crypto
16:33:54 <JeffH> PeterC:  an example wrt bkwards soln, is to take one of those things in the deployed base and go thru exercise of putting them into the new world and see how it works
16:34:11 <wseltzer> q?
16:34:25 <JeffH> ....eg Karen Wu may talk about some of this;  existing smartcard apis need some work....
16:34:47 <solar> good work
16:34:59 <sep_of_church_state> we should abstract away from smartcard or any other low level API
16:35:02 <JeffH> rbarnes:  the fido api, other api are 'useful' in sense we can learn from them to pull stuff into a more general API
16:35:14 <wseltzer> ack next
16:35:20 <selfissued> selfissued has joined #crypto
16:35:38 <sep_of_church_state> JeffH: Agreed, as long as we don't name a well understood concept with a trademark
16:35:47 <sep_of_church_state> It should be like SSL or TLS...
16:35:56 <sep_of_church_state> ...from a naming of the "box"
16:36:01 <Nadalin> and then we have general APIs that are so general they are useless
16:36:20 <JeffH> Philip Hoyer: crypto solutions are good when they work, but when they fail they are spectacular --- forcing a pattern of protocols that focuses on the client side is dangerous -- need to find something where we can innovate end-to=end
16:36:20 <bhill2> sep_of_church_state: trademark relates mostly to attestation of devices that relying parties really want, but is optional at a protcol sense
16:36:42 <JeffH> eg sees in FIDO a lot of innovation on client side
16:37:28 <JeffH> dirk:  ACKs your point, but sees a danger in being too general and we are going to need to carefully balance
16:37:28 <harry> Dirk: To build frameworks to build building blocks to build solutions :)
16:37:30 <bhill2> dirk doesn't want to build frameworks to build building blocks to plug into solutions
16:37:38 <bhill2> … dangers in being too general
16:37:44 <wseltzer> q?
16:37:46 <wseltzer> ack virginie
16:38:02 <JeffH> virginnie: notes we need to prioritize use cases we want to solve in order to figure this all out
16:38:18 <JeffH> dirk: wants to make passwords less of a useful target to the bad guy
16:38:39 <virginie> q?
16:38:40 <JeffH> if they still are used, they should be relegated to 'local use'
16:39:51 <wseltzer> q+ @@
16:39:54 <sep_of_church_state> dirk: software keys better than passwords....hardware keys are even better
16:40:07 <JeffH> wants to employ crypto to make all this happen;  server side need efficient signature verification;  the hard part is on the client side to mint keys per server;   even software keys are better than "passwords"
16:40:37 <bhill2> q+
16:41:00 <JeffH> PeterC: one success story in this area is that everyone in ?? has a govt ID card w/secure element and it works for windows login out of box
16:41:11 <wseltzer> s/??/US government/
16:41:17 <tarcieri> this sounds like SunRay circa 1999 ;)
16:41:18 <harry> CAC/PIV cards I assume
16:41:18 <sep_of_church_state> PeterC: Govt smart card PIV is a good example of
16:41:26 <JeffH> ....wants web logon to work that smoothly....
16:41:52 <solar> software keys on a seperate device (out-of-band) is almost on par with hardware based key storage on the same device
16:42:20 <tarcieri> solar: except you can remove an external hardware token when it's not in use
16:42:35 <JeffH> rbarnes:  notes dirk's use of crypto, thus why we're putting effort into web crypto;   also have to pay attention to the privacy side of this and not make it worse;
16:43:10 <tarcieri> you can also use an external hardware token with multiple devices
16:43:11 <wseltzer> q?
16:43:12 <harry> Mozilla is out of business of implementation-specific token support... quite interesting
16:43:16 <wseltzer> ack next
16:43:17 <sep_of_church_state> rbarnes: tyring to move mozilla away to more standards based framework that is general than smart cards
16:43:25 <JeffH> ....also need impl-specific considerations, in firefox, have support for some sorts of smartcards, but want to make that more uniform and support more kinds of tokens
16:43:26 <virginie> q?
16:43:26 <wseltzer> Bruno Jarvary, Oberthur
16:43:31 <solar> tarcieri: example: when signing in to gmail from desktop, send authentication request to phone (where software key resides) and ask user if they want to allow access to that key by that specific machine
16:43:42 <FaSo> as password can be weak beacuse people takes simple password easy to remember, or wirte pwd on a postit and leave it under the desk, wom people might leave a smartcard inside their laptop all the time
16:43:54 <solar> concept of “out of band” display vs “secure display” is also an interesting one
16:44:32 <JeffH> Bruno: asks dirk about the JS api he was using in the demo and code snippet
16:44:35 <Axel_> Mozilla and Telekom Innovation Laboratories are implementing Secure Element API that @rlbarnes mentioned. https://bugzilla.mozilla.org/show_bug.cgi?id=879861
16:44:51 <tarcieri> FaSo: that's why requiring a button press is nice
16:44:53 <JeffH> dirk: the api was provided by a browser extension, so sorta cheated
16:44:59 <wseltzer> q= karenlu, Jonas, bhill
16:45:04 <wseltzer> queue= karenlu, Jonas, bhill
16:45:28 <JeffH> ...ultimately want a baked-in api that has a simply "sign this please" api  --- not much different from what the extension does
16:45:33 <tarcieri> solar: another use case is I don't want to put the secrets for the second factor on my phone, but still have a hardware token that works both with a desktop/laptop (via e.g. USB) and with a phone (via e.g. NFC)
16:45:57 <virginie> q?
16:46:02 <wseltzer> ack next
16:46:53 <sep_of_church_state> karenlu: smartcard authentication is local...and whatever solution is should [ideally] be applicable to existing IDs and we should define the box that way....
16:47:21 <solar> tarcieri: that’s a good point, but without a display on the hardware authenticator it severly limits the financial services usecases
16:47:34 <solar> and I believe they will be the ones driving this pretty hard
16:47:55 <sep_of_church_state> karenlu: challenges that while we should build a box...is fido a box or a service....JeffH you might be able to comment
16:48:05 <virginie> q?
16:48:10 <solar> nice!
16:48:52 <Herve_SIMalliance> Herve_SIMalliance has joined #crypto
16:48:53 <sep_of_church_state> karenlu: is a box small and generic or box very specific?
16:49:20 <JeffH> karen wu:  gemalto:  believes whatever soln arrived at needs to work with the deployed smartcards in the field,  need to define the "box" thing, however  if authn is a function, then you can plugin different authn means,so that satisfies the box metaphor, and the challenge will be to generalize the box, thinks her paper is in similar vein to rbarne's box notion -- the box can be very general, or more specific eg authn-specific -- plus we need to define something
16:49:26 <JeffH> ...browser vendors will support
16:50:18 <JeffH> karenwu: agrees ? is impt, but other things that are impt -- eg standalone signature and encryption -- and so we want to build a box that also supports those use cases
16:50:24 <Herve_SIMalliance> question/remark
16:50:29 <Ullrich> Ullrich has joined #crypto
16:50:30 <martin_paljak> I think we need to make clear if we want an API (most probably plumbing to the box) or a new set of protocols.
16:51:06 <public_screen> q+ Detlef
16:51:50 <sep_of_church_state> rbarnes: what we standardize is something 100s of millions of web sites will use....so it would need abstraction [to be at a higher level]
16:52:00 <JeffH> rbarnes: so our objective here is to define an API for the web, feels it is going to be an abstract api and wont be defined in terms of APDUs -- thinks fido stuff is a good start
16:52:14 <wseltzer> ack next
16:52:24 <wseltzer> Jonas Andersson (Fingerprints)
16:52:36 <bal> bal has joined #crypto
16:52:39 <Pea> For me the question first is who is the trusted authority then what level of security do they require in order to secure the digital credentials they might be willing to provide
16:52:40 <Ullrich> Scope is unclear to me eg transactions need UI
16:53:04 <solar> agreed
16:53:13 <sep_of_church_state> Jonas: in response to rbarnes: we should also consider billions of users when thinking of standards (or box)
16:53:25 <MartinThiim> MartinThiim has left #crypto
16:53:49 <SeanMichael> q+
16:54:07 <virginie> q?
16:54:14 <JeffH> jonas anderson: fingerprint cards:  looking to make a box that faces millions of websites, but the userfacing side will face billions of users --   working on ways to allow users to choose how they wish to identify themselves -- not all of us will be carrying BLE cards or Swedish ID cards  -- need  approp mechs that will be as easy to use for everyone as username/pswds
16:54:23 <wseltzer> note http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
16:54:38 <JeffH> peterc: agrees
16:55:27 <sep_of_church_state> peterc: agrees with caution?
16:56:06 <JeffH> rbarnes: going to need to have a plausible interaction story
16:57:02 <virginie> q?
16:57:18 <virginie> ack bhill
16:57:28 <sep_of_church_state> ack bhill
16:57:32 <schuki> +1
16:57:35 <sep_of_church_state> +1
16:57:35 <JeffH> bhill: paypal w3c fido:  but personal hat on:  need to separate "identity" from "authentication" -- need to allow for authn without strong identification -- eg support authn'd anonymity --   need to create  apis that do not mandate linkability
16:57:52 <bhill2> q-
16:58:31 <JeffH> ???:  we need to sparate using deployed ID cards  from privacy issuess
16:58:49 <JeffH> ...german ID cards are priv-friendly
16:58:57 <adam_> brad, services are already choosing to mandate linkability eg through only working via logon with facebook
16:59:00 <JeffH> ...we all agree it will be good to get rid of pswds
16:59:11 <wseltzer> Detlef Hühnlein (ECSEC)
16:59:15 <bhill2> even a government id card with privacy friendly technology
16:59:18 <bhill2> is still not controlled by the user
16:59:21 <wseltzer> s/???/Detlef Hühnlein (ECSEC)/
16:59:28 <bhill2> they are often property of and can be revoked by the government
16:59:30 <JeffH> ...deployed things include smartcards, TPMs, etc
16:59:33 <solar> u-prove making a comeback?
16:59:34 <wseltzer> q- Detlef
16:59:42 <virginie> q?
16:59:45 <JeffH> ...we will need to support them
16:59:59 <bhill2> a user's participation in online communities should not be controlled in that way by their government identity
17:00:00 <Martin> Martin has joined #crypto
17:00:09 <martin_paljak> bhill2: government issues the identity (say, a certificate), yet the user controls the card.
17:00:13 <JeffH> peterc: notes that the privacy reqs are important and should be prioritized
17:00:21 <bhill2> but government can revoke the card
17:00:59 <JeffH> ...using id w/govt entity is different -- and should it be possible to use that ID with non-govt entities?
17:01:35 <martin_paljak> JeffH: of course. in Estonia there is one identity, one card, and you can use it wherever you want. Private or public sector or your home.
17:01:53 <karenlu> q+
17:01:55 <JeffH> rbarnes: speaking from browser perspective problem is figuring out which websites ought to be able to leverage that ID card?
17:02:12 <wseltzer> Sean Michael Wykes, Nascent
17:02:32 <wseltzer> ack sep_of_church_state
17:02:35 <wseltzer> ack SeanMichael
17:03:14 <Ullrich> Ullrich has joined #crypto
17:03:22 <JeffH> sean michael:  wrt the "box" proposal -- likes the local user authn leading to device authn -- but has use cases for signing docs -- and also authn'g transactions
17:03:24 <virginie> q?
17:03:50 <JeffH> ....who will supply the "box" ?
17:04:23 <JeffH> ....already have too many diff apis and drivers to interface with specific security devices
17:04:50 <JeffH> ,,,,also ask about the attestation notions dirk mentioned
17:05:36 <Martin> Good point about digital signatures - and also makes me think of Dirk's comment that the browser shouldn't have any special UI etc. and everything should be provided by the application. If the signing screens are provided by the application it makes it difficult for the user to be certain that what is getting signed is what they are seeing on the screen (since the application could go on and sign something different from what was shown).
17:06:10 <tarcieri> Martin: the browser should at least ask you if the site can have access to hardware tokens using its native chrome / "butterbar"
17:06:33 <JeffH> dirk:  thinks that's a good point re 'box' -- have to carefully figure it out
17:06:38 <sep_of_church_state> personal comment: why can't box be what pkcs does and what fido does....and abstract it without either of the names
17:07:03 <engelke> Martin: both sides of the transaction should be able to specify a minimum level of out-of-band user consent to be enforced when signing.
17:07:08 <Martin> Solving this would require either the browser to be able to generate a trusted signing UI (that would always show what would ultimately be signed) or some sort of plug-in architecture where the user could install trusted signing extensions (which would provide the signing UI). Or maybe the identity of the application (or at least the modules that generate the signing UI) can be included under the signature (this would be forced by the user agent)
17:07:12 <JeffH> ...wrt attestation: in enterprise use case want to be sure the employees authn with the issued authenticators/tokens
17:07:31 <JeffH> ...wrt privacy-friently attenstation -- hard problem
17:07:48 <Martin> tarcieri: Strongly agree :)
17:08:22 <JeffH> ....looking at google and consumer offerings, we'd be happy if you just not use pswds and not worry about the attestation
17:08:27 <tarcieri> things like pin entry should probably be handled natively by the browser too
17:08:28 <martin_paljak> with an approach similar to secure element /apdu level API it is not enough, as you have no idea what gets pumped to the device from an almost arbitrary website.
17:08:31 <virginie> q?
17:08:32 <JeffH> ....have a risk engine on backend
17:08:41 <tarcieri> lest a malicious script steals your pin
17:08:47 <wseltzer> ack karenlu
17:08:49 <sep_of_church_state> q+
17:08:56 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/10-crypto-minutes.html wseltzer
17:09:03 <sep_of_church_state> q-
17:09:05 <solar> yeah - that’s back to the different device / out of band question
17:09:10 <martin_paljak> q+
17:09:11 <Martin> engelke: I don't see how the user could specify the level since how can they be guarenteed that the out-of-band process takes place afterwards? It makes more sense the receiver of the signature defines the policy of what needs to be met before they consider it a valid signature. After all, they are the one running the risk.
17:09:13 <wseltzer> q+ Siva
17:09:15 <solar> easy to steal pins on one device
17:11:16 <JeffH> karen_wu:  priv is impt -- in past few years have tried various approaches -- have ways to have 'personas' for diff service providers -- eg separate work from personal persona -- another thing is priv-enhancing credentials, aka anonymous creds -- diff crypto from pki -- can create a cred token on device, then SP can verify it is a certified cred, and only reveal what is necessary [selective disclosure]
17:11:32 <JeffH> ...the cred issuer doesn't know wehre you used creds
17:11:35 <Martin> martin_paljak: True - in that case I'm thinking maybe the user could autneticate the installation of a trusted JavaScript module that would hook into the WebCrypto API and implement it using it's low-level knowledge of the hardware. The user would approve the installation of this module using some browser UI (which would display the signer etc. of the module) before it would be installed. Solves some problems; creates others!
17:11:43 <JeffH> ...mitigates IDP knowing who you've interacted with
17:11:52 <wseltzer> i/Harry: Welcome/scribenick: wseltzer
17:11:53 <virginie> q?
17:11:54 <bhill2> q?
17:12:06 <JeffH> ....so a req is that the API should support these sortts of priv-friendly creds
17:12:25 <bhill2> q+
17:12:43 <wseltzer> i/advertizes/scribenick: JeffH
17:12:59 <JeffH> peterc: most of the exisitng creds out there don't requre attestation (attstn) -- so your card has priv key, and in closed system they already know about the ID and key out-of-band
17:13:01 <virginie> q+
17:13:14 <JeffH> ...attstn comes in when you have an open system
17:13:44 <wseltzer> q+
17:13:47 <solar> but it allows RP’s to pick and choose only authenticators they “like”
17:14:00 <bhill2> what rbarnes is describing for attestation is pretty much exactly how FIDO works…
17:14:20 <JeffH> rbarnes: attstn is bound up in the type of token./card you have  --- and maybe a metadata service is needed  so RPs/SPs can look up properties of the authenticators wielded with themn
17:15:06 <JeffH> dirk: when say attstn was meaning only a part of that complete loop
17:15:16 <JeffH> virginie: so we need to define attestation!
17:15:41 <virginie> q+
17:15:46 <Karen> q+ for Sean Wykes
17:15:46 <bal> I'll be talking about anonymous credentials a bit in the next session (my team owns the U-Prove anonymous credential system).  We have a U-Prove JavaScript client running today on top of our JavaScript WebCrypto library, but it does require access to BigNum underlying mathematical operations not exposed by WebCrypto today.
17:15:59 <Phil_Hoyer> q+
17:16:04 <wseltzer> q+ SeanMichael
17:16:09 <solar> agreed
17:16:12 <solar> i need a muffin
17:16:14 <virginie> zakim, close queue
17:16:14 <Zakim> ok, virginie, the speaker queue is closed
17:16:28 <JeffH> perterc:  is noting that RPs will need to discern between hardware-based authenticators and software-based authenticators  (which is a use case for attstn)
17:17:49 <JeffH> martin_paljak: have a national smartcard in estonia, user use the cards online on the web -- cares about the software "in the box" -- right now have to supply sfwr to the users --
17:17:56 <wseltzer> ack next
17:18:00 <sep_of_church_state> +1
17:18:15 <HadiNahari> HadiNahari has joined #Crypto
17:18:29 <Martin> +1 !!!
17:18:44 <JeffH> ...example of smartcards in windows, or eg fido -- likes them -- but we need to allow for a range of authenticators --
17:18:54 <JeffH> .... just needs an API
17:19:07 <virginie> we will add Herve pierre in the speaker queue as his q+ was not registered
17:19:14 <Rob_Philpott> Rob_Philpott has joined #crypto
17:19:14 <wseltzer> q+ Herve
17:19:16 <virginie> q?
17:19:29 <JeffH> ,,,wrt OSI, which layer are we creating the APIs?  is it appropriate?
17:19:48 <wseltzer> queue= Siva, bhill, virginie, wseltzer, Karen, Phil_Hoyer, SeanMichael, Herve_Pierre
17:19:54 <wseltzer> zakim, reopen queue
17:19:54 <Zakim> ok, wseltzer, the speaker queue is open
17:19:55 <wseltzer> queue= Siva, bhill, virginie, wseltzer, Karen, Phil_Hoyer, SeanMichael, Herve_Pierre
17:20:01 <wseltzer> zakim, close queue
17:20:01 <Zakim> ok, wseltzer, the speaker queue is closed
17:20:06 <karenlu_> karenlu_ has joined #crypto
17:20:13 <wseltzer> ack next
17:20:15 <JeffH> ...if we think we have lots existing systems, maybe we should look at why things didn't get adoption -- will just wrapping it in JS make it work or not?
17:20:39 <ale> ale has joined #crypto
17:21:29 <JeffH> virginie:  we do have some requirements that have been expressed in the prior discussion (enumerates them)
17:21:49 <wseltzer> virginie: user choice, service provider choice, privacy, form-factor choice, enable innovation
17:22:03 <JeffH> siva: why don't we say wrt "the box", there's a few things that actually work, webrtc pkcs#11 fido -- lets start there and..
17:22:23 <JeffH> ...ask what's common and see if we can distill them down to something common? start there?
17:22:34 <virginie> virginie : a box, taking into account user choice, service provider choice, being privacy respectfull
17:22:57 <tarcieri> don't forget encryption! ;)
17:23:02 <JeffH> rbarnes:  bhill's notion of separating authn and identity might be useful in this context
17:23:03 <virginie> virginie : ... a box allowing user anoicesd service provider ch
17:23:20 <virginie> virginie : ... a box allowing user and service provider choices
17:23:39 <virginie> virginie : ... a box usable for different form factors and credentials type
17:23:53 <JeffH> bhill: wrt priv preserv stuff -- in past, having identifiying technologies is default, and user must manage the priv stuff ---
17:24:01 <wseltzer> ack bhill
17:24:28 <JeffH> ...thinks we should invert that and have priv-protecting be the default and then user must do extra stuff to reveal themselves to RPs/SPs
17:24:31 <virginie> virginie : ... a box allowing operations to happen in server or client
17:24:47 <sep_of_church_state> peterc: fact: born in berkeley....fiction: works for a smartcard company!
17:25:00 <virginie> virginie : ... a box leaving space for innovation and usable by millions of websites and billions of users
17:25:03 <virginie> q?
17:25:11 <virginie> q-
17:25:45 <JeffH> peterc:  believes the non-standard priv-preserving crypto is going to be tough to employ.... (eg Chaum's crypto)
17:25:58 <JeffH> +q
17:26:02 <JeffH> :(
17:26:18 <JeffH> rbarnes:  maybe not that hard?
17:26:38 <JeffH> perterc: but you use all that cool crypto and then put your IP addr on the packets you send.....
17:27:32 <HannesTschofenig> HannesTschofenig has joined #crypto
17:27:37 <JeffH> wseltz: pointed earlier in this irc log at w3c priv requirements --   another item wrt attestation....
17:27:52 <virginie> q?
17:28:07 <JeffH> ...how do we do all this in "open" systems -- open to dvlprs and users -- how to strike right balance?
17:28:37 <public_screen> q- wseltzer
17:28:41 <public_screen> q- Karen
17:28:46 <public_screen> q- SeanMichael
17:29:02 <JeffH> sean: wrt atesstation -- wrt internet banking use case -- man in browser attack
17:29:48 <JeffH> ... evil JS injected into browser -- the whole of the stack needs to be trusted, or if there's bad stuff in the stack, it can't do anything --
17:30:20 <JeffH> ...eg for a bank transfer -- what if the numbers can be changed by malware before it's signed?
17:30:27 <wseltzer> s/pointed earlier in this irc log at w3c priv requirements/it's no accident that W3C's Technology & Society domain has both security and privacy considerations. I also pointed out the "priority of constituencies": user interests first, then developers and implementers./
17:30:37 <solar> Secure display or out of band display
17:30:39 <solar> that’s what you need
17:30:54 <tarcieri> or a powerbox in the browser
17:31:03 <wseltzer> q?
17:31:04 <solar> trusted UI is only required if it’s on the same device
17:31:22 <martin_paljak> define "powerbox" ?
17:31:23 <solar> if it’s on a different channel you’re significantly reducing the risk
17:31:28 <solar> which is why FFIEC has accepted it
17:31:38 <JeffH> dirk: calls this transaction authorization (authz) -- the more general case of xaction authz is tough cuz need trusted UI  (is hard...) --
17:31:52 <tarcieri> martin_paljak: http://c2.com/cgi/wiki?PowerBox
17:31:55 <JeffH> ...we've thought about it in FIDO context....
17:32:15 <virginie> q?
17:32:18 <JeffH> ...also, we don't need to solve the Man in browser prob in this context
17:32:24 <Ullrich> Ullrich has joined #crypto
17:32:26 <tarcieri> martin_paljak: a UI provided by the browser which makes it difficult for web content to impersonate
17:32:30 <JeffH> [[ we are over time ]
17:32:35 <solar> without solving MITB it’ll be difficult to garner FI support
17:32:41 <Martin_> Martin_ has joined #crypto
17:32:43 <Martin_> is q closed?
17:32:47 <tarcieri> martin_paljak: e.g. something that pops up over the browser chrome
17:33:05 <virginie> to martin, yes queue is closed
17:33:14 <JeffH> peterc:  observes that pushing things down into hardware tokens helps mitigate such anattack...
17:33:22 <virginie> q?
17:33:42 <JeffH> ...notes that such a hard-token might have a trusted UI associated with it
17:33:44 <martin_paljak> tarcieri: oh, ok. that's what we implement currently with plugins, yeah.
17:34:07 <Ullrich> FIDO UAF does transactions and nerds a UI
17:35:01 <wseltzer> Our goal is to develop a list of tasks and priorities, certainly not to solve them all at once
17:35:02 <JeffH> rbarnes: notes that there's protections out there for much of these threats -- not job of web crypto api to address them
17:35:25 <wseltzer> q?
17:35:54 <JeffH> ....eg webapps ought to take advantage of things like content sec policy (CSP) to help mitigate script injection attacks
17:36:00 <tarcieri> can we trust the browser? Let's ask Douglas Crockford ;) https://d23f6h5jpj26xu.cloudfront.net/hvcrmeegvjrczw_small.jpg
17:36:25 <harry> I think the perhaps they are talking about browser code being compromised, like NSA's attack on Firefox to get around Tor :)
17:36:41 <harry> Anyways, re Doug Crockford's point, please see the point about getting the user to install trusted updates properly:
17:36:58 <martin_paljak> Jsut a small comment, that banking examples are not appropriate, as banks introduce hardware not so that users would trust it more but to mitigate risks and losses.
17:37:25 <solar> correct - in other words: to make it more secure
17:37:33 <solar> which is an interest shared by both banks and users imho
17:37:50 <harry> In browser, right now all code does of course have  a trusted "Trent" in form of origin
17:38:01 <harry> more separation between that and some user-controlled private key material is probably a good thing
17:38:19 <tarcieri> "interest shared by both banks and users imho" <--- when you can trust the browser in Douglas Crockford's perspective, because the user and content provider's interests are aligned
17:38:20 <harry> however, the Web has proven to be much easier at delivering code to users than many other mediums
17:38:32 <harry> most 0days are in plug-in
17:38:46 <harry> "interest shared by both SERVERS and users imho"
17:38:59 <JeffH> ???: need to figure out some way to be able to tell whether the user intended to perform the action....
17:39:00 <martin_paljak> well, I'd say that right now we have JS-OpenSSL. Now we need something like JS-PKCS#11 to satisfy existing token owners  ;)
17:39:19 <wseltzer> s/???/Phil_Hoyer/
17:39:28 <wseltzer> q- Phil_Hoyer
17:39:28 <solar> yes - authentication with context
17:39:34 <harry> But in general, getting users to install and update client code is difficult. See package manager issues: http://theupdateframework.com/
17:39:39 <harry> Getting off the Web is not a magic solution.
17:39:44 <wseltzer> Herve Pierre, SIM Alliance
17:39:46 <tarcieri> harry: <3 TUF
17:39:56 <wseltzer> ack Herve_Pierre
17:40:08 <harry> https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf
17:40:24 <martin_paljak> harry: if you need to talk to "unknown" local hardware, you need to have code running on local machine. Either "bundled" or specifically installed.
17:40:29 <solar> but what about software authenticators?
17:40:37 <solar> should we call that “software secure elements"?
17:40:46 <JeffH> Herve (?) w/sim alliance:   when we say SIM card or smartcard -- at core they are similar, but have diff form factor, plus SIM card is linked to biz partner by definition -- thus we should use the term "secure element"
17:40:51 <tarcieri> solar: no, that's more like HCE
17:41:24 <JeffH> virginie:  so we have set up the outline/scope of our discussions....
17:42:07 <wseltzer> [break, return in 30 minutes]
17:42:11 <JeffH> ...and we're in the specific context of the next steps for web crypto api  and how we can evolve it
17:42:12 <wseltzer> rrsagent, draft minutes
17:42:12 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/10-crypto-minutes.html wseltzer
17:44:06 <tkeiji> tkeiji has joined #crypto
18:04:05 <adam_> adam_ has joined #crypto
18:07:14 <Ullrich> Ullrich has joined #crypto
18:08:03 <bhill2> scribenick bhill2
18:08:32 <public_screen> scribenick: bhill2
18:08:54 <Rob_philpott> Rob_philpott has joined #crypto
18:08:57 <public_screen> Topic: Extending
18:08:58 <Cathy> Cathy has joined #crypto
18:09:22 <lifewsky> lifewsky has joined #crypto
18:09:29 <bhill2> at mic: Brian LaMacchia, Microsoft research
18:09:53 <bhill2> slide deck title: BigNums, BigNums, BigNums
18:10:02 <tarcieri> Brian "I hate Montgomery curves" LaMacchia ;)
18:10:06 <KarenOD> KarenOD has joined #crypto
18:10:24 <bhill2> will denote Brian as "bal"
18:10:28 <wseltzer> s/Extending/Extending the Existing W3C Web Cryptography API/
18:10:28 <virginie> virginie has joined #crypto
18:10:38 <bhill2> bal: slide 1, announcing v1.2 release of MSR JS Crypto LIbrary
18:11:01 <bhill2> … MSR's impl of the Web Cryptography API, polygill-ready, x-browser compatible
18:11:09 <bhill2> … now under Apache 2.0 license
18:11:32 <bhill2> … next slide: Why WEbCrypto needs BigNums
18:11:48 <bhill2> … using 16 bit to simulate large field math is really slow
18:12:00 <wseltzer> i/Welcome,/Topic: Welcome, Introductions to W3C and Workshop Goals
18:12:13 <bhill2> … important for tech like U-Prove to be able to do arbitrary bignum operations in the browser
18:12:29 <wseltzer> zakim, reopen queue
18:12:29 <Zakim> ok, wseltzer, the speaker queue is open
18:12:38 <wseltzer> rrsagent, draft minutes
18:12:38 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/10-crypto-minutes.html wseltzer
18:12:43 <bhill2> … anonymous voting schemes, new elliptic curves and associated arithmetic
18:13:08 <Anders_R> Anders_R has joined #crypto
18:13:21 <rbarnes> rbarnes has joined #crypto
18:13:31 <rbarnes> i'm still not clear on why this isn't a TC39 thing
18:13:35 <rbarnes> oh, here we go
18:13:37 <brunojav> brunojav has joined #crypto
18:13:40 <bhill2> … more esoteric crypto and more performant impl of standard need bignum finite field and ecc operation primitives exposed to clients in the browser
18:13:56 <bhill2> … why this belongs in the browser API and not in core JS
18:14:03 <harry> harry has joined #crypto
18:14:05 <bhill2> … not all JS clients need WebCrypto, but all WebCrypto needs this math
18:14:28 <harry> note that was discussed in the WG earlier and MS had a very detailed proposal, but the WG decided at the time that ECMAScript was way forward.
18:14:36 <tarcieri> it's pretty interesting that there's one pure JS bignum implementation that virtually every JS implementation of RSA is built on now (well, except for MS's lib)
18:14:54 <bhill2> … should be carried with the part of the platform where it is necessary - which is all WebCrypto impls, but not necessarily all ECMAScript impls
18:14:59 <harry> However, that being said, the demand for this seems like its increasing and ECMA has not made any progress i think on this front.
18:15:18 <bhill2> next at mic: Kelsey Cairns, Washington State University
18:15:32 <bhill2> anybody know Kelsey's irc handle?
18:15:46 <tarcieri> cryptographic bignums have concerns that general bignums don't, like sidechannel resistance
18:16:20 <bhill2> deck title: W3C WebCrypto Analysis
18:16:22 <bren2010> bren2010 has joined #crypto
18:16:39 <bal> bal has joined #crypto
18:16:48 <bhill2> KelseyC: internship project to analyze version 1 of WebCrypto API
18:17:01 <bhill2> … don't care what it looks like as long as it is not causing me danger
18:17:22 <bhill2> … formalize API and analyze model with respect to key safety, plus practical concerns
18:17:34 <bhill2> … using model checkers to search all combinations of API calls
18:18:10 <bhill2> … goal is to test properties of keys, extractable keys, usages, basic message passing
18:18:31 <bhill2> … assume attacker has access to API - e.g. injected code, malicious server
18:18:32 <martin_paljak> similar to pkcs11 works.
18:18:34 <bal_> bal_ has joined #crypto
18:18:38 <bhill2> … testing origin safety is out of scope
18:19:32 <bhill2> … Questions we asked: can key be extracted from client, can usages be changed, what security properties hold for messages, what threats apply to use cases?
18:19:46 <bhill2> … can't say that malicious code will never happen, what *can* we say about our use cases?
18:19:59 <bhill2> … our model found that unextractable keys are good
18:20:21 <bhill2> … usages are only enforced for unextractrable keys, otherwise can export / re-import with new usages
18:20:34 <soohyung> soohyung has joined #crypto
18:20:43 <herve> herve has joined #crypto
18:20:52 <bhill2> … what about sending wrapped keys
18:21:03 <bhill2> … from client to server, found more integrity attacks
18:21:26 <bhill2> … most use cases were vulnerable to at least one of the attacks we found
18:21:43 <Brnocrist> Brnocrist has joined #crypto
18:22:03 <virginie> For the ones who never read the Web Crypto API, you can read it here  http://www.w3.org/TR/WebCryptoAPI/ :)
18:22:27 <bhill2> … e.g. if client wants to send new key to server, attacker can export a key, replace the wrapping key; unwrap the key in the client, or polyfill the wrap operation to no-op and force key to be sent in clear
18:22:41 <vkata> vkata has joined #crypto
18:23:15 <harry> Note that this work is on *current* WebCrypto spec, not future spec.
18:23:33 <bhill2> … other things: review of included algorithms, key storage, polyfills, client-trusts-server security model
18:23:54 <harry> It's more or less the same techniques Graham Steel used against PKCS #11: http://xor.cx/data/CryptoTokenAttacks.pdf
18:24:05 <bhill2> … no key storage is of concern to us, most of room, concluded it will take a lot of thought and must be done well for the application
18:24:15 <bhill2> … polyfills made it to easy to replace subtleCrypto functions
18:24:32 <bhill2> … re: security model, lots of people want user to have some control / security properties
18:24:41 <bhill2> … but web app model is inherently remote code execution by server
18:24:50 <wseltzer> for the transcript, that was "if you're doing remote code execution [shrug]"
18:25:24 <tarcieri> JS == RCE as a feature! :D
18:26:14 <virginie> as a note, speaking about web crypto API algorithms review made by Keisley and Graham, the report is availbale here : http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/
18:26:16 <bhill2> demo of webcrypto extension in chrome that shows generate, inspect, import and use keys to do encrypt operations
18:26:43 <harry> This is what she is drying to demo:
18:26:44 <harry> https://github.com/cryptosense/w3c-crypto-inspector
18:27:14 <harry> http://cryptosense.com/webcrypto-api-tracer/
18:27:19 <harry> blog post above ^
18:27:19 <bhill2> KelseyC: general user population won't find crypto details about keys useful, but I would really really like to have them available
18:27:40 <martin_paljak> harry: it is derived from the cryptosense pkcs11 prober?
18:27:47 <bhill2> next up: Nick Van den Bleeken (Inventive Designers)
18:28:04 <harry> It's the same general idea, I think re-coded to deal with JS
18:28:29 <harry> Graham could answer details: http://www.lsv.ens-cachan.fr/~steel/
18:28:38 <bhill2> cultural question from scribe - should it be NickV or NickB?
18:29:01 <bhill2> nvdbleeck: two things are certain, death and taxes
18:29:15 <bhill2> … one of first uses of eID online was a tax application
18:29:27 <wseltzer> s/nvdbleeck/nvdbleek/
18:29:36 <bhill2> … login lets you choose a certificate to use, enter pin, then you can do your taxes
18:29:51 <rbarnes> agreeing is good, right?
18:29:53 <bhill2> … no digital signature has been generated for this
18:30:18 <bhill2> … other use cases, invoices, contracts, insurance agreements do require a signature
18:30:37 <bhill2> … my eID has a certified key allows me to sign documents legally
18:31:10 <bhill2> … to do that I need my eID, an extension or java plugin to access the smart card (in browser)
18:31:37 <bhill2> … currently browsers don't like Java anymore and block it for good reasons
18:32:12 <bhill2> slide demo of the experience
18:32:18 <bhill2> … I got to the end, but doubt my mother would
18:32:37 <bhill2> nvdbleeck: trying to find solution that doesn't require extension or plugin
18:32:42 <bhill2> … found webcrypto API
18:32:58 <bhill2> … can do sign, but where do keys come from?
18:33:09 <bhill2> … all examples use keys generated in browser
18:33:21 <bhill2> … key discovery API uses named, origin-specific, pre-provisioned keys
18:33:27 <bhill2> … we want eID to be available on all websites
18:33:44 <bhill2> … our keys aren't pre-provisioned, user should insert card at start of operation
18:33:54 <bhill2> … don't want to give name for all eIDs
18:34:13 <bhill2> … to enable our use case we only need certificate-based discovery
18:34:44 <bhill2> examples of code showing selectX509Certificate() API
18:35:08 <bhill2> gold bar on top to prompt user for use of keys
18:35:16 <bhill2> select key as done for TLS client certificate
18:35:39 <bhill2> nvdbleeck: good to go without using any extensions or plugins
18:35:39 <tarcieri> ugh popup for pin entry :|
18:35:55 <bhill2> … doesn't limit access to just smart cards but any certificate in system key store potentially
18:36:25 <bhill2> … believe will make it easier to get access to secure hardware
18:36:26 <martin_paljak> yap, +1
18:36:50 <wseltzer> Sangrae_Cho, ETRI
18:36:52 <bhill2> next at mike: Sangrae Cho, Authentication Research Team, ETRI
18:37:30 <nvdbleek> nvdbleek has joined #crypto
18:37:34 <bhill2> SangraeCho: talk today will be introduction of Korean online banking use case as it relates to certificates
18:37:55 <bhill2> … five authorized certificate authorities operating currently, issuing over 30 million certificates to 20 million people and legal entities
18:37:59 <martin_paljak> nvdbleek: +1. Same story told with nice pictures. I assume the UI pictures were mockups?
18:38:22 <bhill2> … used for online banking, stock trading
18:38:33 <bhill2> … but certificate is issued and managed and used in an ActiveX control
18:38:56 <bhill2> … because most browsers in Korea were IE in the past
18:39:14 <bhill2> … certain issues and problems related to ActiveX
18:39:38 <bhill2> … users also need to install ActiveX controls or programs for certificate management, keyboard protection, personal firewall and anti-virus, and web secure channel
18:39:53 <tarcieri> ActiveX o_O
18:40:07 <bhill2> … issues are that it only works for IE, weak against malicious program attacks, user inconvenience and not mobile friendly
18:40:33 <bhill2> … try to use JS for a web-based digital certificate service
18:40:54 <virginie> as a note, W3C web crypto WG has provisionned a wiki page listing the wishes expressed by members for next feature, see https://www.w3.org/2012/webcrypto/wiki/WG_Future_Work
18:41:46 <bhill2> … use webcrypto API, HTML5 for storage and communication, and CMP for cert issuing and PKCS7 for digital signature implemented on top of these layers in JavaScript
18:42:00 <Ullrich> Ullrich has joined #crypto
18:42:05 <bhill2> … will be launched for service in October
18:42:29 <bhill2> … issues for storage.  In Korea, private key and certificate should be stored in secure, hardware-based solutions
18:43:06 <bhill2> … last year developed TouchSign using smart card with NFC (slide shows it working with a smartphone)
18:43:47 <bhill2> … can access bank on desktop, login with smartphone with card issued by bank and use digital signature to transfer money between accounts
18:44:13 <bhill2> … also trying to provide more convenient solutions with FIDO for a password-less or more flexible authentication
18:44:14 <Rob_philpott_> Rob_philpott_ has joined #crypto
18:44:46 <nvdbleek> tarcieri: A pin is the way to authenticate your operations on BeID , you don’t want to provide access of the PIN to the WebApp. And it is the middleware that provides the UI. If the hardware token supports other authentication ways (e.g. fingerprint) this would be sufficiant too offcourse.
18:44:51 <bhill2> … digital certificate can be issued to the authenticator device for attestation
18:45:15 <tarcieri> nvdbleek: yes, that's all true, however a popup like that can be spoofed by a web page to steal the pin
18:45:27 <bhill2> … trying to use technologies for hands-free payments at stores (slide shows bluetooth beacon-based service)
18:46:01 <bhill2> … requirements are storage management for WebCrypto.Next, standard API for hardware tokens, standard API for communications such as NFC, Bluetooth
18:46:23 <virginie> Please note that NFC API is under development in W3C here : http://www.w3.org/TR/nfc/
18:46:24 <nvdbleek> tarcieri: it should be made visible to the end user that it is a “trusted UI”
18:46:44 <bhill2> next at mic: Philip Hoyer (HID Global)
18:46:48 <martin_paljak> don't forget pinpad readers.
18:47:10 <bhill2> Phil_Hoyer: lots of examples where we are sort of speaking about the same thing
18:47:19 <bhill2> … important that user experience in security is good
18:47:25 <tarcieri> nvdbleek: yes, it needs to pop up over the browser chrome so that's clear
18:47:26 <bhill2> … some smart card efforts so far have hampered that
18:47:36 <nvdbleek> martin_paljak: that is true, the only downside is that with the ones I have the belgian middleware doesn’t uses the keypad :(
18:47:42 <bhill2> … new proximity technologies out there, NFC and Bt specifically
18:47:46 <tarcieri> nice @ NFC
18:47:50 <bhill2> … can communicate w/o needing to be plugged in
18:47:52 <martin_paljak> nvdbleek: yeah. that's the problem of the middleware...
18:48:05 <Nadalin> Nadalin has joined #crypto
18:48:09 <nvdbleek> martin_paljak: but that should be the way to go, use the most secure way to autheneticate to the card
18:48:10 <virginie> One should note about trusted UI that WebAppSec chaired by bhill2 has written some interesting guidelines http://www.w3.org/TR/UISecurity/
18:48:31 <bhill2> … seems oxymoronic that speaking to a bank halfway around the world requires an applet to talk to a smartcard
18:48:52 <bhill2> … user wants contactless presentation of credential or have credential on separate device
18:49:32 <bhill2> … going to be many different devices and credentials that expose security / crypto to another device
18:49:34 <nvdbleek> virginie: thanks, will have a look at it
18:49:40 <tarcieri> virginie: nice
18:49:52 <bhill2> … browser should be able to discover, communicate with and use them
18:50:08 <bhill2> … proposes a proximity API in two layers
18:50:27 <bhill2> … no APDU support yet for NFC API, no BLE support yet
18:50:46 <bhill2> … higher level API allowing discovery / connection to list known proximity devices independent of transport
18:50:57 <bhill2> … retrieval of security capabilities
18:51:05 <martin_paljak> nvdbleek: we use readers in Estonia that are usable only through the physical pinpad. thus you *have* to use it
18:51:06 <bhill2> … connection API to talk to devices
18:51:44 <bhill2> … APIs I'm proposing could use low-level APIs
18:51:52 <rbarnes> this discussion of transaction authorization makes me uncomfortable.  big rat-hole.  better to have cards for a focused purpose (identity) that can delegate to application-specific keys, and handle authorization at the app level
18:52:04 <bhill2> … but higher level APIs can also e.g. remember devices seen before and represent them to the user for re-connection
18:52:16 <nvdbleek> nvdbleek has joined #crypto
18:52:53 <bhill2> … in quest to get rid of passwords, contactless proximity offers one of best and most convenient use cases
18:53:26 <bhill2> … enable browsers to leverage them for security through layered APIs will enable new generation of convenient and secure applications
18:53:49 <bhill2> … feel this proposal is ideally aligned and builds on initial work of WebCrypto API charter
18:53:50 <nvdbleek> martin_paljak: if we only had those… only this has the disatvantage that all users need to buy an external reader, as build in readers won’t work
18:53:59 <martin_paljak> tarcieri: I hope that something shall be arranged here so that I could implement a POC plugin for android browser and estonian id card, yes ;)
18:54:01 <virginie> questions...
18:54:04 <wseltzer> q?
18:54:07 <tarcieri> martin_paljak: nice
18:54:09 <harry> http://www.w3.org/2011/11/webcryptography-charter.html
18:54:19 <harry> ^ the current W3C web crypto charter
18:54:31 <harry> the goal of workshop will be to write a new charter for either this WG or another.
18:54:35 <virginie> q?
18:54:37 <harry> q?
18:54:50 <public_screen> [questions?]
18:54:54 <harry> q+
18:55:10 <sep_of_church_state> q+
18:55:14 <sep_of_church_state> q-
18:55:17 <sep_of_church_state> q+ siva
18:55:22 <SamS> SamS has joined #crypto
18:55:29 <virginie> q?
18:55:33 <bhill2> hhalpin: webcrypto API is currently in Last Call
18:55:38 <virginie> ack harry
18:55:51 <bhill2> … have had extensive comment period, unlikely to see large changes at this point
18:55:53 <rbarnes> firefox has implemented it as well :)
18:56:04 <Herve_SIMalliance> Herve_SIMalliance has joined #crypto
18:56:19 <bhill2> … can and will recharter group, how this API relates to larger world of use cases is what we are here to figure out
18:56:42 <bhill2> … have momentum, but still have some very hard problems in WebCrypto group
18:56:44 <virginie> Implementations of web crypto API information can be fund under https://www.w3.org/2012/webcrypto/wiki/Main_Page#First_implementations
18:57:02 <dirk_balfanz> dirk_balfanz has joined #crypto
18:57:03 <bhill2> … can imagine a 1.1 API, working together on a broader basis with other topics raised here
18:57:11 <bhill2> q?
18:57:24 <harry> ah didn't know it actually shipped yet rbarnes! thanks!
18:57:28 <harry> Any links?
18:57:33 <public_screen> q+ hannes
18:58:27 <JeffH> q?
18:58:29 <Rob_philpott> Rob_philpott has joined #crypto
18:58:34 <bhill2> nvdbleek asks sangrae about discovering devices
18:58:56 <bhill2> sangrae: we use banking or credit card with standard smart card APIs
18:59:11 <bhill2> kelsey: Am I only one here who can't keep track of car keys, wallet?
18:59:18 <bhill2> … only thing I can keep track of in my life is my laptop
18:59:38 <tarcieri> kelsey should get a Yubikey Nano ;)
18:59:56 <bhill2> … my friends even can't find their phone
19:00:42 <bhill2> … can't ignore what users are going to do
19:00:43 <virginie> q?
19:01:10 <wseltzer> ack siva
19:01:15 <JeffH> q?
19:01:18 <bhill2> siva: question for Kelsey - are you suggesting storing keys on server, centralizing trust more on server?
19:01:42 <bhill2> kelsey: our analysis assumed operations would happen client-side, looking at what could happen
19:01:57 <Rob_philpott> Rob_philpott has joined #crypto
19:02:03 <HadiNahari> HadiNahari has joined #crypto
19:02:15 <bhill2> … as far as server malware, not going to say how prevalent or not, but if you have a compromised server and client thinks it trusts it, you can get malicious code to run on client easily that way
19:02:30 <bhill2> siva: is solution then to put keys on sever side?
19:02:59 <bhill2> kelsey: trying not to propose solutions, could put it on server side or make sure whatever key storage on client side is designed to be safe against compromise
19:03:26 <bhill2> bal: whare should the key live?  usually on client, try to protect platform
19:03:51 <bhill2> … pretty sure that Google's E2E solution keeps keys on server and bootstraps it into client based on password authentication
19:04:19 <bhill2> … for certificates, what is policy statement for making them available to different origins
19:04:23 <tarcieri> such a problem too :(
19:04:39 <tarcieri> client cert UX is extermely confusing already. now add hardware tokens...
19:04:41 <bhill2> ack hannes
19:05:20 <bhill2> hannes: looked at formal verification of protocols, interesting although I have some skepticism because it relies on lots of assumptions
19:05:31 <keiji> q+
19:05:35 <bhill2> … advantage it to understand why certain pieces are there and what falls apart if you remove them
19:05:51 <bhill2> … has code been published and is it available for people to play with?  e.g. to model extensions to base model
19:06:02 <bhill2> kelsey: haven't published, but b/c lazy not secret, come talk to me
19:06:25 <bhill2> hannes: question about multiple origins and certificate usages in terms of scoping
19:06:48 <JeffH> q?
19:07:02 <JeffH> q+
19:07:04 <bhill2> … concepts of authentication conflate and grow from 2 -party to 3- or multiple party solution with identity providers, SSO, etc.
19:07:19 <bhill2> … makes whole story complicated quite quickly.  unfortunate but in most cases unavoidable
19:07:43 <bhill2> … challenge to avoid dragging security and privacy problems along, past experiences shows we can't just push that onto the user with dialogs
19:08:00 <bhill2> bhill2 +1 to hannes' last comment re: security UI
19:08:12 <tarcieri> +1000 from me ;)
19:08:24 <wseltzer> q+ on usability
19:08:32 <bhill2> Phil_Hoyer: we are honing in on the use cases we want, avoiding bad user experience in use cases we care about
19:08:39 <jarrednicholls> jarrednicholls has joined #crypto
19:08:46 <bhill2> … will always be different categories of credentials out there
19:08:56 <bhill2> … belgian card is simple, german card has more privacy capabilities
19:09:18 <bhill2> … doubt we will agree on one single API or approach to satisfy all constituencies
19:09:49 <bhill2> … these credentials are costly to issue and have little use
19:10:10 <virginie> Note that Israel from Microsoft also advocated for dynamicity in the web crypto API next phase, motivated by algorithm discovery, see http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_31.txt
19:10:18 <virginie> q?
19:10:24 <bhill2> nvdbleek: not just about belgian ID card, but any kind of hardware device for signing
19:10:26 <wseltzer> ack next
19:10:31 <JeffH> q?
19:10:50 <bhill2> keiji: japan digital ID card is optional
19:11:03 <rbarnes> rbarnes has joined #crypto
19:11:05 <bhill2> … majority of people don't use it because they have to install java plugin
19:11:11 <virginie> q+
19:11:26 <bhill2> … clear expectation with API to make it possible without any kind of plugin
19:12:09 <bhill2> Phil_Hoyer: lots of communities across world, many will not have an ID card to be read.  how do we solve identity or better authN mechanism for them?
19:12:46 <bhill2> hannes: wonder whether one underlying problem isn't broken software update model
19:13:19 <bhill2> … couple of years ago, challenge was updating software on desktop PC, now we want to fix browser plugin problem, or how do we get browser to implement APIS
19:13:43 <bhill2> … with smartphone is a bit different, people are more used to installing specific applications for hardware tokens, may make some issues less complicated from deployment part of view
19:14:02 <bhill2> … is bluetooth easier to roll out vs. browser and desktop environments?
19:14:32 <bhill2> Phil_Hoyer: with any new technology, when added to tools used everyday then interactions will be different between devices
19:14:40 <Martin_> But can installed apps hook into the browsers on mobile phones and provide their services to web applications etc? Not AFAIK.
19:14:53 <martin_paljak> Martin_: android intents ?
19:14:55 <bhill2> … but you can do very nice things, like auto-lock when leaving with device on your keychain
19:15:00 <martin_paljak> but that's platform specifci
19:15:14 <bhill2> … normal office worker vs. doctor in hospital - different use cases, some demand contactless like a clean room
19:15:40 <bhill2> … have to think about what if battery is dead
19:15:44 <bhill2> ack JeffH
19:16:01 <Martin_> I think it would be good with a browser-independent plug-in architecture. Something like signed plug-ins written in JS. So the smartcard drivers etc. could be written and deployed like that. WebCrypto could built on that.
19:16:01 <bhill2> Jeff_Hodges: some active participants in WebCrypto here, yes?
19:16:08 <bhill2> … this session is about extending the API
19:16:22 <bhill2> … but there is a layering in these papers,   bal's is very low level, others are very high level
19:16:30 <harry> q+
19:16:30 <bhill2> … bignum thing seems like a no-brainer to me?
19:17:04 <bhill2> hhalpin: came up pretty early in lifecycle of API from Microsoft, sent a detailed draft proposal
19:17:13 <bhill2> … was discussed on list and F2F
19:17:16 <siva> siva has joined #crypto
19:17:21 <siva> q+
19:17:40 <bhill2> … did not reach consensus (publicly minuted as such) in so far as at the time I believe Google felt it was below the security boundary they felt comfortable exposing to browsers
19:18:25 <wseltzer> ack harry
19:18:50 <bhill2> … in general two types of proposals that were pushed out of scope or not accepted in v1: low level and high level
19:18:59 <bhill2> … have come up since beginning of WG and been extensively discussed
19:19:10 <bhill2> … good time now to look back and think what we could have done differently
19:19:31 <bhill2> JeffH: you need bignum underneath current API?
19:19:40 <bhill2> bal: yes, to do many of the algorithms
19:19:52 <rbarnes> q+
19:20:01 <rbarnes> would like to respond on this point
19:20:08 <bhill2> JeffH: bignums are lower level, only needed if you were going to use it to add in algorithms?
19:20:26 <bhill2> bal: if you want to do an RSA operation that isn't specifically an encrypt/decrypt
19:20:57 <bhill2> … my group came to this wanting to dive down a layer beneath wrapped sign, encrypt
19:21:11 <bhill2> … e.g. doing U-Prove blinded operations can't be expressed in terms of these
19:22:14 <bhill2> bal: we exported out our implementation but if you inherited someone else's you might have less access
19:22:15 <rbarnes> i want to jump in
19:22:21 <wseltzer> q- later
19:22:35 <virginie> q- later
19:22:36 <bhill2> jeffh: as I recall, there has been a layering argument that is a major issue here and ought to be on list for considering rechartering
19:22:51 <bhill2> … are we still talking one API or a layer cake?  already today three layers discussed
19:23:10 <harry> I think W3C is OK with different APIs and even different layers.
19:23:11 <bhill2> … also Phil's thing - other APIs that arguable aren't WebCrypto like connection APIs
19:23:16 <harry> q+
19:23:35 <bhill2> … to attract right kind of people, need right label on where work gets done
19:23:38 <rbarnes> a veritable mille-feuille of API layers
19:23:40 <rbarnes> q-
19:23:46 <tarcieri> current API conflates layers, also :( @ algorithms being non-normative
19:24:21 <harry> Note algorithms for browser profiles have been decided by WG to be normative, but will be decided after interop testing rather than before. Seems logical to me.
19:24:23 <bhill2> Phil_Hoyer: agrees, is making the case that these APIs are needed from other groups
19:24:32 <bhill2> q?
19:24:35 <virginie> q?
19:24:40 <harry> q-
19:24:42 <tarcieri> harry: I must've missed that
19:25:20 <bhill2> hhalpin: intense discussion on mailing list early on about layering. consensus so far is to reveal a pretty decent set of primitivess, not being too judgemental
19:25:39 <bhill2> … not trying to build a "developer-proof" API, but algorithm was as low as we wanted to go
19:26:04 <bhill2> … what is "developer-friendly" is contentious
19:26:24 <bhill2> … we put these papers in same group because they were not in same layer as current API, must layer up or down
19:26:30 <rbarnes> totally disagree, harry -- the cert mgmt stuff is layering
19:26:45 <Martin_> why not just make an optional API spec for the primitives (BigNum etc)? Then applications can polyfill on browsers that don't support it. With this approach at least you get a standard way of accessing a native BigNum impl on the browsers where this is available, without putting a burden on everyone for implementing it
19:26:46 <bhill2> … or cannot build on top without adding new kinds of things not in original spec, as e.g. certificates
19:27:12 <bhill2> … main barrier has not be theological, but lack of drafts, people working on them and consensus from implementers
19:27:24 <martin_paljak> OSI defines some. and they can be violated
19:27:32 <bhill2> siva: how many in audience are in hardware business?
19:27:37 <bhill2> … most of us are software
19:27:39 <martin_paljak> (layers)
19:27:50 <bhill2> … would be nice to build new platform, protocol, hardware
19:28:07 <bhill2> … distribution cost of hardware is high, backward compatibility is critical if we are to leverage it
19:28:12 <JeffH> JeffH has joined #crypto
19:28:22 <wseltzer> q?
19:28:33 <bhill2> … 30 billion plastic cards out there, don't imagine existing web properties shipping a billion new cards to their users
19:28:34 <wseltzer> ack siva
19:29:09 <HannesTschofenig> Regarding the cost of hardware there is Webinar given by a co-worker (from ARM) that may be relevant: http://www.tschofenig.priv.at/wp/?p=1036
19:29:24 <bhill2> Phil_Hoyer: yes.  for new cases ability to talk between devices is good - can put credentials on just a few platforms that can be talked to by others
19:29:34 <karenlu_> q+
19:29:41 <bhill2> … maybe Google will put U2F on gear , etc as a personal device?
19:30:06 <bhill2> siva: who will pay?
19:30:23 <bhill2> Phil_Hoyer: don't underestimate cost of brand damage?
19:30:27 <Karen> q+ for Detlef
19:30:33 <wseltzer> q+ Detlef
19:30:38 <wseltzer> q- Karen
19:30:46 <bhill2> q?
19:30:52 <bhill2> ack wseltzer
19:30:52 <Zakim> wseltzer, you wanted to comment on usability
19:31:08 <bhill2> wseltzer: point was about what we present to the user
19:31:11 <virginie> q+ herve_SIMalliance
19:31:23 <bhill2> … we don't have a usability session in agenda, will mention as one point of consideration
19:31:42 <bhill2> … in keeping with giving the user priority we need to think about how to make these systems for the user, treating the user as a sensible intelligent person but who is not an expert
19:31:57 <bhill2> … in any of these pieces of technology and is trying to get their tasks done
19:32:12 <bhill2> … how do we let them manage their security and privacy is a question we need to face
19:32:28 <bhill2> … regarding layering questions: lots of different WGs at W3C and opptys to charter new ones
19:32:43 <bhill2> … our aim is to be modular where that helps and bring participants together where that helps to get the work done
19:32:59 <bhill2> … WebCrypto has a community including implementers and active interest in extending it
19:33:20 <bhill2> … suggestions, the more concrete the better, should be brought into group for version 1.1
19:33:52 <bhill2> … and rest of workshop will look more broadly what will go into 1.1, 2.0, other W3C WGs and even other organizations we can coordinate with on behalf of the web
19:34:20 <JeffH> q?
19:34:21 <martin_paljak> +1 to the speakers chair!
19:34:22 <wseltzer> q-
19:34:25 <bhill2> Phil_Hoyer: would be good to have a quick win for certain constituencies to show use of APIs, I think that win is to use existing credentials and smart cards out there
19:34:26 <wseltzer> ack next
19:34:37 <bhill2> virginie: thank you for great ideas
19:34:46 <bhill2> … WG is not only a machine, is also a human group
19:35:00 <bhill2> … at time there were lots of new ideas, group was not mature and confident enough of reaching v1 of API
19:35:11 <bhill2> … created issues to accepting proposals like bignum and certificates
19:35:19 <bhill2> … maybe now is a better time to revisit
19:35:38 <bhill2> … asking each of panelists: you came with specific use cases you want
19:35:59 <bhill2> … how are your use cases related to the problem of killing the password?
19:36:14 <bhill2> … what is the functional aspect you want to add to the box we have been discussing this morning?
19:36:38 <bhill2> sangrae: we need to have some place to securely store and manage private keys and certificates
19:37:02 <bhill2> … we do not think html5 local storage is secure enough for keys
19:37:10 <harry> q?
19:37:12 <harry> q+
19:37:42 <rbarnes> Nadalin: could we turn down the AC?  freezing in the back here.
19:37:44 <bhill2> … also in Korea there is consensus to store keys in hardware tokens
19:37:54 <bhill2> … so need APIs to hardware tokens
19:38:13 <bhill2> Phil_Hoyer: regarding killing passwords - history has several attempts, all had one or two hurdles to adoption
19:38:52 <bhill2> … ability or proposal to leverage different devices to store credentials and keys and allow use of that for identifications in web applications will finally bring down some of those hurdles and allow a more natural migration away from passwrods
19:39:14 <bhill2> … we issue 10s of millions of cards every year, if we can use these or put a credential vault on a phone that can be used
19:39:30 <martin_paljak> why not look at Java KeyStore interface, which is quite often used and also has well known issues.
19:39:34 <bhill2> … we've already paid for these but can't use them
19:39:44 <rbarnes> q+
19:40:00 <bhill2> nvdbeek: want to sign documents using a key singed by a CA, not bound to a particular domain, especially but not limited to smart cards
19:40:19 <bhill2> bal: not any one single feature is magically going to make passwords go away
19:40:37 <virginie> q?
19:40:42 <bhill2> … we've tried at MSFT, but took 15 years of investment to work today in a well-maintained corporate environment
19:40:45 <rbarnes> q-
19:40:47 <Anders_R> the number question IMO is if WebCrypto key access should be extended to multiple domains or
19:40:52 <Anders_R> not
19:41:07 <bhill2> … attempts to make user understand cryptographic concepts have failed for 15-20 years.. users will just click
19:41:11 <rbarnes> Anders_R: that is emphatically not a question.  that already exists.  postMessage FTW
19:41:28 <bhill2> … requests are to expose underlying features but in the browser.
19:41:47 <bhill2> … e.g. ASN.1 stuff which isn't there or exposed in a non-intuitive way
19:41:56 <bhill2> … this is a layering issue because it requires ecosystem
19:42:12 <bhill2> … I want lower layer things to I can play with ideas that enable new use caases
19:42:27 <bhill2> … at a higher layer it is about how to manage this information and make it available
19:42:36 <FaSo> Question: as a final user would you be happy if the HW token stops working and you have to wait one week before someone delivers you a new one?
19:42:39 <bhill2> ack karenlu_
19:43:02 <bhill2> karenlu_: replacing password is important but should not be the only thing
19:43:11 <bhill2> … practically we should consider the level of assurance
19:43:27 <bhill2> … regarding user experience and existing cards, real world experience with solutions we've developed
19:43:37 <bhill2> … for using smartcards with webapps for authn, signatures, etc.
19:44:02 <rbarnes> q?
19:44:04 <bhill2> … a country where all citizens have id card, they find out that citizens are not really using the smart cards
19:44:20 <bhill2> … list of reasons: one is that it is difficult to choose the certificate
19:44:35 <bhill2> … user is confused by dialogs in certificate chooser
19:44:39 <martin_paljak> tsl tõenäoliselt ?
19:44:40 <bhill2> … is not portable between browsers
19:44:58 <martin_paljak> TSL probably ? A smart card *is* portable.
19:45:06 <rbarnes> TLS?
19:45:15 <bhill2> … we have provided an identity management solution with level of assurance depending on the service you have
19:45:33 <bhill2> … can just login with username/password for less sensitive service, need to use smartcard for high value
19:45:53 <JeffH> q?
19:45:55 <bhill2> … authentication is important but how important?
19:46:09 <bhill2> … malware wait on computer or phone to access post-authentication
19:46:24 <bhill2> … we would like a solution to help with authentication but also secure online transactions
19:46:50 <rbarnes> q+
19:47:15 <bhill2> nvdbeek: incentivizing use of smart cards can be about making better applications than with paper, e.g. as tax example I showed
19:47:18 <martin_paljak> q+
19:47:37 <Rob_philpott> Rob_philpott has left #crypto
19:48:38 <harry> q?
19:48:45 <bhill2> ack Detlef
19:49:01 <Rob_philpott> Rob_philpott has joined #crypto
19:49:16 <bhill2> detlef: can we hear more with respect to mechanisms for discovery?  did you consider what is in FIDO for example, are they sufficient?
19:49:51 <bhill2> Phil_Hoyer: I think there needs to be that alignment, when I said discovery it goes beyond because of unconnected nature
19:50:17 <bhill2> … webapp should be able to know what security capable devices are in vicinity with binding, including already used ones
19:50:35 <bhill2> … security device may have separate keys for different uses
19:50:40 <bhill2> … see if it has some form  of display
19:52:07 <harry> q?
19:52:12 <bhill2> jeff_hodges: FIDO intents to promulgate specs into other standards groups such as W3C when IPR dance is done there
19:52:26 <bhill2> … please take a look at the specs there
19:52:38 <bhill2> ack herve_SIMalliance
19:52:43 <bhill2> ack harry
19:53:03 <tarcieri> q+
19:53:06 <bhill2> hhalpin: what is connection of limitations of first version and hardware tokens?
19:53:13 <wseltzer> zakim, close queue
19:53:13 <Zakim> ok, wseltzer, the speaker queue is closed
19:53:25 <bhill2> … kelsey's work shows crypto api is great but still subject to polyfill attacks and key storage
19:53:41 <bhill2> … hardware tokens may be able to help solve some but not all of these concerns
19:54:06 <bhill2> … also facebook issues, how to do code signing?
19:54:51 <wseltzer> q?
19:54:54 <bhill2> … still, you have to trust web security model, how do we address holes there
19:54:56 <wseltzer> ack next
19:54:59 <bhill2> … we will return to that later
19:55:18 <bhill2> rbarnes: signing is a secondary use case after authentication
19:55:43 <bhill2> … for folks interested, would you consider it a failure to have a layering between identity and signing layer
19:55:52 <JeffH> q?
19:56:00 <rbarnes> ack me
19:56:01 <bhill2> … where an identity could be associated with a key that is not bound to the identity
19:56:28 <wseltzer> ack martin_paljak
19:56:32 <Rob_philpott> Rob_philpott has joined #crypto
19:56:35 <bhill2> nvdbeek: performing bindings like that are not considered legally binding by european law: only the key on the certificate has legal status
19:57:07 <bhill2> martin_paljak: takes a long time for user communities to change their values, so can't get opinions until after 7-10 years
19:57:30 <bhill2> … issue of certificate selection is removed if you use a card, concept is not new to people
19:57:54 <bhill2> … should not try to create out of nothing new authentication metasystem out of nothing
19:58:00 <Martin_> +1
19:58:10 <bhill2> … but adjust so existing systems can be fulfilled with webcrypto APIs
19:58:15 <JeffH> q?
19:58:38 <rbarnes> i'm pretty doubtful that these "use the card as an HSM" cases are going to be tractable
19:58:43 <bhill2> Phil_Hoyer: chip and pin and contactless is something users are experienced with
19:58:54 <bhill2> ack next
19:58:59 <Martin_> rbarnes: Because? :)
19:59:04 <bhill2> tony arcieri from square
19:59:26 <bhill2> tarcieri: if you try to cover lots of things, from authentication, signing, encryption, channel binding
19:59:38 <bhill2> … trying to put all this into a single package, it fails to be usable by average user
19:59:54 <bhill2> … how do we balance usability concerns for something like just the general authentication case which must be simple for average user
20:00:17 <bhill2> … (e.g. html keygen tag failed horribly to replace passwords)
20:00:21 <rbarnes> Martin_: just making an HSM isn't that hard superficially, you just copy/paste the existing API.  but then you have to deal with when the HSM is available.  and i've never heard a scalable story fortransaction authz
20:00:53 <rbarnes> Martin_: lots of complexity for not a ton of incremental benefit
20:00:54 <bhill2> … hardware tokens help with some of that, but how we make that seamless enough to actually get widespread adoption while still having all fancy things financial services users want?
20:01:07 <martin_paljak> what I wanted to add is that first "clone" working things (like real life processes) then tweak them once elements that can be "digitized" have been identified.
20:01:26 <Pea> Pea has joined #crypto
20:01:54 <JeffH> q?
20:01:54 <bhill2> Phil_Hoyer: ability to create an authentication context with different data.  if we can extend that through the web api with something like a proof of possession
20:02:07 <bhill2> … maybe not one thing, but can create a risk assessment of the overall situation
20:02:18 <ilhangurel> ilhangurel has left #crypto
20:02:24 <bhill2> tarcieri: thinking like fido deck, push button, you're authenticated
20:02:25 <Martin_> @rbarnes: HSM's basically only solves the problem of not being able to clone the token and ensures the user must "present" it for it to be used. But it can still be abused in many other ways. I don't think accessibility etc. is in practice a problem (thinking of smartcards etc). Backup schemes need to be in place when used for encryption
20:02:44 <bhill2> … how do we get to that level and prevent fancier features from making it less seamless than that
20:02:59 <rbarnes> Martin_: i feel likey ou're making my point for me :)
20:03:55 <bhill2> … how do we layer these different things for ordinary vs. power users?
20:05:17 <bhill2> bal: reasonable to partition these things
20:05:49 <bhill2> … want enough metadata on keys for system, user agent, browser to make an intelligent decision
20:06:03 <bhill2> … so doesn't have to ask user to choose among 50 keys, but to have some context
20:06:17 <bhill2> … today policy and usage information is in x.509
20:06:23 <bhill2> q+
20:07:00 <bhill2> Brad Hill notes as not-scribe that this is a problem that comes with 3-party key systems
20:07:17 <bhill2> in a 2 party system with targeted credentials it is much less of a problem
20:07:37 <AdrianC> AdrianC has left #crypto
20:07:44 <bhill2> because the service knows which keys registered with it are for what users implicitly and can ask the user for the exact appropriate one
20:08:00 <bhill2> only if you have to rely on a key issued by an identity provider or other third party does this become a problem
20:09:32 <public_screen> [lunch time; we resume at 2pm local time]
20:09:42 <public_screen> rrsagent, draft minutes
20:09:42 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/10-crypto-minutes.html public_screen
20:09:56 <ale> ale has joined #crypto
20:37:21 <drogersuk> drogersuk has joined #crypto
20:45:56 <Karen> Karen has joined #crypto
20:46:57 <tkeiji> tkeiji has joined #crypto
20:50:45 <Rob_philpott> Rob_philpott has joined #crypto
21:06:23 <wseltzer> Topic: Authentication
21:06:36 <Ullrich> Ullrich has joined #crypto
21:07:25 <adam_> adam_ has joined #crypto
21:07:29 <virginie> virginie has joined #crypto
21:07:49 <Anders_R> Anders_R has joined #crypto
21:08:35 <wseltzer> bhill2: Brad Hill, representing FIDO Alliance
21:08:55 <wseltzer> ... technologies to replace username/password
21:08:56 <lifewsky> lifewsky has joined #crypto
21:09:13 <mdwood> mdwood has joined #crypto
21:09:15 <nvdbleek> nvdbleek has joined #crypto
21:09:30 <tkeiji> tkeiji has joined #crypto
21:09:32 <JeffH> JeffH has joined #crypto
21:09:33 <KarenOD> KarenOD has joined #crypto
21:09:36 <virginie> dear all, we are looking for a scribe... any volunteer ?
21:09:50 <wseltzer> ... lessons learned: users and services want keys that are hardware-bound or difficult to steal
21:10:01 <wseltzer> ... but users want unlinkability
21:10:02 <rbarnes> rbarnes has joined #crypto
21:10:08 <Cathy> Cathy has joined #crypto
21:10:22 <rbarnes> rbarnes has left #crypto
21:10:22 <wseltzer> ... ceremony, associate user with key, before using the key
21:10:32 <rbarnes> rbarnes has joined #crypto
21:10:46 <wseltzer> ... once they've gone through the costly key-generation ceremony, users want to use everywhere
21:11:18 <ilhangurel> ilhangurel has joined #crypto
21:11:19 <wseltzer> ... Services have many facets (different presentations, different browser environments, apps, etc.)
21:11:46 <wseltzer> ... facets may be unknown to one another
21:12:03 <wseltzer> ... Just solving for the browser is not enough.
21:12:40 <wseltzer> ... but, also need to help users protect themselves, can't just regenerate an actual fingerprint.
21:13:06 <tkeiji_> tkeiji_ has joined #crypto
21:13:14 <wseltzer> ... Key reference monitor, living outside the browser. "FIDO Client"
21:13:34 <keiji> keiji has joined #crypto
21:13:52 <brunojav> brunojav has joined #crypto
21:14:02 <wseltzer> .... Pieces: key-scoping mechanism (AppID), scope-authorization mech (trusted facte list), platform specific reference monitor (FiIDOClient)
21:14:22 <wseltzer> ... set of platform-apprpriate APISs to access ref montor functions from Web apps, etc.
21:14:37 <wseltzer> ... APIs, where W3C can help
21:14:38 <Martin_> Martin_ has joined #crypto
21:14:54 <wseltzer> ... FIDO has 4: discovery, registration, authentication, deregistration
21:15:05 <wseltzer> ... https://fidoalliance.org/specifications/download
21:16:06 <AdrianC> AdrianC has joined #crypto
21:16:10 <Phil_Hoyer> Phil_Hoyer has joined #crypto
21:16:10 <wseltzer> Detlef: Towards harmonizing ISO24727 FIDO and Web Crypto API
21:16:14 <siva> siva has joined #crypto
21:16:19 <ChrisW> ChrisW has joined #crypto
21:16:26 <siva> i can scribe....
21:17:53 <wseltzer> Detlef: charming part about FIDO, the authentication part is simple on the client side
21:18:20 <siva> Detlef - discovery is about the client; FIDO protocol is fairly simple using request-response stnardard by iso 9798-3; simplicity is "great"; but we should think about we might make facilities for supporting addl auth protocols
21:18:41 <wseltzer> i/Detlef - /scribenick: siva
21:19:46 <JeffH> siva is scribing ?
21:19:48 <siva> Detlef - ISO 24727 is an effort to standardize ID cards by NIST. Now this is all over the world. A few 100 million ID cards. Possibily bigger. Perhaps we use this existing infrasturcture. For e.g. many European countries have national ID cards.
21:20:01 <siva> Yes Jeff...I am
21:20:42 <JeffH> thx :)
21:21:03 <siva> Detlef - a serivce layer abstracts the various nuances of the national ID cards....so you are not relying on the APDU layer...ISO 24727 is a good abstraction layer.
21:21:52 <herve> herve has joined #crypto
21:21:57 <keiji> Detlef: Many European companies are introducing National ID cards.  Introducing ISO/IEC 24727 Architecture and Protocols.
21:21:58 <Peter_Cattaneo> Peter_Cattaneo has joined #crypto
21:22:22 <siva> Detelf - At this layer of abstraction there is no difference between FIDO and ISO 24727....except for multiple request-response pairs and other auth protocols for more "sophisticated" EID tokens and protocols are more complex on purpose.
21:22:33 <siva> *Detlef
21:22:54 <harry> s/Detelf -/Detlef:
21:23:36 <JeffH> iso wants CHF198 for ISO 24727 spec :(
21:23:57 <siva> Detlef - recommends a set of fuctions for the service access layer based on ISO 24727-3...which includes discovery using a localhost interface...
21:24:02 <Rob_philpott> Rob_philpott has joined #crypto
21:24:44 <bal> bal has joined #crypto
21:25:04 <siva> Detlef - nuances including waitforchange such as proximity device is close to client or moves away are covered in this ISO 24727 discovery process
21:25:53 <siva> Detlef - what does this mean for webcrypto API ... on one hand FIDO and ISO 24727 is similar...but ISO is a ISO standard already and can handle arbitrary auth protocol.
21:26:08 <siva> Detlef -- we need to have a BOX where addl protocols in the future can plug in
21:26:33 <wseltzer> s/Detlef -/Detlef:/g
21:27:20 <siva> JohnMattsson - talking about SIM card auth...and its importance in mobile phones
21:27:28 <karenlu> karenlu has joined #crypto
21:29:03 <siva> JohnMattsson - everybody has a mobile phone...or soon will....and everybody will have internet connections....and mobile browsers...so we will need to auth in a mobile phone not PC!
21:29:54 <siva> JohnMattsson - so web auth protocol need to work on mobile phones...the fact is that most mobile phones already have trusted token - the SIM card
21:30:20 <siva> JohnMattsson - with LTE all mobile phones will have SIM cards
21:31:33 <siva> JohnMattsson - GBA standarized 3GPP and uses existing SIM credentials...and derives new temp keys and temp identities...and can be easy to intergate to other protocols such as OAuth and OpenID...VoLTE uses GBA already.
21:31:42 <keiji> JohnMattsson - SIM card is a new web authentication solutions need to work with smart phones.
21:32:09 <siva> JohnMattsson - Browser supporting missing for SIM card...and should be considered...
21:32:35 <siva> JohnMattsson - SIM cards are already used for other applications such as National ID, Mobile banking, and SMS 2nd factor auth.
21:33:17 <Karen> Karen has joined #crypto
21:33:17 <wseltzer> s/JohnMattsson -/JohnMattsson:/g
21:33:22 <siva> Personal comments - SIMs do solve the hardware distribution problem even better than embedding...since access will be universal
21:33:33 <keiji> JohnMattsson - certificate can be installed on SIM card and used as eNational ID.
21:33:36 <rbarnes> to dirk's question earlier -- these are point solutions :)
21:34:05 <siva> wseltzer - got it!
21:34:40 <JeffH> wseltzer is a zakim jockey :)
21:35:02 <siva> Hannes: Widespread deployment necessary for replacing password.
21:35:43 <siva> Hannes: New technologies face the same problem. All stakeholders need to cooperate.
21:37:15 <siva> Hannes: Taking FIDO as an example. Pointing out one aspect of FIDO...it is not as simple as mentioned by Detlef...formal verification indicates FIDO meets critical need for security.
21:37:30 <Martin__> Martin__ has joined #crypto
21:38:47 <siva> Hannes: Typically in W3C the objective is to identify building blocks so we can put things together instead of a point solution. Build point solutions on top of the building blocks.
21:41:03 <siva> Hannes: In the case of FIDO where discovery is needed or privacy mechnism as mentioned by Brad of PayPal could easily be the building blocks for FIDO and other authentication protocols. GBA is different the FIDO. But can we identify "abstract" functions that can supports privacy, security, simple, and support FIDO and all other authentication protocols
21:42:29 <siva> Hannes: Many stakeholders need to cooperate...in IETF's experience on paper in standards it might be easy...but in the real world a good experience for user is a completely difference thing.
21:42:52 <siva> Hannes: Abstract the hardware protocol such as BTLE, USB ... like FIDO
21:44:47 <siva> Hannes: Questions: why past efforts have failed (business model?), how to get all stakeholders involved, support innovation?, how to get good user experience end-to-end soln....
21:44:54 <neXus> neXus has joined #crypto
21:44:59 <virginie> +1 to abstraction exercice required :)
21:45:01 <JeffH> Landau, Susan, and Tyler Moore. "Economic tussles in federated identity management." First Monday 17.10 (2012).
21:45:07 <siva> Hannes: Privacy is important (mentions with the risk of kicking out!)
21:45:17 <siva> And that is 11.5 mins! :-)
21:45:20 <JeffH> http://uncommonculture.org/ojs/index.php/fm/article/view/4254/3340
21:45:28 <siva> Personal comment: Didn't feel like 11.54
21:45:33 <siva> *11.5 mins
21:46:04 <keiji> Wykes: Beyond Authentication
21:47:30 <siva> Sean: How to integrate h/w tokens to Webcrypto API...need token, token driver, standard (APDU, PKCS11, FIDO, trusted interface...?)
21:48:13 <siva> Sean: Authentication means diff things to diff people - 4 entires based on context on one axis and security on the other (refer to paper on the details)
21:49:58 <siva> Sean: Brazil example: Government ID - 9M certs; Employee ID cards - 15,000 employees; Banking - 5M cards, zero fraud with 5.6B USD/month
21:50:18 <siva> *zero online fraud using smart cards
21:52:05 <siva> Sean: MITB attacks are very sophisticated....a transaction signature method is used
21:53:07 <siva> Sean: Going forward....there is lower browser support to applets...browsers re removing sandbox...so we need - a flexible web standards...that has a trusted UI and can we adapt HTML, CSS and Javascript
21:53:29 <keiji> Sean:  We need flexible web-standard for security related functionality with a TRUSTED UI.
21:53:45 <tarcieri> +1
21:54:01 <siva> Sean: Proposes a new architecture...with webcrypto API with trusted UI...native authn...talking out of band (not through APP) comm to the token....
21:54:39 <siva> Sean: a Box that does cyrpto secuirty services is needed outside of the webcrytp API
21:56:05 <siva> Sean: Impl idea = Webworker + Frame + Signed JAR = a new tag = a standard way of appl vendors to do this!
21:56:29 <keiji> Sean:  suggest to Combine best ideas from : webworker + <FRAME/> +Signed JAR -> new tag <trusted />
21:56:36 <selfissued> selfissued has joined #crypto
21:56:37 <rbarnes> a+
21:56:39 <selfissued> q+
21:56:39 <rbarnes> q+
21:56:56 <wseltzer> zakim, open queue
21:56:56 <Zakim> ok, wseltzer, the speaker queue is open
21:56:57 <Ullrich> Ullrich has joined #crypto
21:56:58 <siva> q?
21:57:01 <rbarnes> q+
21:57:02 <selfissued> q+
21:57:20 <Martin_> Martin_ has joined #crypto
21:57:58 <siva> Brad: I have a lot of devices...how do I make sure a SIM soln will solve the problem?
21:58:01 <sangrae> sangrae has joined #crypto
21:58:16 <JeffH> ....as while preserving privacy
21:58:16 <siva> John: Need cooperation from mobile operators
21:58:18 <gmandyam_> q+
21:59:55 <siva> Hannes: Less attractive for developers to use SIM cards for call use cases [maybe] misguded
21:59:59 <siva> *misguided
22:00:43 <HadiNahari> HadiNahari has joined #crypto
22:00:44 <siva> John: SIM tech is ideal...but business model is a challenge. But issue will exist for any secure element.
22:00:50 <lifewsky> lifewsky has joined #crypto
22:01:25 <siva> Hannes: A web developer if faced with such a challenge...might just want to do it using a trusted execution environment...or get an external token
22:01:44 <siva> John: A lot of web apps already use SIM through SMS one time password
22:02:17 <siva> Hannes: Disagrees SMS example will move to other uses such as email
22:02:27 <rbarnes> i need to step out, could someone proxy my question?  regarding "trusted UI", (1) how is this better than HTTPS + Content Security Policy, (2) why does it require a hardware token and (3) why would we not do this for the rest of the web?
22:02:29 <rbarnes> q-
22:02:37 <rbarnes> i'll take my answer via the scribes :)
22:02:47 <siva> Brad: If we are bulding web API it will need to be of web scale not just for govt and banks...limited to a few
22:02:49 <siva> q?
22:02:58 <tarcieri> OTPs sent over SMS are often replayable for a window of time, and SMS traffic can be sniffed
22:04:11 <siva> Hannes: The important aspect is to determine how we talk to the various hardware tokens...FIDO has an intermediate abstraction layer so that web app and web service provider doesnt need to card about the hardware transport layer
22:04:52 <JeffH> need to know
22:05:01 <wseltzer> ack selfissued
22:05:06 <JeffH> q?
22:05:18 <virginie> s/need to card/need to know
22:05:22 <siva> MikeJones: Question for Sean - in Brazil was smartcards for banking legislated
22:05:51 <siva> Sean: No. It is done by the bank giving local reader for users.
22:06:13 <wseltzer> q?
22:06:32 <siva> Sean: Cost of couple of million readers @ $5 + already issued smart card for the transaction volume they have is justifiable
22:06:47 <AdrianC> AdrianC has joined #crypto
22:07:30 <siva> Sean: There is a lot of resistane nevertheless since the user doesn't want to carry this reader....go after a different form factor...
22:07:38 <gmandyam_> gmandyam_ has joined #crypto
22:07:42 <siva> Sean: Question is how can user this hardware....
22:07:49 <gmandyam_> q?
22:07:50 <siva> MikeJones; Supports that thought
22:07:50 <Peter_Cattaneo> q+
22:07:51 <siva> q?
22:07:52 <Ullrich> Banks are not liable if fraud happens with a secure tech
22:08:00 <wseltzer> ack gmandyam_
22:08:32 <siva> gmandyam_: what is the goal of GBA given FIDO arch?
22:08:53 <siva> given GBA requires lot of changes to browsers
22:09:38 <siva> John: GBA should be implemented with FIDO  or something else as defined by W3C....
22:10:14 <virginie> q+
22:10:16 <siva> Hannes: FIDO and GBA don't align well with the IMA client
22:10:23 <siva> *IMS
22:10:52 <siva> Hannes: Believes that basically make use of GBA for web services...
22:10:55 <virginie> q+ to proxy richard question regarding "trusted UI", (1) how is this better than HTTPS + Content Security Policy, (2) why does it require a hardware token and (3) why would we not do this for the rest of the web?
22:12:22 <siva> Hannes: FIDO auth is local there is not over the air protocol like GBA
22:13:20 <siva> Detlef: FIDO is a great use if you assume there is nothing else out there...but there are lot of auth solns out there....so the question is how do we take advantage of it...so it can interoperate for all auth....
22:13:34 <siva> q+
22:13:54 <harry> q+
22:14:45 <JeffH> bhill: we need to ask why all that already-deployed stuff hasn't succeeded to replace username+pswd -- thinks it is because...
22:14:45 <siva> Brad: Existing solns have not been adopoted so far for web....so why support it
22:15:23 <siva> Hannes: how many legacy infrastucture do we want to support with shortened innovation cycles
22:15:39 <JeffH> ...a combo of not being 'easy' for users to wield,  unbalanced requirements between RPs/issuers/users, privacy concerns, etc.....
22:16:04 <siva> Hannes: Maybe another try with FIDO instead of retro fitting with legacy infrasturcture
22:16:09 <siva> q?
22:16:27 <siva> Hannes: lets move an build from scratch
22:16:31 <wseltzer> ack next
22:17:57 <siva> Peter: Two things are getting mixed up. CryptoAPI is about Crypto protocol that can go in lots of places including SIM. But we are confusing ownership and control. It is completely independent of the auth algorithm.
22:18:53 <siva> Hannes: Business model is and will be a barrier...and therefore there are some caveats to that
22:19:14 <siva> q?
22:20:39 <siva> Sean: We need to seperate centrally issued and user issued. In an open web arch can we exclude on and the other....but is that open?
22:21:04 <siva> Sean: Some of the legacy stuff is working.
22:21:30 <siva> Sean: Can we build into the web crytpo API both of these
22:21:48 <martin_paljak> q+
22:21:51 <siva> Brad: Users are not good at managing security etc.
22:22:02 <Phil_Hoyer> q+
22:22:22 <siva> Brad: Too many choices may not be user experience
22:22:51 <tarcieri> +1 to reducing user security decisions for the common case
22:23:43 <siva> Detlef: we do not have good integration for existing methods...so web use is not common...
22:24:14 <siva> q?
22:24:53 <siva> Detlef: Build better interfaces to existing methods  work...
22:25:31 <JeffH> Q?
22:25:35 <siva> Hannes: Disagreeing with Sean...Existing methods to not offer standard of user authn process....
22:25:40 <siva> q?
22:27:51 <siva> virginie: question to Richard - trusted user interface...how is it better than what we already have
22:28:15 <siva> Detlef: what we have is only available in microsoft platform. it is not available on all platforms.
22:28:29 <adam_> no
22:28:34 <tarcieri> hahaha
22:28:34 <siva> q?
22:28:42 <tarcieri> cryptographic service provider =/= content security policy
22:28:53 <virginie> argh...
22:29:19 <tarcieri> see also: communicating sequential processes
22:29:39 <martin_paljak> trollmode: we need "trusted html" </trollmode>
22:29:54 <rbarnes> Content Security Policy -- limits script injection
22:30:00 <siva> q?
22:30:59 <JeffH> bhill: doing anything other than PNG in a trusted display is a path to issues.....
22:31:26 <siva> Handing off scribing to JeffH (Thanks!)
22:31:46 <harry> scribenick: JeffH
22:32:40 <siva> q?
22:32:44 <JeffH> hannes: an issue with getting new authn mechs deployed is the requirement for supporting plethora of existing deployed creds and mechs -- so maybe we shouldn't do that.....
22:33:26 <JeffH> detlof: the deployment prob is solved by the browser vendors -- if they step up this prob can be solved -- so what
22:33:38 <JeffH> s their agenda?
22:33:50 <JeffH> virginie: have heard..
22:33:58 <JeffH> ..fido is applicable/interesting
22:34:25 <JeffH> ..?
22:34:32 <JeffH> ..? trusted UI ?
22:34:42 <harry> SIM cards are important
22:34:52 <harry> virginie: Trusted UI is a feature
22:35:07 <harry> virginie: government and banks needs are important
22:35:09 <virginie> virginie : we heard several people pushing their use cases and technology : fido, ebanking, governement, SIM based authentication
22:35:22 <harry> virginie: can we re-design FIDO to incorporate this?
22:35:32 <virginie> virginie : can we re-design FIDO to have all use cases being impelmented in FIDO ?
22:35:53 <JeffH> bhill: fido can address some of these use cases -- signing govt doc with approp key is a diff use case from everyday login to all the webapps people use -- so they can be orthogonal APIs -- keep the authn api simple, have others for eg the doc signing use case....
22:36:03 <virginie> sorry harry, wendy asked me to type my question
22:36:29 <JeffH> hannes: how do you support the ISO25747 in fido context?
22:37:31 <JeffH> detlof: have the ISO api on top, then have generic api that can support arbitrary authn mechs below -- so doing the ISO api on top of FIDO is possible, but not the other way around
22:38:42 <dirk_balfanz> dirk_balfanz has joined #crypto
22:38:42 <JeffH> sean: there's a danger to supporting two apis together -- if the lower layer is exposed in browser -- how do we control which app can wield a given key pair -- eg with pkcs#11 how do i keep some app from doing bad things to the keys?
22:39:03 <JeffH> detlof: the JS web app wouldn't have access to the lower levels
22:39:08 <harry> q?
22:39:13 <harry> ack virginie
22:39:13 <Zakim> virginie, you wanted to proxy richard question regarding "trusted UI", (1) how is this better than HTTPS + Content Security Policy, (2) why does it require a hardware token and (3)
22:39:16 <Zakim> ... why would we not do this for the rest of the web?
22:39:32 <harry> q+ virginie
22:39:32 <virginie> To all attendees : I have provisioned a wiki page listing all questions we need to answer to move forward here : https://www.w3.org/2012/webcrypto/wiki/Workshop_webcryptonext
22:39:47 <virginie> Please do not hesitate to edit, and amend...
22:40:24 <JeffH> siva: it is clear existing impl hasn't really gotten into the web,  however, the pkcs stuff isn't what we need for the way, if we say fido way  and/or ISO is the right way,...
22:40:31 <Martin> Martin has joined #crypto
22:41:00 <JeffH> ..we need options, deployed infrastruct is out there and working for their use cases, so why can't we do both ?
22:41:14 <JeffH> hannes: if it works in a priv preserving way....
22:41:24 <Martin> Regarding the question of why trusted UI is necessary... One important reason: Secure authentication even in case of man-in-the-browser (or even deeper system-level compromise).
22:41:25 <JeffH> bhill: you can split the market that way...
22:41:51 <JeffH> siva: buy i have 17 diff cards in my pocket, they work....
22:41:52 <virginie> hum... debate starts...
22:42:01 <JeffH> bhill: but for most users that sucks!
22:42:26 <wseltzer> q+
22:42:43 <JeffH> bhill: our vision is very low, we just wanna replace username+pswd jn a priv preserving way everywhere it's used....keep it simple
22:42:49 <virginie> q-
22:42:52 <JeffH> siva: let market decide.....
22:43:48 <JeffH> bhill: we have a coalition of relying parties.....post snowden need to do uname+pswd replacement in priv-friendly manner
22:44:57 <JeffH> detlof:  scenario of leveraging cors header to control allowing some origin access to discover the available authnrs on the user device....
22:45:33 <karenlu> q+
22:45:45 <JeffH> ...this is a small extension to the cors mech -- can use the same type of mech to enforce privacy -- its almost there....
22:46:46 <JeffH> harryh: regardless of what standards etc out there, we're building on v. heterogen market -- there'll always be deployed infrastruc need to have a story for...
22:47:47 <martin_paljak> q-
22:47:58 <JeffH> ..that said, from w3c perspec, thinks is more productive to scale down and concentrate on solving particular use cases on the web -- each panelist please remark..
22:48:28 <JeffH> bhill: need to get away from using uname+pswd -- all he cares about
22:48:44 <JeffH> detlof: need to have a discovery mech, otherwise can't use keys in useful way
22:48:49 <wseltzer> q- siva
22:48:52 <wseltzer> q- harry
22:48:54 <JeffH> hannes: need api to select ?
22:49:09 <wseltzer> q-
22:49:14 <JeffH> sean: need a way to replace pswds
22:49:23 <wseltzer> ack next
22:49:59 <wseltzer> q+
22:50:49 <JeffH> phil_h: why things have failed -- costs, installation, etc -- we have oppty here to change things -- but can't throw away existing stuff 'until the replacement is "accepted" eg by the banks etc.
22:53:28 <JeffH> bhill: just arguing that "identities" should not be "credentials" -- eg keep the decoupled and separate use case spaces
22:53:46 <wseltzer> ack karenlu
22:53:46 <martin_paljak> that was a good one (previous line)
22:55:40 <JeffH> karen_lu:  so suppose b of a supports fido, i use my u2f token to login, but then the banks move to emv cards -- so to get $ i pull out my card, but also had to use my u2f token to login -- another use case, i work for govt, have a PIV cards,...
22:55:51 <tarcieri> +1 on the encrypted messaging use case
22:55:55 <JeffH> ...and need to use it with u2f
22:57:41 <JeffH> bhill -- b of a can be smart and reimagine authn and identity attribs -- eg register mobile w/fingerprint sensor (fps) with b of a, then associate emv card with it, and then that's a one-time thing and b of a knows the binding between those two things
22:59:46 <tarcieri> WebCrypto should have *some way* to support OpenPGP applets on smart cards
23:00:34 <martin_paljak> tarcieri: keystore interface should work for openpgp or piv or estonian eid.
23:00:36 <JeffH> karen_lu: if i already have the piv card should be able to leverage it
23:00:55 <martin_paljak> or heck, plain fido tokens.
23:01:03 <tarcieri> martin_paljak: what about the PIN?
23:01:13 <JeffH> wseltzer: asks panel what we can (simply) add to web to make it better
23:01:29 <JeffH> bhill: simple authn and attestation (diff use cases)
23:01:30 <martin_paljak> tarcieri: same for openpgp applets or eid applets. same problem. including pinpad readers (no pin entry) etc.
23:02:04 <JeffH> hannes: be good to keep complexity low
23:02:11 <tarcieri> the browser needs to provide some sort of PIN entry API to unlock the OpenPGP applet for message decryption
23:02:18 <rbarnes> because, as we know, browser vendors are lazy
23:02:20 <tarcieri> s/API/UI/
23:03:14 <JeffH> sean: need an api for authn that can replace uname+pswd; at same time need to support legacy apps that use say smartcards; so until they can be updated to the new stuff, need to support them
23:04:05 <Karen> Karen has joined #crypto
23:04:45 <public_screen> [break for 30 min, return at 4:30 local]
23:04:57 <public_screen> rrsagent, make minutes
23:04:57 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/10-crypto-minutes.html public_screen
23:42:38 <Rob_philpott> Rob_philpott has joined #crypto
23:45:00 <public_screen> [reconvening]
23:45:05 <public_screen> Topic: Breakouts
23:45:45 <Cathy> Cathy has joined #crypto
23:49:19 <public_screen> 1. User experience/usability
23:49:28 <public_screen> 2. FIDO tech intro & Q&A
23:49:38 <public_screen> 3. Signatures & HW keystores
23:49:48 <public_screen> 4. Trust, liability, & distribution
23:50:08 <public_screen> discuss, and report back at 5:40
23:53:08 <Karen> Karen has joined #crypto
23:53:10 <bhill2> bhill2 has joined #crypto
23:56:28 <bal> bal has joined #crypto