RE: [widgets] Getting synch'ed up on Widgets Digital Signatures

Hi Art,

Some specific responses to your points:
 
>* Is supporting multiple signatures per package a MUST for v1?

[mp] Vodafone would say yes. IMHO I don't think it's that hard to
specify - depending a bit on how we address other issues. 

>* Is supporting OCSP and CRL a MUST for v1?

[mp] Vodafone view: Support for embedded OCSP responses and CRLs in the
signature = No. Support for some sort of revocation checking = yes but
having thought about this some more I don't think it's something we
should specify in Widget 1.0: Digital Signatures [1] (see my other
email). There are however some things we need to specify support for in
the certificate format/processing to support revocation checking.  

>* What is the relationship between DigSig and Widget Updates?

[mp] Vodafone would like to see the definition of an "update signature"
to support the authentication and authorisation of updates. We do not
think that "update signatures" are a must for the updates spec or even
that they must be specified in [1] (although that would be nice) but we
do feel strongly that [1] shouldn't make it impossible or difficult to
specify "update signatures", or other types of signatures, at a later
date.  

Thanks,

Mark


[1] http://dev.w3.org/2006/waf/widgets-digsig/





>-----Original Message-----
>From: Arthur Barstow [mailto:art.barstow@nokia.com] 
>Sent: 04 February 2009 20:45
>To: Priestley, Mark, VF-Group; ext Marcos Caceres; Thomas 
>Roessler; Frederick Hirsch; public-webapps
>Subject: [widgets] Getting synch'ed up on Widgets Digital Signatures
>
>Hi All,
>
>I think it would be helpful to back up a bit and make sure 
>we're all synch'ed on the critical use cases and requirements 
>for v1.0 of the Widgets DigSig spec before continuing to 
>discuss inputs for that spec.
>
>I realize Marcos will not be able to attend the Feb 12 Widgets 
>call (09:00 Boston time), but I would like to use that meeting 
>to exclusively discuss the Widgets DigSig.
>
>Among the discussion points are:
>
>* What are the main use cases regarding creation, installation 
>and updating?
>
>* Are the related requirements in [Reqs] "right" or do they 
>still need some work?
>
>* What are the security implications and threats?
>
>* Is supporting multiple signatures per package a MUST for v1?
>
>* Is supporting OCSP and CRL a MUST for v1?
>
>* Properties - what are the specific use cases and 
>requirements for each of the proposed properties?
>
>* What is the relationship between DigSig and Widget Updates?
>
>Comments welcome and will be reflected in the agenda.
>
>-Art
>
>[Reqs] <http://dev.w3.org/2006/waf/widgets-reqs/>
>
>
>
>Begin forwarded message:
>
>> From: ext Marcos Caceres <marcosscaceres@gmail.com>
>> Date: January 27, 2009 5:56:19 AM EST
>> To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, 
>> "public-webapps@w3.org" <public-webapps@w3.org>
>> Subject: Re: [widgets] Comment on Widgets 1.0: Digital Signatures - 
>> the Usage  property
>> Archived-At: <http://www.w3.org/mid/C5A498D3.3E8C%
>> 25marcosscaceres@gmail.com>
>>
>>
>>
>> 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.Priestley@vodafone.com> wrote:
>>
>>>
>>> Hi All,
>>>
>>> The following email aims to clarify an idea that was discussed on a 
>>> couple of WebApps calls, most recently on the 8th Jan [3]. 
>It relates 
>>> to being able to re-use the digital signature format that we are 
>>> defining for a range of use-cases and is linked to the 
>definition of 
>>> the usage property. Apologies in advance for the length of 
>the email 
>>> but I felt it was important to try and explain the idea fully to 
>>> illustrate how a relatively small change could provide far greater 
>>> flexibility in the use of the specification.
>>>
>>> -------------------------------------------
>>> Using Widgets 1.0: Digital Signatures
>>> -------------------------------------------
>>>
>>> The initial goal of the Widgets 1.0 Digital Signature specification 
>>> [1] was to provide a mechanism that reliably allowed an end use to
>>> determine:
>>>
>>> (1) The identity of the distributor(s) of a widget archive;
>>>
>>> (2) The integrity of the widget package - i.e. the widget archive 
>>> received by the end user is the same as the widget archive supplied 
>>> by the distributor.
>>
>> Right...
>>
>>> This information could by used by the end-user or the consuming 
>>> widget user agent to make a decision about whether or not 
>to install 
>>> the widget and, in some cases, to inform the configuration of 
>>> security policies associated to the widget (it is noted that the 
>>> configuration of actual security policies is an 
>implementation issue 
>>> and out of scope of [1]).
>>
>> I definitely agree that security policy related stuff is out 
>of scope 
>> for [1]. But where are we going to do this work? This comment is not 
>> directed at you, Mark, but at the working group in general. 
>I think it 
>> would be a good idea to start parallel discussion around this issue 
>> ASAP.
>> Architecturally,
>> all these things are interrelated and should probably be specified 
>> together.
>>
>>> The use of a PKI and technologies such as OCSP and CRLs 
>could enable 
>>> the revocation of a widget signature, and thereby (again, depending 
>>> on the implemented security policy) the revocation of the widget 
>>> itself, which could be useful in the case that it was found to 
>>> malicious.
>>
>> Agreed.
>>
>>> To address the case in which the same widget might be 
>distributed by 
>>> multiple parties each of whom want to sign the widget archive, [1] 
>>> allows for the inclusion of multiple widget signatures in the same 
>>> widget archive.
>>
>> Right.
>>
>>> Recent updates to [1] have introduced the usage property and some 
>>> associated semantics.
>>>
>>> I would like to propose a change to the definition of the usage 
>>> element and some other relatively small changes to allow for 
>>> different processing to be applied to signatures with 
>different usage 
>>> properties.
>>> This is desirable as it would allow signatures to be used for 
>>> different purposes in parallel. Below I outline two 
>possible uses of 
>>> widget signatures as an illustration of how this 
>functionality could 
>>> be used.
>>> While I think the use-cases are real I am happy to discuss them in 
>>> more detail if there are differing views. However, regardless of 
>>> whether or not the signature uses described below are 
>accepted and/or 
>>> others are defined, I hope that they help support the need to make 
>>> the reference processing dependent on the usage property.
>>>
>>> ------------------------------
>>> "Distributor" signatures
>>>
>>> Distributor signatures would be the signatures currently 
>described by 
>>> [1] and support the goals (1) and (2) identified above.
>>
>> Right.
>>
>>> The distributor signature contains a reference element for 
>every file 
>>> in the widget archive, excluding any other signature files 
>>> (identified by a reserved filename pattern). The inclusion of a 
>>> reference element for every non-signature file is required 
>to ensure 
>>> that the authenticity and integrity of the entire widget 
>archive can 
>>> be verified.
>>
>> Right.
>>
>>> Other
>>> distributor signatures are excluded because they are only 
>used during 
>>> the installation of the widget and have their own inherent 
>mechanisms 
>>> for ensuring integrity and authenticity.
>>
>> Ok, but does this not leave the possibility that non-distributor 
>> signatures (e.g. Author's signature) could be removed by an 
>attacker. 
>> Does that matter?
>>
>>> I am not proposing any change to the distributor signature other
>>> than:
>>>
>>> (a) The definition of a "distributor" usage property value
>>>
>>> (b) A change to the signature generation rules, specifically to
>>> change:
>>>
>>> "Every file in a widget resource apart from any widget 
>signature MUST 
>>> have a corresponding XML Signature Reference contained in the 
>>> signature, generated according to the Reference Generation 
>section of 
>>> the [XMLDSIG11] specification."
>>>
>>> To
>>>
>>> "<change>If the widget signature includes the "distributor" usage 
>>> property, </change> every file in a widget resource apart from any 
>>> <change>"distributor"</change> widget signatures MUST have a 
>>> corresponding XML Signature Reference contained in the signature, 
>>> generated according to the Reference Generation section of the 
>>> [XMLDSIG11] specification".
>>
>> I'm ok with this as it does not seem to add any significant 
>processing 
>> or complexity.
>>
>>> (c) In the rules for verifying a widget signature, more 
>specifically 
>>> the part on reference verification, something like the following is
>>> needed:
>>>
>>> "If the widget signature contains the "distributor" usage property, 
>>> it MUST include a XML Signature Reference for every file in the 
>>> widget resource apart from any "distributor" widget signatures, as 
>>> identified by the widget signature name pattern for "distribution"
>>> signatures. If
>>> the widget archive contains a file for which there is no 
>>> corresponding Reference in the signature, the signature MUST be 
>>> treated as invalid."
>>
>> Seems ok, though it's a little repetitive given the text already you 
>> proposed above. I wonder if the two can be merged into one. If not, 
>> that's ok as they reinforce each other.
>>
>>> Note that even in the case that the processing was not dependent on 
>>> the usage property, a modified version of the above still 
>needs to be 
>>> added to the specification e.g.:
>>>
>>> "A widget signature MUST include a XML Signature Reference 
>for every 
>>> file in the widget resource apart from any widget signature, as 
>>> identified by the widget signature name pattern. If the widget 
>>> archive contains a file for which there is no corresponding 
>Reference 
>>> in the widget signature, the widget signature MUST be treated as 
>>> invalid."
>>
>> We will have to formally define the "signature name pattern" 
>in either 
>> the P&C spec or the Widgets dig sig spec (or both). I know 
>we already 
>> have, but we just need to be consistent with the terms.
>>
>>> ------------------------------
>>> "Update" or "Source" signature
>>>
>>> When looking at security for automatic updates [2], we identified 
>>> that there is no reliable way to verify that a widget archive that 
>>> claims to be an update of an installed widget resource is an 
>>> authorised update for that widget resource. While some 
>assurance can 
>>> be provided by the source of the update, this is limited 
>both by the 
>>> security of the mechanisms used and the trust placed in the source 
>>> (which may change over time).
>>
>> Correct.
>>
>>> 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.
>>
>>> We would obviously like to re-use the widget signature  
>>> specification to
>>> address this use case but there are some issues:
>>>
>>> * It is useful to generate "Distributor" signatures (as described  
>>> above)
>>> using a private key that is specific to a single widget 
>archive, i.e.
>>> the private key is used only once. This is useful in enabling widget
>>> revocation, but also in ensuring the security of the private keys  
>>> used
>>> (they are used once and then destroyed). In contrast an "Update"
>>> signature needs to be generated using a private key that has been  
>>> used
>>> before and would typically not be used for revocation of a widget
>>> (although it must still be possible to revoke the (key used to  
>>> generate)
>>> "update" signature itself).
>>
>> Is there any "prior art" that does this? This all sounds very fancy  
>> and
>> complicated. How it is that most pieces of modern software can get  
>> away with
>> performing updates without requiring all this extra infrastructure?  
>> In other
>> words, are you absolutely 100% sure we need all this?
>>
>>> * It would be useful for the "update" signature to be covered by the
>>> distributor signature so that the distributor can indicate that they
>>> approve of the source of future updates of the widget, however, this
>>> would not be possible given the current processing model.
>>
>> Well, it is covered in as far as the distributor signs the  
>> config.xml file,
>> which implies that they do endorse the update location.
>>
>>> * There should only be one "Update" signature per widget archive.
>>>
>>> To support "Update" signatures in [1] the following would be  
>>> required:
>>>
>>> (d) The definition of an "Update" usage property value
>>>
>>> (e) The addition of the something along the following lines to the
>>> signature generation rules:
>>>
>>> "If the widget signature includes the "update" usage property, every
>>> file in a widget resource apart from any "distribution" widget
>>> signatures MUST have a corresponding XML Signature Reference  
>>> contained
>>> in the signature, generated according to the Reference Generation
>>> section of the [XMLDSIG11] specification".
>>>
>>> (f) There would need to be a check before processing an "update"
>>> signature that there was only one "update" signature present in the
>>> widget archive.
>>>
>>> To make this processing cleaner it will probably be advisable to  
>>> define
>>> a widget signature name for each signature usage e.g.:
>>>
>>> distrubtion-dig-sig-filename = "signature" *[0-9] ".xml".
>>>
>>> update-dig-sig-filename = "update-signature.xml"
>>
>> Ok, makes sense as a way of making the process a bit more  
>> efficient... But
>> at the same time I'm left wondering why not just rely on the usage  
>> property.
>> The update signature could be identified on first run, and then  
>> somehow
>> stored.
>>
>>> Note that if the above is true then the verification of an "update"
>>> signature is exactly the same as for a "distribution" signature,  
>>> apart
>>> from the checking of the usage property, e.g. something like the
>>> following could be added:
>>>
>>> "If the widget signature contains the "update" usage property, it  
>>> MUST
>>> include a XML Signature Reference for every file in the widget  
>>> resource
>>> apart from any "distribution" widget signatures. If the widget  
>>> archive
>>> contains a file for which there is no corresponding Reference in the
>>> signature, the signature MUST be treated as invalid."
>>
>>
>> I have to say that I'm uncomfortable with the complexity of this  
>> proposal
>> thus far. However, I need some time to absorb it before making a  
>> proposal to
>> simplify it. That's my personal opinion, and if others are willing to
>> support it then I'll be happy to abstain and continue 
>working on this.
>>
>>
>>> ------------------------------
>>> Summary
>>>
>>> The above examples and proposed changes are provided to illustrate  
>>> how a
>>> small change to [1] could enable the specification to be re-used to
>>> address use-cases uncovered as both widgets and the specifications
>>> evolve. While we think that the "update" signature is a valid and
>>> compelling use case, and would like to see it at least discussed  
>>> further
>>> in WebApps, we are not necessarily pushing for its inclusion in  
>>> Widgets
>>> 1.0. We do however believe that it provides strong support 
>for making
>>> both the generation and verification of widget signatures  
>>> dependent on
>>> the usage property. This will involve relatively small 
>changes to [1]
>>> and it is, to our understanding, entirely compatible with 
>XML Digital
>>> Signatures.
>>>
>>> We look forward to any feedback you may have!
>>
>> Like I said, most of what you have proposed seems reasonable in  
>> regards to
>> [1]. In regards to [2], I think that needs further discussion  
>> within the
>> group.
>>
>>
>> Kind regards,
>> Marcos
>>
>>> [1] http://dev.w3.org/2006/waf/widgets-digsig/
>>> [2] http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html
>>> [3] http://www.w3.org/2009/01/08-wam-minutes.html
>

Received on Thursday, 12 February 2009 12:05:11 UTC