From: ext Marcos Caceres <[email protected]>
Date: January 27, 2009 5:56:19 AM EST
To: "Priestley, Mark, VF-Group" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [widgets] Comment on Widgets 1.0: Digital Signatures -
the Usage property
Archived-At: <http://www.w3.org/mid/C5A498D3.3E8C%
[email protected]>
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"
<[email protected]> 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
