W3C home > Mailing lists > Public > public-appformats@w3.org > May 2008

Widgets 1.0: Digital Signature feedback

From: Michael Davey <md84419@googlemail.com>
Date: Tue, 6 May 2008 13:39:03 +0100
Message-ID: <c991517a0805060539w59d44f03j5492a2bf4f10e54a@mail.gmail.com>
To: public-appformats@w3.org

I have some comments on the "Widgets 1.0: Digital Signature" W3C
Working Draft 14 April 2008,
http://www.w3.org/TR/widgets-digsig/

1.  Section 4 describes a DigestMethod element and a SignatureMethod,
both with an Algorithm attribute.  The Auto Updates editor's draft
(http://dev.w3.org/2006/waf/auto-updates/Overview.src.html) specifies
a hash element with a method or type attribute.  The attributes are
specified in different ways.  I'd like to suggest that the
capitalisation, attribute names and attribute contents are consistent
between the two documents.  I understant that the auto updates
document is a very early draft.

2.  Ensure that it is possible for multiple companies to sign an
individual widget.  I have two suggestions for how one might achieve
this:

2.1.  Rename signiature.xml to be vendor.sig or vendor.xsf or similar.
 This would allow clients to quickly scan an archive for all files
matching a pattern to find the signiature files.

2.2.   The approach advocated by
<http://www.w3.org/TR/xmldsig-core/#sec-CoreValidation>, which is
(IIUIC): Put the <Reference elements inside a <Manifest element that
lives outside of <Signiature.  Allow multiple <Signiature elements.
Each <Signiature element has child elements that reference the files
listed in the <Manifest.

2.3.  In either case, the client would check each signature until it
finds a vendor it trusts.  It would then verify the widget using the
algorithm described in section 5.

2.4.  (Sections 5.4 and 5.5) Ideally this specification would allow
for different parts of the widget to be signed by different vendors
rather than requring that the whole widget is signed by a single
vendor.  This could be achieved by repeating my point #2.3 for the
remaining files until all signiatures have been checked.  If there are
still files remaining in the archive that haven't been verified then
the behaviour would be implementation (or possibly security policy)
dependant.

3. Section 5.6 describes the Procedure for Verifying a Digital
Signature.  The language should be changed so that the word "extract"
is removed.  I'd suggest something like (incorporating Thomas
Roessler's and Frederick Hirsch's text):

For each file entry in the widget resource, the DigestValue in
signiature.xml is compared against a digest calculated against the
file entry's decompressed representation (see Reference Validation
algorithm in [XMLDsig] for how to do this) .  Successful widget
signature validation requires verifying that the signiature.xml
includes a Reference element for every item in the widget resource and
that each Reference digest validates.  Successfull widget digital
signature verification additionally requires certificate chain
[...insert details...]

Care should be taken not to write the decompressed representation to
disk or otherwise treat the decompressed representation as valid and
trusted until the security checks have been successfully completed.
Need to add other security considerations here (eg protecting against
decompressed representations that are too large for the device to
handle).

4. Further to my point #2 above and feedback I'll provide shortly on
Widgets 1.0: Packaging and Configuration (that config.xml be required
to be the first item in a widget archive), I'd like to recommend that
the manifest information is moved from the signiature.xml file to the
config.xml file.  This simple change makes it much easier and more
efficient for implementors targetting embedded platforms.

Regards,
-- 
Michael Davey
Received on Wednesday, 7 May 2008 04:13:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 May 2008 04:13:54 GMT