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

From: Anders Rundgren <[email-masked]>
Date: Thu, 19 Mar 2015 06:40:36 +0100

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

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 19 Mar 2015 11:05:50 -0700

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]
Subject: [jose] Charter Proposal: "Trusted Code" for the Web

Trusted Code for the Web

References

---

From: John Bradley <[email-masked]>
Date: Thu, 19 Mar 2015 15:15:19 -0300

It sounds like WebCrypto or something more related to it. http://www.w3.org/2012/webcrypto/ <http://www.w3.org/2012/webcrypto/> 

> On Mar 19, 2015, at 3:05 PM, Jim Schaad <[email-masked]> wrote:
> 
> 2] https://code.google.com/p/chromium/issues/detail?id=378566 <https://code.google.com/p/chromium/issues/detail?id=378566>
> 
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 20 Mar 2015 06:49:52 +0100

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:
>>
>> *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
>>
>>
>> *References
>> 2]https://code.google.com/p/chromium/issues/detail?id=378566
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Mar 2015 08:30:42 +0100

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:
>>> 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
>>> *
>>> - Browser plugins like NPAPI/ActiveX.  Used (for example) by millions
>>> of people in Korea for PKI support but is now being deprecated