RE: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1
Hi Art, All, Vodafone has some late comments which it would like to provide to the group for consideration and apologise for supplying these after the deadline. We believe that all but one of the comments is editorial and so there inclusion or otherwise should not affect or delay the decision to go to CR status, which we support. In submitting these comments it is not our intention or desire to hold up this process, only to provide the comments for consideration. The only comment that doesn't fit into this category is a question that has been raised by one of our developers. My hope is that there is already an answer! Thanks, Mark --- Editorial Comments --- ---[Definition of file entry]--- Section: 1.2 A file entry is the compressed (or Stored [ZIP]) representation of a physical file or folder contained within a widget package, as defined in the [Widgets Packaging] specification. In Widgets 1.0: Packaging and Configuration [2] the file entry definition is different. A file entry is the data held by a local file header, file data, and (optional) data descriptor, as defined in the [ZIP] specification, for each physical file contained in a Zip archive. Comment - the inclusion of folder in the definition in [1] has caused one reviewer to ask if there should be a reference element for folders? I believe this is not the case and or folder could be removed from the definition. ---[Requirements accuracy]--- Section: 2 R52. Support for Multiple Signature Algorithms: DSA-SHA-1, RSA-SHA-1, DSA-SHA-256 and RSA-SHA-256. Are these algorithms still correct? DSA-SHA-256 and RSA-SHA-1 should probably be removed as they are not required algorithms. ECDSA-SHA-256 could be added. [Conflict between mandatory statements] A user agent MAY support additional signature algorithms. (Section: 6.1) A user agent MAY support additional digest methods. (Section: 6.2) A user agent MAY support additional XML canonicalization methods. (Section: 6.3) Section: 7.1 The Algorithm attribute of the ds:digestMethod MUST be one of the digest algorithms. The Algorithm attribute of the ds:CanonicalizationMethod element MUST be one of the canonicalization algorithms. The ds:SignatureMethod algorithm used in the ds:SignatureValue element MUST be one of the signature algorithms. Comment - If in section 6 we say A user agent MAY support additional XXX algorithms, which seems to be in conflict with section 7 that states the algorithm used must be one of algorithms listed in section 6. This seems to be an open ended requirement. Suggestion - Remove the statements in section 7.1. It is down to the signer to choose the algorithm to use. If they choose to use a non-recommended algorithm they should understand that user agent support cannot be guaranteed. --- Question / non-editorial --- ---[Support for certificate chains]--- Typically more than one X509 certificate will need to be included in the signature in order to construct a certificate chain to an installed root certificate. Ideally the widget user agent would be given an indication of how to re-construct the certificate chain. This could be done my recommending that X509Certificate elements be included in certificate chain order or by including an attribute to the element, e.g. X509Data X509Certificate order=1.../X509Certificate X509Certificate order=2.../X509Certificate X509Certificate order=3.../X509Certificate /X509Data Maybe this is already solved with other uses of XML Digital Signatures? [1] http://dev.w3.org/2006/waf/widgets-digsig/ [2] http://www.w3.org/TR/widgets/#definitions -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 21 May 2009 18:23 To: public-webapps; public-xml...@w3.org Subject: Reminder: Comments for LCWD of Widgets 1.0: Digital Signatures due June 1 Hi All - a friendly reminder June 1 is the end of the comment period for the April 30 Widgets 1.0: Digital Signatures Last Call Working Draft: http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ Please send all comments by June 1. -Regards, Art Barstow On May 1, 2009, at 10:48 AM, Barstow Art (Nokia-CIC/Boston) wrote: On April 30 the WebApps WG published a LCWD of the Widgets 1.0 Digital Signatures spec: [[ http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ Introduction This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Widget authors and distributors can digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the widget package and to confirm the signing key(s). This document specifies conformance requirements on
RE: [widgets] Moving Widgets 1.0: Digital Signature spec to Candidate Recommendation
Hi Art, Vodafone supports this proposal. I have submitted some late (sorry!) editorial comments (see separate email) but do not believe any other comments were received or that the comments I submitted should hold up this process. Thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 02 June 2009 14:02 To: public-webapps Subject: [widgets] Moving Widgets 1.0: Digital Signature spec to Candidate Recommendation The comment period for the 30 April 2009 Widgets Digital Signature LCWD [1] ended 1 June 2009. It appears the only changes between the latest ED [2] and the LCWD are Editorial. It also appears no formal comments were submitted. Editors - please confirm this. One of the next steps to move this spec to CR is to agree on the CR's Exit Criteria. A strawman proposal (based on the Element Traversal CR) follows: [[ This is the DD MMM 2009 Candidate Recommendation of the Widgets 1.0: Digital Signature specification. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. The Web Applications (WebApps) Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has developed a comprehensive Widgets 1.0: Digital Signature test suite, and demonstrated at least two interoperable implementations for each test. The WebApps Working Group expects to show these implementations by September 2009. The Working Group does not plan to request to advance to Proposed Recommendation prior to 01 September 2009. ]] An agenda topic for the June 4 widgets voice conference will be a proposal to advance this spec to Candidate Recommendation. If you cannot attend that meeting and object to such a proposal, please clearly state your reason(s) for objecting before that meeting starts (June 4 @ 15:00 Paris time). -Regards, Art Barstow [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ [2] http://dev.w3.org/2006/waf/widgets-digsig/
RE: [widget-digsig] Updated Widget Signature editors draft
I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents. Agreed - in fact I think a general statement about use of optional algorithms would be beneficial -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 24 April 2009 09:46 To: Frederick Hirsch Cc: Web Applications Working Group WG Subject: Re: [widget-digsig] Updated Widget Signature editors draft Hi Frederick, Thanks for updating the spec! comment below. On Fri, Apr 24, 2009 at 3:14 AM, Frederick Hirsch frederick.hir...@nokia.com wrote: I have updated the Widget Signature draft to reflect decisions on today's call, as follows: Added ECDSAwithSHA256 as SHOULD signature algorithm I would like to see some text cautioning authors not to rely on this algorithm, since it is optional in user agents. Removed editor notes re feedback on signature algorithms Removed editor note with Signature Properties reference, since we've removed section 9 Added FIPS-186-3 reference http://dev.w3.org/2006/waf/widgets-digsig/ Note that we will need to update the Signature Properties reference, when that specification is published with this specification. regards, Frederick Frederick Hirsch Nokia -- Marcos Caceres http://datadriven.com.au
RE: Proposal for ISSUE-83
+1 for Art's shorter counter proposal Thanks, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 23 April 2009 07:47 To: Arthur Barstow Cc: Marcos Caceres; Priestley, Mark, VF-Group; Hirsch Frederick (Nokia-CIC/Boston); public-webapps Subject: Re: Proposal for ISSUE-83 Also works for me. Marcos On Thursday, April 23, 2009, Arthur Barstow art.bars...@nokia.com wrote: A shorter counter-proposal below ... On Apr 21, 2009, at 9:56 AM, ext Marcos Caceres wrote: On Tue, Apr 21, 2009 at 3:31 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: ISSUE-83 states: Instantiated widget should not be able to read digital signature http://www.w3.org/2008/webapps/track/issues/83 The following is a proposal of text to add to PC to address this issue, based on text from Marcos and adding the notion of allowing policy and access control mechanisms to be used: Where a user agent that implements this specification interacts with implementations of other specifications, this user agent MUST deny other implementations access to digital signature documents unless an access control mechanism is in place to enable access according to policy. The definition of such a policy mechanism is out of scope of this specification, but may be defined to allow access to all or parts of the signature documents, or deny any such access. An exception is if a user agent that implements this specification also implements the OPTIONAL [Widgts-DigSig] specification, in which case the user agent MUST make signature documents available to the implementation of the [Widgets-DigSig] specification. Added under Digital Signatures section. If Mark is happy, then we should close this issue. Proposed text: [[ A user agent MUST prevent a widget from accessing the contents of a digital signature document unless an access control mechanism explicitly enables such access e.g. via an access control policy. The definition of such a policy mechanism is out of scope of this specification, but may be defined to allow access to all or parts of the signature documents, or deny any such access. ]] -Regards, Art Barstow -- Marcos Caceres http://datadriven.com.au
RE: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider
Hi Frederick, All, Actually, Vodafone are staying silent on whether this should be a MUST for XML Signature 1.1 specification. However we are saying that we won't object, which I had previously indicated that we might on the WebApps call. Regards, Mark -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: 23 April 2009 13:20 To: ext David Rogers Cc: Frederick Hirsch; marc...@opera.com; Priestley, Mark, VF-Group; Web Applications Working Group WG; Babbage, Steve, VF-Group Subject: Re: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider I agree . Also to be clear Mark, I believe you are saying VF supports a MUST in the XML Signature 1.1 specification. regards, Frederick Frederick Hirsch Nokia On Apr 23, 2009, at 8:15 AM, ext David Rogers wrote: Marcos, Surely the logic should support algorithm evolution in that way. If it is a SHOULD it doesn't mean that engines need to support all algorithms - that would be a SHALL? If we say nothing at all, you run the risk of dropping off a security cliff if you need to migrate in the future. A SHOULD at least prescribes an intended roadmap and gives the option for implementers to go for that if they so choose. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Marcos Caceres Sent: 23 April 2009 08:53 To: Priestley, Mark, VF-Group Cc: Frederick Hirsch; Web Applications Working Group WG; Babbage, Steve, VF-Group Subject: Re: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider On Thu, Apr 23, 2009 at 9:31 AM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Frederick, All, Vodafone supports the move to support ECDSA in XML Signature 1.1 [2] and welcomes the new clarifying text. Vodafone will not object to ECDSAwithSHA256 being specified as mandatory [2] however we would like to propose that it is a recommended algorithm in Widgets 1.0: Digital Signatures [5] (e.g. a SHOULD). Sorry, it doesn't make sense to have them as a should in this context. Either they are in or out because in practice engines will need to support all prescribed algorithms. Lets keep to the smallest possible subset of most commonly used algorithms in 1.0; every algorithm we add makes this specification more difficult/expensive to implement, adds more points of failure, etc. If the market shifts to new algorithms, then we can add those later in a new draft. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: [widget] [widget-digsig] Comment on WD of Widgets 1.0: Digital Signatures - use of Created property
Vodafone also supports the removal of the Created property from the Widget 1.0: Digital Signature specification. Thanks, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 April 2009 12:31 To: Frederick Hirsch Cc: Priestley, Mark, VF-Group; public-webapps Subject: Re: [widget] [widget-digsig] Comment on WD of Widgets 1.0: Digital Signatures - use of Created property On Tue, Apr 21, 2009 at 11:17 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: if there is no need for the Created property in the Widgets Signature spec I suggest we remove it, though keep what we have in the Signature Properties specification. The less dependencies the better, from my POV. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
Thanks Frederick and Marcos - responses inline. Only a couple of questions left :) Regards, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 April 2009 11:46 To: Frederick Hirsch; Priestley, Mark, VF-Group Cc: Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31 On Tue, Apr 21, 2009 at 11:14 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Mark Please find responses inline. Thanks for the review. regards, Frederick Frederick Hirsch Nokia On Apr 7, 2009, at 2:27 AM, ext Priestley, Mark, VF-Group wrote: Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 A widget package can be signed by the author of the widget producing an [XMLDSIG11] signature that cryptographically includes all of the file entries other than signature files. A widget package can also be signed by one or more distributors, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. ok [mp] Thanks - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. ok [mp] Thanks - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? We define URIs using this namespace so we should keep the URI definition. ok with removing prefix since it is not used now but would prefer to keep to avoid errors later. Not a big issue to remove though. [mp] I'm OK either way. - The terms XML elements and resources seem to be used interchangeably? Is there a difference? yes, one is xml elements others are resources as referenced by URI Mark, I'm worried you asked this question? Is there confusion somewhere wrt to the use resource and xml elements? [mp] No, it's mostly a case of me needing to read the text more carefully! My confusion was caused by the fact we only define the namespace prefixes that we use in throughout the spec in the context of resources. - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? No, XMLSecAlgs does not define the algs. There are defined in a number of places :) OK - my concern was just that [XMLSecAlgs] cross references lots of algorithms that we don't need but happy to leave as it is. - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed I suggest stored. Marcos? Stored should probably be [Stored], with a reference to the RFC for the algorithm. [mp] OK for me - physical file - file ? Marcos? ok with file personally Agree. [mp] Thanks - top-most path level - is there a better way of saying this? don't think so unless you have a proposal without using the word root I know it's nasty, but people understand it. Lets play wordsmith only once we have all the tech stuff solved. [mp] As I can't think of anything better, happy to leave as is. - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST I think it is a MAY, others? Technically, Mark is correct. But leave it as a MAY (or maybe drop MAY altogether) because this spec does not put conformance criteria on packaging. [mp] proposal of the widget package, which logically contain one or more file entries, as defined Note that reading this again - if a file entry is a file or a folder, then there must be at least one file entry unless the widget is an empty package (and if it's signed it can't be empty because at a minimum there would be a signature file entry!) so I think one one or more is correct. - Question: is a file entry the same
RE: [widgets] dropping screenshot
Vodafone supports the proposal to drop screenshots from v1 of the Widgets specifications. Thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 18 April 2009 15:21 To: ext Marcos Caceres Cc: public-webapps Subject: Re: [widgets] dropping screenshot I generally support with this proposal but would add that this functionality be added to the widgets v2 list [1]. All - please send your comments on this proposal by April 23 at the latest. -Regards, Art Barstow [1] http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R On Apr 16, 2009, at 9:05 AM, ext Marcos Caceres wrote: After discussions with Josh and Arve, I would like to propose that we drop the screenshot element. The rationales for the decision are: * screenshots bloat the package, * and screenshots are never used when the widget is instantiated. * Also, there is no way to identify on which platform the screenshot of the widget was taken on. This is an issue because a UA may render form elements used by a widget differently from one platform to another. Authors will want to show what a widget looks like when running on a platform. To show this, authors should provide distributors/galleries with platform specific screenshots. Having a bunch of screenshots in the package may confuse/mislead users in believing the widget will look/behave in some particular way, which may not be true on some platforms. Kind regards, Marcos
RE: [Widgets AE] Removing show() and hide()
+1 -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arve Bersvendsen Sent: 16 April 2009 13:17 To: public-webapps@w3.org Subject: [Widgets AE] Removing show() and hide() The show() and hide() methods from the Widgets AE specification has a lot of potential to be abused, and annoying. In this sense, it should really be hidden behind a feature definitions, so a User Agent can optionally allow or disallow the feature. With that in mind, I would propose dropping these two methods from AE, and leave them to later be specified as an extension. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
[widget] [widget-digsig] Comment on WD of Widgets 1.0: Digital Signatures - use of Created property
Dear All, I have a number of comments against the Created property. As previously communicated on conference calls (although I can't find the relevant minutes) Vodafone objects to the mandatory use of the Created property. The main objection is that on mobile devices the user often does not set the correct time (or more usually the correct year) which means the device defaults to the time/year of manufacture. As a result many signatures will contain Created property values that, as far as the device is concerned, happen in the future. Without a requirement on a reliable and accurate timesource, which we are not proposing to introduce, the Created property cannot be relied on. This combined with the fact that the use of the Created property is down to the signer, or the signing scheme within which the signer is operating, mean we think its use should be optional. This general comment translates to the specific comments below. - 5.1 Each signature file MUST contain a dsp:Created signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification. We would like to see the above changed to a MAY. - 5.6 As an example of use, assume a distributor's signing process is found to have been compromised. Thus, it is not practical to exchange the signature key. Being able to invalidate all signatures made before a particular date would be important in such a scenario. I'm not sure the above is a good example? If the signing process has been compromised then I may want to invalidate signatures before this date, but wouldn't I also change my key at this time to stop creating new compromised signatures? In this case the end-entity cert should be revoked. My understanding of timestamps was that their main reason for being is to confirm that a signature was created at a particular instance in time. This information can then be used for non-repudiation and/or proof of existence of the signed object at a particular time in the past. The above use case seems to be suggesting something else which I do not fully understand. As previously communicated I think there is a case for an Expires property, which could be used to state a point in time after which a Signature is no longer valid (to allow for Signature with shorter lives than the keys used to create them), but this is different from the Created property. My suggestion is to rework the example. - 7.2 The sentence: A wall clock timestamp SHOULD be placed is inconsistent with the text in 5.1 which states the element as a MUST. If the text in 5.1 is changed to a MAY then the text in 7.2 would be OK but we would prefer to make this a MAY as well. - 7.3 The Created Signature Property value SHOULD represent a wall clock timestamp earlier than the current time, to the nearest minute. It's not clear what the user agent should do to respect this requirement? We think that this should be left to the signer or signing scheme to reflect use of the Created property through the UA's security policy. The text on the Created property could then be deleted from this section. - 9.2.1 Upon signature generation, if this property is used, the time value is set to a reference time, as defined by the application. Again, this is inconsistent with the text in 5.1 in which the Created property is mandatory, unless the intention of the text is to be if the property is used by the UA? - 9.2.2 We think it should be made clear that Validation of the Created property is optional. Thanks, Mark Mark Priestley Mobile: +44 (0)7717512838 E-mail: mark.priest...@vodafone.com mailto:mark.priest...@vodafone.com Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001
RE: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
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: [widgets] New WD of Widgets 1.0: Digital Signatures spec published on March 31
Hi Art, All, Please find below my editorial comments and requests for clarifications based on the new WD [1]. While it is a long list the comments are all minor and so hopefully easily addressed. Overall I think the spec is looking good, for which a lot of thanks must go to Frederick and Marcos! That said, I have a couple of more substantive comments that I will send in the next couple of days. Many thanks, Mark [1] http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/ - COMMENTS - 1.0 A widget package can be signed by the author of the widget producing an [XMLDSIG11] signature that cryptographically includes all of the file entries other than signature files. A widget package can also be signed by one or more distributors, with XML signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. Change the last sentence for consistency between definitions, ie: ... A widget package can also be signed by one or more distributors change of the widget, producing [XMLDSIG11] /change signatures that each cryptographically includes all of the non-signature file entries as well as any author signature. - Can we remove the following sentence? This is a general property of signatures which I'm not sure we need to include. Digitally signing implies use of private key material only known by the signer, thus enabling verification of integrity and signature source. - 1.1 We don't actually define any XML elements in the http://www.w3.org/ns/widgets-digsig; namespace... is this worth noting this and/or removing the wsig prefix? - The terms XML elements and resources seem to be used interchangeably? Is there a difference? - Algorithms used by XML Security are defined in a number of places... - could we tighten up this sentence, eg something like This specification references algorithms defined in [XMLSecAlgs] and [XMLDSIG11] ? - 1.2 compressed (or Stored) - either remove capitalisation of Stored or add it to compressed - physical file - file ? - top-most path level - is there a better way of saying this? - which MAY logically contain - if the configuration file is made mandatory then the MAY should be a MUST - Question: is a file entry the same as a file? If so then we should always use file entry in place of file. If not then perhaps we should define file? - (i.e., a third party that is distributing the widget on behalf of the author). - in some cases the author may also be (one of) the distributor(s). suggest changing i.e. to e.g. - 3 As well as sections marked as non-normative, examples and notes in this specification are non-normative. Everything else in this specification is normative. The security considerations section is non-normative. Suggest change to the following for readability: As well as sections marked as non-normative, the examples and notes, and security considerations in this specification are non-normative. Everything else in this specification is normative. - 4 This section defines how to locate digital signatures in a widget package for processing. An implementation MUST achieve the same result as the following algorithm used to locate digital signatures in a widget package: In the sentence above, change digital signatures to signature files (in both cases) - This MAY be determined by the security policy used by the user agent. Can we say will or, better yet, SHOULD or MUST? Otherwise, what do we mean when we say MAY? Who (what) else may enforce security policy? - Thus the highest numbered distributor signature would be validated first. Change to: Thus in the case that one or more distributor signatures were validated, the highest numbered distributor signature would be validated first. - 5.1 A widget package MAY be digitally signed using XML Signature [XMLDSIG11]. don't we mean: A widget package MAY be digitally signed using the profile of XML Signature [XMLDSIG11] defined by this specification. ? - As this section is talking about generating a signature, I suggest that we remove and validated in the following sentence: Each signature file MUST be generated and validated in - 5.2 As per previous email exchange we need to re-work author signature definition - zero or one author signatures. - remove final s - This represents the digital signature of the author of the widget package. add signature file ie This signature file represents the digital signature of the author of the widget package. - 5.3 This represents the digital signature of a distributor of the widget package. add signature file ie This signature file represents the digital signature of a distributor of the widget package. - 5.3.1 Within a widget package these signature files MUST be ordered based on the numeric portion of the signature file name. Thus, for example, signature2.xml precedes signature11.xml.
RE: Re: [BONDI Architecture Security] [widgets] new digsig draft
Hi All, As the author signature was something I had a hand in creating let me add my 2 pence worth. Rainer is correct in that the author signature need not actually come from the author of the widget. It comes from someone who claims to be the widget's author. Whether you believe this claim depends on how much you trust the signer. In [1] the current text says: [ The author signature can be used to determine: * the author of a widget, * that the integrity of the widget is as the author intended, * and whether two widgets came from the same author. ] I would suggest changing this to: [ The author signature can be used to: * authenticate the identity of the entity that added the author signature to the widget package, * confirm that no widget files have been modified, deleted or added since the generation of the author signature. The author signature may be used to: * determine whether two widgets came from the same author. ] The reason the last point is a may is as follows: If two widgets contain author signatures that were created using the same private key then we can say that the widgets were both signed by someone who had access to that key. That would normally mean the same entity (author, company, whatever). If the owner of that key shares it with others then obviously this no longer is true. However, this is the choice of the owner of the key - normally you would not share your private key! One additional point to add. We also define a distributor signature. Distributor signatures cover the author signature. As such a distributor signature may (depending on other factors) be making an implicit statement that the distributor believes the owner of the author signature to be the widget's author. Any clearer? Thanks, Mark [1] http://dev.w3.org/2006/waf/widgets-digsig/Overview.html -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Hillebrand, Rainer Sent: 26 March 2009 16:20 To: marc...@opera.com; pa...@aplix.co.jp Cc: public-webapps@w3.org; otsi-arch-...@omtplists.org Subject: AW: Re: [BONDI Architecture Security] [widgets] new digsig draft Dear Marcos, We cannot technically guarantee that the author signature really comes from the widget's author. It is like having an envelop with an unsigned letter. The envelop and the letter can come from different sources even if the envelop has a signature. Best Regards, Rainer --- Sent from my mobile device - Originalnachricht - Von: Marcos Caceres marc...@opera.com An: Paddy Byers pa...@aplix.co.jp Cc: Hillebrand, Rainer; WebApps WG public-webapps@w3.org; otsi-arch-...@omtplists.org otsi-arch-...@omtplists.org Gesendet: Thu Mar 26 17:12:20 2009 Betreff: Re: [BONDI Architecture Security] [widgets] new digsig draft On Thu, Mar 26, 2009 at 4:29 PM, Paddy Byers pa...@aplix.co.jp wrote: Hi, Agreed. Can we say were signed with the same certificate instead? I understood that Webapps had agreed to add a signature profile that designates a particular signature as the author signature - and where this is present it is possible to come up with appropriate precise wording as to whether or not two packages originate from the same author. Well, that's basically what we have, but Rainer seems to imply that it is impossible to do this. I think we get as close as we technically can to achieving that goal. However, if that current solution is inadequate, then please send us suggestions. -- Marcos Caceres http://datadriven.com.au T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
[widgets] Further argument for making config.xml mandatory
Hi Marcos, All, I would like to raise a comment in support of making the configuration document at the root of the widget mandatory. The localisation model currently described by [1] allows for multiple configuration documents; zero or one at the root of the widget and zero or one at the root of each locales folder. While we support the approach of allowing localisation of the configuration document (with the addition of the fallback mechanism that has been previously discussed), one concern we had with such an approach was that it doesn't make sense to localise some of the information in the configuration document, for example: the feature element, (the replacement for) the access element, the license element, the id and version attributes (and maybe others?). In fact in some cases, allowing different values could present security risks. Previously we (Vodafone) had considered an approach of requiring user agents to, for example, create a list of all feature elements present in any valid configuration document. We had not yet thought how to handle the case in which the different configuration documents contain different id attribute values. However, now that there is a proposal to make the configuration document at the root of the widget mandatory, I would like to propose that a better (although not pretty) solution would be specify which attributes and elements are localisable. The non-localisable attributes / elements would only be valid if included in the configuration document at the root of the widget. Thoughts? Thanks, Mark [1] http://dev.w3.org/2006/waf/widgets/ Mark Priestley Mobile: +44 (0)7717512838 E-mail: mark.priest...@vodafone.com mailto:mark.priest...@vodafone.com Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001
RE: [widgets-digsig] Updated 5.1 with revised Reference constraint text
Looks good to me - thanks Frederick and Marcos! From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Frederick Hirsch Sent: 18 March 2009 21:03 To: WebApps WG Cc: Frederick Hirsch Subject: [widgets-digsig] Updated 5.1 with revised Reference constraint text I have updated the Widgets Signature editors draft, section 5.1 (use of xml signature) with revised text for Reference constraints. This is revised from what I proposed on list earlier as I tried to make the two cases clear (and disallow other random external references): I replaced: Every ds:Reference used within a widget signature http://dev.w3.org/2006/waf/widgets-digsig/#widget-signature MUST have a URI http://dev.w3.org/2006/waf/widgets-digsig/#uri attribute. Every ds:Reference to an item within the widget signature http://dev.w3.org/2006/waf/widgets-digsig/#widget-signature MUST use an IDREF value for the ds:Reference URI http://dev.w3.org/2006/waf/widgets-digsig/#uri attribute, referring to a unique ID within the widget signature http://dev.w3.org/2006/waf/widgets-digsig/#widget-signature [XML-Schema-Datatypes] http://dev.w3.org/2006/waf/widgets-digsig/#xml-schema-datatypes . Every ds:Reference to a widget file http://dev.w3.org/2006/waf/widgets-digsig/#widget-file MUST use a relative URI expressing the path from the root of the widget resource http://dev.w3.org/2006/waf/widgets-digsig/#root-of-the-widget-resource to the referenced widget file http://dev.w3.org/2006/waf/widgets-digsig/#widget-file [URI] http://dev.w3.org/2006/waf/widgets-digsig/#uri . with Every ds:Reference used within a widget signature http://dev.w3.org/2006/waf/widgets-digsig/#widget-signature MUST have a URI http://dev.w3.org/2006/waf/widgets-digsig/#uri attribute. Every ds:Reference MUST be one of the following two kinds of reference: Reference to content within the same ds:Signature element Every ds:Reference to an item within the widget signature http://dev.w3.org/2006/waf/widgets-digsig/#widget-signature MUST use an IDREF value for theds:Reference URI http://dev.w3.org/2006/waf/widgets-digsig/#uri attribute, referring to a unique ID within the widget signature http://dev.w3.org/2006/waf/widgets-digsig/#widget-signature [XML-Schema-Datatypes] http://dev.w3.org/2006/waf/widgets-digsig/#xml-schema-datatypes . Reference to a widget file http://dev.w3.org/2006/waf/widgets-digsig/#widget-file in the same widget resource http://dev.w3.org/2006/waf/widgets-digsig/#widget-resource The URI attribute of every ds:Reference to a widget file http://dev.w3.org/2006/waf/widgets-digsig/#widget-file MUST be a URL-encoded [URI] http://dev.w3.org/2006/waf/widgets-digsig/#uri zip relative path that identifies a file inside the widget package. A zip relative path MUST conform to the [ABNF] http://dev.w3.org/2006/waf/widgets-digsig/#abnf for zip-rel-path as specified in [Widgets Packaging] http://dev.w3.org/2006/waf/widgets-digsig/#widgets-packaging . Please let me know any additional comment or corrections. Thanks Marcos for suggestions to this wording. (Also removed Inc from Nokia in title page) regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/
RE: [widget-digsig] proposed change to 7.1, common constraints, for algorithms
Hi Frederick, I agree with all of your changes with two comments. The sentence: The Signature MUST be produced using a key of the recommended key length http://dev.w3.org/2006/waf/widgets-digsig/#recommended-key-length is still problematic given that we allow (although discourage) key lengths less than the recommended key length, and probably don't want to rule out the use of longer keys. Suggest changing to: The Signature SHOULD be produced using a key of the recommended key length http://dev.w3.org/2006/waf/widgets-digsig/#recommended-key-length . The Signature MUST comply with Signature method algorithm requirements in the Algorithms section of this document I also think we need to link recommended key length to algorithms now we allow other algorithms to be used, ie if ECDSA is used it would be OK to use shorter keys. Thanks, Mark From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: 18 March 2009 20:34 To: WebApps WG Cc: Frederick Hirsch; Priestley, Mark, VF-Group; Marcos Caceres Subject: [widget-digsig] proposed change to 7.1, common constraints, for algorithms Mark One issue you raised was that we have MUSTS on algorithms in the processing rules in section 7.1, but allow other algorithms in the algorithm section with MAY. After our previous email exchange, I suggest the following changes to section 7.1 in Widget Signature [1] to address this concern: (1) Change item 3b from The Algorithm attribute of the ds:digestMethod MUST be set to a digest algorithm specified in the Algorithms section of this document. to The Algorithm attribute of the ds:digestMethod MUST comply with the digest algorithm requirements specified in the Algorithms section of this document. (2) Change 5a from The Algorithm attribute of the ds:CanonicalizationMethod element MUST be set to a Canonicalization method specified in the Algorithms section of this document. to The Algorithm attribute of the ds:CanonicalizationMethod element MUST comply with the Canonicalization method algorithm requirements specified in the Algorithms section of this document. (3) Change 5b from 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 arecommended key length http://dev.w3.org/2006/waf/widgets-digsig/#recommended-key-length . to The Signature method algorithm used in the ds:SignatureValue element MUST comply with Signature method algorithm requirements in the Algorithms section of this document. The Signature MUST be produced using a key of the recommended key length http://dev.w3.org/2006/waf/widgets-digsig/#recommended-key-length Does this change make sense? Do you have any suggestion or comment? Thanks for the careful review of the draft. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/ [mp] While this is better I think it misses the fact that we are strongly recommending the use of certain algorithms. I still like the idea of including authoring (signing) guidelines/recommendations, ie you can sign your widget using any signature algorithm but if you want it to work across all W3C widget user agents use algorithm X. Same sort of thing for digest algorithm and key length. What do you think?
RE: [widgets] Further argument for making config.xml mandatory
FWIW, I think this will confuse authors... and irritate the poor souls who need to implement this :) Other suggestions are of course welcome! One alternative would be to separate out the non-localisable data into a separate document, eg manifest.xml... But this is also likely to irritate implementers :( -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 19 March 2009 14:25 To: Priestley, Mark, VF-Group Cc: public-webapps@w3.org Subject: Re: [widgets] Further argument for making config.xml mandatory On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Marcos, All, I would like to raise a comment in support of making the configuration document at the root of the widget mandatory. The localisation model currently described by [1] allows for multiple configuration documents; zero or one at the root of the widget and zero or one at the root of each locales folder. While we support the approach of allowing localisation of the configuration document (with the addition of the fallback mechanism that has been previously discussed), one concern we had with such an approach was that it doesn't make sense to localise some of the information in the configuration document, for example: the feature element, (the replacement for) the access element, the license element, the id and version attributes (and maybe others?). In fact in some cases, allowing different values could present security risks. Previously we (Vodafone) had considered an approach of requiring user agents to, for example, create a list of all feature elements present in any valid configuration document. We had not yet thought how to handle the case in which the different configuration documents contain different id attribute values. However, now that there is a proposal to make the configuration document at the root of the widget mandatory, I would like to propose that a better (although not pretty) solution would be specify which attributes and elements are localisable. The non-localisable attributes / elements would only be valid if included in the configuration document at the root of the widget. Thoughts? Proposal: not localizable: widget's id and version attributes. feature and its options access The following elements would be localizable: widget (but no id or version, derived from root config, if available) name description author license icon content preference screenshot FWIW, I think this will confuse authors... and irritate the poor souls who need to implement this :) Kind regards, Marcos -- 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] Digsig optimization
Sorry for the delayed reply - I agree with Frederick's comments and would like to go further and suggest we add a note on how implementations could be smart. Might be worth doing from a security point as well as there could be ways of being smart that aren't so smart if you get what I mean... Thanks, Mark -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: 27 February 2009 13:19 To: marc...@opera.com Cc: Frederick Hirsch; public-webapps@w3.org WG; Priestley, Mark, VF-Group Subject: Re: [widgets] Digsig optimization Marcos Yes, logically there would be two self contained signatures with references to every file in the package. Again Policy indicates which signatures must be verified. What does the packaging spec currently say? To date it has been one distributor spec that must be verified. We should be clearer on this - I think this goes with the changes we make regarding filename sorting and processing. However if both are to be verified, and if the algorithms are the same (which is currently the case given one hash algorithm in widget signatures) an implementation could be smart and calculate the reference hashes once, eliminating that overhead if it were a concern. regards, Frederick Frederick Hirsch Nokia On Feb 27, 2009, at 6:48 AM, ext Marcos Caceres wrote: Hi Frederick, Mark, I have a concern wrt the author signature. It seems that both the author signature and the distributor signature need to sign every file in the package. Does this mean that, to verify a package, you would need to effectively verify everything in the package twice? or is verification of the author signature optional? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[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 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?
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
RE: [widgets] Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures
Comments inline. Thanks, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 February 2009 16:59 To: Priestley, Mark, VF-Group Cc: public-webapps Subject: Re: [widgets] Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures 2009/2/19 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, In response to: Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures; Mark and Marcos - http://www.w3.org/2008/webapps/track/actions/224 I have outlined two alternative approaches to address the issues that currently exist with the processing of multiple digital signatures (see below). Both approaches need some word-smithing but hopefully they provide a decent starting point for us to agree an approach. FWIW I think I prefer Approach 2. Ok, I like approach 2 too. I'll just make it explicit to pass the signatures list across to the user agent that process the digital signatures. However, something resembling approach 1 will need to go into the Widgets Dig Sig spec. I'm not sure this is true. IMHO it should be enough for the Widgets Digital Signature spec to describe the processing of a single digital signature but let's discuss further at the WebApps face-to-face. Some things to note. 1. The signed variable of the configuration document is no longer set (and should be deleted). I can't think of anyway to make this variable useful, especially with multiple signatures and the definition of different types of signature. Ok. Gone. 2. The dependency on the Digital Signature spec is nearly completely removed. There is actually one thing that I think needs to be added - how to find the author signature, but otherwise I think we the specifications can be decoupled. Whoa, hold up there! :) Did we reach a resolution that we were going to include a separate author signature? You're right - I have jumped the gun on this in two ways: 1) The use of an author signature is still for further discussion in the context of the Digital Signture spec. 2) Even if it's agreed we would need to discuss whether it needed to be reflected in the Packaging and Configuration spec. As such, please defer this comment until these other discussions have been concluded, when it may or may not still be relevant. 3. The more I've been thinking about it recently, the more I've come to the conclusion that we should avoid specify anything that equates to a security policy. This is what I have tried to do below, although this does make it necessary to rather obliquely refer to security policies. Agreed. Thoughts and comments welcomed. Thanks, Mark -- Approach 1 -- Step 5 - Process the Digital Signatures Note: The way in which both the author digital signature and distributor digital signature(s) are used is dependent on the security policy implemented by the widget user agent. As such, it is expected that a widget user agent implementing [Widgets-DigSig] will process any digital signatures according to the following algorithm. It is however recognised that a security policy might not require the processing of all of the digital signatures included in the widget package. A widget user agent is therefore able to exit the processing of distributor digital signatures once it has established the information necessary to inform the security decision making process represented by its security policy, eg a signature from a particular end entity has been verified or confirmed as revoked. Exit criteria - A result or set of results from the application of the Procedure for Verifying a Digital Signature Document in the [Widgets-DigSig] to one or more digital signatures that satisfies, positively or negatively, the widget user agents security policy. 1. If present, the widget user agent should apply the Procedure for Verifying a Digital Signature Document, as defined in the [Widgets-DigSig] specification, to the author signature. 2. If the widget user agent determines that an exit criteria has been met: a. If the widget user agent determines that the widget is a valid widget, terminate this algorithm and go to step 6. b. If the widget user agent determines that the widget is an invalid widget, apply the rules for dealing with invalid widgets . 3. Starting with the first file entry in the signatures list; a. Apply the Procedure for Verifying a Digital Signature Document, as defined in the [Widgets-DigSig] specification, to the file entry; b. If the widget user agent determines that an exit criteria has been met: i. If the widget user agent determines that the widget is a valid widget, terminate this algorithm
RE: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec)
Comments inline. Thanks, Mark -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 22 February 2009 16:02 To: Priestley, Mark, VF-Group Cc: Arthur Barstow; public-webapps Subject: Re: [widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec) Hi Mark, 2009/2/19 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, In the email [1] containing my comments against the LCWD of Widgets 1.0: Packaging Configuration spec, I wrote: 7.10 The access Element The access element defines a network attribute as A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. Based on this description we would like to make the following observations and suggestion: The access element contains security permissions that will be used as hooks in the yet to be written [Widgets-Security] specification. The problem is that the permissions haven't yet been discussed in detail and so we may find that we want to represent additional context other than a black and white is network access required?. For example, it may be the case that it is important from a security point of view to know which bearer or protocol will be used, or to nest a set of domains/URLs with which the widget wants to communicate. I do not have a strong view on what might be relevant here, and I am not suggesting that it needs to be considered as part of the last call of the Packaging and Configuration spec, only that it is likely that the permission will need to be more complex when we look at it from a security perspective. Marcos replied: I think we better start this soon, then. My feeling is that we will need some kind of domain access declarations, and I would like to see them in the configuration document. My follow up: Marcos makes the suggestion that he would like to see the access element replaced/extended with domains. Vodafone have come to a similar conclusion. We feel that a widget author should be able to declare the hosts with which they want to communicate. The widget should then only be allowed to communicate with those hosts. This is beneficial for two reasons: 1.) It allows the widget author to practice the principle of least privilege, limiting the potential attack space Agreed. 2.) It allows other parties (users, widget distributors, consuming widget user agents) to inspect the widget to get some idea of who the widget will communicate with, thereby enabling more sensible security decisions to be made. Agreed. There is however one exception that we would like to enable, the ability for a widget author to indicate that their widget might be expected to communicate with any host. This is to allow for use cases such as widget RSS readers. We would therefore like to propose that the access element is extended along the following lines: access network any-host=true/false target host=somehost.com / target host=en.anotherurl.com / /network /access Firstly, this assumes communication over HTTP. I think we need to make this protocol agnostic. How do I indicate I want to use HTTPs? You would need a special purpose URI parse that can parse malformed URIs. I propose the simpler: access network=true domain href=URI / /access The semantics of the URI can be derived from whatever URI type is used (most likely case will be HTTP, in which case you parse the URI semantics using RFC2616). User agents can support whatever URIs they like, or exclude others (e.g., file://). Agreed - with some comments below Declaring network any-host=true/ would mean that regardless of whether the network element contained any child domain elements, the author was declaring that they wanted access to any host (note that by default this value would be false so only authors who wanted access to any host would be inclined to use it). I suggest a special case of domain: domain href=*/ Agreed - the only advantage I saw of using an attribute was that if an author incorrectly specified specific domains and the all domains value, the user agent wouldn't have to process the specific domains that were in error. But I agree this was ugly and support a special domain value as you suggest. There is IMO an open question as to whether it would better to specify: 1. full URLs in place of hostnames, eg: target url=http://somehost.com; / From my point of view, yes... as per the rationale above. I mostly agree but with some follow up questions below... 2. hostnames (to allow for use of http and https and other protocols without requiring multiple declarations), maybe by using an additional attribute, eg: target host=somehost.com protocol=http/ URIs already define all this, so we don't need
RE: [widgets] A revised proposal on widget modes
Many thanks for the feedback - comments inline. Regards, Mark -Original Message- From: timeless.b...@gmail.com [mailto:timeless.b...@gmail.com] On Behalf Of timeless Sent: 21 February 2009 18:28 To: Priestley, Mark, VF-Group Cc: public-webapps Subject: Re: [widgets] A revised proposal on widget modes On Thu, Feb 19, 2009 at 3:36 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: I'm not stuck on the names of the viewmodes and their respective elements. For example, I am inclined to agree with one of the earlier comments that maximised might be a better name for fullscreen. i'd like to offer a preemptive veto of maximised. it's not the correct spelling in en-US, and anything which is likely to be misspelled is a bad start. Fine by me viewmodes default=floating/fullscreen/docked it's hard to tell if you mean that you can specify one of those, or if / is ok. And there's the minor issue of what happens if a certain WUA only supports some of the modes and the widget is only allowed to specify one. Sorry - my example wasn't clear. I meant that the widget author could declare the widgets preferred mode of operation, therefore they would only specify a single value which would be one of the defined keywords. I think i'd rather startview=x,y where there's some rule for whether the first or last supported view is handled. I'd probably prefer: mode name=floating height=300 width=500/ mode name=fullscreen max-height=500 max-width=600/ for the child element, i suspect it's easier to deal w/ validation. Marcos has pointed out some other issues with specifying height and width and so this probably needs rethinking anyway. However, if not, I agree your proposal is preferable.
[widgets] Digital Signature Roles - summary of proposal
Hi All, Below is a copy of the proposal that I sent to Frederick and Marcos following last week's WebApp call to capture the agreements that were reached in regards to defining different signature roles. I'm reposting to the public list to provide background to the updates to that Widgets 1.0: Digital Signature that Frederick plans to provide before the Paris face-to-face meeting. - It should be possible to create a signature - lets call it the author signature - which is used solely for determining who the author of a widget is, and as a result whether or not two widgets came from the same author. The most reliable way of doing this would be if two signatures were created using the same private key but this need not be specified. It should be possible to create a signature - lets call it the distributor signature - that is used to determine that a particular distributor has distributed this widget. Typically this signature might be used to mean something by the consuming widget user agent's security policy, such as allocate this widget to trust domain X. Again I don't think the use of this signature needs to be specified here. The properties for each signature type are as follows. Author signature - Instances allowed: zero or one - Located: at the root of the widget - Name: Some reserved file name, eg author-signature .xml - Generated over: All widget resources excluding distributor signatures - Role property: eg http://www.w3.org/2009/widgets-digsig#role-author Distributor signature - Instances allowed: zero or more - Located: at the root of the widget - Name: signature *[0-9].xml - Generated over: All widget resources excluding other distributor signatures but including the author signature (if present) - Role property: eg http://www.w3.org/2009/widgets-digsig#role-distributor In addition to the above, the rules for generation and verification of the reference elements would need to be updated to be dependent on the role of the signature. I think that's the only significant change needed to the current spec, along with changing of the usage property to a role property. To make life easy for readers it may also be desirable to define different types of signature corresponding to the different roles. - Comments welcome. Thanks, Mark Mark Priestley Security Expert Vodafone Group RD Mobile: +44 (0)7717512838 E-mail: mark.priest...@vodafone.com mailto:mark.priest...@vodafone.com www.betavine.net http://www.betavine.net/ - Web betavine.mobi - Mobile Web Vodafone Group Services Limited Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001
[widgets] Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures
Hi All, In response to: Action #224 - Work with Marcos to flesh out the details of the processing model for multiple signatures; Mark and Marcos - http://www.w3.org/2008/webapps/track/actions/224 http://www.w3.org/2008/webapps/track/actions/224 I have outlined two alternative approaches to address the issues that currently exist with the processing of multiple digital signatures (see below). Both approaches need some word-smithing but hopefully they provide a decent starting point for us to agree an approach. FWIW I think I prefer Approach 2. Some things to note. 1. The signed variable of the configuration document is no longer set (and should be deleted). I can't think of anyway to make this variable useful, especially with multiple signatures and the definition of different types of signature. 2. The dependency on the Digital Signature spec is nearly completely removed. There is actually one thing that I think needs to be added - how to find the author signature, but otherwise I think we the specifications can be decoupled. 3. The more I've been thinking about it recently, the more I've come to the conclusion that we should avoid specify anything that equates to a security policy. This is what I have tried to do below, although this does make it necessary to rather obliquely refer to security policies. Thoughts and comments welcomed. Thanks, Mark -- Approach 1 -- Step 5 - Process the Digital Signatures Note: The way in which both the author digital signature and distributor digital signature(s) are used is dependent on the security policy implemented by the widget user agent. As such, it is expected that a widget user agent implementing [Widgets-DigSig] http://www.w3.org/TR/2008/WD-widgets-20081222/#widgets-digsig will process any digital signatures according to the following algorithm. It is however recognised that a security policy might not require the processing of all of the digital signatures included in the widget package. A widget user agent is therefore able to exit the processing of distributor digital signatures once it has established the information necessary to inform the security decision making process represented by its security policy, eg a signature from a particular end entity has been verified or confirmed as revoked. Exit criteria - A result or set of results from the application of the Procedure for Verifying a Digital Signature Document in the [Widgets-DigSig] http://www.w3.org/TR/2008/WD-widgets-20081222/#widgets-digsig to one or more digital signatures that satisfies, positively or negatively, the widget user agents security policy. 1. If present, the widget user agent should apply the Procedure for Verifying a Digital Signature Document, as defined in the [Widgets-DigSig] http://www.w3.org/TR/2008/WD-widgets-20081222/#widgets-digsig specification, to the author signature. 2. If the widget user agent determines that an exit criteria has been met: a. If the widget user agent determins that the widget is a valid widget, terminate this algorithm and go to step 6 http://www.w3.org/TR/2008/WD-widgets-20081222/#step-6-determine-the-bas e-folder-and-widget-locale . b. If the widget user agent determines that the widget is an invalid widget, apply the rules for dealing with invalid widgets. 3. Starting with the first file entry in the signatures list; a. Apply the Procedure for Verifying a Digital Signature Document, as defined in the [Widgets-DigSig] http://www.w3.org/TR/2008/WD-widgets-20081222/#widgets-digsig specification, to the file entry; b. If the widget user agent determines that an exit criteria has been met: i. If the widget user agent determines that the widget is a valid widget, terminate this algorithm and go to step 6 http://www.w3.org/TR/2008/WD-widgets-20081222/#step-6-determine-the-bas e-folder-and-widget-locale . ii. If the widget user agent determines that the widget is an invalid widget, apply the rules for dealing with invalid widgets, c. Otherwise, select the next file entry http://www.w3.org/TR/2008/WD-widgets-20081222/#file-entry in the signatures http://www.w3.org/TR/2008/WD-widgets-20081222/#signatures list and go to 3a in this algorithm. 4. If all of the file entries in signatures have been processed and no exit criteria has been met, go to step 6 http://www.w3.org/TR/2008/WD-widgets-20081222/#step-6-determine-the-bas e-folder-and-widget-locale . -- Approach 2 -- Step 5 - Process the Digital Signatures It is expected that the widget user agent will process the digital signatures in accordance with its security policy. This
[widgets] The access element (was: RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec)
from a Vodafone perspective and as someone who participates in both W3C WebApps and BONDI, ideally we would like to see the solution specified in W3C and then simply referenced in BONDI. With BONDIs current specifications being at Candidate Release status until the 9th March there is still a good opportunity to achieve this kind of alignment. I realise that it's late in the day to be specifying new elements but I think there are real advantages to extending the access element in the way proposed and it addresses a real use case. As always, comments, questions and suggestions are welcomed! Thanks, Mark [1] http://www.mail-archive.com/public-webapps@w3.org/msg02058.html [2] http://bondi.omtp.org/Documents/CR10/BONDI_Architecture_Security_Task_CR 10.pdf -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 04 February 2009 17:35 To: Priestley, Mark, VF-Group Cc: Arthur Barstow; public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec Hi Mark, On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- -- -- Substantive comments -- -- -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget., on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing, but it seemed like a good idea to put this in here at the time. In other words, this is something that is controlled by the Widgets Dig Sig spec. If it turns out that Widgets Dig Sig never results in an invalid widget situation, then I will take this out. I've created a red note in the spec that says Issue: [Widgets-DigSig] may never identify a widget package as invalid as a reminder that we need to sort this out. FWIW, I think step 5 is buggy and needs a rewrite (I've added another issue to the spec stating as such). I'll need to work with you to fix it as we progress the Dig Sig spec. --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. Good point. This seems like something that needs to be in the yet to be written a widget runtime security spec. I've added an issue note to the spec so we don't forget about this. Just out of interest, can you present the nature of the security hole? i.e., once an attacker has the signature, say, via an XSS attack, what could they do with it? --- 7.10 The access Element The access element defines a network attribute as A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. Based on this description we would like to make the following observations and suggestion: The access element contains security permissions that will be used as hooks in the yet to be written [Widgets-Security] specification. The problem is that the permissions haven't yet been discussed in detail and so we may find that we want to represent additional context other than a black and white
RE: ISSUE-80: Runtime localization model for widgets [Widgets]
Hi Marcos, All, I think we're all roughly on the same page about potential changes to the localisation model and should therefore be able to specify something that keeps everyone happy. I'll try and illustrate using an example. Widget resource is localised, with the following file structure: /config.xml /index.html /picture.png /locales/es/config.xml /locales/es/index.html /locales/es/picture.png /locales/en/config.xml /locales/en/picture.png /locales/ja/config.xml /locales/ja/index.html The desired behaviour is that the widget author can reference the relevant picture.png file without forking index HTML files unnecessarily. As long as the localisation algorithm allows the author to use img src=picture.png/ in any index.html file and get back the file they are expecting they will be happy. If the base folder is / (ie the user's locale doesn't match one of the included locales) then img src=picture.png/, refers to a file that exists (/picture.png) so there is no problem. If the base folder is /locales/es/ then then img src=picture.png/, refers to a file that exists (/locales/es/picture.png)so there is no problem. The same is true if the base folder is /locales/en/, as even though the config file is at the root of the widget the img src resolves to /locales/en/picture.png. The interesting case is when the base folder is /locales/ja/, in which case img src=picture.png/ in the localised index.html file does not refer to a file that exists in the localised folder. I believe that following your discussion with Josh your suggestion was that, on failure to locate the file in the base folder, the widget user agent should look for the file at the root of the widget. This makes perfect sense to me, and is a change we would support; it makes life simpler for the author by removing the need to fork HTML. Furthermore, if this fallback behaviour was specified there should be no need for authors to use the leading / as the widget user agent would do the work for them. In fact with the fallback behaviour specified I can't think why an author would want to use the leading /, with the possible exception of performance? So while I'm not suggesting that we change the semantics of URIs, if we specify the fallback behaviour authors could get by without using the leading /, thereby largely addressing Jon's concerns. We may even want to encourage using the fallback mechanism in the specs, for example using an non-normative note. Any thoughts? Thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 12 February 2009 14:07 To: Jon Ferraiolo Cc: Web Applications Working Group WG Subject: Re: ISSUE-80: Runtime localization model for widgets [Widgets] 2009/2/5 Jon Ferraiolo jfer...@us.ibm.com: I am all in favor of *not* having to replicate many files in the widget distribution just so you can create localized versions of a single image. One more thing I'll add. One of the URL techniques in the Widgets spec, using / as the first character in a relative address, works OK in widget workflows where the content is always wrapped in a ZIP, but in various Web Widget workflows, the widget contents are often exploded into a file system where the root of the widget is not the root of the file system or the root of the Web site. In those scenarios, you can't use / as the first character in a relative address, which means the entire set of files would have to be duplicated for each locale. Hardly ideal. A slash a the front always indicates an absolute path. We are not changing the semantics of URIs. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
No problem. From http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0346.html: [mp] The hole is that signature files are excluded from the generation of the signature values in any other signature files. This means that if, for example, an attacker added to the widget resource a signature file containing some malicious content, the malicious content of that file wouldn't be covered by any of the other signatures but the widget user agent thinks the entire widget resource is signed. This could happen regardless of whether or not the signature file was actually valid, or was just named according to the convention for digital signature. To be abused by an attacker it would either be necessary to inject a reference to the file into the widget, which might be difficult, or to hijack an existing reference to a signature file by swapping the intended signature file for the attacker's signature file (with the same name). While this later attack depends on the author providing such a reference in their widget, there are two reasons why the author may currently choose to do this - to get some information about the signature to display to the user, or possibly more likely, to get around the need to sign everything in their widget resource (I thought of this as a way around signing everything so developers will too!). It's not a big hole and the attacks require some assistance from developers, but unless there's a reason not to it should be pretty easy to close. I realise that this still requires the ability to read in the file, which would probably have to be via a local Ajax call, not a reference as I suggested above. You could say that it's a pretty theoretical vulnerability but if it's easy to fix and there's no negatives then I think we should address it. Thanks, Mark -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 13 February 2009 13:27 To: Priestley, Mark, VF-Group Cc: Frederick Hirsch; Barstow Art (Nokia-CIC/Boston); public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec Hi Mark, 2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com: [mp] To be clear I was suggesting that access to signatures was restricted from the widget after installation. I was not suggesting that they were not more generally available. As you say access to signatures after installation (outside of the widget) is useful and should be supported. Could you please explain what the security implications of allowing a widget to have access to the signatures at runtime? (apologies if you have done this in another email, I might have missed it). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
A very brief response below, marked [mp] Thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Hillebrand, Rainer Sent: 11 February 2009 08:03 To: Marcos Caceres Cc: public-webapps@w3.org Subject: RE: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property Hi Marcos, I am not aware of any feedback on your e-mail. Here is mine. Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Dienstag, 27. Januar 2009 11:56 To: Priestley, Mark, VF-Group; public-webapps@w3.org Subject: Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property Hi Mark, Some minor comments below. Bar a few clarifications, I mostly agree with your proposal. On 1/26/09 1:35 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: A possible solution to this problem would be to require an updates to be signed using the same private key that was used to sign the previous version of the widget archive. Essentially this update signature would securely link an update to an installed widget resource by nature of the fact that they had both been signed by someone with access to the same private key. I'm ok with this so long as it an auxiliary feature and that updates can be performed over plain-old HTTP without requiring a certificate. If an implementer chooses to deviate from this model by disallowing updates that lack a digital signature, that is their prerogative. Irrespective, I am of the position that we must architecture the update model to work without signatures and then progressibly enhance the update model firstly through HTTPS and then through signatures. RH: An update may not need to be signed. This depends on the original widget resource that shall be updated. An update for a widget resource should only be processed if it has the same or a higher security level than the original widget resource. For example, a signed widget resource that was installed from a memory card shall not be updated with an unsigned update package that was retrieved from a web server without SSL/TLS. On the other hand, a signed update package should update a widget resource that was retrieved from a web server without SSL/TLS. [mp] As a general comment, I think this is a pretty difficult problem to address in a secure manner. IMO the most reliable way of authorising an update would be through the use of an update signature however, HTTPS provides a workable alternative and plain HTTP might be fine in other circumstances. For what it's worth I think that the real security issue is how the update is handled but this doesn't mean defining an update signature is not useful.
RE: [widgets] Getting synch'ed up on Widgets Digital Signatures
Thomas Roessler wrote: Just for clarity, there are two possible requirements around OCSP and CRLs: - support embedding an OCSP response (or a CRL, or a link to a CRL) in the mark-up of signatures - support querying OCSP responders (and CRLs) as part of certificate validation I'd argue that the latter is more important than the former. [mp] I agree latter is more important, but see below... Frederick Hirsch wrote: we need explicit schema support (in Signature 1.1) for explicit OCSP responses, for the latter a processing rule in widgets signature may be enough. Perhaps this does not need to be required must in the widgets spec, depends on requirements. Mark, I believe you mentioned you have additional thoughts on these requirements. [mp] The requirements state that it must be possible to include revocation information in the signature, and when present that the specification should say how to process this information [3]. On re-reading this requirement, I wonder whether we didn't fold two requirements into one and not get it quite right... In any case, looking at the requirement afresh, as Thomas and Frederick suggest, the ability to include OCSP responses in signatures should be addressed in XML Signature Syntax and Processing Version 1.1 [4]. Our requirement should probably be changed to be the ability to process revocation information contained in the signature, and should probably be a SHOULD. In regards to the processing of revocation information, orignally I was pushing for Widgets 1.0: Digital Signatures [1] to include an OCSP and CRL profile to try and help ensure interoperability between OCSP/CRL clients and responders/servers across organisations. My suggestion for an OCSP profile would have been to reference (or take inspiration from) the OMA Online Certificate Status Protocol Mobile Profile [2], however, I'm no longer sure that this is a good idea. This profile is obviously aimed at mobile devices and therefore may create inter-operability issues for non-mobile implementations (and mobile implementations that don't follow OMA). So more generally, I would propose that OCSP and CRL processing should be removed from [1]. The reasoning being that it is likely that other standards bodies, companies and organisations will want to specify this behaviour in order to work with their existing infrastructure. I am more and more of the opinion that [1] should simply provide the format and processing rules that enables the use of interoperable signatures across widget user agents. How these signatures are used should be covered elsewhere. Thanks, Mark [1] http://dev.w3.org/2006/waf/widgets-digsig/ [2] http://www.openmobilealliance.org/Technical/release_program/docs/copyrig htclick.aspx?pck=OCSPfile=V1_0-20070403-A/OMA-WAP-OCSP_MP-V1_0-20070403 -A.pdf [3] http://dev.w3.org/2006/waf/widgets-reqs/#r49.-inclusion-of-revocation-in formation [4] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/ -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: 04 February 2009 20:53 To: ext Thomas Roessler Cc: Frederick Hirsch; Barstow Art (Nokia-CIC/Boston); Priestley, Mark, VF-Group; ext Marcos Caceres; public-webapps Subject: Re: [widgets] Getting synch'ed up on Widgets Digital Signatures we need explicit schema support (in Signature 1.1) for explicit OCSP responses, for the latter a processing rule in widgets signature may be enough. Perhaps this does not need to be required must in the widgets spec, depends on requirements. Mark, I believe you mentioned you have additional thoughts on these requirements. regards, Frederick Frederick Hirsch Nokia On Feb 4, 2009, at 3:49 PM, ext Thomas Roessler wrote: On 4 Feb 2009, at 21:45, Arthur Barstow wrote: * Is supporting OCSP and CRL a MUST for v1? Just for clarity, there are two possible requirements around OCSP and CRLs: - support embedding an OCSP response (or a CRL, or a link to a CRL) in the mark-up of signatures - support querying OCSP responders (and CRLs) as part of certificate validation I'd argue that the latter is more important than the former. -- Thomas Roessler, W3C t...@w3.org
RE: ISSUE-80: Runtime localization model for widgets [Widgets]
Having discussed this internally and gone through some examples we agree with the issue identified by Josh. In addition, concerns were raised that even without the prospect of authors forking html to create localised content - which we agree is highly undesirable, debugging localised widgets could become more cumbersome, i.e. a case of checking all relative paths to see if they started with a / or not. A simple override behaviour is easier to understand, and, in our opinion, debug. We therefore support specifying the kind of behaviour outlined by Josh, i.e. first check the base folder for the file, if no match is found and if the base folder isn't the root, checking there using the same filename. My follow up question is that if this behaviour is specified then can't we also get rid of the behaviour relating to the leading / for relative paths in widgets? Maybe this is already implicit in Josh's proposal? This would also seem to partly address Jon's concerns below. Thanks, Mark From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jon Ferraiolo Sent: 05 February 2009 06:44 To: Web Applications Working Group WG Subject: Re: ISSUE-80: Runtime localization model for widgets [Widgets] I am all in favor of *not* having to replicate many files in the widget distribution just so you can create localized versions of a single image. One more thing I'll add. One of the URL techniques in the Widgets spec, using / as the first character in a relative address, works OK in widget workflows where the content is always wrapped in a ZIP, but in various Web Widget workflows, the widget contents are often exploded into a file system where the root of the widget is not the root of the file system or the root of the Web site. In those scenarios, you can't use / as the first character in a relative address, which means the entire set of files would have to be duplicated for each locale. Hardly ideal. Jon Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Sent by: public-webapps-requ...@w3.org 02/02/2009 03:51 PM Please respond to Web Applications Working Group WG public-webapps@w3.org To public-webapps@w3.org cc Subject ISSUE-80: Runtime localization model for widgets [Widgets] ISSUE-80: Runtime localization model for widgets [Widgets] http://www.w3.org/2008/webapps/track/issues/80 Raised by: Josh Soref On product: Widgets Below is a discussion I had with Josh about the localization model for widgets. Josh identifies an issue that may affect localization at runtime that may be overcome by having the widget engines dynamically change folders when it can't find resources. timeless.b...@gmail.com: how do localized folders work anyway? Sent at 12:01 AM on Sunday timeless.b...@gmail.com: oh, it's hidden in base folder me: you put folders that follow the lang-place pattern into a folder called locale. The UA looks for a folder that matches the user's locale prefs timeless.b...@gmail.com: i'm not quite sure i understand or like that imagine i have 100 images and only want to localize 2 if base-folder means that i have to copy the whole set, i'm unhappy me: no, just make all your refs absolute. it's no problem timeless.b...@gmail.com: no, definitely bad that means i have to know in advance if i need to localize a path instead of just having 1 locale that needs to localize a file me: yes. But it supports multiple models of localization. So the model is quite flexible. timeless.b...@gmail.com: supporting a virtual mapping would have been better :( me: we can always change it if you have a better proposal timeless.b...@gmail.com: i guess the simplest question is would you ever have a localized file foo.bar and want access to the original unlocalized file timeless.b...@gmail.com: i claim no me: no, you wouldn't the idea is that you only localize what you want. timeless.b...@gmail.com: yeah so, in my model, instead of 'base folder' a localized file i18n/en-GB/index.html appears as /index.html if the UA selects en-GB me: I'm sure we are thinking of the same thing here, but now I'm worried I've done this wrong. timeless.b...@gmail.com: (so searches go first to i18n/en-GB/ and then to /)
RE: [widgets] Comments on the 22-Dec-2008 LCWD of the Widgets 1.0: PC spec
3. Signature handling should be specified in [Widgets-DigSig], thus, replace all of Step 5 in section 8.2 with the following: [[ The algorithm that describes how to process the list of signatures created in step 4 is defined in [Widgets-DigSig]. ]] And add the processing model currently defined in Step 5 to [Widgets-DigSig]. I need to discuss this change with the editor's of the Widget Dig Sig spec before doing that. I'll get back to you shortly about that. [mp] I know that this is part of a broader discussion on the digital signature spec, but for what its worth I think the packaging and configuration spec should cover how to handle multiple signatures while simply referencing the digital signatures spec for the processing of the actual signature document. Putting the handling of multiple signatures this into the digital signatures spec would IMHO bloat it in an undesirable way. It is possible that the best place for some of this may be in the mythical [Widget Security] spec. Thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 31 January 2009 13:32 To: Arthur Barstow Cc: public-webapps Subject: Re: [widgets] Comments on the 22-Dec-2008 LCWD of the Widgets 1.0: PC spec Hi Art, On Sat, Jan 31, 2009 at 12:48 PM, Arthur Barstow art.bars...@nokia.com wrote: I propose the following changes to the 22 December 2008 PC LCWD [1]: 1. As currently written, the spec implies a Widget User Agent must support [Widgets-DigSig]. I think that requirement is too strong and must be relaxed. To address this, change the first paragraph in Section 3.0 to: [[ A widget user agent is a user agent that implements this specification. A widget user agent should implement other specifications in the Widgets 1.0 family of specifications such as [Widgets-APIs], [Widgets-DigSig], and [Widgets-Updates] specifications. ]] Ok, fair enough. However, I think the words such as does not make the assertion sound particularly definitive. I think it MUST that widget engines support the APIs and a SHOULD that they support updates and sigs. New text: A widget user agent is a user agent that attempts to implement this specification. A widget user agent MUST also support the [Widgets-APIs]. A widget user agent SHOULD support the [Widgets-DigSig] specification and the [Widgets-Updates] specification. As you did, I removed reference to the fictional [Widget Security] specification :) 2. Change the first paragraph of Step 4 in section 8.2 to: [[ If a widget user agent does not support [Widgets-DigSig], go to Step 6; otherwise, the algorithm to locate digital signatures for the widget is as follows: ]] Done. 3. Signature handling should be specified in [Widgets-DigSig], thus, replace all of Step 5 in section 8.2 with the following: [[ The algorithm that describes how to process the list of signatures created in step 4 is defined in [Widgets-DigSig]. ]] And add the processing model currently defined in Step 5 to [Widgets-DigSig]. I need to discuss this change with the editor's of the Widget Dig Sig spec before doing that. I'll get back to you shortly about that. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
developers, but unless there's a reason not to it should be pretty easy to close. -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 04 February 2009 17:35 To: Priestley, Mark, VF-Group Cc: Arthur Barstow; public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec Hi Mark, On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- -- -- Substantive comments -- -- -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget., on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing, but it seemed like a good idea to put this in here at the time. In other words, this is something that is controlled by the Widgets Dig Sig spec. If it turns out that Widgets Dig Sig never results in an invalid widget situation, then I will take this out. I've created a red note in the spec that says Issue: [Widgets-DigSig] may never identify a widget package as invalid as a reminder that we need to sort this out. FWIW, I think step 5 is buggy and needs a rewrite (I've added another issue to the spec stating as such). I'll need to work with you to fix it as we progress the Dig Sig spec. --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. Good point. This seems like something that needs to be in the yet to be written a widget runtime security spec. I've added an issue note to the spec so we don't forget about this. Just out of interest, can you present the nature of the security hole? i.e., once an attacker has the signature, say, via an XSS attack, what could they do with it? --- 7.10 The access Element The access element defines a network attribute as A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. Based on this description we would like to make the following observations and suggestion: The access element contains security permissions that will be used as hooks in the yet to be written [Widgets-Security] specification. The problem is that the permissions haven't yet been discussed in detail and so we may find that we want to represent additional context other than a black and white is network access required?. For example, it may be the case that it is important from a security point of view to know which bearer or protocol will be used, or to nest a set of domains/URLs with which the widget wants to communicate. I do not have a strong view on what might be relevant here, and I am not suggesting that it needs to be considered as part of the last call of the Packaging and Configuration spec, only that it is likely that the permission will need to be more complex when we look at it from a security perspective. I think we better start this soon, then. My feeling is that we will need some kind of domain access declarations, and I would like to see
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
agent may use bigger heights and widths if it wants to? Equally should there be default sizes in case the attribute is not used? Hmm... good point. I've added that as an issue in the relevant section. [mp] OK - no strong opinion on this I was just really asking a question In terms of raster graphics the text currently says If the file pointed to by the src is a supported raster graphic, this value may be ignored by the widget user agent. but shouldn't the may in this case be a should? Correct, but that should should be a must. Fixed. [mp] Even better, thanks. --- 7.13 The feature Element In the sentence The feature is used by an author to denote that, at runtime, a widget may require access to a feature. the use of may require is very slightly confusing given that the next attribute is required. Suggest changing require to try to or attempt to. Changed require to attempt to. [mp] Thanks Likewise in the definition of the name attribute in the sentence A URI attribute that identifies a feature required by the widget at runtime (such as an API). change required by to that may be used. Done. [mp] Thanks --- 8 Steps for Processing a Widget Resource The sentence The steps for processing a widget resource involves ten steps that a widget user agent must follow, in sequential order, responding accordingly if any of the steps result in an error. could be slightly misleading as some of the steps are skipped depending on the processing in a preceding step. I'm not sure if this is always in a response to an error? Ok, I changed it to: The steps for processing a widget resource involves ten steps that a user agent must follow, in sequential order, responding accordingly if any of the steps result in an error or if the specification asks for the user agent to skip a step. Is that any better? [mp] Yep - sorry if I was being over pedantic :( A minor comment on section 8 as a whole - some of the steps have an explicit link to go to the next step while others (like 9) don't. It would be nice if this was consistent. Ok, I checked every step and made sure things are consistent. Once all the comments are done, I'll do another editorial round to make sure everything is more consistent. In addition, some of the algorithms, for example step 7, could be made clearer by explicitly stating when to go to the next step (i.e. in case of success in 7.1 and 7.2). Ok, I did what you said for step 7 and Step 8. Can you let me know which other ones need a rewrite? Finally, in Step 6 there is a sentence Else, remove the last subtag of the range and repeat this step 2.d. (e.g., if the range Just to be super clear perhaps this step 2.d. could be change to and go to 2.d of this algorithm Made the change you suggested. [mp] All of the above changes for Section 8 look good to me- thanks. -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 04 February 2009 17:35 To: Priestley, Mark, VF-Group Cc: Arthur Barstow; public-webapps Subject: Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec Hi Mark, On Thu, Jan 29, 2009 at 6:29 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- -- -- Substantive comments -- -- -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget., on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. Sorry, I think you might have misunderstood what I was trying to say here (probably I did not write it clearly enough). This assertion is here to deal with instances where the digital signature deemed by the Widgets Dig Sig spec to be somehow fully broken or completely non-conforming in such a way that all processing must stop. I don't yet know if Widgets Dig Sig will spit out such a result for any digsig it is processing
[widgets] Strawman requirements for widget (view/display/window) modes
Hi All, Closing the action 291 (http://www.w3.org/2008/webapps/track/actions/291) please find below a strawman for a set of requirements relating to widget (view/display/window) modes. I have tried to define the requirements without basing them on any of the technical solutions that have been discussed to date. I am in no doubt that the proposed requirements need discussion and refinement - essentially, they are meant only as a starting point. It's over to the group now to agree how best to progress them - I welcome any suggestions on how they could be improved. Thanks, Mark - Strawman Requirement for widget modes - 1. There MUST be a defined set of display modes for a Widget. For each defined display mode, the way in which the Widget is displayed MUST be specified so that the rendering of the Widget is consistent across Widget User Agents. The display modes SHOULD be based on the most common display modes existing in widget implementations today. Proprietary display modes MAY be supported by the Widget User Agent. Rationale: This is required if Widget Authors are to be able to design Widgets that work across different Widget User Agents in a consistent manner. Without this feature, Widget Authors will end up developing Widgets for specific Widget User Agents. Failure to define a core set of display modes will also confuse Users. Allowing proprietary display modes provides a means to support innovative UIs. 2. There MUST NOT be a display mode for each possible screen dimension. Rationale: Such an approach is not scalable and fails to leverage the ability to define flexible layouts, e.g. using CSS and JavaScript. 3. It MUST be possible for a widget author to indicate the preferred display mode of a Widget. Rationale: Some Widgets will suite being displayed in a particular display mode. Having designed the Widget to run in a particular display mode the author should be able to request that the Widget opens in that display mode. Widget User Agents may choose to ignore this indication, for example if they do not support the indicated display mode. 4. It SHOULD be possible for a widget author to indicate to the Widget User Agent which display modes the Widget has been designed to run in. The Widget User Agent MAY ignore the indications of display mode supported. Rational: Some Widgets will not be designed to work in some modes. It should be possible for the author to indicate this to the Widget User Agent. This allows the Widget User Agent to provide a better user experience, e.g. by advising the user that the widget is not designed to work in a particular display mode. 5. It MUST be possible for a widget author to indicate the preferred dimensions of the widget in each display mode in the Configuration document of the Widget. The Widget User Agent MAY ignore the preferred dimensions. Rationale: The Widget Author may have designed their Widget such that viewing it with larger or smaller dimensions than those indicated will negatively effect the user experience. This is especially true in the case in which Widgets are expected to run on devices with very different screen dimensions, e.g. a mobile, a monitor, a TV. 6. Switching from one mode to another MUST not require the re-instantiation of the Widget. Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining any processes that were in progress. Rationale: Users will expect the state of their widget to be maintained when switching between modes. 7. It MUST be possible for a Widget to change the content it presents for rendering in reaction to a display mode change. Rational: The Widget may need to adapt the content displayed when it moves from one mode to another. 8. It MUST be possible for a Widget to change its behaviour in reaction to a display mode change. Rational: The Widget may need to adapt its behaviour when it moves from one mode to another, for example if a content is changed, actions related to new/removed elements might need to be started/stopped. 9. The Widget User Agent MAY display the same instance of a Widget in multiple display modes at the same time, subject to any behavioural restrictions based on individual display modes. If supported, it SHOULD be possible to react to user interaction with one display mode in the other display modes. Rationale: To allow maximum flexibility in UI design, while ensuring a certain level of consistency across Widget User Agents. 10. The Widget User Agent MUST be able to move a Widget between display modes. Rational: If a Widget User Agent supports multiple display modes it should allow the user to switch between display modes at runtime. It is for discussion whether a Widget should be able to move itself to a new display mode as there may be security concerns dependent on the display modes that are
RE: [widgets] Widget modes
We share Yoan's concerns. In addition believe that in lots of cases most of the content (in the broadest sense) will be the same between modes and only the presentation will need to be changed. In cases in which the content is different, we feel this would be better addressed programmatically and/or through styling, thereby avoiding the need for redundant html. I would however like to return to the agreement that was made on the call of the 22nd - to list requirements for modes before attempting to agree a technical proposal. I am currently working on a strawman to circulate early next week but from this email exchange I will add something like: It MUST be possible to maintain the state of a widget when moving between widget view modes. I would encourage anyone who has an opinion on this topic to try and formulate their thoughts in the form of requirements. I will then be happy to collate and, as far as possible, merge into a single set of requirements for discussion. Many thanks, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Yoan Blanc Sent: 30 January 2009 09:52 To: SUZANNE Benoit RD-SIRP-ISS Cc: public-webapps Subject: Re: [widgets] Widget modes The problem I see by having different html pages for each mode is that you cannot handle keeping the state of a widget when changing from one mode to the other. expanded - iconized - expanded I expect my widget to stay in the same state. content src=minimumbackgroundaction.js mode=hidden/ How is this supposed to work? The state of the application while running is stored into its content file, into window (for the JavaScript part) and document (for the HTML part). Regards, -- Yoan Widget Developer, Opera Software ASA On Thu, 29 Jan 2009, SUZANNE Benoit RD-SIRP-ISS wrote: Hi all, about the widget windows modes, I wanted to share the following points: *** Wording *** In the wordings of the modes, I think that the wording used in some of the modes are too specific to existing platforms, therefore I propose the following names: * Icon: I'm not sure this one is really a mode as it is already dealt with in the rest of the spec in the right manner with a static image format * Iconized: this mode will allow to define an icon that can be adapted to the content status, for example a weather icon will display the right cloud or sun based on the real time information. This is possible using the svg, but I believe this is one of the modes of displaying information in a widget. * Expanded: this is the reference to the existing floating mode in the spec or the undocked mode for vista * Minimized: this is the reference to the existing docked mode in the spec but is too restrictive in the wordings * Full screen: now for this one my worry is more the fact that there are other attributes that should be available for this mode as the display can be specific to the orientation (landscape or portrait) and to the size of the screen's device (vga, qvga, ...) * Hidden: I like the proposition from mark to allow a widget to run as a background task that can awaken an action, so you would probably need to add this as a mode as well. * Settings: I would also like to add the settings of the widget as a specific mode as this will largely simplify the coding of the widget where all the various screens to display will all be defined as modes. ***Context*** The way I see this implemented is that based on the platform actions (drag on a widget bar for example) the platform would switch from one view to the other. Or based on a code input in the hidden mode, a widget would be able to call it's Minimized mode through the code. In this context the one thing that needs to be included is how to pass parameters from one mode to the other, but that could be resolved using some kind of parametered declaration. ***Usage*** I do not see the mode as an element, but as an item of the content element, see examples below. ***Code example*** In the format to use the modes I propose the following as a bases for discussions: content src=miniview.html mode=minimized/ content src=index.html mode=expanded default=true flying=true/ content src=fullscreen-vga.html mode=fullscreen width=640 height=480/ content src=fullscreen-wvga.html mode=fullscreen width=854 height=480 orientation=landscape/ content src=fullscreen-wvga.html mode=fullscreen width=854 height=480 orientation=portrait/ content src=minimumbackgroundaction.js mode=idden/ content src=settings.html mode=settings/ What do you think? Best Regards, Benoit [IMAGE] Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 benoit.suza...@orange-ftgroup.com [IMAGE]
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
Hi Marcos, Art, All, Please find below Vodafone's comments on the Widgets 1.0: Packaging and Configuration specification. I have divided them into what I consider to be substantive comments and editorial comments. Thanks, Mark -- Substantive comments -- Step 5 Process the Digital Signatures We disagree with the stage 2, specifically If the file entry is deemed by the [Widgets-DigSig] to be an invalid widget, then a widget user agent must treat this widget as an invalid widget., on two grounds: (1) Because one signature is invalid it doesn't mean that all of the signatures are invalid; (2) Just because one signature or all signatures are invalid does not mean that the widget should not be installed, only that it should _not_ be treated as a signed widget. The security policy of the device might be configured not to install an unsigned widget or a widget with an invalid signature but this should be dependent on the security policy implemented. --- Step 4 Locate Digital Signatures for the Widget I'm not sure whether the packaging and configuration specification is the correct place to do this but IMHO there needs to be a statement that a files with a file name corresponding to the naming convention for digital signatures are not accessible from the widget once the widget is installed / instantiated. Failure to impose this restriction will make it possible to include a signature and then reference it from the signed code, which presents a security hole. --- 7.10 The access Element The access element defines a network attribute as A boolean attribute that indicates that the widget might need to access network resources as specified in [Widgets-Security]. Based on this description we would like to make the following observations and suggestion: The access element contains security permissions that will be used as hooks in the yet to be written [Widgets-Security] specification. The problem is that the permissions haven't yet been discussed in detail and so we may find that we want to represent additional context other than a black and white is network access required?. For example, it may be the case that it is important from a security point of view to know which bearer or protocol will be used, or to nest a set of domains/URLs with which the widget wants to communicate. I do not have a strong view on what might be relevant here, and I am not suggesting that it needs to be considered as part of the last call of the Packaging and Configuration spec, only that it is likely that the permission will need to be more complex when we look at it from a security perspective. There is also the case in which the network permission may be used to determine whether or not the user wants to install a widget, or by the widget user agent may want to indicate whether or not the widget can run when there is no available network connection. Some widgets may only operate when there is a network connection, whereas others may degrade gracefully. So to provide a degree of future-proofing we would like to suggest something like: access network use=true/false required=true/false/ /access (I realise that the use attribute in the above example is a horrible name but I couldn't think of another word for access...There are probably also better ways of capturing the meaning - we open to suggested improvements) Sorry for not raising this earlier but it has only become apparent when considering in more detail how the access element would be used. -- Editorial comments -- 6 Widget Resources First 5 bullets should say and/or rather than or ? --- 6.5 Content Localization The container for localized content is a folder at the root of the widget whose the first five characters of the folder-name case insensitively match the string 'locales/'. Why the first five characters only? Also sentence has an extra the in the middle, i.e. whose *the* first --- 6.6 Start file and Default Start Files Sentence For consistency with other sections I suggest to add: A default start file is a start file whose file-name case insensitively matches a file-name given in the first column of the default start files below and whose MIME type matches the MIME type given in the second column of the table. before the sentence starting: A default start file is a start file that a widget user agent... And then to combine the last two sentences before the default start files table to: A
RE: [widgets] A proposal on widget modes
Hi Arve,
Thanks for your feedback - I'm glad our thinking is along similar lines.
Some responses to your comments below.
Thanks,
Mark
-Original Message-
From: Arve Bersvendsen [mailto:ar...@opera.com]
Sent: 20 January 2009 20:53
To: Priestley, Mark, VF-Group; public-webapps
Subject: Re: [widgets] A proposal on widget modes
On Tue, 20 Jan 2009 20:58:41 +0100, Priestley, Mark, VF-Group
mark.priest...@vodafone.com wrote:
Hi All,
In the current Widgets 1.0: Packaging and Configuration
specification
[1], the window modes feature is identified as being at risk.
Vodafone
believes that window modes are an important feature and should be
supported in Widgets 1.0. This email provides a proposal for
how modes
could be specified and why we think this would be of value. Our
proposal is based on our experiences with current and
prototype widget
implementations, however, we welcome any suggestions on how this
proposal could be improved.
Mostly, this proposal is in line with what Opera wants, but a
few specific comments follow.
Vodafone has identified the need for floating, fullscreen and docked
modes. We have not identified a need for an application
mode, although
we recognise that this may not be aimed at mobile devices. We would
therefore support the addition of the following attribute definition
to
[1]:
Application mode is required outside of a mobile context, to
differentiate between chromeless (e.g. Opera
Widgets/Dashboard/etc) and widgets with OS Chrome (e.g. the
Adobe AIR view state model)
[MP] We are of course fine with an application mode being defined, we
just
don't have an opinion on what it should be... From your description we
assume it will be as per the floating mode but with chrome?
A keyword attribute whose value is one of the following valid modes:
floating, fullscreen, docked. The default value, which is used when
the attribute is omitted or has a value other than one of the valid
modes, is floating.
See above regarding 'application'. 'floating' is equivalent
to what we have in the past named 'widget', but frankly, I
think 'floating' might be a better choice of word
[MP] We agree
Also, there is some different in expected behaviour between
these modes -- I'll dig up the specific text Opera has for
supporting view states, and how it interacts with the initial
viewport size, and behavior of CSS.
The mode Element
The mode element represents the modes that a widget has been
designed
to operate in.
I am a bit unsure about whether an attribute, or an element is
the right choice here. Either way, if an element is the
preferred choice, I would prefer something that would remain
unambigous for a foreseeable future. 'viewmode'?
[MP] We feel that if there is more than one attribute related
to the display of the widget it makes sense to group them together in an
element. We agree viewmode is better than mode
default
Optional. A mode attribute that indicates the default mode of
operation for a widget.
Depends on whether this should be an element or attribute.
a.)onModeChange - an event triggered when the widget
transitions to a
new mode;
It needs to be specified _when_ this event is triggered. Is it
prior to the mode switch taking place? Is it a DOM event, or
a callback. Is it cancellable?
[MP] We think that this should be a DOM event that takes place after the
switch of modes. Not cancellable.
b.)getMode - an API that returns the current mode of the widget,
alternatively this could be a property of the widget object;
ECMAScript bindings have little tradition for using getters
this way. What about
interface Widget {
/* ... */
readonly attribute DOMString currentMode; }
(Alternatively, replace DOMString with an unsigned integer)
[MP] We agree that this is a better approach and prefer the use of a
DOMString
c.)onBlur - an event triggered when the widget loses focus;
d.)onFocus
- an event triggered when the widget gets focus;
Blur and focus events are already de facto part of the window
object, and as such is out of scope here, but should perhaps
be mentioned as part of HTML
[MP] Agreed
e.)resize(height, width) - an API for changing the size of a
floating
widget; f.)onResize - an event triggered when the widget is re-sized
in floating mode;
Also part of Window:
resizeTo(in int width, in int height);
resizeBy(in int delta_x, in int delta_y);
[MP] Agreed - although we want to make clear that this should only be
applicable
to floating (and application) modes
g.)getDockSize() - an API that returns the size of the dock(s)
supported by the widget user agent.
Dock size is tricky as an implementation may want to support
simultaneous display of the dock and of the widget. This is
essentially an unsolved problem, and I would rather we drop
docking features for now.
[MP] We understand the problem that you highlight but we feel strongly
that docked
mode should be supported
[widgets] A proposal on widget modes
Hi All, In the current Widgets 1.0: Packaging and Configuration specification [1], the window modes feature is identified as being at risk. Vodafone believes that window modes are an important feature and should be supported in Widgets 1.0. This email provides a proposal for how modes could be specified and why we think this would be of value. Our proposal is based on our experiences with current and prototype widget implementations, however, we welcome any suggestions on how this proposal could be improved. Thanks, Mark --- Proposal --- Vodafone has identified the need for floating, fullscreen and docked modes. We have not identified a need for an application mode, although we recognise that this may not be aimed at mobile devices. We would therefore support the addition of the following attribute definition to [1]: Start of addition-- Mode Attribute A keyword attribute whose value is one of the following valid modes: floating, fullscreen, docked. The default value, which is used when the attribute is omitted or has a value other than one of the valid modes, is floating. End of addition-- Vodafone has also identifed the need to allow a widget author to declare a preferred mode of operation in the configuration document. This value would be used by the widget user agent to determine which mode to start the widget in. If a widget user agent does not support the indicated mode it should open the widget in floating mode. Vodafone also believes that it should be possible for a widget to be able to indicate which modes it has been designed to support. We therefore propose the introduction of a mode element, i.e. Start of addition-- The mode Element The mode element represents the modes that a widget has been designed to operate in. Context in which this element may be used: In the widget element. Content model: Empty. Occurrences: Zero or one. Attributes default Optional. A mode attribute that indicates the default mode of operation for a widget. fullscreen Optional. A boolean attribute that indicates whether the widget has been designed to run in fullscreen mode. dockable Optional. A boolean attribute that indicates whether the widget has been designed to run in dockable mode. Usage Example This section is non-normative. This example shows the expected usage of the mode element. widget xmlns=http://www.w3.org/ns/widgets; mode default=floating dockable=true fullscreen=false/ /widget End of addition-- The fullscreen and dockable attributes would be used by the widget user agent to determine whether it should support transition to the indicated mode. For example, if a widget declared dockable=false the widget user agent should not try and render the widget within a dock and might instead choose to display the widget's icon. It is expected that all widgets will be capable of running in floating mode. There is therefore no need to indicate support for floating mode, i.e. using a floating attribute. --- Background --- The following text is provided as background information to support the proposal above. It defines the supported widget modes, their expected behavioural differences and the relationship to configuration elements. It is not our expectation that any of this text should be included in the Packaging or Configuration specification but we hope it will be useful in explaining our proposal and as input to the drafting of the APIs and Events specification. A widget mode is a visual and behavioural state of a widget instance. As such, each widget instance can only be in a single mode at any one given time. Transition from one mode to another may be triggered by user interaction and potentially by the widget itself, although this is for further study. Widget user agents may support the ability to open multiple instances of the same Widget Resource, in which case each instance will have its own independent mode. Only one widget instance can ever operate in fullscreen mode at any one time. A widget user agent may display icons as shortcuts to instantiated widgets, however an icon is not considered to be a widget mode. The widget user agent is expected to provide the APIs, events and properties to support modes, e.g.: a.)onModeChange - an event triggered when the widget transitions to a new mode; b.)getMode - an API that returns the current mode of the widget, alternatively this could be a property of the widget object; c.)onBlur - an event triggered when the widget loses focus; d.)onFocus - an event triggered when the widget gets focus; e.)resize(height, width) - an API for changing the size of a floating widget; f.)onResize - an event triggered when the widget is re-sized in floating mode; g.)getDockSize() - an API that returns the size of the dock(s) supported by the widget
RE: Comments on Widgets 1.0 Security requirements
Hi Frederick, All, As promised on last week's call some further clarifications below on R44. Thanks, Mark (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.- This requirement is unclear. Is the intent to say that a signature associated with a widget package might be extracted and served to a client independently of the package, allowing the package to be delivered without the signature inside of it? Or is it saying that the certificate chain and/or revocation information should be able to be accessed independently of the package? In general it might not make sense to validate a signature without access the widget content, since that is not meaningful unless it is possible to validate the content hashes used to generate and validate the signature. [MP] Re-reading the requirement I agree we could have been clearer in what we were requiring, which is: 1. It MUST be possible to extract a _copy_ of the digital signature document(s) from the widget package. 2. It SHOULD (MUST?) be possible for the widget user agent to complete the signature validation processing for a digital signature document that is provided independently of a widget package (noting that the signature is not validated until the reference validation processing has also been successfully completed) When we write the specification text to meet this requirement we will need to ensure that the error cases are covered, e.g. when the independently supplied and packaged digital signature do not match. With these clarifications hopefully the requirement and rationale make more sense? Although one can extract a signature XML element from a widget package, I'm not sure how meaningful that is if one cannot subsequently locate the content that is signed - for example if a ds:Reference refers to an item in the widget package, how can an extracted signature be validated if that item is no longer available? Along similar lines, I might expect the URI for a resource to be relative if the signature is always enveloped (the signature is within the widget package containing the signature and other items) but perhaps a full URL for detached, when the signature is stored separately from the signed items. I do not think this requirement is met by the Widgets Signature document as it states The URI attribute must be a relative path to the root of the widget. how will this work with detached signatures where the widget content is not in the same context as the signature? [MP] I think there is still some confusion over the use case we're trying to address. There is no desire to complete the validation of the signature document before the widget package has been downloaded and therefore no need to use anything other than relative paths in the reference elements. The main motivation for providing the signature document in advance of the widget package is to allow the widget user agent to check whether it has the necessary root certs installed to validate the signature's cert chain. If the widget agent can't do this it may choose not to download the widget package. In some cases there may be an advantage to validating the signature value of the signature document in advance of downloading the widget package, noting that the entire signature document will not be validated until the reference validation has also been successfully completed. However, as stated on the call, it is not the intention to specify this use of the signature document in Widgets 1.0. As such the only requirement on the specification is that it does not rule out this use case, e.g. by specifying that reference validation must always happen before validation of the signature value. My understanding is that the current text is fine in this regards. -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: 07 January 2009 18:36 To: Priestley, Mark, VF-Group Cc: Frederick Hirsch; public-webapps; Thomas Roessler Subject: Re: Comments on Widgets 1.0 Security requirements Mark Some more discussion inline, thanks for taking the time to review. Do you mind updating the draft with the items we agree? regards, Frederick Frederick Hirsch Nokia On Jan 7, 2009, at 11:03 AM, ext Priestley, Mark, VF-Group wrote: Hi Frederick, Thanks for your comments. As someone who had a hand in some of the requirements that you've commented on, please see some responses inline. Regards, Mark -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Frederick Hirsch Sent: 05 January 2009 22:22 To: public-webapps Cc: Frederick Hirsch; Thomas Roessler Subject: Comments on Widgets 1.0 Security requirements I have some comments on requirements section 4.6, Security and DIgital Signatures, editors draft [1], and some concrete suggestions for changes: (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44
RE: [widgets] Digital Signatures questions for discussion
Hi All, Marcos, Frederick and I met with Thomas at the recent W3C Security workshop and were able to answer the questions that I had put forward following the face-to-face discussion with the XML Security working group in Mandelieu. In short we agreed: 1. DSA-SHA256 will be specified as a second mandatory Signature Algorithm. The XML Security working group will specify the necessary URI as this is currently not available. 2. The Widgets 1.0: Digital Signature specification will mandate the use of a Usage element (in place of the profile element). This will allow signatures to be created that can be used for different purposes with different processing requirements. Exact details to be worked out. 3. The Widgets 1.0: Digital Signatures specification will support the use of a Timestamp element. This will allow the signature to have a shorter lifetime than the certificate associated to it. The timestamp need not be generated by a trusted time stamp authority - it will only be valid provided that the certificates associated to the signature are also still valid (not expired or revoked) 4. The Usage and Timestamp elements will be specified in a separate specification so that they can be used by other specifications based on XML DigSig. Frederick has drafted an initial proposal at http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/ Thomas/Marcos/Frederick - please feel free to correct or add to the above. Comments and questions welcomed. Thanks, Mark From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of David Rogers Sent: 14 November 2008 15:59 To: public-webapps@w3.org Subject: [widgets] Digital Signatures questions for discussion Dear all, In Mark Priestley's absence, he has asked me to forward these questions for discussion within WebApps, with the intention of this group submitting to the XML Digital Signatures group. These questions are in response to the discussions at TPAC: 1. While it is recognised that there is a broad move to elliptic curve techniques, please can you provide an explanation for your recommendation that DSA should not be supported even with 2048 bit keys? Note: We are aware that there is no published specification describing the use of DSA with key lengths over 1024 but there is a NIST draft[1] (publication process due to start before the end of the year). It has also been noted that there are concerns around licensing on elliptic curve technologies. 2. Please can you explain in more detail how you would propose to use the profile element? 3. Similarly, please can you explain how the addition of the timestamp would help with the revocation process? We assume that you require the timestamp to come from a Trusted Timestamp Authority [1] http://csrc.nist.gov/publications/drafts/fips_186-3/Draft-FIPS-186-3%20_ March2006.pdf Thanks, David. David Rogers OMTP Director of External Relations
RE: [widgets] Minutes from 7 August 2008 Voice Conference
Hi Art, All, Unfortunately I won't be able to attend today's call but would like to provide feedback on some of the discussions from last week's call. On the addition to R11, specifically: A conforming specification SHALL specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHALL be treated as unsigned. A conforming specification SHALL specify that the widget environment SHALL not install or load a widget resource when it can determine that any certificate in the chain has been revoked. There was a desire to clarify what was and wasn't allowed and to check that this didn't lead to any inconsistent behaviour. To re-cap this addition was a result of a desire to treat widgets that are known to be bad (e.g. that have been revoked) differently from widgets for which the widget platform cannot verify the signature because of missing or out of date information. In the former case we're suggesting that the correct action would be to not install the widget, in the latter the widget should be treated as if it hasn't been signed. The issue was identified on the call that in some cases revoked certificates are removed from CRLs once they have expired. In this case the above rules could lead to revoked widgets being treated as unsigned widgets, which would not be satisfactory. To address this case we suggest the addition of the following sentence: CRLs for certificates used in certificate chains associated to signed widgets SHALL include expired certificates I think a similar proposal was made by Thomas on the call and to us it is the best way to resolve the issue. On the comments to R38 there was a desire to re-word our proposal on the ability to add new root certificates. The proposal was: A conforming specification SHOULD define mechanisms to enable end-users to install additional root certificates, provided this is compatible with the security policy of the widget processing environment. The suggested re-wording would look something like: Implementations MAY 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. There was also a discussion on the new requirement titled Signing procedure agnostic. The request was to re-formulate this requirement so that it was specific to the widget specifications. However, having looked in detail at the PKCS#11 specification we are inclined to suggest that the requirement is possibly out of scope. The PKCS#11 specification details how applications can use the interface and what this means in terms of their processing logic but it should be possible to meet the requirements it makes with whatever scheme is defined in W3C. We still believe that PCKS#11 support will be vital for widespread adoption of the specification but perhaps on closer inspection this specification is not the right place to make this a requirement. We of course welcome any feedback on the above. I look forward to meeting you all in Turin, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arthur Barstow Sent: 07 August 2008 13:25 To: public-webapps Subject: [widgets] Minutes from 7 August 2008 Voice Conference The minutes from the August 7 Widgets voice conference are available at the following and copied below: http://www.w3.org/2008/08/07-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before August 14 (next voice conference); otherwise these minutes will be considered approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 07 Aug 2008 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2008JulSep/0318.html See also: [3]IRC log [3] http://www.w3.org/2008/08/07-wam-irc Attendees Present Art, Nick, David, Luca, Claudio, Mark, Marcos, Thomas, Arve, Bryan Regrets Chair Art Scribe Art Contents * [4]Topics 1. [5]Agenda Review 2. [6]Annoucements 3. [7]R11 Digital Signatures 4. [8]R38 Addtional Digital Certs 5. [9]Proposed Requirements 6. [10]Signing Procedure Agnostic 7. [11]AOB * [12]Summary of Action Items _ Date: 7 August 2008 scribe Scribe: Art tlr whooops scribe ScribeNick: ArtB tlr zaim, I am thomas marcos I would never! marcos :) marcos oh crap. I'll dial in again. marcos tlr, was it me? marcos hmmm,
