Subject: Re: [jose] Charter Proposal: "Trusted Code" for the Web

From: Samuel Erdtman <[email-masked]>
Date: Sat, 11 Apr 2015 12:03:45 +0200

Hi,

I think this could be interesting, don´t know if a standards for this
should be written under IETF or somewhere else, but I can share a few use
cases we have at neXus where we need to use platform specific capabilities.
And a bit on how we currently solve it.

* Smart Card signatures
In e.g bank transactions signatures are desired. We develop a middleware
with this support (has been used for the Swedish eID for many years), we
have historically created plugins to the comunication between the browser
and the middleware. But as NPAPI is going away we have now created a new
architecture that relies on server component that makes it possible to open
up a communication channel between the browser and the middleware.

* RFID coding
This is kind of like printing, when creating cards for physical access
systems (PACS) some data has to be coded in the card or read from it as it
is printed (Mifare Desfire etc.), for this we have a SDK/application that
runs locally but the card management system runs in the browser. The
communication is currently done with a socket connection to localhost, it
works well but has some clear drawbacks e.g. TLS.

* Signature pad
* Fingerprint recording
* Document scanning
When doing identity management we collect data about the user when
enrolling. Once again it is not possible to collect all this data from a
browser i.e. we need something running locally, and we need to communicate
with it. Currently we do a connection to localhost.

* End point integrity
We have a client application that is loaded to validate that that platform
(OS, antivirus etc.) is updated before allowing the user to connect to the
corporate network. And when the user is logged out it helps the user to
clean upp downloaded files so that sensitive data gets minimal exposure.
(this solution relies on java applet and activeX)

All of these use cases would benefit form a standardised way of
communicating from the web browser (JavaScript) with a locally installed
application.

Best Regards
Samuel Erdtman

On Fri, Mar 20, 2015 at 8:30 AM, Hannes Tschofenig <
[email-masked]> wrote:

> I like the proposal Anders put forward.
> Doing some work in the IETF in that area might not be a bad idea to
> stimulate discussions.
>
> Ciao
> Hannes
>
>
> On 03/20/2015 06:49 AM, Anders Rundgren wrote:
> > On 2015-03-19 19:15, John Bradley wrote:
> >> It sounds like WebCrypto or something more related to it.
> >> http://www.w3.org/2012/webcrypto/
> >
> > I would rather characterize this as the opposite to WebCrypto since the
> > referred schemes
> > all are based on the idea that "The Web is not enough".
> >
> > That is, the Web needs (as proven any number of times), to be extended
> > with its more
> > powerful native/platform companion for a lot of reasons including access
> > to platform-
> > resident keys as well as breaking away from the crippling SOP notion.
> >
> > The W3C does not appear to be a suitable home for such an effort, they
> > rather prefer
> > continuing the so far pretty unsuccessful efforts DUPLICATING the native
> > level into
> > the Web [1], instead of recognizing the power of COMBINING these worlds.
> >
> > Cheers,
> > Anders
> >
> > 1] https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/0000.html
> >
> >>
> >>
> >>> On Mar 19, 2015, at 3:05 PM, Jim Schaad <[email-masked]
> >>> <mailto:[email-masked]>> wrote:
> >>>
> >>> To me this sounds more like a W3C activity than an IETF activity.
> >>> Jim
> >>> *From:*jose [mailto:[email-masked]]*On Behalf Of*Anders
> Rundgren
> >>> *Sent:*Wednesday, March 18, 2015 10:41 PM
> >>> *To:[email-masked] <mailto:[email-masked]>
> >>> *Subject:*[jose] Charter Proposal: "Trusted Code" for the Web
> >>> Trusted Code for the Web
> >>>
> >>>
> >>> Existing security-related applications like authentication, payments,
> >>> etc. are all based on that a core-part is executed by statically
> >>> installed software that is supposed to be TRUSTED.
> >>>
> >>> Since web-based applications are transiently downloaded, unsigned and
> >>> come from any number of more or less unknown sources, such
> >>> applications are by definition UNTRUSTED.
> >>>
> >>> To compensate for this, web-based security applications currently
> >>> rely on a hodge-podge of non-standard methods [1] where trusted code
> >>> resides (and executes) somewhere outside of the actual web application.
> >>>
> >>> However, because each browser-vendor have their own idea on what is
> >>> secure and useful [2], interoperability has proven to be a major
> >>> hassle.  In addition, the ongoing quest for locking down browsers (in
> >>> order to make them more secure), tends to break applications after
> >>> browser updates.
> >>>
> >>> Although security applications are interesting, they haven't proved
> >>> to be a driver.  Fortunately it has turned out that the desired
> >>> capability ("Trusted Code"), is also used by massively popular music
> >>> streaming services, cloud-based storage systems, on-line gaming sites
> >>> and open source collaboration networks.
> >>>
> >>> The goal for the proposed effort would be to define a vendor- and
> >>> device-neutral solution for dealing with trusted code on the Web.
> >>>
> >>>
> >>> *References
> >>> *
> >>> 1] An non-exhaustive list include:
> >>> - Custom protocol handlers.  Primarily used on Android and iOS.
> >>> GitHub also uses it on Windows
> >>> - Local web services on 127.0.0.1.  Used by lots of services, from
> >>> Spotify to digital signatures
> >>> - Browser plugins like NPAPI/ActiveX.  Used (for example) by millions
> >>> of people in Korea for PKI support but is now being deprecated
> >>> - Chrome native messaging.  Fairly recent solution which enables
> >>> Native <=> Web communication
> >>>
> >>> 2]https://code.google.com/p/chromium/issues/detail?id=378566
> >>>
> >>> _______________________________________________
> >>> jose mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/jose
> >>
> >
> > _______________________________________________
> > jose mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/jose
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 14 Apr 2015 12:20:52 +0900

