Re: Widgets 1.0: Digital Signature feedback

Hi Michael,

On Tue, May 6, 2008 at 10:39 PM, Michael Davey <md84419@googlemail.com> wrote:
>
> 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 understand that the auto updates
> document is a very early draft.

The current proposal supports both SHA-1 and MD5. From my own
experience, MD5 seems to be more commonly used by developers to hash
binary content (though I have no evidence to back this up). Also, I
can't guarantee that any of that stuff will be in there after I
re-write it... but if it is, your comments will be taken into
consideration.

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

I don't see how renaming a file would cause it to be found more
quickly/efficiently than our current approach? Also, both those file
extensions are already in public use, so it might add to the confusion
of what kind of file the signatures are. I prefer to keep the generic
and unassuming .xml file extension.

> 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 <Signature.  Allow multiple <Signature elements.
> Each <Signature element has child elements that reference the files
> listed in the <Manifest.

We had this in the spec previously [1], but we removed it for
simplicity and because no use cases were presented for it (and,
technically, because validation then occurs on the <manifest>'s
content, but not on the files, which defeats the purpose of core
validation... but that might just have been a problem with the way the
spec was written). I'm happy to bring back multiple signatures if
people want it.

Note, however, that the proposal we had originally was a bit different
from yours. If I am understanding correctly, in 2.1, you are
advocating distinct signatures (eg. one signed with a vendorA cert and
other signed with a vendorB cert?). Our original proposal was to allow
signatures to be signed, as implied by your point 2.2. The way we
proposed to do this was by putting incrementing each successive
signature with a number (ie. signature1.xml, signature2.xml).

So, if we want to bring back multiple signatures, what approach do we want?:

A. Sign the signature (signer-B signs signer-A's signature).
B. Sign the files twice (signer-A and signer-B's sign the resources,
but with different certs).

Note also that our current model allows for certificate chaining, but
I'm not 100% as to how that works in practice.

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

Right.

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

What's the use case for that? Seems like a rare edge case that would
add complexity.

> This could be achieved by repeating my point #2.3 for the
> remaining files until all signatures 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.

We have already reached a resolution that if any file is encountered
that is not signed, the the widget is treated as an invalid widget
archive (for security reasons: so files don't get sneaked into the
archive in transit). Having multiple security policies makes things
unnecessarily more complicated.

> 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
> signature.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 signature.xml
> includes a Reference element for every item in the widget resource and
> that each Reference digest validates.  Successful widget digital
> signature verification additionally requires certificate chain
> [...insert details...]

We simplified the text in the spec at the last F2F. We try to defer as
much as possible to XMLDigSig:

"The procedure for verifying a widget signature is to validate the XML
Signature according to [XMLDsig], including Reference digest
validation. Successful widget signature validation requires verifying
that the XML Signature includes a Reference element for every
decompressed representation of a file entry in the widget resource and
that each Reference hash validates. When general purpose bit 11 of the
local file header of a file entry is not set, then the value derived
from the file name field must be converted from [CP437] to [UTF-8]
when validating."

If a certificate chain is encountered, then user agents will behave as
specified in XMLDigSig. Like I said previously, it is unclear if we
need to make that explicit in the Widget-digsig spec.

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

I've added this as a note and an issue.

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

Although technically feasible, doing this would not work well with our
i18n model. The reason is that a widget can have multiple config.xml
files, so the signature would need to be repeated multiple times.

Kind regards,
Marcos

[1] http://www.w3.org/TR/2007/WD-widgets-20071013/
-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 27 May 2008 02:23:57 UTC