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.Hirsch@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 "MUST"s however the sections 
>where we 
>> describe Digest Algorithms, Signature Algorithms and recommended key 
>> lengths the text currently allow the use of undefined other 
>algorithms 
>> and key lengths. This seems inconsistent. I think we need to 
>allow for 
>> the use of other algorithms and key lengths but at the same time we 
>> have to somehow state that a widget user agent MUST support the base 
>> set defined in the specification, and authors should use 
>these if they 
>> want to ensure interoperability. As such, perhaps 3b and 5b would be 
>> better included as authoring guidelines?
>
>how about replacing:
>
>The ds:Signature MUST meet the following requirements:
>
>	* The Algorithm attribute of the 
>ds:CanonicalizationMethod element MUST be set to a 
>Canonicalization method specified in the Algorithms section of 
>this document.
>	* The ds:SignatureValue element MUST contain a 
>signature generated using a Signature method specified in the 
>Algorithms section of this document and MUST use a key that is 
>of the length of a recommended key length.
>with
>
>
>
>The ds:Signature MUST meet the following requirements:
>
>	* Algorithms MUST conform to requirements given in the 
>algorithms section of this specification.
>
>re is really no need to say this except to make sure it is not 
>missed, since the algorithms section outlines algorithm 
>requirements. I'm also ok with removing this entirely. What do 
>you think?)

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

>
>>
>>
>> 8
>>
>> "Implementations that store the content of widget archives 
>to the file 
>> system during signature verification MUST NOT trust any path 
>> components of file names present in the archive, to avoid 
>overwriting 
>> of arbitrary files during signature verification."
>>
>
>
>> {Comment] I don't understand this sentence - which may well be a 
>> problem with my understanding rather than the sentence - please can 
>> you enlighten me, thanks.
>>
>>
>
>
>I think this is better worded as:
>
>Implementations MUST NOT overwrite <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?)
>
>> ---------------------------
>> Editorial comments
>> ---------------------------
>>
>> General Terminology
>>
>> "Widget agent", "widget platform", "application"? -> "widget user
>> agent"?
>>
>> "signature", "digital signature(s)" -> "widget signature(s)"
>
>some instances refer to the widget signature file (widget signature)  
>other to an XML Signature itself, some to generic signature  
>operations. I'll take a look to clarify.
>
>>
>>
>> "Policy" -> "Security policy"
>
>ok
>>
>> "author widget signature" -> author signature (or vice versa)
>
>ok
>
>>
>>
>> "distributor widget signature" -> distributor signature (or vice  
>> versa)
>
>ok
>
>>
>>
>> "Digest method" -> "Digest Algorithm"
>>
>> Also, as a general comment, not all defined terms are linked  
>> throughout
>> the document.
>>
>
>doesn't it get to be a bit much to link every instance?  If a term is  
>linked once in a paragraph/list, I suggest not linking it again in  
>that same paragraph/list.
>
>>
>> 1.4
>>
>> "Example of a distributor signature document, named signature.xml:"
>>
>> [Change] "signature.xml" -> "signature1.xml"
>
>yes
>
>>
>>
>> 4
>>
>> [Comment] Has it been decided to move this processing to the Digital
>> Signatures specification rather than the Packaging and Configuration
>> specification? FWIW I think it's cleaner to have it in the 
>Packaging  
>> and
>> Configuration specification but I don't have strong feelings either  
>> way.
>>
>
>it was decided by the WG I believe.
>
>>
>> 5.2
>>
>> "The author signature can be used to determine the author of 
>a widget,
>> that the widget is as the author intended, and whether two widgets  
>> came
>> from the same author."
>>
>> [Comment] The author signature _may_ be used to determine whether two
>> widgets came from the same author, ie it depends whether the same
>> private key was used.
>> [Change] "and whether two widgets came from the same author" 
-> "and  
>> may
>> be used to determine whether two widgets came from the same author"
>
>isn't this saying the same thing with more words?

[mp] It's close but what I was trying to emphasize is that two author
signatures will not always allow you to reliably make the link between
the author (the author may use different private keys) but it will
always allow you to determine the author the widget and it's integrity,
hence the difference of using can verses may.

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

Received on Monday, 16 March 2009 20:47:19 UTC