I think this is an interesting idea.
One of the disappointment of webcrypto, if I am not mistaken, is that they
confined themselves too narrowly that it did not define the APIs that can
leverage, for example, a secure element.
If a discussion here at IETF would stimulate the discussion there as well,
it would benefit the community, IMHO.

Nat

2015-04-11 19:03 GMT+09:00 Samuel Erdtman <[email-masked]>:

>> > 1]
>> https://lists.w3.org/Archives/Public/public-sysapps/2014Dec/0000.html
>> >
>> >>
>> >>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 14 Apr 2015 07:36:58 +0200

On 2015-04-14 05:20, Nat Sakimura wrote:
> One of the disappointment of webcrypto, if I am not mistaken, is that they confined themselves
 > too narrowly that it did not define the APIs that can leverage, for example, a secure element.

There are many ways of expressing why it didn't work out as anticipated. IMO, if existing
applications had been "decomposed", it had been more obvious that they work because they
don't expose sensitive cryptographic APIs to arbitrary Web code.  I.e. there's a reason why
we after 20 years with secure payment cards still can't use them on the Web!

I'm thinking about a system where locally "Trusted Applications" are "talking" with
untrusted Web pages:
https://cyberphone.github.io/openkeystore/resources/docs/web2native-bridge.pdf
A predecessor is already available in the Chrome browser.

It turned out that the very same concept could probably also be applied to devices
connected with NFC/Bluetooth:
https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf

Anders

