Signed Web Code - Usage and Limitations

Hi Guys,
I would like to be in California but I'm stuck in France.
Anyway,  FWIW, here are some thoughts on Signed Web Code.

Signed code intended to give *users* a feeling of trust has proved to be useless;
it is essentially only a business for a few CAs.  Users only hit OK until the darn
thing installs, right?

However, signed code is absolutely crucial for:
1.  System updates
2.  Code that has been vetted by a third party such as required by Apple for iOS
3.  Separating/Joining apps as featured in Android

The problem with #2 is that for this to work well with web-apps (=runs everywhere)
there must (at least) be a united vetting facility as well as a recognized CA.
Although technically feasible, from a political/commercial perspective it doesn't look too promising.

#3 could be applicable for web apps to break away from SOP.  I haven't thought deep
enough here yet...

Finally, there is a specific need for signed code in the "Web SE" scheme I'm working
with.  This system departs completely from the other signature schemes since it is
the SE (or rather resources inside of it) which is the actual RP (Relying Party),
rather than the client platform.  The signature also makes the code appear as a
virtual domain shielding it from direct access by the embedding application which
doesn't have to be trusted.  I.e. embedded signed code behaves like if it was
protected by SOP even if the entire application is delivered from a single domain.

Would the scheme above apply to the W3C SE API?  Probably not because the Web SE
is based on a fundamentally different principle which in short is that the Web SE is
intended to be an integral part of the client platform regardless if it soldered onto
the platform or just connected.

The W3C SE API would IMO require options #1 or #2.

Cheers,
Anders

Received on Wednesday, 9 April 2014 03:37:26 UTC