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

A very brief response below, marked [mp]

Thanks,

Mark 

>-----Original Message-----
>From: public-webapps-request@w3.org 
>[mailto:public-webapps-request@w3.org] On Behalf Of Hillebrand, Rainer
>Sent: 11 February 2009 08:03
>To: Marcos Caceres
>Cc: public-webapps@w3.org
>Subject: 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,
>
>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: public-webapps-request@w3.org 
>[mailto:public-webapps-request@w3.org] On Behalf Of Marcos Caceres
>Sent: Dienstag, 27. Januar 2009 11:56
>To: Priestley, Mark, VF-Group; public-webapps@w3.org
>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"
><Mark.Priestley@vodafone.com> 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.
>

[mp] As a general comment, I think this is a pretty difficult problem to address in a secure manner. IMO the most reliable way of authorising an update would be through the use of an "update signature" however, HTTPS provides a workable alternative and plain HTTP might be fine in other circumstances. For what it's worth I think that the real security issue is how the update is handled but this doesn't mean defining an "update signature" is not useful.

Received on Thursday, 12 February 2009 11:09:45 UTC