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.hanclik@access-company.com

-----Original Message-----
From: public-webapps-request@w3.org [mailto:public-webapps-request@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 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.


---------------------------
Editorial comments
---------------------------

General Terminology

"Widget agent", "widget platform", "application"? -> "widget user
agent"?

"signature", "digital signature(s)" -> "widget signature(s)"

"Policy" -> "Security policy"

"author widget signature" -> author signature (or vice versa)

"distributor widget signature" -> distributor signature (or vice versa)

"Digest method" -> "Digest Algorithm"

Also, as a general comment, not all defined terms are linked throughout
the document.


1.4

"Example of a distributor signature document, named signature.xml:"

[Change] "signature.xml" -> "signature1.xml"

4

[Comment] Has it been decided to move this processing to the Digital
Signatures specification rather than the Packaging and Configuration
specification? FWIW I think it's cleaner to have it in the Packaging and
Configuration specification but I don't have strong feelings either way.


5.2

"The author signature can be used to determine the author of a widget,
that the widget is as the author intended, and whether two widgets came
from the same author."

[Comment] The author signature _may_ be used to determine whether two
widgets came from the same author, ie it depends whether the same
private key was used.
[Change] "and whether two widgets came from the same author" -> "and may
be used to determine whether two widgets came from the same author"

"An author signature need not be present in a widget resource, but at
most one author signature may be present. A widget resource  MAY contain
zero or one author signatures, as defined by this specification."

[Comment] Sentence contains redundant text.
[Delete] "An author signature need not be present in a widget resource,
but at most one author signature may be present."

7.3

"If Widget Signature Validation fails for any reason then the
application MUST be informed of the failure. In this case the
application might choose not to install the widget."

[Comment] by "application" do you mean "widget user agent"?


Thanks again!

Mark



>-----Original Message-----
>From: public-webapps-request@w3.org
>[mailto:public-webapps-request@w3.org] On Behalf Of Frederick Hirsch
>Sent: 09 March 2009 20:51
>To: ext Marcos Caceres
>Cc: Frederick Hirsch; WebApps WG
>Subject: Re: Widget Signature update
>
>I updated section 4 to correspond to  this:
>
>"If the signatures list is not empty, sort the list of
>signatures by the file name field in ascending numerical order
>(e.g.signature1.xml followed by signature2.xml followed by
>signature3.xml etc)."
>
>
>regards, Frederick
>
>Frederick Hirsch
>Nokia
>
>
>
>On Mar 6, 2009, at 10:07 AM, ext Marcos Caceres wrote:
>
>> Hi Frederick,
>>
>> On 3/6/09 3:59 PM, Frederick Hirsch wrote:
>>> I've updated the widget signature document distributor file naming
>>> convention to the following after discussing this with Josh (thanks
>>> Josh):
>>>
>>> Naming convention for a distributor signature:
>>>    |"signature" [1-9][0-9]* ".xml"|
>>>
>>>        *
>>>
>>>          Each distributor signature /MUST/ have a name consisting of
>>>          the string "signature" followed by a digit in the range 1-9
>>>          inclusive, followed by zero or more digits in the range 0-9
>>>          inclusive and then ".xml", as stated by the BNF.
>An example
>>> is
>>>          "signature20.xml".
>>>
>>>        *
>>>
>>>          Leading zeros are disallowed in the numbers.
>>>
>>>        *
>>>
>>>          Any file name that does not match this BNF /MUST/ be
>>> ignored.
>>>          Thus a file named "signature01.xml" will be ignored. A
>>> warning
>>>          /MAY/ be generated.
>>>
>>>        *
>>>
>>>          There is no requirement that all the signature file names
>>> form
>>>          a contiguous set of numeric values.
>>>
>>>        *
>>>
>>>          These signatures /MUST/ be sorted numerically based on the
>>>          numeric portion of the name. Thus signature2.xml preceeds
>>>          signature11.xml, for example.
>>>
>>>
>>> See draft
>>> http://dev.w3.org/2006/waf/widgets-digsig/#distributor-signatures
>>>
>>> I also updated the notation section, changed the code format to be
>>> italic (without color), and updated the body style to not
>be quite so
>>> large.
>>>
>>> Please indicate any comment or corrections on the list.
>>>
>>
>> The changes look good to me! thank you.
>>
>> Kind regards,
>> Marcos
>
>
>


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Thursday, 12 March 2009 17:28:46 UTC