RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

Hi Frederick,

Some comments inline below.

Thanks,

Mark 

>-----Original Message-----
>From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] 
>Sent: 11 February 2009 23:21
>To: Priestley, Mark, VF-Group
>Cc: Frederick Hirsch; Marcos Caceres; Barstow Art 
>(Nokia-CIC/Boston); public-webapps
>Subject: Re: Reminder: January 31 comment deadline for LCWD of 
>Widgets 1.0: Packaging & Configuration spec
>
>I'm not sure restricting access to a signature is desirable 
>since signatures are intended to be objects that can be 
>evaluated etc - there is even a widget requirement that they 
>can be removed and conveyed independently of the widget.
>Thus I assume access to the signature is possible outside the 
>context of the engine.
>

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

>XML Signature is used in many applications where signatures 
>are to be shared and used - the idea is that it should be a 
>secure object in and of itself. If there is a security risk it 
>should then be addressed, but restricting access to the 
>signature should not be necessary.
>

[mp] See above comment - my explanation below explains that while
signatures may be secure in of themselves there is (an admittedly edge)
case in which the presence of multiple signatures could create a
problem. 

>Addition or removal of signatures might be an issue however, 
>if signature elements are not included in overall integrity 
>protection of the entire widget. 

[mp] Yes, this is the cause of the issue but I think it is a necessary
behaviour if we are to allow multiple signatures, which is what we are
aiming for. 

>This might be mitigated to 
>some degree by certificate requirements, especially if widgets 
>are always required to be signed. We might want to clarify the 
>requirements, now they seem to require signing but the email 
>discussion suggests unsigned widgets as well.

[mp] I don't think this is necessary. The requirements, as I understand
them, require support for signed widgets but not that all widgets are
signed, which I think is fine. To address the issue I outlined below (if
we agree that it is an issue) we just need to make the signature files
unavailable to the widget at runtime. They are identified by a filename
pattern so this shouldn't be hard.

>
>Is there currently any specification of how policy is 
>expressed and handled in the context of widgets? I didn't see 
>anything on the wiki.  

[mp] Not in the W3C Widgets specs AFAIK

>Absent expressed policy, will widget installation and use be 
>possible?  
>If so then a simpler rule might be required for signature 
>validation success since there will be "nobody there" to 
>evaluate response codes.

[mp] I agree that we might need a simple default policy in the case that
there is "nobody there", but it should be possible to override this
policy if there is a policy has been implemented by "someone"

>
>Moreover, how is a policy engine to know what a verification 
>success/ failure for a variety of possible signature 
>usage/role types and/or signers to be handled, will rules be 
>expressed in terms of usage/role (e.g. distributor) and what 
>else? The model is not clear to me.
>

[mp] without meaning to provide a circular answer, I assume that this
will be down to the policy engine. What I think it is important for the
Digital Signatures spec to provide is the hooks for the policy engine to
act on. 