> If a discussion here at IETF would stimulate the discussion there as well, it would benefit the community, IMHO.
>
> Nat
>
> 2015-04-11 19:03 GMT+09:00 Samuel Erdtman <[email-masked] <mailto:[email-masked]>>:
>
>     Hi,
>
>     I think this could be interesting, don´t know if a standards for this should be written under IETF or somewhere else, but I can share a few use cases we have at neXus where we need to use platform specific capabilities. And a bit on how we currently solve it.
>
>     * Smart Card signatures
>     In e.g bank transactions signatures are desired. We develop a middleware with this support (has been used for the Swedish eID for many years), we have historically created plugins to the comunication between the browser and the middleware. But as NPAPI is going away we have now created a new architecture that relies on server component that makes it possible to open up a communication channel between the browser and the middleware.
>
>     * RFID coding
>     This is kind of like printing, when creating cards for physical access systems (PACS) some data has to be coded in the card or read from it as it is printed (Mifare Desfire etc.), for this we have a SDK/application that runs locally but the card management system runs in the browser. The communication is currently done with a socket connection to localhost, it works well but has some clear drawbacks e.g. TLS.
>
>     * Signature pad
>     * Fingerprint recording
>     * Document scanning
>     When doing identity management we collect data about the user when enrolling. Once again it is not possible to collect all this data from a browser i.e. we need something running locally, and we need to communicate with it. Currently we do a connection to localhost.
>
>     * End point integrity
>     We have a client application that is loaded to validate that that platform (OS, antivirus etc.) is updated before allowing the user to connect to the corporate network. And when the user is logged out it helps the user to clean upp downloaded files so that sensitive data gets minimal exposure. (this solution relies on java applet and activeX)
>
>     All of these use cases would benefit form a standardised way of communicating from the web browser (JavaScript) with a locally installed application.
>
>     Best Regards
>     Samuel Erdtman
>
>
>
>
>     On Fri, Mar 20, 2015 at 8:30 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>
>          >>> On Mar 19, 2015, at 3:05 PM, Jim Schaad <[email-masked] <mailto:[email-masked]>
>          >>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          >>>
>          >>> *From:*jose [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf Of*Anders Rundgren
>          >>> *To:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>          >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 14 Apr 2015 09:17:09 -0400

Sent from my iPhone

> On Apr 14, 2015, at 1:36 AM, Anders Rundgren <[email-masked]> wrote:
> 

This is similar to what NEA and SACM are working on, but their definition of end point is not scoped to just a browser or application.  For this interested in this question, please take a look at SACM and proposed solutions can be reviewed there.  They have an open call for proposals and recognize that different solutions will be needed depending on re platform being assessed.

Best regards,
Kathleen

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 16 Apr 2015 02:16:32 +0900

Thanks. I will have a look at.

Cheers,

Nat

2015-04-14 22:17 GMT+09:00 Kathleen Moriarty <
[email-masked]>:

> >> If a discussion here at IETF would stimulate the discussion there as
> well, it would benefit the community, IMHO.
> >>
> >> Nat
> >>
> >>    I think this could be interesting, don´t know if a standards for
> this should be written under IETF or somewhere else, but I can share a few
> use cases we have at neXus where we need to use platform specific
> capabilities. And a bit on how we currently solve it.
> >>
> >>    * Smart Card signatures
> >>    In e.g bank transactions signatures are desired. We develop a
> middleware with this support (has been used for the Swedish eID for many
> years), we have historically created plugins to the comunication between
> the browser and the middleware. But as NPAPI is going away we have now
> created a new architecture that relies on server component that makes it
> possible to open up a communication channel between the browser and the
> middleware.
> >>
> >>    * RFID coding
> >>    This is kind of like printing, when creating cards for physical
> access systems (PACS) some data has to be coded in the card or read from it
> as it is printed (Mifare Desfire etc.), for this we have a SDK/application
> that runs locally but the card management system runs in the browser. The
> >>    We have a client application that is loaded to validate that that
> platform (OS, antivirus etc.) is updated before allowing the user to
> connect to the corporate network. And when the user is logged out it helps
> the user to clean upp downloaded files so that sensitive data gets minimal
> exposure. (this solution relies on java applet and activeX)
> >>
>
> This is similar to what NEA and SACM are working on, but their definition
> of end point is not scoped to just a browser or application.  For this
> interested in this question, please take a look at SACM and proposed
> solutions can be reviewed there.  They have an open call for proposals and
> recognize that different solutions will be needed depending on re platform
> being assessed.
>
> Best regards,
> Kathleen
>
> [email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>         >>> On Mar 19, 2015, at 3:05 PM, Jim Schaad <
> [email-masked] <mailto:[email-masked]>
> >>         >>> *From:*jose [mailto:[email-masked] <mailto:
> [email-masked]>]*On Behalf Of*Anders Rundgren
> >>         >>> 2]
> https://code.google.com/p/chromium/issues/detail?id=378566
> >>         >>>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 17 Apr 2015 08:33:42 +0200

On 2015-04-14 15:17, Kathleen Moriarty wrote:

Kathleen,

This feature (the ability to communicate to the "native" layer from a Web-page),
is currently used by thousands of different applications including remote diagnostics
by major PC-vendors.

The browser vendors took the decision to remove support for ActiveX and NPAPI
but never considered a replacement.

I wouldn't try to mix this with any other "security project" because the Web is
pretty unique: Untrusted code is transiently downloaded into the client platform.

Anders

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 17 Apr 2015 08:59:31 -0400

Anders,

On Fri, Apr 17, 2015 at 2:33 AM, Anders Rundgren <
[email-masked]> wrote:

> I wouldn't try to mix this with any other "security project"

SAMC and NEA are IETF working groups, not a little project off somewhere.
NEA is closed, but SACM is accepting proposals for end point assessment.
Your endpoint could be a web server.  The work doesn't have to stay in
SACM, but I think that's a better starting point.

If you have a proposed solution for this scoped to detection of untrusted
code in web transactions, I'm just saying that it is a better fit than JOSE
for that work (which I hope to close soon).  I'm fully aware of the
problems with untrusted code, malware, etc. being downloaded to end users
through firewalls, etc.  Current solutions are proxy firewalls that block
access to domains, URLs, and IPs that have been found to be problematic
(threat discovered).  It would be nice to have something that worked
end-to-end.

See the use cases Samuel shared, especially the last one, but a few of the
other ones have enough similarities to SACM for that to be a starting
point.  I'm specifically avoiding the webcrypto use cases, which may be of
more interest to you.

Kathleen

> because the Web is

-- 

Best regards,
Kathleen

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 17 Apr 2015 15:58:25 +0200

On 2015-04-17 14:59, Kathleen Moriarty wrote:
> Anders,
>
> On Fri, Apr 17, 2015 at 2:33 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>
 > Your endpoint could be a web server.  The work doesn't have to stay in SACM, but I think that's a better starting point.
> If you have a proposed solution for this scoped to detection of untrusted code in web transactions,

This may sound awfully strange but the proposed scheme doesn't detect untrusted code.
It is simply a way to let a locally trusted sub-system talk with (and through), potentially
malicious web-code while shielding the platform and user from various attacks.

As you may know "Secure AND Convenient Web Payments" have effectively gone *backward*
since we began using credit-cards on the Web some 20 years ago.

If you do a search you will probably not find a single paper from any major vendors' R&D
department dealing with this topic either.  It is obviously "The stepchild of the Web" :-)

 > I'm just saying that it is a better fit than JOSE for that work (which I hope to close soon).

