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

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.

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]).
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. 

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.

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.

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. 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. 

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".

(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." 

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."

------------------------------
"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). 

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. 

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).

* 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. 

* 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"

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." 

------------------------------
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!

Thanks,

Mark

 

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

[2] http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html
<http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html>
<http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html
<http://dev.w3.org/2006/waf/widgets-updates/Overview.src.html> 

[3] http://www.w3.org/2009/01/08-wam-minutes.html
<http://www.w3.org/2009/01/08-wam-minutes.html>

Received on Monday, 26 January 2009 13:35:58 UTC