Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
+1, I think the current Widget Signature draft reflects this point of
view with the focus on author and distributor signatures and no usage
or concern with updates specific to Widget Signature. That said, we
may wish to review the update mechanism from a security point of view,
but I don't believe that is specific to Widget Signature.
regards, Frederick
Frederick Hirsch
Nokia
On Feb 13, 2009, at 8:26 AM, ext Marcos Caceres wrote:
2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:
[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.
I agree that an update signature would be useful, but would like to
see this just be solved with HTTP and HTTPS for v1. That should cover
most use cases.
Here is my current thinking. Widget version 1 is distributed and
signed. The config looks like this:
widget version=1.0
update href=https://some.com/update?version=1.0; /
/widget
Because the widget was signed, the update href can be considered
authoritative/trusted. That securely downloads the update description
document:
widgetupdate xmlns=http://www.w3.org/ns/widgets;
src=https://example.com/myWidget/v1.1b/awesome.wgt;
version=1.1
id=http://example.com/myWidget;
size=1024
notify=https://example.com/myWidget/updateManager.php?this-v=1.1amp;was-v=
{version}
details href=http://a.com/myWidget/1.1/whatsnew;
We fixed some bugs and improved performance!
/details
/widgetupdate
The src is downloaded and treated as a normal widget package. If it is
not signed, or the signature cannot be validated, then the usual
warnings are given. If it is signed, then it is processed as normal.
Is there much wrong with the current model?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:
[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.
I agree that an update signature would be useful, but would like to
see this just be solved with HTTP and HTTPS for v1. That should cover
most use cases.
Here is my current thinking. Widget version 1 is distributed and
signed. The config looks like this:
widget version=1.0
update href=https://some.com/update?version=1.0; /
/widget
Because the widget was signed, the update href can be considered
authoritative/trusted. That securely downloads the update description
document:
widgetupdate xmlns=http://www.w3.org/ns/widgets;
src=https://example.com/myWidget/v1.1b/awesome.wgt;
version=1.1
id=http://example.com/myWidget;
size=1024
notify=https://example.com/myWidget/updateManager.php?this-v=1.1amp;was-v={version};
details href=http://a.com/myWidget/1.1/whatsnew;
We fixed some bugs and improved performance!
/details
/widgetupdate
The src is downloaded and treated as a normal widget package. If it is
not signed, or the signature cannot be validated, then the usual
warnings are given. If it is signed, then it is processed as normal.
Is there much wrong with the current model?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
RE: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
Dear Marcos, From my point of view the current model as described by you is ok. The author of the update description document and the author of the widget resource that shall be updated are able to control the security level shall be reached. This is not mandated by the widget specifications family. If somebody wants to provide an unsigned update package via HTTP for a signed widget resource then this will not be prevented by a widget user agent. 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.hillebr...@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
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-requ...@w3.org [mailto:public-webapps-requ...@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.hillebr...@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-requ...@w3.org [mailto:public-webapps-requ...@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.priest...@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.
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.hillebr...@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-requ...@w3.org [mailto:public-webapps-requ...@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.priest...@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.
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.priest...@vodafone.com wrote: Hi All, The following email aims to clarify an idea that was discussed on a couple of WebApps calls, most recently on the 8th Jan [3]. It relates to being able to re-use the digital signature format that we are defining for a range of use-cases and is linked to the definition of the usage property. Apologies in advance for the length of the email but I felt it was important to try and explain the idea fully to illustrate how a relatively small change could provide far greater flexibility in the use of the specification. --- Using Widgets 1.0: Digital Signatures --- The initial goal of the Widgets 1.0 Digital Signature specification [1] was to provide a mechanism that reliably allowed an end use to determine: (1) The identity of the distributor(s) of a widget archive; (2) The integrity of the widget package - i.e. the widget archive received by the end user is the same as the widget archive supplied by the distributor. Right... This information could by used by the end-user or the consuming widget user agent to make a decision about whether or not to install the widget and, in some cases, to inform the configuration of security policies associated to the widget (it is noted that the configuration of actual security policies is an implementation issue and out of scope of [1]). I definitely agree that security policy related stuff is out of scope for [1]. But where are we going to do this work? This comment is not directed at you, Mark, but at the working group in general. I think it would be a good idea to start parallel discussion around this issue ASAP. Architecturally, all these things are interrelated and should probably be specified together. The use of a PKI and technologies such as OCSP and CRLs could enable the revocation of a widget signature, and thereby (again, depending on the implemented security policy) the revocation of the widget itself, which could be useful in the case that it was found to malicious. Agreed. To address the case in which the same widget might be distributed by multiple parties each of whom want to sign the widget archive, [1] allows for the inclusion of multiple widget signatures in the same widget archive. Right. Recent updates to [1] have introduced the usage property and some associated semantics. I would like to propose a change to the definition of the usage element and some other relatively small changes to allow for different processing to be applied to signatures with different usage properties. This is desirable as it would allow signatures to be used for different purposes in parallel. Below I outline two possible uses of widget signatures as an illustration of how this functionality could be used. While I think the use-cases are real I am happy to discuss them in more detail if there are differing views. However, regardless of whether or not the signature uses described below are accepted and/or others are defined, I hope that they help support the need to make the reference processing dependent on the usage property. -- Distributor signatures Distributor signatures would be the signatures currently described by [1] and support the goals (1) and (2) identified above. Right. The distributor signature contains a reference element for every file in the widget archive, excluding any other signature files (identified by a reserved filename pattern). The inclusion of a reference element for every non-signature file is required to ensure that the authenticity and integrity of the entire widget archive can be verified. Right. Other distributor signatures are excluded because they are only used during the installation of the widget and have their own inherent mechanisms for ensuring integrity and authenticity. Ok, but does this not leave the possibility that non-distributor signatures (e.g. Author's signature) could be removed by an attacker. Does that matter? I am not proposing any change to the distributor signature other than: (a) The definition of a distributor usage property value (b) A change to the signature generation rules, specifically to change: Every file in a widget resource apart from any widget signature MUST have a corresponding XML Signature Reference contained in the signature, generated according to the Reference Generation section of the [XMLDSIG11] specification. To changeIf the widget signature includes the distributor usage property, /change every file in a widget resource apart from any changedistributor/change widget signatures MUST have a corresponding XML Signature Reference contained in the signature, generated according to the Reference
