Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property

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 Tuesday, 27 January 2009 15:51:21 UTC