- From: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
- Date: Thu, 12 Feb 2009 13:04:17 +0100
- To: "Arthur Barstow" <art.barstow@nokia.com>, "ext Marcos Caceres" <marcosscaceres@gmail.com>, "Thomas Roessler" <tlr@w3.org>, "Frederick Hirsch" <frederick.hirsch@nokia.com>, "public-webapps" <public-webapps@w3.org>
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