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:[email protected]]
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.
