RE: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]

Comments inline. 

FWIW my view is that if there is a valid use case for a widget being
able to access information in a signature file, either it should access
this information using an API or we should add further restrictions to
the widget digital signature format and processing.

Thanks,

Mark

>-----Original Message-----
>From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] 
>Sent: 02 April 2009 22:29
>To: Priestley, Mark, VF-Group
>Cc: Frederick Hirsch; Barstow Art (Nokia-CIC/Boston); 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]
>
>I think we may need to be more precise since in this context a 
>"signature" means an xml signature structure.
>

If this is what we mean then I agree we need to be more precise about
what wee say in the specification.
At the moment if I include a file and call it signature1.xml, it's
excluded from the validation of any other signature present. But
signature10.xml could contain anything I wanted it to.

We could say that only signatureX.xml files that contain a valid xml
signature structure should be accessible to the widget at runtime but
this means every signature file has to be validated, which is something
we've tried to avoid. Also see comments below

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

I don't see how this information could be important to the widget? To
the WUA, yes, but why would a widget that has been installed want to
check (old) CRLs and OCSP responses? I may be missing something obvious
but what is the use case? Note for this information to be valuable the
widget must also be able to determine that the signature was validated
successfully. Effectively the widget would need to implement it's own
signature processing. 

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

If we can be sure that signatureX.xml contains a valid signature
document, that helps but I believe that XML signature allows the
addition of Objects defined by the signer? If this is the case then even
a valid signature could pose a risk. 

>
>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 22:01:54 UTC