Re: Widgets 1.0: Digital Signature feedback

2008/5/27 Marcos Caceres <marcosscaceres@gmail.com>:
> 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.
> ...
> The current proposal supports both SHA-1 and MD5...

My point was that autoupdates looks like this:

<hash type="MD5">c1bcf9317ba200daeb7d64dc55c97fe95e02ab87</hash>

but digsig looks like this:

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>pq...56=</DigestValue>

<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
...
<SignatureValue>MC...LE=</SignatureValue>

> I'm happy to bring back multiple signatures if
> people want it.

We would certainly want it.  In the case where the OS/browser
provider, hardware/system integrator, operator and widget ISV are all
different companies it becomes a requirement.

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

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

B is much more flexible and additionally allows the specification to
be expanded in the future so that different organisations can sign
different parts of the widget.  In practice organisations are likely
to be uncomfortable with signing code they haven't written.  I don't
see that being in version 1 of the spec.

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

I understand.  Perhaps a solution that addresses both points would be
to have the manifest information in a separate manifest.xml file.  The
widget would then only have the one manifest file rather than the
information being repeated in each signiature file.  Reading the
XMLDsig spec, this seems to be an option.

Regards,
-- 
Michael

Received on Tuesday, 27 May 2008 09:27:44 UTC