[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 Wednesday, 4 February 2009 20:46:41 UTC