Re: [widgets] Comments on Widget Signature update (was RE: Widget Signature update)
On Mon, Mar 16, 2009 at 12:17 PM, Thomas Roessler t...@w3.org 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 PC spec are secure as possible. -- Marcos Caceres http://datadriven.com.au
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 PC 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 PC [1] and see if it is usable in dig sigs. Given that the paths in the reference 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)
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)
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)
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 PC 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 PC [1] and see if it is usable in dig sigs. Given that the paths in the reference 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)
On 3/17/09, Frederick Hirsch frederick.hir...@nokia.com 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 PC 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 PC [1] and see if it is usable in dig sigs. Given that the paths in the reference 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)
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 that is of the length of a recommended key length. [Comment] These constraints are MUSTs 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
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 widget files 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)
due to malformed ds:Reference URIs in a signature that has been replaced. (Thomas, can you please verify that I got that right?) --- Editorial comments --- General Terminology Widget agent, widget platform, application? - widget user agent? signature, digital signature(s) - widget signature(s) some instances refer to the widget signature file (widget signature) other to an XML Signature itself, some to generic signature operations. I'll take a look to clarify. Policy - Security policy ok author widget signature - author signature (or vice versa) ok distributor widget signature - distributor signature (or vice versa) ok Digest method - Digest Algorithm Also, as a general comment, not all defined terms are linked throughout the document. doesn't it get to be a bit much to link every instance? If a term is linked once in a paragraph/list, I suggest not linking it again in that same paragraph/list. 1.4 Example of a distributor signature document, named signature.xml: [Change] signature.xml - signature1.xml yes 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. it was decided by the WG I believe. 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 isn't this saying the same thing with more words? 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. ok 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? yes Thanks again! Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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 regards, Frederick Frederick Hirsch Nokia
Re: Widget Signature update
One (possibly minor) point regarding the filename rule: At least the Widgets 1.0 PC spec uses ABNF (RFC 5234) and refers to it, maybe this would be good also in the DigSig spec? The rule expressed in ABNF would be something like: signature-filename = signature non-zero-digit *DIGIT .xml non-zero-digit = %x31-39 Here, DIGIT is a prefabricated rule defined in RFC 5234. This rule says that in between the strings there must be at least one non-zero digit, followed by zero or more normal digits. The normative reference for ABNF would be (grabbed from the PC spec): dtdfn id=abnf[ABNF]/dfn/dt ddRFC 5234, a href=http://www.ietf.org/rfc/rfc5234.txt;citeAugmented BNF for Syntax Specifications: abbr title=Augmented Backus-Naur FormABNF/abbr/cite/a. D. Crocker and P. Overell. January 2008./dd --Jere On 9.3.2009 22.51, Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com wrote: 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
[widgets] Comments on Widget Signature update (was RE: Widget Signature update)
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-requ...@w3.org [mailto:public-webapps-requ...@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
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
