Re: Charter Proposal: "Trusted Code" for the Web

On 2015-03-30 16:19, Martin Paljak wrote:
> Hello,
>
> I very much like what Anders has writtendown, the focus is much more
> clear this time and I find this the best way forward, for now,
> especially for "legacy" solutions that don't want to follow the "cloud"
> buzzword or have requirements different from "designed for web".

Thanx Martin,

I think there are parallel universes interacting here...

There's a bunch of folks who insist that DUPLICATING all the goodies of the
native OSes into the "Open Web" is the way ahead despite the fact that it has
proved to be virtually impossible.

Then there's Google who claims the following regarding extensions based on
interactions with "localhost":
https://code.google.com/p/chromium/issues/detail?id=378566#c78
"we are committed to finding a long-term solution that is viable for valid use cases"

This work is not performed (or even discussed), in any SDO and the definition of
valid use cases is up to anybody's interpretation.

I'm personally in favor of building on Chrome's Native Messaging although Google
want to cut off that as well.

Therefore we just have to wait......................................
Well, forking Chrome is of course another possibility.

Cheers,
Anders
Native Messaging using NFC/Bluetooth:
https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf

>
> For smart card and "hardware crypto", we could all build upon a
> standardized communication mechanism(s) and just define our API with
> necessary granularity on top of it.
>
> To draw a parallel: what we need here is a "PKCS#11 specification"
> supported by browsers, not "TSL specification with implementation and
> support for PKCS#11". But we're of course not talking ONLY about
> cryptography, the same interface or messaging solution could be used for
> whatever other purposes.
>
> On 18/03/15 16:55, Anders Rundgren wrote:
>> There are currently at least four (!) entirely different ways to invoke
>> "trusted code" so I guess
>> the first step would be to characterize them so that it gets easier to
>> select which one to go with.
>>
>> The existing schemes are:
>> - Custom protocol handlers.  Primarily used on Android and iOS.  GitHub
>> also uses it on Windows
>> - Local web services on 127.0.01.  Used by lots of services, from
>> Spotify to digital signatures
>> - Browser plugins NAPAP/ActiveX.  Used (for example) by 25M people in
>> Korea but is now being deprecated
>> - Chrome native messaging.  Fairly recent solution which enables Native
>> <=> Web messaging
>
> You forgot Java, which is still an important solution in some countries,
> while practically a technology forgotten for good.
>
>>
>> There may of course be a new scheme as well.
>>
>> The end-result should be a deliverable that describes interfaces and
>> deployment recommendations.
>> The goal is that the deliverable eventually should be a standard feature
>> in browsers.
>
> We drafted an "API" (so small it is hard to claim it an API) that deals
> with the semantics of online signatures with smart cards, boringly named
> "hwcrypto.js". This "fixes" things for us by allowing to use with the
> help of a single JavaScript library different integration methods on
> different platforms, TODAY.
>
> For the technical implementations for this specific task (signing on the
> web) we gathered from the vicinity of Estonia almost all four
> implementations (except url handlers), which shows that not only they
> exist in theory, but have been created by people in (desperate) need.
>
> What is important at this stage, IMHO, is separating the goal (usage of
> smart cards on the web) from the machinery.
>
> It seems obvious to me that browser vendors are not interested in
> building some sort of APDU or transport or card-knowledge into their
> products, which is something I totally agree with.
>
> I think the right focus would be that how to allow native 3rd party code
> to interact with browser experiences in a safe and recommended way,
> instead of NPAPI, on all platforms.
>
> Together with recommendations for best results (security, UX, etc) this
> could be a nice way to fix many things that don't fall into the limits
> of current web browser capabilities.
>
> Here's a link to the "hardware cryptography. certificate based API"
> effort, again:
>
> https://github.com/open-eid/hwcrypto.js#hwcryptojs
>
>
> Regarding the "web to native" initiative, how could we proceed on this
> one? Anders, could we set up an unofficial work group to draft initial
> ideas? Who would be interested in joining?
>
> Best,
>
> Martin Paljak
> Chief specialist, R&D
> Estonian Information System Authority
>

Received on Tuesday, 14 April 2015 06:40:38 UTC