On 2013-02-15 06:38, Martin Paljak wrote: > Hello, > > On Thu, Feb 14, 2013 at 5:48 PM, David Dahl <dd...@mozilla.com> wrote: >> I do understand the frustration you must feel in trying to get browsers > to work closely with your national ID/Cert system. There are many such > systems, and trying to create an API that works with your specific > requirements, hardware and regulations is very difficult. The WG notes > this by placing such efforts in the WG's "secondary features". > This is a shame, but it is also a bit of realism as getting caught up > in multiple varying national schemes may have stunted progress on a more > generic API, which I feel is a first priority. > > > Given that I'm a citizen of a country that has a national ID system > and I've also had to/tried to make browsers (including Firefox) work > closely with it, I'd like to ask this controversial question: > > Maybe creating a "PKCS#11 for javascript" will not fix anything, > except create a new fantastic attack vector and source for mitm/timing > attacks? Maybe analyzing the higher level implementations would > actually reveal requirements (legal and operational), when catered for > would actually benefit a fair amount of users? Given that usecases of > a citizen don't differ that much from average corporate users, the > work would most probably be useful to two important groups: corporate > users and "average home users".
Hi Martin, As far as I can tell, the current Web Crypto API doesn't address national eID-cards at all. IMO, the most workable (security + privacy + usability) solution for such support requires dropping arcane stuff like PKCS #11 and NSS and turning to more current security-architectures, like the one powering the Google Wallet, where the security-resource itself declares which applications are allowed to access it. By doing that you don't get separate tracks for "apps" and the web and you will also be able to provision and manage security-resources through unified mechanisms. This obviously requires signed application-code and that the "crypto API" runs as a part of the OS or in a specific TEE (Trusted Execution Environment). Anders > > The fact that in browser world only Firefox depends on PKCS#11 and > thus lags behind in features and interoperability on platforms where > more useful and serious API-s are present is a sign that *maybe* > PKCS#11 really is just a low level plumbing API for scenarios where > plumbing matters (maybe HSMs, but deficiencies and proprietary > solutions are not su uncommon there as well). > > In fact, I think that the most ambiguous standards/specifications I've > worked with are PKCS#11 (where most "interesting" things are left out > of the scope) and ISO7816 and friends, where most is optional and > choices to choose from are plenty. > > Users choose a working tap over interoperable plumbing elements. Maybe > trying to design a tap instead of plumbing joints would be a better > idea. I think that plumbers would also like it. > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
