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

Dear Marcos,

I added my comments inline. 

Best Regards,

Rainer
*************************************
T-Mobile International
Terminal Technology
Rainer Hillebrand
Head of Terminal Security
Landgrabenweg 151, D-53227 Bonn
Germany

+49 171 5211056 (My T-Mobile)
+49 228 936 13916 (Tel.)
+49 228 936 18406 (Fax)
E-Mail: rainer.hillebrand@t-mobile.net

http://www.t-mobile.net

This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. 

Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck.




T-Mobile International AG
Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman)
Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender
Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276
Steuer-Nr./Tax No.: 205 / 5777/ 0518
USt.-ID./VAT Reg.No.: DE189669124
Sitz der Gesellschaft/ Corporate Headquarters: Bonn




-----Original Message----- 
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Montag, 2. März 2009 15:03
To: Hillebrand, Rainer
Cc: public-webapps
Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

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. 

RH: I will be concerned like you that a widget has access to all widget user agent resources regardless of whether:

a) it was signed and signatures were left untouched,

b) it was signed but the signatures were removed,

c) it was unsigned and transported over a secure channel,

d) it was unsigned and transported over an unprotected channel.

As long as the P&C does not specify any security mechanism that verifies the integrity and the authenticity of a widget resource and that has an influence on the access to widget user agent resources or the processing of the widget, then we have to live with this concern. Then we can only hope that WUA implementers provide their own security mechanism leading to fragmentation in this respect.

> 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.

RH: From my point of view, signing does not necessarily mean that a developer has to pay for it. On the other hand, I am aware of the note in the P&C saying "How a widget user agent uses a digital signature is determined by the security policy implemented by that widget user agent. As such, this specification does not mandate processing rules dependent on the verification of one or more digital signature documents or on the revocation status obtained for the certificates associated with a verified digital signature document."

> 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 implementers.

RH: I would recommend not to standardize a base security policy for all markets on the world. It would take too long. However, we might want to discuss for Widgets 2.0 whether we would try agreeing on a security framework defining what needs to be protected, how a security policy is defined (i.e. format, vocabulary) and how security policies could be provisioned or managed.

--
Marcos Caceres
http://datadriven.com.au

Received on Monday, 2 March 2009 14:56:54 UTC