RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

Hello,

(A bit like a rant, but the conclusions might make sense)

This describes a more exact technical proposal I could imagine using *to get the job done*, but has some deficiencies that are obvious to me personally, as I'm a not a smart card vendor nor a global platform associate but a developer with practical low level smart card background and higher level web applications that make use of keys on smart cards, via current plugin hacks.

1. It is not OK from openness perspective to have - yet another - "central registry", together with the bureaucracy, risks, costs etc, for "applications and owners" and a fixed matching of what/how you are allowed to talk to some application on your card. If there are limitations, those better be enforced and controlled by sound cryptographic protocols over the open and free pipe rather than organizational limitations of guarding the "pipe" and if there are "recommendation and discovery services" that can benefit either the user or developer, they shall emerge. "Rent-seeking activities" was a phrase used several times at Mountain View meeting and avoiding such possibilities really is important for the open web platform.

2. The way I understood previous discussions about WebCrypto on mailing list, bugzillas etc, the focus is/was on working with what is available and implemented right now. This means what is supported by the browsers, platforms and their internal API-s, described in RFC-s, and the related algorithms for example (thus no 25519 yet). None of the browsers currently "speaks APDU-s" to my knowledge (and I do think they should not). While the quite extensive layering above current desktop hardware and platform keystore abstractions might be too fat and could make use of modern, fresh optimizations with direct implementation of some layers in the browser, making a shortcut from the browser level to a smart card "APDU-ish" layer contradicts the current focus and should be a subject for a set of different discussions and workgroups.

3. WebCrypto is about cryptography "as we currently know it". Keys, ciphers etc. Making an APDU shortcut is "necessary plumbing for a 20 year old technology" that is understandable from vendor stakeholders point of view as it is the lowest common denominator for them, so to say. All smart cards or similar devices speak APDU-s in some form, so if we make an abstract way to discover and talk to those devices/services in APDU language, we finally build a bridge between smart cards and the web, which is very OK from smart card vendor perspective. Of course having this would be better than nothing, but I just can't see this implemented in the context of *WebCrypto*.

As this has nothing to do with cryptography! It also means that application developers - who are not smart card developers, but want to *use keys* - suddenly have to deal more than they want with archaic APDU scripts, which by nature is a traditional driver issue. Having been an OpenSC developer (that includes drivers of different capabilities and quality for some 30 or so different PKI-ish smart cards or on-card applications) I know quite well what it means *in practical terms* to shift around the "responsibility to have a driver" in convenient ways. I don't want to see the "driver hell" happen on the web as well. While the "central authority" of appid->js mapping would remedy, it would create a SPOF and as described  1., would contradict the goals of the open web.

I've said this before, and repeat once again:

The truth is, nobody outside of the smart card industry really cares about APDU-s, the same way nobody cares about direct IP capabilities because there exists a fancy new protocol that might one day replace TCP - except those network gear manufacturers and hardcore network administrators. "Lets make a scriptable IP layer interface into browsers so that those network gear vendors could speak their new protocol to their network boxes" really doesn't concern me as a user or as a casual ignorant application developer, when the only thing I want is to open a data stream between host A and B. The maximum I'd be willing to change would be the protocol parameter to the "openSocket(B, protocol)" method, not the IP layer.

Smart card industry has had 15+ years of time to learn to cope with and to circumvent the quirks of browsers when bridging smart cards with web apps *in the desktop browser context* via java applets and browser plugins. But plugins are being phased out by browsers and the knowledge gathered previously is worth nothing on mobile platform, as this new and important platform is not similar to the desktop ones the sector has known to love and hate.

To make it really simple: what the industry - and users! - needs might not be a cleverly designed webcrypto  2.0 capable of talking to smart cards at all, but *some* agreed upon method of bridging the archaic and often close to hardware based world to browsers without plugins and also on mobile platforms. Preferably in sync with WebCrypto, with a similar API and developer experience etc. But if that's not possible, we can work with other options as well. But we need *something*, *right now*, *for the existing billion*. Something as universal as NPAPI - which either all relevant browsers support or not support.


4. Conclusion:
The way I see it, there are at least 4 different options:

 - Option 0: we declare the problem as non-solvable/"not relevant for the web"/too difficult and nothing changes. Users (maybe 1billion is exaggerated, but certainly tens of millions) would suffer and this is not OK.
 - Option 1: we stick to current abstractions in WebCrypto and go through existing platform key/certstore capabilities, the same way as client certificate authentication is used on desktop (except by Mozilla). Needs to solve the origin policy on a consistent way and would be fit for a "WebCrypto 2.0" target. Proposal by Microsoft is a very good example of very practical API improvements in this direction and I stand behind that. I think we should work in this direction for WebCrypto 2.0.
 - Option 2: a new workgroup is created with a specific goal of bridging "APDU speaking things" into the web. Falls into the same are as permissions and webcams/mics/gps/etc. If the solution shall introduce a "javascript driver problem" (as described in current proposal) shall be for the workgroup to figure out. My personal opinion would be NO for the "driver thing", create a functional  pipe and let the developers figure out the best way forward.
 - Option 3: a new workgroup is crated or existing ones amended with efforts of bridging native applications with specific purposes to the web, and the smart card / pki sector agrees upon a framework or specification on how to build upon that. Something along the lines of webpki.org/papers/web2native-bridge.pdf. As said before, a "trusted" or "expected" user interface is part of the use cases, so keeping the "driver problem" to the platform (app store downloadable components, components distributed with other platform drivers/installers etc). While at it, if the browser vendor happens to own a mobile platform, please consider technical capabilities for initiating client authenticated sessions with keys and certificates from for example NFC enabled PKI-capable card.
 

Thanks,

Martin Paljak
Estonian Information System Authority
Cyber Security Branch
Chief R&D specialist
 

________________________________________
From: Harry Halpin [hhalpin@w3.org]
Sent: Friday, January 30, 2015 00:52
To: Lu HongQian Karen; GALINDO Virginie; public-webcrypto@w3.org
Cc: public-web-security@w3.org; Wendy Seltzer
Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto  contribution

Thanks for the contribution! The W3C has begun an internal review and
will be back in touch shortly with more specific information, including
questions.

   cheers,
       harry


On 01/28/2015 07:01 PM, Lu HongQian Karen wrote:
> Please review Gemalto's contribution. We welcome your comments.
>
> Regards,
> Karen
>
> From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com]
> Sent: Wednesday, January 07, 2015 3:48 AM
> To: public-webcrypto@w3.org
> Cc: public-web-security@w3.org; Wendy Seltzer; Harry Halpin
> Subject: [W3C Web Crypto WG] Rechartering discussion
>
> Dear all,
>
> Web Crypto WG charter [1] will end by the end of March. We need to prepare the next charter of Web Crypto.
>
> As a reminder, the conversation has started on this page :   https://www.w3..org/Security/wiki/IG/webcryptonext_draft_charter
> Feel free to add you ideas and suggestions on the wiki and/or expose your opinion and question on the public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> or public-webcrypto-comment@w3.org<mailto:public-webcrypto-comment@w3.org> (for non W3C Web Crypto WG members).
>
> Regards,
> Virginie
>
> [1] http://www.w3.org/2011/11/webcryptography-charter.html
>
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
> ________________________________
> This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus
>

Received on Friday, 30 January 2015 18:19:49 UTC