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

[Frederick Hirsch]

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

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

[Marcos Caceres]

Hi Art,

On 4/13/09 1:03 PM, Arthur Barstow 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
 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.


Ok, I see the confusion here. It should really have said,

"If a user agent implements [Widgets-Digsig], then it MUST ..."

Implementing [Widgets-DigSig] is always optional. We have similar weak 
dependencies for  and A&E, as well as another weak 
dependency on [Widgets-DigSig] in Step 4... So, I guess they are not 
really "dependencies", more like specified conditions in the presence of 
an implementation of particular specifications.





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.


True.


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


Agreed.


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.


Please see Mark's emails[1][2]. He outlined the problem pretty clearly 
and use cases for the author accessing the signature have not been 
presented.


Kind regards,
Marcos

[1]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0018.html
[2]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0466.html

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

[Arthur Barstow]

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

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

[Marcos Caceres]

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
 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. A user agent MUST 
NOT allow read access to any digital signature in the widget package at 
runtime. 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.


Kind regards,
Marcos

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

[Arthur Barstow]

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

-Thanks, Art Barstow

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

[Marcos Caceres]

On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group
 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.

Kind regards,
Marcos

>>-Original Message-
>>From: Arthur Barstow [mailto:art.bars...@nokia.com]
>>Sent: 07 April 2009 21:57
>>To: Priestley, Mark, VF-Group
>>Cc: Hirsch Frederick (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]
>>
> - Show quoted text -
>>On Apr 2, 2009, at 6:01 PM, ext Priestley, Mark, VF-Group wrote:
>>
>>> 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.
>>
>>Since Frederick's use cases [1] didn't convince you, what specific
>>change(s) do you think is needed in the Widgets DigSig spec?
>>
>>Defining an API in this spec doesn't seem like a good approach.
>>
>>-Regards, Art Barstow
>>
>>[1] <http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
>>0017.html>
>>
>>
>>
>
>



-- 
Marcos Caceres
http://datadriven.com.au

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

[Priestley, Mark, VF-Group]

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.

Thanks,

Mark


>-Original Message-
>From: Arthur Barstow [mailto:art.bars...@nokia.com] 
>Sent: 07 April 2009 21:57
>To: Priestley, Mark, VF-Group
>Cc: Hirsch Frederick (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]
>
>On Apr 2, 2009, at 6:01 PM, ext Priestley, Mark, VF-Group wrote:
>
>> 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.
>
>Since Frederick's use cases [1] didn't convince you, what specific
>change(s) do you think is needed in the Widgets DigSig spec?
>
>Defining an API in this spec doesn't seem like a good approach.
>
>-Regards, Art Barstow
>
>[1] <http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
>0017.html>
>
>
>

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

[Arthur Barstow]

On Apr 2, 2009, at 6:01 PM, ext Priestley, Mark, VF-Group wrote:


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.


Since Frederick's use cases [1] didn't convince you, what specific  
change(s) do you think is needed in the Widgets DigSig spec?


Defining an API in this spec doesn't seem like a good approach.

-Regards, Art Barstow

[1] 

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

[Priestley, Mark, VF-Group]

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.hir...@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.bars...@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 re

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

[Frederick Hirsch]

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

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

[Priestley, Mark, VF-Group]

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

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

[Arthur Barstow]

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:


 


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.