W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 2 Mar 2009 15:02:56 +0100
Message-ID: <b21a10670903020602r7982b780pc580ed338d44ba3d@mail.gmail.com>
To: "Hillebrand, Rainer" <Rainer.Hillebrand@t-mobile.net>
Cc: public-webapps <public-webapps@w3.org>
On Mon, Mar 2, 2009 at 2:56 PM, Hillebrand, Rainer
<Rainer.Hillebrand@t-mobile.net> wrote:
> Dear Marcos,
> In order to detect a man-in-the-middle-attack, a widget resource is signed, either by an author's certificate that I trust or by an author certificate and a distributor certificate that I trust. "that I trust" means that I have the proven public keys for these certificates. If an attacker replaces or adds a file in the widget resource after it was signed then the signatures will be invalid. If the signatures are stripped off, a file is replaced or added and the widget resource is signed again with another certificate that I do not trust then the attack will fail when checking the signature.

Yes, I am only really concerned with the case whereby the signature is
removed (I'm aware that it is not possible to do any kind of
replacement or tampering of the sig). The security policy that we (Web
Apps) have been discussing would allow unsigned widgets to run with
full privileges by default. I also push for this model because I don't
think developers should have to pay for a cert to have their apps run
on a device.

> I would agree with you that a secure transport will be useful if the widget resource is unsigned or signed with an unknown certificate. Then it will be the decision of a security framework and its security policies how such a widget resource will be treated.

Agreed. A point of contention is whether we standardize a base
security policy or not. We might just leave that totally up to

Marcos Caceres
Received on Monday, 2 March 2009 14:03:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:51 UTC