Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On 3/17/09, Frederick Hirsch wrote: > Marcos > > Rather than replicating this, which might be error prone and hard to > maintain, perhaps Widget Signature should reference P & C for this. > What do you think ? > I think that should be fine. > regards, Frederick > > > On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote: > >> >> Hi Frederick, >> >> On 3/17/09 1:01 PM, Frederick Hirsch wrote: >>> The latest draft includes the revised text from Thomas. >>> >>> Marcos, are you suggesting we add something more? It sounds like what >>> you are saying here, is that it should be a valid widget file. Isn't >>> that part of P&C checking? I'm not sure what it means to check that >>> the >>> paths are "as secure as possible." >> >> You might want to check the following section of the P&C [1] and see >> if >> it is usable in dig sigs. Given that the paths in the >> elements MUST be zip-relative-paths, the rules for checking the >> validity >> of those paths may apply to the Widgets Dig Sig spec. >> >> >> [1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths >> > > regards, Frederick > > Frederick Hirsch > Nokia > > > > > -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Marcos Rather than replicating this, which might be error prone and hard to maintain, perhaps Widget Signature should reference P & C for this. What do you think ? regards, Frederick On Mar 17, 2009, at 8:15 AM, ext Marcos Caceres wrote: Hi Frederick, On 3/17/09 1:01 PM, Frederick Hirsch wrote: The latest draft includes the revised text from Thomas. Marcos, are you suggesting we add something more? It sounds like what you are saying here, is that it should be a valid widget file. Isn't that part of P&C checking? I'm not sure what it means to check that the paths are "as secure as possible." You might want to check the following section of the P&C [1] and see if it is usable in dig sigs. Given that the paths in the elements MUST be zip-relative-paths, the rules for checking the validity of those paths may apply to the Widgets Dig Sig spec. [1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths regards, Frederick Frederick Hirsch Nokia
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Marcos, Frederick, I should have asked Frederick to make the changes Marcos suggested below. Sorry about that! Anyhow, Frederick agreed to make the changes. -Regards, Art Barstow On Mar 17, 2009, at 8:44 AM, ext Marcos Caceres wrote: On 3/17/09 12:59 PM, Frederick Hirsch wrote: I already made this change :) to widget user agent. I think that should work... Sorry to be annoying, but we should be trying to architecturally design all the specs to behave as independent as possible (and eradicate the notion of an overall "Widget User Agent"). For the sake of consistency, I would again ask that we don't use the term "widget user agent" in any of the specs and just use user agent.
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On 3/17/09 12:59 PM, Frederick Hirsch wrote: I already made this change :) to widget user agent. I think that should work... Sorry to be annoying, but we should be trying to architecturally design all the specs to behave as independent as possible (and eradicate the notion of an overall "Widget User Agent"). For the sake of consistency, I would again ask that we don't use the term "widget user agent" in any of the specs and just use user agent.
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Hi Frederick, On 3/17/09 1:01 PM, Frederick Hirsch wrote: The latest draft includes the revised text from Thomas. Marcos, are you suggesting we add something more? It sounds like what you are saying here, is that it should be a valid widget file. Isn't that part of P&C checking? I'm not sure what it means to check that the paths are "as secure as possible." You might want to check the following section of the P&C [1] and see if it is usable in dig sigs. Given that the paths in the elements MUST be zip-relative-paths, the rules for checking the validity of those paths may apply to the Widgets Dig Sig spec. [1] http://dev.w3.org/2006/waf/widgets/#zip-relative-paths
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
I already made this change :) to widget user agent. I think that should work... On Mar 17, 2009, at 6:28 AM, ext Marcos Caceres wrote: On Thu, Mar 12, 2009 at 5:53 PM, Priestley, Mark, VF-Group wrote: --- Editorial comments --- General Terminology "Widget agent", "widget platform", "application"? -> "widget user agent"? Lets just use "user agent". I don't think we should have a notion of a "widget user agent". A user agent is one that attempts to implement the said specification; that is, one that only implements signatures. It should be possible to build a user agent that only processes signatures and is unaware any other of the widget 1.0 specifications. [Comment] by "application" do you mean "widget user agent"? as above. -- Marcos Caceres http://datadriven.com.au regards, Frederick Frederick Hirsch Nokia
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
The latest draft includes the revised text from Thomas. Marcos, are you suggesting we add something more? It sounds like what you are saying here, is that it should be a valid widget file. Isn't that part of P&C checking? I'm not sure what it means to check that the paths are "as secure as possible." regards, Frederick Frederick Hirsch Nokia On Mar 17, 2009, at 7:22 AM, ext Marcos Caceres wrote: On Mon, Mar 16, 2009 at 12:17 PM, Thomas Roessler wrote: I'd suggest this instead: Implementations should be careful about trusting path components found in the zip archive: Such path components might be interpreted by operating systems as pointing at security critical files outside the widget environment proper, and naive unpacking of widget archives into the file system might lead to undesirable and security relevant effects, e.g., overwriting of startup or system files. What do you think? I support this change. Makes sense. The other thing is to force implementations of the dig sig spec to verify that a path conforms to a zip-relative-path as defined in the packaging spec. And that we check that zip-relative-paths as defined in the P&C spec are secure as possible. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On Mon, Mar 16, 2009 at 12:17 PM, Thomas Roessler wrote: > I'd suggest this instead: > >> Implementations should be careful about trusting path components found in >> the zip archive: Such path components might be interpreted by operating >> systems as pointing at security critical files outside the widget >> environment proper, and naive unpacking of widget archives into the file >> system might lead to undesirable and security relevant effects, e.g., >> overwriting of startup or system files. > > What do you think? I support this change. Makes sense. The other thing is to force implementations of the dig sig spec to verify that a path conforms to a zip-relative-path as defined in the packaging spec. And that we check that zip-relative-paths as defined in the P&C spec are secure as possible. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On Thu, Mar 12, 2009 at 6:27 PM, Marcin Hanclik
wrote:
> Hi Mark,
>
>>>"Implementations that store the content of widget archives to the file
>system during signature verification MUST NOT trust any path components of
>file names present in the archive, to avoid overwriting of arbitrary files
>during signature verification."
>>>
>>>{Comment] I don't understand this sentence - which may well be a problem
>with my understanding rather than the sentence - please can you enlighten
>me, thanks.
> I assume it is as follows:
>
> 1. Imagine the WUA is processing a widget archive, i.e. a zip file where each
> file has its associate relative path.
>
> ZIP spec contains the following text:
>
> file name: (Variable)
>
> The name of the file, with optional relative path.
> The path stored should not contain a drive or
> device letter, or a leading slash.
> I.e. the path may be virtually any string.
Yep. Don't know if this helps, but in the packaging we define the
notion of a "file entry", which is essentially, the file name (path),
and the compressed data.
> 2. Prior to signature verification the archive is untrusted.
right. In the packaging spec, we call this a potential zip archive and
a potential widget archive, IIRC.
> 3. Next, let's assume WUA is configured to store the temporary files from the
> widget archive (storage may be necessary for devices with limited RAM) in a
> folder like C:/widgetplayer (e.g. on Win32/WinCE).
>
> 4. Then a file from a widget archive could have a path like "../windows/XXX".
>
> 5. As for me the text says that the path should be ignored when processing
> the signature to prevent WUA from storing the files e.g. in a sensitive
> folder like "c:/windows/" as it could be the case when combining the above
> paths.
>
This sounds like an implementation detail. A warning note to
implementers should be sufficient to address this.
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On Thu, Mar 12, 2009 at 5:53 PM, Priestley, Mark, VF-Group wrote: > --- > Editorial comments > --- > > General Terminology > > "Widget agent", "widget platform", "application"? -> "widget user > agent"? Lets just use "user agent". I don't think we should have a notion of a "widget user agent". A user agent is one that attempts to implement the said specification; that is, one that only implements signatures. It should be possible to build a user agent that only processes signatures and is unaware any other of the widget 1.0 specifications. > [Comment] by "application" do you mean "widget user agent"? as above. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Thanks Thomas (and also Marcin from an earlier email) for the
explanation.
I support Thomas' suggested changes.
Mark
>-Original Message-
>From: Thomas Roessler [mailto:t...@w3.org]
>Sent: 16 March 2009 11:18
>To: Frederick Hirsch
>Cc: Priestley, Mark, VF-Group; ext Marcos Caceres; WebApps WG
>Subject: Re: [widgets] Comments on Widget Signature update
>(was RE: Widget Signature update)
>
>On 13 Mar 2009, at 15:50, Frederick Hirsch wrote:
>
>> Thanks for your review, I have some comments inline. Thomas, can you
>> please review my proposed change to the security considerations text
>> Mark mentioned?
>
>
>I believe that you mean this piece of text:
>
>>> "Implementations that store the content of widget archives to the
>>> file system during signature verification MUST NOT trust any path
>>> components of file names present in the archive, to avoid
>overwriting
>>> of arbitrary files during signature verification."
>>>
>>
>>
>>> {Comment] I don't understand this sentence - which may well be a
>>> problem with my understanding rather than the sentence - please can
>>> you enlighten me, thanks.
>>
>> I think this is better worded as:
>>
>> Implementations MUST NOT overwrite during signature
>> verification, as this could open the possibility of an
>attack based on
>> substituting content for files due to malformed ds:Reference
>URIs in a
>> signature that has been replaced.
>>
>> (Thomas, can you please verify that I got that right?)
>
>The basic attack that this piece of the text is about is
>unpacking a zip archive into the file system, trusting path
>components, and ending up overwriting arbitrary system files,
>because the zip file contained '../../../../etc/passwd'.
>(Yes, I'm painting with an extremely broad brush here.)
>
>Two points:
>
>1. This should go into the security considerations, and
>probably shouldn't be phrased as normative text.
>
>2. I agree with Mark that it's probably too confusing; I fear
>that your proposed replacement doesn't capture everything.
>
>I'd suggest this instead:
>
>> Implementations should be careful about trusting path
>components found
>> in the zip archive: Such path components might be interpreted by
>> operating systems as pointing at security critical files outside the
>> widget environment proper, and naive unpacking of widget
>archives into
>> the file system might lead to undesirable and security relevant
>> effects, e.g., overwriting of startup or system files.
>
>What do you think?
>
RE: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Frederick, Many thanks for the feedback. Responses inline, marked [mp]. Happy with the resolution you suggest for all the other comments. Thanks, Mark >-Original Message- >From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] >Sent: 13 March 2009 14:50 >To: Priestley, Mark, VF-Group >Cc: Frederick Hirsch; ext Marcos Caceres; WebApps WG; Thomas Roessler >Subject: Re: [widgets] Comments on Widget Signature update >(was RE: Widget Signature update) > >Mark > >Thanks for your review, I have some comments inline. Thomas, >can you please review my proposed change to the security >considerations text Mark mentioned? > >Thanks > >regards, Frederick > >Frederick Hirsch >Nokia > >On Mar 12, 2009, at 12:53 PM, ext Priestley, Mark, VF-Group wrote: > >> Hi Frederick, All, >> >> Some comments on the updated specification but first let me >again say >> thanks for doing a great job making all the changes! >> >> --- >> Substantive comments >> --- >> >> 3 >> >> "Implementers are encouraged to provide mechanisms to enable >end-users >> to install additional root certificates. Trust in a root certificate >> is established through a security critical mechanism implemented by >> the widget platform that is out of scope for this specification" >> >> [Comment] I know this was discussed before, and while I >agree with the >> overall sentiment of the text, if we are encouraging implementers to >> do this then I wonder if we should also add some warning text to the >> security considerations section, eg mechanisms to install new root >> certificates should be subject to security critical mechanisms, for >> example it end-users should be made aware of what they are doing and >> why when installing a new root certificate. > >sounds reasonable to add text to security considerations, will do. [mp] Thanks >> >> >> 4 >> >> "5 Process the digital signatures in the signatures list in >descending >> order, with distributor signatures first. >> >> a. Only the first distributor signature MUST be processed." >> >> [Comment] Why is it required to always process the first distributor >> signature? What if the widget user agents security policy is only >> concerned with the author signature? I think 5a should be removed. > >ok, but where do we say that only one need be processed in the >set of specifications? >Do we need to clarify that even if more than one is present, >not all need be processed? This seems to be important >assumption/decision that will get lost. > [mp] My view is that whether zero, one or more signatures is processed is up to the widget user agents security policy therefore we don't need to say anything about which signatures (if any) must be processed. The purpose of sorting the distributor signatures into ascending order is to allow some optimisation of signature processing under certain conditions. Maybe good to further clarify - I can try and come up with something if you'd like (and of course if you agree)? >> >> >> 6.1 >> >> "Required for signature verification, optional for generation: >> DSAwithSHA1" >> >> [Comment] When we discussed this before I think we agreed that it >> might be necessary to support DSAwithSHA1 (and RSAwithSHA1?) for the >> verification of signatures in certificate chains but we >ruled out the >> use of DSAwithSHA1 (and RSAwithSHA1) for widget signature generation >> (and therefore verification) as they are already considered too weak. >> Did I miss something? > >What is the status of Requirement R47? looks like the >algorithm MUSTs etc and requirement both need adjustment. [mp] Yep, I think this is an issue with the requirement. I believe it comes from the fact that at some point we split the digest and signature algorithm requirements, which, having checked the version in the latest editor's draft, means we have also lost some of the intended meaning of the digest algorithm requirement. I suggest I work with Marcos to go back and double check / fix our requirements. > > >> >> >> 7.1 >> >> Constraint 3b >> >> "The Algorithm attribute of the ds:digestMethod MUST be set to a >> Digest method specified in the Algorithms section of this document." >> >> Constraint 5b >> >> "The ds:SignatureValue element MUST contain a signature generated >> using a Signature method specified in the Algorithms section of this >> document and MUST use a key
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On 13 Mar 2009, at 15:50, Frederick Hirsch wrote:
Thanks for your review, I have some comments inline. Thomas, can you
please review
my proposed change to the security considerations text Mark mentioned?
I believe that you mean this piece of text:
"Implementations that store the content of widget archives to the
file
system during signature verification MUST NOT trust any path
components
of file names present in the archive, to avoid overwriting of
arbitrary
files during signature verification."
{Comment] I don't understand this sentence - which may well be a
problem
with my understanding rather than the sentence - please can you
enlighten me, thanks.
I think this is better worded as:
Implementations MUST NOT overwrite during signature
verification, as this could open the possibility of an attack based
on substituting content for files due to malformed ds:Reference URIs
in a signature that has been replaced.
(Thomas, can you please verify that I got that right?)
The basic attack that this piece of the text is about is unpacking a
zip archive into the file system, trusting path components, and ending
up overwriting arbitrary system files, because the zip file contained
'../../../../etc/passwd'. (Yes, I'm painting with an extremely broad
brush here.)
Two points:
1. This should go into the security considerations, and probably
shouldn't be phrased as normative text.
2. I agree with Mark that it's probably too confusing; I fear that
your proposed replacement doesn't capture everything.
I'd suggest this instead:
Implementations should be careful about trusting path components
found in the zip archive: Such path components might be interpreted
by operating systems as pointing at security critical files outside
the widget environment proper, and naive unpacking of widget
archives into the file system might lead to undesirable and security
relevant effects, e.g., overwriting of startup or system files.
What do you think?
Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Mark
Thanks for your review, I have some comments inline. Thomas, can you
please review my proposed change to the security considerations text
Mark mentioned?
Thanks
regards, Frederick
Frederick Hirsch
Nokia
On Mar 12, 2009, at 12:53 PM, ext Priestley, Mark, VF-Group wrote:
Hi Frederick, All,
Some comments on the updated specification but first let me again say
thanks for doing a great job making all the changes!
---
Substantive comments
---
3
"Implementers are encouraged to provide mechanisms to enable end-users
to install additional root certificates. Trust in a root certificate
is
established through a security critical mechanism implemented by the
widget platform that is out of scope for this specification"
[Comment] I know this was discussed before, and while I agree with the
overall sentiment of the text, if we are encouraging implementers to
do
this then I wonder if we should also add some warning text to the
security considerations section, eg mechanisms to install new root
certificates should be subject to security critical mechanisms, for
example it end-users should be made aware of what they are doing and
why
when installing a new root certificate.
sounds reasonable to add text to security considerations, will do.
4
"5 Process the digital signatures in the signatures list in descending
order, with distributor signatures first.
a. Only the first distributor signature MUST be processed."
[Comment] Why is it required to always process the first distributor
signature? What if the widget user agents security policy is only
concerned with the author signature? I think 5a should be removed.
ok, but where do we say that only one need be processed in the set of
specifications?
Do we need to clarify that even if more than one is present, not all
need be processed? This seems to be important assumption/decision that
will get lost.
6.1
"Required for signature verification, optional for generation:
DSAwithSHA1"
[Comment] When we discussed this before I think we agreed that it
might
be necessary to support DSAwithSHA1 (and RSAwithSHA1?) for the
verification of signatures in certificate chains but we ruled out the
use of DSAwithSHA1 (and RSAwithSHA1) for widget signature generation
(and therefore verification) as they are already considered too weak.
Did I miss something?
What is the status of Requirement R47? looks like the algorithm MUSTs
etc and requirement both need adjustment.
7.1
Constraint 3b
"The Algorithm attribute of the ds:digestMethod MUST be set to a
Digest
method specified in the Algorithms section of this document."
Constraint 5b
"The ds:SignatureValue element MUST contain a signature generated
using
a Signature method specified in the Algorithms section of this
document
and MUST use a key that is of the length of a recommended key length."
[Comment] These constraints are "MUST"s however the sections where we
describe Digest Algorithms, Signature Algorithms and recommended key
lengths the text currently allow the use of undefined other algorithms
and key lengths. This seems inconsistent. I think we need to allow for
the use of other algorithms and key lengths but at the same time we
have
to somehow state that a widget user agent MUST support the base set
defined in the specification, and authors should use these if they
want
to ensure interoperability. As such, perhaps 3b and 5b would be better
included as authoring guidelines?
how about replacing:
The ds:Signature MUST meet the following requirements:
• The Algorithm attribute of the ds:CanonicalizationMethod element
MUST be set to a Canonicalization method specified in the Algorithms
section of this document.
• The ds:SignatureValue element MUST contain a signature generated
using a Signature method specified in the Algorithms section of this
document and MUST use a key that is of the length of a recommended key
length.
with
The ds:Signature MUST meet the following requirements:
* Algorithms MUST conform to requirements given in the algorithms
section of this specification.
re is really no need to say this except to make sure it is not missed,
since the algorithms section outlines algorithm requirements. I'm also
ok with removing this entirely. What do you think?)
8
"Implementations that store the content of widget archives to the file
system during signature verification MUST NOT trust any path
components
of file names present in the archive, to avoid overwriting of
arbitrary
files during signature verification."
{Comment] I don't understand this sentence - which may well be a
problem
with my understanding rather than the sentence - please can you
enlighten me, thanks.
I think this is better worded as:
Implementations MUST NOT overwrite during signature
verification, as this could open the possibility of an attack based on
substituting content for files
RE: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
Hi Mark,
>>"Implementations that store the content of widget archives to the file
system during signature verification MUST NOT trust any path components of
file names present in the archive, to avoid overwriting of arbitrary files
during signature verification."
>>
>>{Comment] I don't understand this sentence - which may well be a problem
with my understanding rather than the sentence - please can you enlighten
me, thanks.
I assume it is as follows:
1. Imagine the WUA is processing a widget archive, i.e. a zip file where each
file has its associate relative path.
ZIP spec contains the following text:
file name: (Variable)
The name of the file, with optional relative path.
The path stored should not contain a drive or
device letter, or a leading slash.
I.e. the path may be virtually any string.
2. Prior to signature verification the archive is untrusted.
3. Next, let's assume WUA is configured to store the temporary files from the
widget archive (storage may be necessary for devices with limited RAM) in a
folder like C:/widgetplayer (e.g. on Win32/WinCE).
4. Then a file from a widget archive could have a path like "../windows/XXX".
5. As for me the text says that the path should be ignored when processing the
signature to prevent WUA from storing the files e.g. in a sensitive folder like
"c:/windows/" as it could be the case when combining the above paths.
Thanks.
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Europe GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Priestley, Mark, VF-Group
Sent: Thursday, March 12, 2009 5:54 PM
To: Frederick Hirsch; ext Marcos Caceres
Cc: WebApps WG
Subject: [widgets] Comments on Widget Signature update (was RE: Widget
Signature update)
Hi Frederick, All,
Some comments on the updated specification but first let me again say
thanks for doing a great job making all the changes!
---
Substantive comments
---
3
"Implementers are encouraged to provide mechanisms to enable end-users
to install additional root certificates. Trust in a root certificate is
established through a security critical mechanism implemented by the
widget platform that is out of scope for this specification"
[Comment] I know this was discussed before, and while I agree with the
overall sentiment of the text, if we are encouraging implementers to do
this then I wonder if we should also add some warning text to the
security considerations section, eg mechanisms to install new root
certificates should be subject to security critical mechanisms, for
example it end-users should be made aware of what they are doing and why
when installing a new root certificate.
4
"5 Process the digital signatures in the signatures list in descending
order, with distributor signatures first.
a. Only the first distributor signature MUST be processed."
[Comment] Why is it required to always process the first distributor
signature? What if the widget user agents security policy is only
concerned with the author signature? I think 5a should be removed.
6.1
"Required for signature verification, optional for generation:
DSAwithSHA1"
[Comment] When we discussed this before I think we agreed that it might
be necessary to support DSAwithSHA1 (and RSAwithSHA1?) for the
verification of signatures in certificate chains but we ruled out the
use of DSAwithSHA1 (and RSAwithSHA1) for widget signature generation
(and therefore verification) as they are already considered too weak.
Did I miss something?
7.1
Constraint 3b
"The Algorithm attribute of the ds:digestMethod MUST be set to a Digest
method specified in the Algorithms section of this document."
Constraint 5b
"The ds:SignatureValue element MUST contain a signature generated using
a Signature method specified in the Algorithms section of this document
and MUST use a key that is of the length of a recommended key length."
[Comment] These constraints are "MUST"s however the sections where we
describe Digest Algorithms, Signature Algorithms and recommended key
lengths the text currently allow the use of undefined other algorithms
and key lengths. This seems inconsistent. I think we need to allow for
the use of other algorithms and key lengths but at the same time we have
to somehow state that a widget user agent MUST support the base set
defined in the specification, and authors should use these if they want
to ensure interoperability. As such, perhaps 3b and 5b would be better
included as authoring guidelines?
8
"Implementations that store the content of widget archives to the file
system during signature verification MUST NOT trust any path components
of file names present in the archive, to avoid overwriting of arbitrary
files during signature verificatio
