- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Thu, 2 Apr 2009 17:29:25 -0400
- To: "ext Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, Web Applications Working Group WG <public-webapps@w3.org>
I think we may need to be more precise since in this context a "signature" means an xml signature structure. An XML Signature is an XML structure that includes a signature value but may also include other information such as properties recorded in the ds:Object element within the ds:Signature element. Thus access to property values may be an important reason for access. If KeyInfo includes CRL or OCSP information that may also be important. If we are concerned about integrity of the signature we should note that all important aspects should be included in the cryptographic signature value. Maybe we should rely on the security of the key and leave it at that? Apart from the risk of addition or removal of signatures noted in the security considerations section, it appears that cryptographically the signature should be protected as long as the key is secure (and of course there are no attacks available against the algorithms and so on). regards, Frederick Frederick Hirsch Nokia On Apr 2, 2009, at 5:20 PM, ext Priestley, Mark, VF-Group wrote: > Hi Art, All, > > I tracked down my original explanation with subsequent qualification > [1]. > > The problem in a nutshell is that by allowing multiple signatures, > which > is something we want to do, we create a situation in which not all > of a > signed widget's files are covered by the signature. This is fine if > the > parts that aren't signed can not be "used" by the widget. My > suggestion > was that the contents of the signature files were simply made > unavailable to the widget at runtime. To me this seemed like a > straight > forward solution to mitigating the threat. However I understand that > there have been comments that there may be cases in which a widget > might > want to read the contents of it's own signature files. > > So while I don't want to divert attention away from more important > discussions, before we close this issue I would like to hear what the > requirement is for a widget to access it's own signatures? What are > the > use cases. For example, I would like to understand whether it would be > enough for those use cases to only allow the widget access valid > signatures? > > Thanks, > > Mark > > [1] > http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ > 0466.html > > > >> -----Original Message----- >> From: Arthur Barstow [mailto:art.barstow@nokia.com] >> Sent: 05 March 2009 17:37 >> To: Priestley, Mark, VF-Group >> Cc: Web Applications Working Group WG >> Subject: Re: ISSUE-83 (digsig should not be read at runtime): >> Instantiated widget should not be able to read digital >> signature [Widgets] >> >> Mark - during the March 5 widgets voice conference we >> discussed this issue that you raised [1]. Marcos created this >> issue from the following e-mail thread: >> >> <http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ >> 0521.html> >> >> A couple of the people on the call asked for some more >> information, in particular the specific threat scenario. >> >> We would appreciate it if you would please elaborate on your concern. >> >> -Regards, Art Barstow >> >> >> On Feb 22, 2009, at 11:53 AM, ext Web Applications Working >> Group Issue Tracker wrote: >> >>> >>> ISSUE-83 (digsig should not be read at runtime): Instantiated >>> widget should not be able to read digital signature [Widgets] >>> >>> http://www.w3.org/2008/webapps/track/issues/83 >>> >>> Raised by: Mark Priestley >>> On product: Widgets >>> >>> Need to mention somewhere that the digital signature must not be >>> accessible by the start file once the widget is running. >>> >>> >>> >> >> >
Received on Thursday, 2 April 2009 21:30:18 UTC