+1
I do not understand the attack, but can envision cases where
precluding access could cause problems. Examples might be user "see
what is signed" or access to signature properties.
Is this an access control issue rather than a general specification
rule?
regards, Frederick
Frederick Hirsch
Nokia
On Apr 13, 2009, at 7:03 AM, Barstow Art (Nokia-CIC/Boston) wrote:
On Apr 9, 2009, at 1:44 PM, ext Marcos Caceres wrote:
On 4/9/09 3:56 PM, Arthur Barstow wrote:
On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote:
On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
<mark.priest...@vodafone.com> wrote:
Hi Art, All,
If there is no use case for accessing this information (I was
after why
you would want to access this information because I think just
saying it
might be interesting to do so isn't justification enough), then
I think
my original proposal holds - make the signature files
unavailable to the
widget at runtime.
For clarification I was not suggesting that an API should be
added to
the DigSig spec but rather that some of the information could be
exposed
via an API defined in the APIs and Events spec. But I don't
think this
is necessary or worth the additional specification effort.
FWIW, I agree with Mark.
Please propose text that will address your concerns.
In the P&C spec, I would add something like:
"A user agent MUST make the digital signature available only to
implementations of the [Widgets-DigSig] specification.
I don't understand why we would want to create this type for a P&C UA.
A user agent MUST
NOT allow read access to any digital signature in the widget
package at
runtime.
I think this conflates requirements for a P&C UA with the
requirements for Widget [Runtime] UA. As such, I disagree with what
you are trying to prescribe here and think the specs should remain
silent on this (or perhaps defer this to a definition of a Widgets UA
runtime model).
I still cannot understand why you want to preclude a widget from
being able to access *all* of its resources. Perhaps it would be
helpful if you would elaborate on the risk(s) you are trying to
mitigate.
-Regards, Art Barstow
In other words, a user agent MUST NOT allow a start file, or
any other file or resource inside or outside the context of the
widget
(e.g., a script or stylesheet), or API, or feature, to read any
digital
signature file within the widget package. At runtime, a user agent
MUST
make it seem as if digital signatures do not exist in the widget
package
by, for example, excluding them from any file listings, and not
allowing
them to be accessed via a URI."
That's just some quick draft text, please feel free to change, add,
or
whatever.