That OK, I justed wanted to see if there where any folks out there that also could
consider dealing with awkward and "forgotten" problems.

 > I'm fully aware of the problems with untrusted code, malware, etc. being downloaded to end users
 > through firewalls, etc.  Current solutions are proxy firewalls that block access to domains, URLs,
 > and IPs that have been found to be problematic (threat discovered).
 > It would be nice to have something that worked end-to-end.

The locally trusted applications and their associates in the other end deal with E2ES but
in a completely application-specific manner.  This may seem a bit short-sighted but the
needs are quite different so it is not possible doing otherwise: A payment protocol
shouldn't leak user data to the RP (merchant), while authentication is about
establishing an authenticated user ID.

Anyway, thanx for the comments!

Anders

>
> See the use cases Samuel shared, especially the last one, but a few of the other ones have enough similarities to SACM for that to be a starting point.  I'm specifically avoiding the webcrypto use cases, which may be of more interest to you.
>
> Kathleen
>
>     because the Web is
>             On Apr 14, 2015, at 1:36 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 2015-04-11 19:03 GMT+09:00 Samuel Erdtman <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>:
>
>                      Hi,
>
>                      On Fri, Mar 20, 2015 at 8:30 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                           >>> On Mar 19, 2015, at 3:05 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>                           >>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>                           >>>
>                           >>> *From:*jose [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>]*On Behalf Of*Anders Rundgren
>                           >>> *To:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>                           >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 22 Apr 2015 12:18:29 +0100

Hi All,
I apologize in advance for the off-topic post but I've seen links to 
other implementations before so I thought I'd share a link to a 
presentation I did at Apache Con NA last week about the JOSE 
implementation [1] of Apache CXF [2] project. The actual presentation's 
content is actually 80% about pure JOSE.

I'd like to thank:
- Brian Campbell for creating Jose4J - I used it to debug an RSA-OAEP 
and EC tests in order to understand why my tests do not work; I also 
wanted to make sure CXF users can use Jose4J if preferred.

- Anders Rundgren for creating a nice demo [3] showing a JWS 
interoperability in action between a WebCrypto client and a JWS-aware 
HTTP server and helping me to get started with it and having a JWS demo 
option even though a very nice JCS style is also shown :-).

- Cologne University team for their expert review which helped to 
modularize/package the implementation better.

In [1] I also referred to the following Java based Apache licensed 
projects (I can not refer to other non-ASF licensed projects at Apache Con):

Jose4J
Apache Oltu
RestEasy
Spring Security

I should've also linked to
http://connect2id.com/products/nimbus-jose-jwt

I will update the slides with this link and be happy to add more links.

If anyone is interested to chat about Apache CXF + JOSE - please send me 
a private email or subscribe to the CXF users list.

Sorry for the noise :-)

Thanks, Sergey

[1] 
http://events.linuxfoundation.org/sites/events/files/slides/ACNA15JoseCxf.pdf
[2] http://cxf.apache.org/
[3] https://mobilepki.org/WCPPSignatureDemo/home