RE: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property

Hi Marcos,

I am not aware of any feedback on your e-mail. Here is mine.

Best Regards,

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

+49 171 5211056 (My T-Mobile)
+49 228 936 13916 (Tel.)
+49 228 936 18406 (Fax)

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: [] On Behalf Of Marcos Caceres
Sent: Dienstag, 27. Januar 2009 11:56
To: Priestley, Mark, VF-Group;
Subject: Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property

Hi Mark,
Some minor comments below. Bar a few clarifications, I mostly agree with your proposal. 

On 1/26/09 1:35 PM, "Priestley, Mark, VF-Group"
<> wrote:

> A possible solution to this problem would be to require an updates to 
> be signed using the same private key that was used to sign the 
> previous version of the widget archive. Essentially this update 
> signature would securely link an update to an installed widget 
> resource by nature of the fact that they had both been signed by 
> someone with access to the same private key.

I'm ok with this so long as it an auxiliary feature and that updates can be performed over plain-old HTTP without requiring a certificate. If an implementer chooses to deviate from this model by disallowing updates that lack a digital signature, that is their prerogative. Irrespective, I am of the position that we must architecture the update model to work without signatures and then progressibly enhance the update model firstly through HTTPS and then through signatures.
RH: An update may not need to be signed. This depends on the original widget resource that shall be updated. An update for a widget resource should only be processed if it has the same or a higher security level than the original widget resource. For example, a signed widget resource that was installed from a memory card shall not be updated with an unsigned update package that was retrieved from a web server without SSL/TLS. On the other hand, a signed update package should update a widget resource that was retrieved from a web server without SSL/TLS.

Received on Wednesday, 11 February 2009 08:04:07 UTC