>regards, Frederick
>
>Frederick Hirsch
>Nokia
>
>
>
>On Feb 6, 2009, at 10:51 AM, ext Priestley, Mark, VF-Group wrote:
>
>>
>>
>> Hi Marcos,
>>
>> More responses to your comments below (marked [mp]). Still 
>need to get 
>> back to you on the access element but I need to think about it a bit 
>> more first.
>>
>> Thanks,
>>
>> Mark
>>
>>
>>> ----------------------
>>> 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.
>>
>> [mp] No this was pretty much my understanding. Maybe my 
>comment wasn't 
>> clear enough... IMO [Widgets-DigSig] should result in a list of 
>> signature status values. How the widget user agent responds to those 
>> values should be dependent on the security policy of the widget user 
>> agent.
>>
>> 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.
>>
>> [mp] Well I would argue that the [Widgets-DigSig] will never 
>identify 
>> a widget package as invalid although it may decide that one or more
>> signature(s) are invalid. The security policy of the device 
>may decide 
>> that the widget shouldn't be installed based on the result of 
>> processing the signature file(s) but that is a different thing. I 
>> think that best we can do in the P&C spec is say whether or not the 
>> widget is signed (and even this could be tricky).
>>
>> 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.
>>
>> [mp] I'll be available to work on this next week
>>
>>> -----------------------------------------------
>>> 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?
>>
>> [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.
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Marcos Caceres [mailto:marcosscaceres@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.Priestley@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 them in the configuration document.
>>>
>>> __This has the potential to block progress of this specification.__
>>>
>>>> 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,
>>>
>>> This sounds reasonable.
>>>
>>>> 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.
>>>
>>> This sounds like something authors need to deal with, not user  
>>> agents.
>>>
>>>> So to provide a degree of future-proofing we would like to suggest
>>>> something like:
>>>>
>>>> <access>
>>>>   <network use="true/false" required="true/false"/> </access>
>>>
>>> We might not need this at all, actually: If we go down the
>>> declaring domain route, then network is off unless a domain is
>>> declared.
>>>
>>>> (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)
>>>
>>> This needs further discussion.
>>>
>>>> Sorry for not raising this earlier but it has only become apparent
>>>> when considering in more detail how the access element would be  
>>>> used.
>>>
>>> No probs.
>>>
>>>>
>>>>
>>> 
>----------------------------------------------------------------------
>>>> --
>>>> ----------------------
>>>> Editorial comments
>>>>
>>> 
>----------------------------------------------------------------------
>>>> --
>>>> ----------------------
>>>> 6 Widget Resources
>>>>
>>>> First 5 bullets should say "and/or" rather than "or" ?
>>>
>>> "Zero and/or more" sounds weird to me (i.e., "Zero and more").
>>> If you feel strongly about this, I will change it; otherwise,
>>> I would prefer to leave it as is.
>>>
>>>> -----------------------------------------------
>>>> 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?
>>>
>>> That was a mistake, the sentence now reads:
>>> "The container for localized content is a folder at the root
>>> of the widget whose folder-name case insensitively match the
>>> string 'locales/'. A container for localized content may
>>> contain zero or more localized folders."
>>>
>>>> Also sentence has an extra "the" in the middle, i.e. "whose
>>> *the* first"
>>>
>>> fixed.
>>>
>>>> -----------------------------------------------
>>>> 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..."
>>>
>>> Ok, I think there was a more significant problem: I've defined
>>> "custom start files" and "default start files". As a result, I
>>> changed that whole section.
>>>
>>>> And then to combine the last two sentences before the default start
>>>> files table to:
>>>>
>>>> "A widget user agent will attempt to locate a file entry whose
>>>> file-name case insensitively matches one of the default start files
>>>> based on the order they appear in the table below (from top
>>> to bottom). "
>>>
>>> Can you please check that section again and let me know if the
>>> rewrite is ok?
>>>
>>>> -----------------------------------------------
>>>> 7.1 Namespace
>>>>
>>>> It seems a bit tough that an invalid configuration document
>>> results in
>>>> a invalid widget as the configuration document is 
>optional. Also, if
>>>> the configuration document in the localised folder is invalid, it
>>>> could be the case that there is a valid configuration
>>> document at the
>>>> root of the widget.
>>>>
>>>> I don't have a strong opinion on this and have no objection
>>> to leaving
>>>> the text as it is, I just wondered if there was a reason why this
>>>> approach had been taken?
>>>
>>> Although I agree that it's a bit cruel on developers, we made
>>> this decision to make the behavior of configuration documents
>>> predictable.
>>> I feel pretty strongly that we should leave it as is.
>>>
>>>> -----------------------------------------------
>>>> 7.2 Proprietary Extensions
>>>>
>>>> Should the "may" be a "should"? Otherwise, it could be
>>> interpreted as
>>>> suggesting that vendors may equally use other approaches?
>>>
>>> Right, fixed. This should, in fact, be a must (i.e., if you
>>> want to extend, then you must use your own namespace).
>>>
>>>> -----------------------------------------------
>>>> 7.9 The icon Element
>>>>
>>>> (disclaimer - I may well be talking rubbish here as the following
>>>> comments are based on a _very_ basic understanding of graphics
>>>> formats)
>>>>
>>>> The text says that if the icon is vector format then the height and
>>>> width attributes will be used, however, isn't one the 
>point of using
>>>> vector graphics that they could be re-sized to fit the
>>> available space.
>>>
>>> Yes and no. Beyond certain sizes (e.g., too little, too big),
>>> the rendering engine may have undesirable effects on a design
>>> (think, for example, of a really tiny font having anti-alias
>>> applied to it:
>>> because of sub-pixel interpolation, it becomes too blurry to
>>> read. The same can happen with graphics, very thin lines can
>>> vanish or become blurry, which can make a design look crappy).
>>> In such cases, it may be desirable to use a bitmap.
>>>
>>>> Therefore shouldn't there be a statement saying that the 
>widget user
>>>> agent MAY ignore these values?
>>>
>>> No, the width and height attributes represent the _minimum_
>>> size at which an image may be used. Then, the vector graphic
>>> can behave in the manner you describe (i.e., can be used to
>>> fill a rendering context larger than the width and height).
>>>
>>>> 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.
>>>
>>>> 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.
>>>
>>>> -----------------------------------------------
>>>> 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".
>>>
>>>> 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.
>>>
>>>> -----------------------------------------------
>>>> 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?
>>>
>>>> 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.
>>>
>>> Very much appreciate Vodafone taking the time to conduct 
>this review.
>>>
>>> Kind regards,
>>> Marcos
>>> --
>>> Marcos Caceres
>>> http://datadriven.com.au
>>>
>>
>
>

Received on Thursday, 12 February 2009 09:10:42 UTC